关于国内前端和JS技术发展的乱想

http://hax.iteye.com/blog/1128269 【2011-07-19 18:53】

玉伯在我的一条微博后面写了一些（和主题不是很相关但）非常值得思考的评论。而这些评论的源头来自于我非常尊敬的不在你们前端界混的JS大师愚公（爱民）。 


摘录如下： 

我想补充几点。 

至少在前端技术和JS语言上，我不认为我们的前端精英（比总是比最好的那一群）离最先进的技术有什么差距，半年也没有。甚至我们有许多东西是领跑世界的。 

比如最早的鼻祖级人物wch的JSVM，在JS包和命名空间管理、JS代码编译、单页应用框架方面，绝对是世界领先。最近这三方面的发展都非常活跃，但至少在上个世纪，wch就已经涉及了三方面的工作！ 

再如，在RequireJS风行之前，金大为做的JSI就已经达到了几乎所有RequireJS的功能。我认为至今也未见任何module管理方案对它有实质性的功能超越。 

还有，像传说中的月影mm在JS的函数式编程方面有大量创造性的研究，尖端程度肯定不输给underscore。 

又如，在UI组件方面，有非常多，一段时间里几乎所有大一点的团队都会自己做一套，虽然质量参差不齐，但敢说其中没有能与当时的ExtJS比肩的？ 

还有，著名的51js社区，在上面有大量非常有创意和技术的脚本和产品。 

还有不得不提的小盆友infinte（现在叫belleveinvis），他两次在D2上展示了他做的编译器和语言设计方面的尝试，我认为在这个方面，技术上已经不存在任何距离（当然有其他问题，下面再说）。 



那么问题出在哪里？为什么这么多好东西都湮没了？ 


玉伯提到的是企业和团队存在问题。我相信这是很重要的方面，但是我认为这不是核心问题。 


我大略分析几个案例： 

JSVM的问题是，他太庞杂了，并且错误选择了java风格，其名字也有误导，后来再做调整也无济于事了。但最最关键的是，当时还是前ajax时代。JSVM生不逢时。 

金大为的JSI的问题也部分是，有一定的超前度，代码模块管理的优点和必要性在几年前还没有在国内得到普遍认知。另外老金太低调，宣传太不够（偶倒是到处提到，不过没有原创者来推广总是不够）。老金要成，必须走出去，把自己做成标准才行，可惜的是这个时间已经错过了。 

这就提到一个问题，酒香也怕巷子深。我们许多人只会关起门来写代码，出来交流得太少。这有一个原因是国内的前端技术交流会议太少，且只集中在北京和杭州。这个问题现在稍有改善，但各种会议交流还是不够丰富和多样化。这方面w3ctech做了一些努力，希望能有改善。 


但最主要的问题，我觉得是，我们有非常出色的顶尖牛人，水平是世界级的，但是社区是与世界是脱节的。 

这个一个是语言因素。本人也深受其累。无他，唯尝试耳。写出文档文法词法狗屁不通，管他呢，先弄出去，态度要好，将来找英语好的同志（或者直接老外）帮忙就是了。 

另一个是心态问题，就是不够开放，不够主动。你要主动参与到世界性社区里。因为语言和技术是没有国界的。 


同样是是模块、包管理、loader之类的，为什么SeaJS现在势头就不错？【最近几个明显无法通过面试的小朋友也都知道seajs了】 


几个原因： 

1. 整个国内社区对这块的认识上来了 

2. 玉伯同志在社区的号召力比较强，并主动出来介绍 

3. 玉伯的文档不错，国际化程度高 

4. SeaJS的质量好 

注意这个质量好，并不是指代码实现质量高（当然seajs可能实现质量确实也不错），而是我们最缺的一块，就是API接口的质量高。 

这个从哪里来呢？我们就注意到了，SeaJS是站在社区规范上的，即CommonJS规范，且API基本照抄FlyJS，站在巨人的肩膀上了。 


这是非常大的进步。 


我们最大的缺点是老是敝帚自珍。这本身其实也没错，重造轮子也ok。但你必须吸收前人的好东西。特别是接口上，规范上。这个是关键的关键。这也是SeaJS胜过当年JSI的最大优点。 


5. 专注 

我可以断言，现在在大的框架上要出头已经没有前景（这也是qwrap要面临的问题），jQuery是事实标准，YUI/MooTools/Dojo/ExtJS等瓜分了剩下的地盘，昔年的Prototype/MochiKit已经日落西山，任何一个新的大而全的框架（走出企业团队以外）已经没有任何机会【除非有突破性的地方，像当前selector改变书写方式那样，这个几乎不可能再有】。除非在专门领域如移动开发方面，才有一点点空间（但也马上将被前述大框架瓜分完毕——毕竟这是应有之义，移动web开发仍然是web开发，应该被统一起来）。 

但是现在前端和JS方面确是前所未有的欣欣向荣，大量专注解决单一方面问题的库涌现出来，可以到microjs上去看一看，就会发现了。 

实际上，在module方面的推进是非常重要的，目前基本上已经被统一到几个方向（也就是事实标准），即CommonJS 1.0规范（如nodejs），AMD等。 

当module体系能稳定下来后，整个系统的生态将一下子被激活。NodeJS社区的蓬勃发展，与此不无关联。 

可以预见，这个趋势会越来越明显。 


因此，我可以说，只要我们顺应这个潮流，做到： 
1. 心态开放 
2. 融入社区 
3. 国际化 
4. 专注 

做出好东西并能持续成功的可能性将会很高。 



另外，心态方面，还有一点，其实不必考虑所有的东西都要有巨大市场，那样太功利，太功利往往反而束缚了自己。 

比如 老赵jscex / 小盆友的编译器 / qobean 等，由于种种原因注定是小众，并且注定是过渡性产物【具体不赘述，有机会再阐述】，即研究和尝试性质更大。不是说不能产品化实用化，但是不要包过高的期望。将来有新东西超越、吸收、融合你的东西几乎是必然的，也应该是乐见此事。比如jscex的async语义已经在ES harmony的proposol里，这是一件很好的事情，虽然这也宣布了jscex的寿命最长就活到harmony定案。小盆友的编译器也是，coffeescript非常火——已经前有珠玉，怎么能做到更好？几乎是不可能的，只有做好自我定位，专注在某个方向上，或者干脆就是研究性质的，说不定未来就能结出果实。 



再补充一个重要的问题。 

如果要产品化，特别是通用化，我认为考虑标准是及其重要的。这个标准，不仅是指现在已经有的纸面标准，而是要考虑标准的方向。 

比方说过去大量的js库都是建立在一个小的方法集上的。但是新的库就应该注重base在ES5标准上。因为这是方向。不仅是纸面标准，而且也一定会是事实标准。在JS生存10年之后，我们必须认清楚，现在是一个跨越，就是开发者的baseline即将或已经提升到了ES5（比如nodejs上的开发社区），而不是之前残疾的ES3。 

社区精英们，应该集中力量到如何在ES5基础上构建自己的库，而不要再浪费时间在那些无谓兼容性上。因为开发者即将以ES5为baseline，你再提供某些和es5重复的部分是没有意义的。所有那些用到元编程或OO或类似方向尝试的，都应该考虑如何建立在ES5的语义基础上，若能考虑到harmony的方向，甚至参与进去就更好了。 

Traits.js就是这样一个例子。作为又一种OO增强，问题不在于traits如何比其他mixins方案好，甚至traits这个模式本身就有其他的js实现，关键在于Traits.js很好的match了ES5，也就是，它是ES3/5的语义增强，而不是自创体系。经过ES4的分歧之后，从ES3到ES5到Harmony，认识逐渐统一到尽量是充分利用到已有设施，并增强之，而不是单纯添加特性。库开发者也应有这个认识。 


当然ES5这个baseline，是需要建立的，这就需要有库能把legacy浏览器弥补好。现在这个方向做的最好的是es5-shim。但是说实话，它真的还不够好。这块是有机会的，如果国内js高手们能联合起来，专注于这一个方向上做出世界级的库，绝不是天方夜谭。 


另外一个我认为非常广阔的领域是dom。是的，始终是。 

尽管我之前说过了，大框架没有机会。但是注意到一点，jQuery等仍然是建立在前ES5前HTML5时代的。因此那些库其实都干了大量重复的事情。真正有益的是把这些事情做一次，做好它，怎么做好？不是发明各种自己的api，而是大家努力按照html5的规范，去尽量实现一套一致的符合html5语义的底层dom api。 

然后大家自由在这个api上去发展自己的各种特色库，且这些特色库可以只解决他们该解决的问题（封装高级功能，解决易用性问题等），并且所有这些库可以很好的协作融合——而这需要三点配合：编程语言模块机制、编程语言的基础API、dom基础API。 

seajs是第一点（但还有提升余地），es5-shim是第二点（做得还不够好，空间大大），第三点也已有大量尝试（未开垦领域太多了）。 


我个人认为qwrap的思路与我讲的所有理念是match的。但是似乎没有那么明确。只是说解决一个API风格问题是不够的，大家其实不太关心这个。包括高级的函数式编程会吓走一些人。类似traits的构建方式其实更友好。另外如我之前所说，qwrap的baseline还是旧的模式。 

一个可比的例子是qobean，它只用js的一个子集构建系统，但是那是一个元编程的实验性项目，所以无所谓。qwrap也只从一个基本的函数式变换构建出来，这值得骄傲，但是仅此并不提供生产力价值。 


开发者其实并不会纠结于你的Array上的map/reduce等方法是静态方法变换而来。【也许会关心是否能将这些方法变换到dom collection上】，可裁剪、定制、转换……都只在baseline以上才有意义。 

所以我个人提供一个思路，供jk、月影等qwrap的同志参考： 

可将qwrap拆分成几个项目（代码上估计已经拆分了，但建议在项目体系上拆分）： 

0. JS module system 
何种形式暂未想好。我个人对seajs不是最满意，qwrap下的未仔细研究。 

1. 补齐es5 baseline的库 
这一部分用何种机制实现并不重要，我个人倾向于避免依赖过于复杂的函数变换。这一部分的目标并非好看，或者实现精巧，这一部分的最关键的目标是实现一个好的baseline： 
A. 正确性，最大限度符合es5标准 
B. 高效 

2. 核心的函数变换是独立的库，不必跟浏览器挂钩，到处可用。整成像underscore那样，说不定在nodejs上就火了！ 

3. JS语言增强库。长什么样无所谓。其实这块最好就是百花齐放的。所以qwrap现在做的库只是其中一个选择而已。这里在0和2的帮助下，应该尽量做成可独立使用的小模块。之间的依赖性越小越好（也就是只依赖0,1,2，互相间无依赖）。 

以上是JS，下面是DOM 

4. 补齐 html5 DOM baseline的库 
以html5规范和语义为准。时刻记得避免夹带私货。此库的最高境界是只作为给浏览器打patch用，也就是一个patch框架加patch实现。此方面技术实现难度和方式都有待研究。不一定是光用函数变换或者traits之类的能解决的，有大量的坑。依赖何种JS库不重要。 

5. 基于4的包装库。实际上等价于基于html5开发一个库。此方面大家萝卜青菜各有所爱无所谓了。 


所以，qwrap这一整个大框架，其实我觉得拆得四分五裂，每一个都叫不同的名字，可以分别发展团队，才是最有前途的。哈哈哈。 


以上这些就是最近一段时间来想法的大致总结，由玉伯引用爱民的评论开始，后面就逐渐离题了，不过无所谓了，能引起大家的思考就好了。