關(guān)于國(guó)內(nèi)前端和JS技術(shù)發(fā)展的亂想
玉伯在我的一條微博后面寫了一些(和主題不是很相關(guān)但)非常值得思考的評(píng)論。而這些評(píng)論的源頭來(lái)自于我非常尊敬的不在你們前端界混的JS大師愚公(愛民)。
摘錄如下：
玉伯也叫射雕 寫道
想起愚公的一番言論：我們做了一個(gè)不錯(cuò)的東西，有很多好的 IDEA。最終這些東西卻消散了，變成了另外一些更大更好的東西的局部。我們的努力白費(fèi)了。我們的成果湮沒了。我們——我指的是國(guó)內(nèi)的軟件開發(fā)的現(xiàn)狀——什么“好”的東西也做不出來(lái)。
其根本的原因并不是我們技術(shù)不行，開發(fā)能力不好，或者投入不夠多。老老實(shí)實(shí)地講，這些我們都不會(huì)承認(rèn)。我以前就一直說(shuō)：我們離最先進(jìn)的技術(shù)的差距只有半年。我們并不差多少，在一個(gè)問題上努力耕耘半年，我們就會(huì)變成頂尖的好手。但是，接下來(lái)我們?nèi)匀粫?huì)白費(fèi)、湮沒，以至于消失得無(wú)影無(wú)蹤。
kissy 也好，qwrap 也好，jet 也好，都面臨這樣一個(gè)問題。
我想補(bǔ)充幾點(diǎn)。
至少在前端技術(shù)和JS語(yǔ)言上，我不認(rèn)為我們的前端精英(比總是比最好的那一群)離最先進(jìn)的技術(shù)有什么差距，半年也沒有。甚至我們有許多東西是領(lǐng)跑世界的。
比如最早的鼻祖級(jí)人物wch的JSVM，在JS包和命名空間管理、JS代碼編譯、單頁(yè)應(yīng)用框架方面，絕對(duì)是世界領(lǐng)先。最近這三方面的發(fā)展都非常活躍，但至少在上個(gè)世紀(jì)，wch就已經(jīng)涉及了三方面的工作!
再如，在RequireJS風(fēng)行之前，金大為做的JSI就已經(jīng)達(dá)到了幾乎所有RequireJS的功能。我認(rèn)為至今也未見任何module管理方案對(duì)它有實(shí)質(zhì)性的功能超越。
還有，像傳說(shuō)中的月影mm在JS的函數(shù)式編程方面有大量創(chuàng)造性的研究，尖端程度肯定不輸給underscore。
又如，在UI組件方面，有非常多，一段時(shí)間里幾乎所有大一點(diǎn)的團(tuán)隊(duì)都會(huì)自己做一套，雖然質(zhì)量參差不齊，但敢說(shuō)其中沒有能與當(dāng)時(shí)的ExtJS比肩的?
還有，著名的51js社區(qū)，在上面有大量非常有創(chuàng)意和技術(shù)的腳本和產(chǎn)品。
還有不得不提的小盆友infinte(現(xiàn)在叫belleveinvis)，他兩次在D2上展示了他做的編譯器和語(yǔ)言設(shè)計(jì)方面的嘗試，我認(rèn)為在這個(gè)方面，技術(shù)上已經(jīng)不存在任何距離(當(dāng)然有其他問題，下面再說(shuō))。
那么問題出在哪里?為什么這么多好東西都湮沒了?
玉伯提到的是企業(yè)和團(tuán)隊(duì)存在問題。我相信這是很重要的方面，但是我認(rèn)為這不是核心問題。
我大略分析幾個(gè)案例：
JSVM的問題是，他太龐雜了，并且錯(cuò)誤選擇了java風(fēng)格，其名字也有誤導(dǎo)，后來(lái)再做調(diào)整也無(wú)濟(jì)于事了。但最最關(guān)鍵的是，當(dāng)時(shí)還是前ajax時(shí)代。JSVM生不逢時(shí)。
金大為的JSI的問題也部分是，有一定的超前度，代碼模塊管理的優(yōu)點(diǎn)和必要性在幾年前還沒有在國(guó)內(nèi)得到普遍認(rèn)知。另外老金太低調(diào)，宣傳太不夠(偶倒是到處提到，不過(guò)沒有原創(chuàng)者來(lái)推廣總是不夠)。老金要成，必須走出去，把自己做成標(biāo)準(zhǔn)才行，可惜的是這個(gè)時(shí)間已經(jīng)錯(cuò)過(guò)了。
這就提到一個(gè)問題，酒香也怕巷子深。我們?cè)S多人只會(huì)關(guān)起門來(lái)寫代碼，出來(lái)交流得太少。這有一個(gè)原因是國(guó)內(nèi)的前端技術(shù)交流會(huì)議太少，且只集中在北京和杭州。這個(gè)問題現(xiàn)在稍有改善，但各種會(huì)議交流還是不夠豐富和多樣化。這方面w3ctech做了一些努力，希望能有改善。
但最主要的問題，我覺得是，我們有非常出色的頂尖牛人，水平是世界級(jí)的，但是社區(qū)是與世界是脫節(jié)的。
這個(gè)一個(gè)是語(yǔ)言因素。本人也深受其累。無(wú)他，唯嘗試耳。寫出文檔文法詞法狗屁不通，管他呢，先弄出去，態(tài)度要好，將來(lái)找英語(yǔ)好的同志(或者直接老外)幫忙就是了。
另一個(gè)是心態(tài)問題，就是不夠開放，不夠主動(dòng)。你要主動(dòng)參與到世界性社區(qū)里。因?yàn)檎Z(yǔ)言和技術(shù)是沒有國(guó)界的。
同樣是是模塊、包管理、loader之類的，為什么SeaJS現(xiàn)在勢(shì)頭就不錯(cuò)?【最近幾個(gè)明顯無(wú)法通過(guò)面試的小朋友也都知道seajs了】
幾個(gè)原因：
1. 整個(gè)國(guó)內(nèi)社區(qū)對(duì)這塊的認(rèn)識(shí)上來(lái)了
2. 玉伯同志在社區(qū)的號(hào)召力比較強(qiáng)，并主動(dòng)出來(lái)介紹
3. 玉伯的文檔不錯(cuò)，國(guó)際化程度高
4. SeaJS的質(zhì)量好
注意這個(gè)質(zhì)量好，并不是指代碼實(shí)現(xiàn)質(zhì)量高(當(dāng)然seajs可能實(shí)現(xiàn)質(zhì)量確實(shí)也不錯(cuò))，而是我們最缺的一塊，就是API接口的質(zhì)量高。
這個(gè)從哪里來(lái)呢?我們就注意到了，SeaJS是站在社區(qū)規(guī)范上的，即CommonJS規(guī)范，且API基本照抄FlyJS，站在巨人的肩膀上了。
這是非常大的進(jìn)步。
我們最大的缺點(diǎn)是老是敝帚自珍。這本身其實(shí)也沒錯(cuò)，重造輪子也ok。但你必須吸收前人的好東西。特別是接口上，規(guī)范上。這個(gè)是關(guān)鍵的關(guān)鍵。這也是SeaJS勝過(guò)當(dāng)年JSI的最大優(yōu)點(diǎn)。
5. 專注
我可以斷言，現(xiàn)在在大的框架上要出頭已經(jīng)沒有前景(這也是qwrap要面臨的問題)，jQuery是事實(shí)標(biāo)準(zhǔn)，YUI/MooTools/Dojo/ExtJS等瓜分了剩下的地盤，昔年的Prototype/MochiKit已經(jīng)日落西山，任何一個(gè)新的大而全的框架(走出企業(yè)團(tuán)隊(duì)以外)已經(jīng)沒有任何機(jī)會(huì)【除非有突破性的地方，像當(dāng)前selector改變書寫方式那樣，這個(gè)幾乎不可能再有】。除非在專門領(lǐng)域如移動(dòng)開發(fā)方面，才有一點(diǎn)點(diǎn)空間(但也馬上將被前述大框架瓜分完畢——畢竟這是應(yīng)有之義，移動(dòng)web開發(fā)仍然是web開發(fā)，應(yīng)該被統(tǒng)一起來(lái))。
但是現(xiàn)在前端和JS方面確是前所未有的欣欣向榮，大量專注解決單一方面問題的庫(kù)涌現(xiàn)出來(lái)，可以到microjs上去看一看，就會(huì)發(fā)現(xiàn)了。
實(shí)際上，在module方面的推進(jìn)是非常重要的，目前基本上已經(jīng)被統(tǒng)一到幾個(gè)方向(也就是事實(shí)標(biāo)準(zhǔn))，即CommonJS 1.0規(guī)范(如nodejs)，AMD等。
當(dāng)module體系能穩(wěn)定下來(lái)后，整個(gè)系統(tǒng)的生態(tài)將一下子被激活。NodeJS社區(qū)的蓬勃發(fā)展，與此不無(wú)關(guān)聯(lián)。
可以預(yù)見，這個(gè)趨勢(shì)會(huì)越來(lái)越明顯。
因此，我可以說(shuō)，只要我們順應(yīng)這個(gè)潮流，做到：
1. 心態(tài)開放
2. 融入社區(qū)
3. 國(guó)際化
4. 專注
做出好東西并能持續(xù)成功的可能性將會(huì)很高。
另外，心態(tài)方面，還有一點(diǎn)，其實(shí)不必考慮所有的東西都要有巨大市場(chǎng)，那樣太功利，太功利往往反而束縛了自己。
比如 老趙jscex / 小盆友的編譯器 / qobean 等，由于種種原因注定是小眾，并且注定是過(guò)渡性產(chǎn)物【具體不贅述，有機(jī)會(huì)再闡述】，即研究和嘗試性質(zhì)更大。不是說(shuō)不能產(chǎn)品化實(shí)用化，但是不要包過(guò)高的期望。將來(lái)有新東西超越、吸收、融合你的東西幾乎是必然的，也應(yīng)該是樂見此事。比如jscex的async語(yǔ)義已經(jīng)在ES harmony的proposol里，這是一件很好的事情，雖然這也宣布了jscex的壽命最長(zhǎng)就活到harmony定案。小盆友的編譯器也是，coffeescript非常火——已經(jīng)前有珠玉，怎么能做到更好?幾乎是不可能的，只有做好自我定位，專注在某個(gè)方向上，或者干脆就是研究性質(zhì)的，說(shuō)不定未來(lái)就能結(jié)出果實(shí)。
再補(bǔ)充一個(gè)重要的問題。
如果要產(chǎn)品化，特別是通用化，我認(rèn)為考慮標(biāo)準(zhǔn)是及其重要的。這個(gè)標(biāo)準(zhǔn)，不僅是指現(xiàn)在已經(jīng)有的紙面標(biāo)準(zhǔn)，而是要考慮標(biāo)準(zhǔn)的方向。
比方說(shuō)過(guò)去大量的js庫(kù)都是建立在一個(gè)小的方法集上的。但是新的庫(kù)就應(yīng)該注重base在ES5標(biāo)準(zhǔn)上。因?yàn)檫@是方向。不僅是紙面標(biāo)準(zhǔn)，而且也一定會(huì)是事實(shí)標(biāo)準(zhǔn)。在JS生存10年之后，我們必須認(rèn)清楚，現(xiàn)在是一個(gè)跨越，就是開發(fā)者的baseline即將或已經(jīng)提升到了ES5(比如nodejs上的開發(fā)社區(qū))，而不是之前殘疾的ES3。
社區(qū)精英們，應(yīng)該集中力量到如何在ES5基礎(chǔ)上構(gòu)建自己的庫(kù)，而不要再浪費(fèi)時(shí)間在那些無(wú)謂兼容性上。因?yàn)殚_發(fā)者即將以ES5為baseline，你再提供某些和es5重復(fù)的部分是沒有意義的。所有那些用到元編程或OO或類似方向嘗試的，都應(yīng)該考慮如何建立在ES5的語(yǔ)義基礎(chǔ)上，若能考慮到harmony的方向，甚至參與進(jìn)去就更好了。
Traits.js就是這樣一個(gè)例子。作為又一種OO增強(qiáng)，問題不在于traits如何比其他mixins方案好，甚至traits這個(gè)模式本身就有其他的js實(shí)現(xiàn)，關(guān)鍵在于Traits.js很好的match了ES5，也就是，它是ES3/5的語(yǔ)義增強(qiáng)，而不是自創(chuàng)體系。經(jīng)過(guò)ES4的分歧之后，從ES3到ES5到Harmony，認(rèn)識(shí)逐漸統(tǒng)一到盡量是充分利用到已有設(shè)施，并增強(qiáng)之，而不是單純添加特性。庫(kù)開發(fā)者也應(yīng)有這個(gè)認(rèn)識(shí)。
當(dāng)然ES5這個(gè)baseline，是需要建立的，這就需要有庫(kù)能把legacy瀏覽器彌補(bǔ)好。現(xiàn)在這個(gè)方向做的最好的是es5-shim。但是說(shuō)實(shí)話，它真的還不夠好。這塊是有機(jī)會(huì)的，如果國(guó)內(nèi)js高手們能聯(lián)合起來(lái)，專注于這一個(gè)方向上做出世界級(jí)的庫(kù)，絕不是天方夜譚。
另外一個(gè)我認(rèn)為非常廣闊的領(lǐng)域是dom。是的，始終是。
盡管我之前說(shuō)過(guò)了，大框架沒有機(jī)會(huì)。但是注意到一點(diǎn)，jQuery等仍然是建立在前ES5前HTML5時(shí)代的。因此那些庫(kù)其實(shí)都干了大量重復(fù)的事情。真正有益的是把這些事情做一次，做好它，怎么做好?不是發(fā)明各種自己的api，而是大家努力按照html5的規(guī)范，去盡量實(shí)現(xiàn)一套一致的符合html5語(yǔ)義的底層dom api。
然后大家自由在這個(gè)api上去發(fā)展自己的各種特色庫(kù)，且這些特色庫(kù)可以只解決他們?cè)摻鉀Q的問題(封裝高級(jí)功能，解決易用性問題等)，并且所有這些庫(kù)可以很好的協(xié)作融合——而這需要三點(diǎn)配合：編程語(yǔ)言模塊機(jī)制、編程語(yǔ)言的基礎(chǔ)API、dom基礎(chǔ)API。
seajs是第一點(diǎn)(但還有提升余地)，es5-shim是第二點(diǎn)(做得還不夠好，空間大大)，第三點(diǎn)也已有大量嘗試(未開墾領(lǐng)域太多了)。
我個(gè)人認(rèn)為qwrap的思路與我講的所有理念是match的。但是似乎沒有那么明確。只是說(shuō)解決一個(gè)API風(fēng)格問題是不夠的，大家其實(shí)不太關(guān)心這個(gè)。包括高級(jí)的函數(shù)式編程會(huì)嚇走一些人。類似traits的構(gòu)建方式其實(shí)更友好。另外如我之前所說(shuō)，qwrap的baseline還是舊的模式。
一個(gè)可比的例子是qobean，它只用js的一個(gè)子集構(gòu)建系統(tǒng)，但是那是一個(gè)元編程的實(shí)驗(yàn)性項(xiàng)目，所以無(wú)所謂。qwrap也只從一個(gè)基本的函數(shù)式變換構(gòu)建出來(lái)，這值得驕傲，但是僅此并不提供生產(chǎn)力價(jià)值。
開發(fā)者其實(shí)并不會(huì)糾結(jié)于你的Array上的map/reduce等方法是靜態(tài)方法變換而來(lái)。【也許會(huì)關(guān)心是否能將這些方法變換到dom collection上】，可裁剪、定制、轉(zhuǎn)換……都只在baseline以上才有意義。
所以我個(gè)人提供一個(gè)思路，供jk、月影等qwrap的同志參考：
可將qwrap拆分成幾個(gè)項(xiàng)目(代碼上估計(jì)已經(jīng)拆分了，但建議在項(xiàng)目體系上拆分)：
0. JS module system
何種形式暫未想好。我個(gè)人對(duì)seajs不是最滿意，qwrap下的未仔細(xì)研究。
1. 補(bǔ)齊es5 baseline的庫(kù)
這一部分用何種機(jī)制實(shí)現(xiàn)并不重要，我個(gè)人傾向于避免依賴過(guò)于復(fù)雜的函數(shù)變換。這一部分的目標(biāo)并非好看，或者實(shí)現(xiàn)精巧，這一部分的最關(guān)鍵的目標(biāo)是實(shí)現(xiàn)一個(gè)好的baseline：
A. 正確性，最大限度符合es5標(biāo)準(zhǔn)
B. 高效
2. 核心的函數(shù)變換是獨(dú)立的庫(kù)，不必跟瀏覽器掛鉤，到處可用。整成像underscore那樣，說(shuō)不定在nodejs上就火了!
3. JS語(yǔ)言增強(qiáng)庫(kù)。長(zhǎng)什么樣無(wú)所謂。其實(shí)這塊最好就是百花齊放的。所以qwrap現(xiàn)在做的庫(kù)只是其中一個(gè)選擇而已。這里在0和2的幫助下，應(yīng)該盡量做成可獨(dú)立使用的小模塊。之間的依賴性越小越好(也就是只依賴0,1,2，互相間無(wú)依賴)。
以上是JS，下面是DOM
4. 補(bǔ)齊 html5 DOM baseline的庫(kù)
以html5規(guī)范和語(yǔ)義為準(zhǔn)。時(shí)刻記得避免夾帶私貨。此庫(kù)的最高境界是只作為給瀏覽器打patch用，也就是一個(gè)patch框架加patch實(shí)現(xiàn)。此方面技術(shù)實(shí)現(xiàn)難度和方式都有待研究。不一定是光用函數(shù)變換或者traits之類的能解決的，有大量的坑。依賴何種JS庫(kù)不重要。
5. 基于4的包裝庫(kù)。實(shí)際上等價(jià)于基于html5開發(fā)一個(gè)庫(kù)。此方面大家蘿卜青菜各有所愛無(wú)所謂了。
所以，qwrap這一整個(gè)大框架，其實(shí)我覺得拆得四分五裂，每一個(gè)都叫不同的名字，可以分別發(fā)展團(tuán)隊(duì)，才是最有前途的。哈哈哈。
以上這些就是最近一段時(shí)間來(lái)想法的大致總結(jié)，由玉伯引用愛民的評(píng)論開始，后面就逐漸離題了，不過(guò)無(wú)所謂了，能引起大家的思考就好了。
原文：http://hax.iteye.com/blog/1128269
【編輯推薦】
