关于国内前端和JS技术发展的乱想
玉伯在我的一条微博后面写了一些（和主题不是很相关但）非常值得思考的评论。而这些评论的源头来自于我非常尊敬的不在你们前端界混的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的分歧之后，从E