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

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


摘录如下：

玉伯也叫射雕 写道

想起愚公的一番言论：我们做了一个不错的东西，有很多好的 IDEA。最终这些东西却消散了，变成了另外一些更大更好的东西的局部。我们的努力白费了。我们的成果湮没了。我们——我指的是国内的软件开发的现状——什么“好”的东西也做不出来。
其根本的原因并不是我们技术不行，开发能力不好，或者投入不够多。老老实实地讲，这些我们都不会承认。我以前就一直说：我们离最先进的技术的差距只有半年。我们并不差多少，在一个问题上努力耕耘半年，我们就会变成顶尖的好手。但是，接下来我们仍然会白费、湮没，以至于消失得无影无踪。
kissy 也好，qwrap 也好，jet 也好，都面临这样一个问题。

我想补充几点。

至少在前端技术和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这一整个大框架，其实我觉得拆得四分五裂，每一个都叫不同的名字，可以分别发展团队，才是最有前途的。哈哈哈。


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

评论

22 楼 mike8625 2015-06-12  

说的都是给大公司听的,国内很多还是小公司,做个小项目, 说实话什么框架不用最省事.

21 楼 xueduanyang 2014-01-18  

我是水羊，年轻的时候觉得只要有好斧子就能做成好产品，各种产品都有用过，最崇拜jsi，ui工具上确实大家各自发展每个公司都有自己一套标准，甚至我自己都搞了一个kitjs，中国前端能人还是很多的，但是很多时候不是不团结的问题 是没法团结的问题
hax说的问题从web前端层面推广是一个好办法，但是就我自己遇到的问题更多是被各种前端无法实现的功能或者兼容性在坑，说句实话web技术发展已经远远落后同类其他语言的功能类库发展了，很多东西，app能做，c能做，就js不能做，能做也有各种问题，hax对于我遇到的这种问题怎么看？

20 楼 EvanTre 2013-04-20  

“最近几个明显无法通过面试的小朋友也都知道seajs了”看到这句话的时候，深深中了一枪

19 楼 fugees 2011-08-02  

讲了这么多有些确实很有道理，以开放的心态更开放的社区才能走的更远。毕竟上面提到的几个大牛水平确实有世界级。

18 楼 lin04com 2011-07-30  

分析的很不错，不过里面有的东西对我来说太深了。

17 楼 jkisjk 2011-07-24  

已发了一篇blog回应hax的建议：http://www.cnblogs.com/jkisjk/archive/2011/07/24/about_hax_advice.html
主要内容：
回到“在融入社区与国际化这两点上，QWrap几乎零分”这个问题点上来，我们之前把推广放在了第三阶段，这种阶段分法的确需要重新检讨一下。在试用阶段完全有必要开始融入社区，进行国际化。
Hax的建议之后，也开始在社区上加力了。目前已注册了QWrap新浪微博，也在寻找合适的同学在twitter或其它国际性社区与团体进行宣传，这也牵涉到国际化，QWrap网站上也会很快加一个英文介绍（现在只有中文介绍）。
所谓的“出口转内销是不二法门”的很现实，现实得心理有点适应不过来，但是也需要认真对待。
Hax的“心态开放”，我想应该是虚心学习的意思吧，这个是必然应该的，努力中。至于第四条“专注”，这一个在分析专门针对QWrap的建议时讲到。
。。。。。。。

16 楼 est 2011-07-22  

51js。。。好遥远的回忆

15 楼 pku2011 2011-07-22  

14 楼 kimmking 2011-07-21  

damoqiongqiu 写道

EXT粉淡淡路过，支持JSVM

提到的东西，都有接触。
也和其中的几个作者聊过。

虽然很早就不怎么关注前端了，但是对hax的话，认识很深。

13 楼 damoqiongqiu 2011-07-21  

EXT粉淡淡路过，支持JSVM

12 楼 hax 2011-07-21  

luolonghao 写道

想法很好，不过补齐标准库有时候很难，比如在IE6-8下实现标准Range接口，标准里的commonAncestorContainer是一个属性，如果在JS里也做成属性，每次改变Range都要重新计算所以性能很差，还有outerHTML之类的应该不能实现吧。

Range暂未研究过。outerHTML本来就有，如果要patch，也是有可能实现的。IE8+支持对DOM prototype定义get/set。IE8-可用htc。

11 楼 luolonghao 2011-07-20  

想法很好，不过补齐标准库有时候很难，比如在IE6-8下实现标准Range接口，标准里的commonAncestorContainer是一个属性，如果在JS里也做成属性，每次改变Range都要重新计算所以性能很差，还有outerHTML之类的应该不能实现吧。

10 楼 houfeng0923 2011-07-20  

楼主博文有深度。学习。

9 楼 庄表伟 2011-07-20  

写得很好！

另外对ITEye出现越来越多的“见人就踩”，表示严重失望！

8 楼 dulao5 2011-07-20  

对大势分析的很棒.
标准和规范, 是聚合了众多高手的思想的, 朝这个方向发展的确是正确的选择, 是避免被淘汰, 避免在升级浏览器之后被抛弃的选择.

特别是html5, 做个支持html5标准的js库, 支持在退化的浏览器内仍然能使用html5, 这是一个很诱人的方向.

7 楼 cly84920 2011-07-20  

一半的内容没看懂，提到的几个国内原创的js库一个也没用过，惭愧。我想我应该代表了很大的一个前端工程师群体吧——一方面对知名度不是那么国际化的东西不敢去用，另一方面如果没有切实地听说到这些新东西对我的工作有实质性帮助，我甚至懒得去了解。

我同意hax文中的几个观点：

1） 我们的工程师太低调了，做出了东西却羞于出来宣传，最后东西只能自己孤芳自赏，挺可惜的，这个不怪工程师本人，一方面因为交流的机会不多，没有多少宣传机会，另一方面也因为中国人传统美德中有个“谦虚”，这一谦虚吧，也不知道谦到什么程度是个度，不谦吧让人说不低调，谦吧一谦就谦到没人听得到声响了，这个也有点纠结啊;

2） 做的东西的关注点不宜大而全。国内很多公司的团队喜欢重复开发大而全的js库，类似jquery、YUI之类的，语言底层，UI组件全都自己去开发一套，其实这样真的很难吸引公司外部的人去使用，有jquery了，有YUI了我干嘛还要去用你的东西？别说公司外部了，公司内部推广都会遇到很大阻力吧？我曾经很不解地问过某家公司“坚持自己开发框架”的工程师，为什么要自己重复造轮子呢？得到的答案是“用别人的框架，代码不可控，如果代码有漏洞就危险了，如果是自己的代码就会好维护多了”，我觉得这答案也太牵强了，你用一个很小众的js框架的话，的确很可能有这种问题，但如果是jquery、YUI这种级别的js框架，我觉得他出错的概率比自己开发一套框架出错的机率要小得多，更何况全世界已经有这么多公司在用了，其中绝不乏一些超级公司，为什么别人都能用我们就不能用了？重复造轮子除了能向外证明“公司有开发自己框架的实力”这种面子工程外，好处实在有限。如果觉得开源的js框架在UI组件上定制性不合用，没问题，你可以基于他们再自己封装一层自己公司的定制的UI组件库嘛。

   既然重复造轮子没什么大用处，那做什么是正途呢？可以将注意力关注到一些别的地方啊，比如说软件开发过程的改善上，例如javascriptMVC就是一个很好的例子，他自己不关注和页面的底层交互了，把那个交给jquery了，自己关注于如何开发一个js工程，类似rails和django那样，我提供一个命令行，工程的新建从命令行开始，一行命令整个工程的目录结构都搭好了，然后我将mvc的角色划分好，测试工具准备好...这种思路的js库关注点就不再去抢红海了吧？这里不说javascriptMVC是否就是一种很好的解决方案，但这种思路是可以借鉴的，绕开红海，另外再去做些别的领域的开拓。这种思路的东西才是真正有益于整个行业，真正造福于人的。

   我们需要的不是微创新，我们需要的是创新，有精力就做点思路不一样的东西吧。

  

6 楼 lwkyykk 2011-07-20  

对es5为baseline我也有同样的看法，最近在写的小东西，完全是从这个观点出发，对于不支持es5的一些浏览器直接污染原始对象的方式补上，没有必要再像以前那样在自己的库中实现个each之类的方法了，原生挺好。

seajs我深入的研究过，代码的质量上挺不错的，但对于当前JS的URL的获取上花了大量的行数以及曲折的过程，我尝试着查找更好的方法。

by asins

5 楼 chaoslee 2011-07-19  

嗯，，函数变换是qwrap的一个亮点，，也是代码组织的形式。。

核心仍然是做为javascript语言的一种内部dsl，链式操作方便的解决了dom对象装配这一领域问题。

而jk大大写的css选择器，是解决dom树检索这个领域问题的外部dsl。


而这些的组织形式呢，就是用月影大大的函数变换了，无论是gsetter还是methodize，都让人眼前一亮。

qwrap做为一个js库来说，是非常优雅且实用的，，目前来说，组件，社区，文档各方面，还是稍稍欠缺的。

4 楼 qgy18 2011-07-19  

代转JK的回复，他刚注册iteye用户，需要明天才能回复：

赞，辛苦hax了。很多建议，都需要仔细的领悟吸收下，先粗略的说一些临时的想法，周末时再写一篇文章详尽回复。

关于"module管理"：
QWrap现在已经有一个module.h.js，简略介绍在这里有http://www.cnblogs.com/jkisjk/archive/2011/04/15/qwrap_apps_seed_youa.html
它现在还只是一个可用的版本，没有精细。
精细的话，也会承袭目前的几个接口。到时可以替换这个（就像用简版selector替换强大版selector一样，Apps机制有这种灵活性），

关于"函数变换"：
很多同学是因为函数变换才来了解QWrap，以至外面所传说的，QWrap的核心是函数变换。其实函数变换只是一个手段，不是核心。
我也很怕函数变换这个高门槛的东东成为QWrap的代言，所以我写了一系列文章来解释Helper + Wrap + Retouch + Apps。
尽管如此，那一系列文章也是写给javascript熟手门用的，而不是真正需要框架的用户。
希望先有一批行内人士了解，由经得起剪熬的人来吃螃蟹，再向那些需要食物的人推荐。
这也许是一个怪圈，我一直在说：“用户不需要了解这些”，却一直说了很多“为什么会有这些”，反省中。

关于"补齐es5 baseline的库"：
这个就是系列的Helper，以及对应的Retouch。
它们的效率是可以经过考验的。

关于“核心的函数变换是独立的库”:
函数变换，现在只有有限的四五个方法，实际使用得少的，我们已经去掉了，或是放在dev的目录下。dev目录是用来存放弱推荐或备用的东西

关于“JS语言增强库”：
QWrap一直在少依赖少耦合上很努力。这也是QWrap的初衷之一：让组件开发者依赖QWrap开发，但是发布出无依赖的组件。

关于“补齐 html5 DOM baseline的库 ”
现分成NodeH、EventTargetH、JssH等几个。

。。。。。

更多内容，周末我再写篇文章详述吧。。。。
感谢hax，我得好好理一下自己的思路。

3 楼 lovevfp 2011-07-19  

永远不缺高手。
而且强中必有强中手。

但是高手又怎么样，不愿意分享，不乐于分享，只是为了自己出名而分享，一切都是虚度呀，这就是大环境的情况。

不愿意分享的人太多，仅仅是为了出名而分享的人太多了，这就是现状。

除非能够改变这一现状，恐怕才能真正解决很多问题。