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