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

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

Tagged: , , ,

Comments are closed.