關于國內前端和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這一整個大框架，其實我覺得拆得四分五裂，每一個都叫不同的名字，可以分別發展團隊，才是最有前途的。哈哈哈。
以上這些就是最近一段時間來想法的大致總結，由玉伯引用愛民的評論開始，后面就逐漸離題了，不過無所謂了，能引起大家的思考就好了。
原文：http://hax.iteye.com/blog/1128269
【編輯推薦】
