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

标签: 国内 前端 js | 发表时间:2011-07-19 18:53 | 作者:(author unknown) blankyao
出处:http://hax.iteye.com
玉伯在我的一条微博后面写了一些(和主题不是很相关但)非常值得思考的评论。而这些评论的源头来自于我非常尊敬的不在你们前端界混的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这一整个大框架,其实我觉得拆得四分五裂,每一个都叫不同的名字,可以分别发展团队,才是最有前途的。哈哈哈。


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






已有 20 人发表留言,猛击->>这里<<-参与讨论


ITeye推荐



相关 [国内 前端 js] 推荐:

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

- blankyao - hax的技术部落格
玉伯在我的一条微博后面写了一些(和主题不是很相关但)非常值得思考的评论. 而这些评论的源头来自于我非常尊敬的不在你们前端界混的JS大师愚公(爱民). 想起愚公的一番言论:我们做了一个不错的东西,有很多好的 IDEA. 最终这些东西却消散了,变成了另外一些更大更好的东西的局部. 我们——我指的是国内的软件开发的现状——什么“好”的东西也做不出来.

网易前端云课堂,JavaScript程序设计:JS调试

- - CSDN博客推荐文章
本节主要通过一个加法器,介绍JS如何调试. 计算器
. . 1,一般调试JS,打印信息有如下三种:. a,用alert,缺点是每次都弹框. b,用console.log,这个数据量小还可以.

页面构建和js前端不得不说的那点事儿

- - 微博UDC
作为微博的页面构建工程师,主要职责就是利用html&css,高质量的完成静态页面的制作,保证项目的按时完成. 而页面需要的js效果则交给下游的js前端工程师去做. 但在大家的思维定势里可能觉得这两个岗位应由一个人来完成最好,毕竟,页面构建工程师写的html结构不一定是js工程师想要的那种,js工程师可能有更高效的方式.

WebView JS 交互

- - ITeye博客
WebView加jquery做页面会怎么样呢. // 创建WebView对象. // 把programList添加到js的全局对象window中,. // 这样就可以使用window.programList来获取数据. * 定义js回调java函数. // 绑定键盘的向上,向下按钮事件触发相应的js事件.

JS游戏引擎

- 米随随 - HTML5研究小组
If you don’t have anything better to do and want to help fellow redditors interested in JS game dev out, feel free to fork the list and modify it as you like.

來源請求.js

- 红烧鲤鱼 - Blog: timdream
很早以前就想講了,但講了大概又會被戰. 相較於英文維基百科,中文維基百科在社會和歷史條目充滿了 systemic bias. 但是那些主觀論述又不是編輯者有意加進去的,而是某種編輯者存在的社會所給予的暗示(Inception?)與集體共識,而不是原本百科全書應該有的可驗證的事實. 因為是暗示又是共識,所以有自覺的百科編輯者反而是少數;中文維基只好長成現在這個樣子了.

Js删除节点

- - JavaScript - Web前端 - ITeye博客
 方式一:传this参数调用方法:.  方式二:js方法中通过选择器获取节点:. //此处删除的是a节点 }. 方式三:通过jQuery方式获取节点:(尚未测试,有待测试. 此处a标签传this到js中,js通过this(即a节点)取parent(即p节点). (1)p.remove();可直接删除整个p节点.

JS游戏引擎列表

- sku - 酷壳 - CoolShell.cn
这里有一个网址收集了关于JS游戏引擎开发库的一个列表,转过来. 关于使用JS和HTML5做的一些小游戏,可参见《HTML5 小游戏展示》. Name Latest Release License Type Notes The Render Engine 1.5.3 MIT 跨浏览器; 大规模 API; 开源. 2 gameQuery 0.5.1 CC BY-SA 2.5 和 jQuery 一起使用 gTile 0.0.1 Tile based.

Deck JS: HTML5 幻灯片

- L - LinuxTOY
Deck.js 是一组开源的 JavaScript 类库,方便使用现代的 HTML5/CSS3/JS 技术创建幻灯片. 该软件十分适用于开源项目介绍,交互式的方式比单纯的文字说明更简洁易懂. 不废话了,赶紧前往该项目主页去体验 HTML5 时代的幻灯片吧. 分类: Productivity |. 收藏到 del.icio.us |.