從開始接觸互聯網（2009）到進入前端開發(fā)（2011）一直到現在，我感受到6年前端開發(fā)來，畢業(yè)這三年絕對是我經歷的變化最快的幾年。常常感嘆再不學習就老了，前端真的是長江后浪推前浪，前浪死在沙灘上……，作者最后一句感同身受：“未來的前端web應用技術選型還有不小的變數，身為大齡前端技術人員，一方面感慨有些自己熟知的技術逐步落幕消亡，另外一方面又看到新事物不斷出現，以種種方式改進和沖擊著我們的開發(fā)方式。生在這個時代是一種不幸，也是幸運。以下為全文：

07年底，我所在的團隊需要重構一個產品，在此之前，我們的前端框架是這樣的：

• 使用html?Components（htc）作為基礎控件的實現方式，包括選項卡，樹形表格，日期選擇等控件。

• 在原生JS的基礎上作了一些簡單封裝，形成了包括表單校驗，彈出菜單（基于popup），簡單圖表（基于XML），動態(tài)表單等功能的業(yè)務公共庫。

• 使用XMLHTTP作為前后端通信方式，將請求參數序列化為XML發(fā)送給服務端，反序列化之后，反射調用后端服務（Java和.net），再把返回結果序列化為XML傳輸回來，用js解析為javascript對象。這個傳輸方式從03年版本就開始使用，還在ajax概念出現之前，只是一直使用的是同步傳輸方式，調用的時候界面會卡死。

• 開發(fā)方式也是前后端分離的，前端只寫HTML和JS，后端提供接口（但并不是HTTP接口，而是服務端的類接口，然后通過一個統(tǒng)一的facade類去反射調用）。

• 
  

這個時期的版本不用說，肯定都是只支持IE的，我們當時需要兼容的瀏覽器包括IE 5.0，5.5，6，后來7出來之后還需要支持7。

這個產品重構的目的是，對近幾年積累的業(yè)務需求進行整合，并且把服務端完全遷移到Java。對于前端來說，其實不做遷移也可以，但當時我們發(fā)現一個問題，FireFox這個東西突然崛起了，所以，我們從原先面臨的只支持IE，變成了可能要支持跨瀏覽器。

所以我們覺得需要把這個事情做一下，因為當時判斷，IE的份額可能會下降到70%左右，FireFox可能會占有25-30%的份額，這個兼容是有可能需要的，雖然以我們的場景，幾乎全部面向行業(yè)用戶，可以把瀏覽器限制得很死，但也有部分用戶自服務的產品，將來還有擴大的趨勢。

這時候我們問題就很大了，因為前端的基礎功能面臨大改，一些校驗之類的庫好辦，通信封裝也好辦，基于htc的控件就是個大問題了，必須全部重寫。

當時幾個成員產生了熱烈的討論，jQuery那時候還沒有一家獨大，也沒有產生這種趨勢，可選項包含：

• ExtJS這樣的全整合框架

• jQuery，prototype，mootools，Ext Core這樣的核心js庫加外圍

在這兩個選擇里，我們排除了第一個，因為雖然看上去它很符合我們的業(yè)務場景，但我們的定制化需求比較多，不確定有能力在這個基礎上做定制，可控性不好。

所以我們就決定選一個核心js庫，然后自己開發(fā)外圍控件。那么，選誰呢？最終選的是prototype，因為大家判斷，我們不需要類似class的機制，這樣就把后面兩個排除了，而我們不需要太多DOM方面的封裝，因為最后業(yè)務上需要直接操作DOM的東西不會很多，都會被我們封裝掉，所以又把jQuery排除了。

所以我們的需求其實也很明確，就是有一定基礎功能的js核心庫。然后就是在這個基礎上開發(fā)控件了，時間也很倉促，大約只有2-3個人，2-3個月，最后幾個東西：

• 數據表格

• 樹形表格

• 日期選擇（我們的日歷需求比較變態(tài)，因為有伊朗和尼泊爾客戶，所以會有波斯日歷和尼泊爾日歷之類。。。）

• 分頁

• 動態(tài)表單

• 國際化方案

• 其他一些基礎功能，布局指引之類

• 
  

最后，因為趕時間，這個版本的框架最終并未跨瀏覽器，部分控件的功能還是使用了IE only的特性……更致命的是，我們因為沒時間，所以在業(yè)務開發(fā)指引上花的時間很少，這導致業(yè)務開發(fā)人員趕工的時候，整個就不可控了，因為我們后面還參與了業(yè)務開發(fā)，十多個寫HTML和JS的人，被業(yè)務壓著走，壓根沒人有時間看FireFox的狀況……

后面幾年中，這個大版本被作為基礎版本，拉了無數分支出來，期間，面臨了IE8之類的兼容性修改，除此之外，已經沒有機會再修改基礎庫的部分了。

09年底，我主導這個產品下一代版本的前端框架選型。我們現在回頭看這個時間點，會發(fā)現很尷尬，當時流行的，或者即將流行的所有前端方案，其實也都是第一代的理念，在現在這個時候，都已經被時代大潮沖刷得死傷殆盡了。

所以我當時非常糾結，我是預見到前端這幾年的亂象的，當時大家炒得最火的概念是什么，是HTML5，然而我看了這方面的一些資料，發(fā)現廣義上，更多提供的是一些功能方面的東西，或者能提升布局方式，等等，這與我們想要的東西相去甚遠，好比說，我們想要蒸汽機之類的東西，發(fā)現手里將要有的還只是各種鐵塊。

我當時想要什么呢？想想我當時有過什么，經歷過什么，早在05年初，我就有了一種設想，那就是前端的全組件化開發(fā)，當時的老大問我對現有項目有什么看法，我提出了一個方案：

• 擴展htc的使用場景，不限于基礎組件，把業(yè)務界面也全部組件化

• 各組件可以獨立通過XMLHTTP與服務端交互，也就是說，你把一個已經調試好的組件加到界面之后，什么都不用管，它自己是能夠管理與服務端的通訊的，然后你只要管跟它怎么交互就行了

• 在此基礎上，考慮界面的動態(tài)定制，像積木一樣拼裝業(yè)務界面

這個想法在當時確實比較激進，所以當然沒人支持。但我在05-09這幾年的開發(fā)過程中，目睹各種業(yè)務代碼的混亂，覺得可能還是應該推進組件化的開發(fā)理念。理念是有了，細節(jié)怎么處理呢，因為HTML Components這一規(guī)范被廢棄之后，我發(fā)現現有的任何方案都不再能夠像原先那樣簡便地封裝組件了，如果對于業(yè)務開發(fā)人員來說，開發(fā)業(yè)務組件的代價過高，那工程成本更加不可控。

回想我們使用HTML Components的時候，開發(fā)一個組件易如反掌，就像開發(fā)普通頁面一樣簡單，只需在頭部聲明對外的屬性、方法、事件即可，樣式也是隔離的，JS作用域也是隔離的，使用起來也是非常簡單，就是一個自定義標簽，而且是客戶端的（區(qū)別于taglib之類的服務端標簽封裝）。

以05年時候那個產品的場景而言，絕大部分界面都是普通的配置和管理，每個界面的獨立性都較高，并不存在強集成的場景，所以是否使用組件化方式開發(fā)，并不是很重要，這跟我前幾天在微博上說：“輕量級管理控制臺有至少100種做法”是一個意思。

但是后來的做的，有包括CRM和呼叫中心之類的強集成產品，不再是原先那種單菜單配置頁面了，整個產品幾乎就是一個菜單，然后通過各種交互去觸發(fā)一系列功能，在這種場景下，組件化就變成了一個重要的實施手段。

所以我萬般無奈，就把目光投到04年開始持續(xù)關注的一項技術：Adobe Flex，在這個東西剛出來的時候，我曾經預言微軟會推出一個精簡的CLR，作為瀏覽器插件運行，與Flash平臺抗衡，后來大家看到了SilverLight，不過這個東西當時的普及度并不好，第一代極其簡陋，第二代稍微好一點，所以我沒有考慮它。

在2009年，Adobe Flex算是比較成熟了，帶有完善的組件化機制，生命周期管理，強大而易于擴展的基礎控件，優(yōu)雅而強大的開發(fā)語言，但我當時有判斷，這東西是一個走下坡路的平臺，而且Adobe自身有很大不足，也沒有能力把它支撐和運營好。最終，我反復權衡，仍然選擇了使用它來構建這個版本。

所以當時我面臨的壓力非常大，公司內部的辯論達到白熱化，正反雙方都有相當多的人參與，而且反對者還略多些，年輕開發(fā)者居多。在有資格參與這項決策的各基層管理者和技術專家組的投票來看，雙方也是基本對等的。這個爭論現在回頭看，很有意思，雙方考慮的事情其實不在一個層面上，從基層開發(fā)者的角度，他會從流行趨勢方面進行一個判斷，覺得Flash必死，HTML永生，你讓我1948年加入國民黨，是何居心？

但從我們有些老員工的角度，看到的問題是由于公司開發(fā)人員水平參差不齊，導致很多代碼寫得非常糟糕，很難調試，也很難重構，更沒有一些全局視圖，讓我們能看到代碼的結構是怎樣，數據的流動又是怎樣，產品的質量如何，我們覺得對于大部分低層次開發(fā)者來說，JavaScript的約束還是太弱了，這樣松散的語言在他們手里會造成開發(fā)效率極低，bug率很高。

當時我有個比喻，我們相當于在2000年選擇了使用Delphi。這個比喻是為了向公司高層說明，我們到底是在干什么，大家在這么激烈地吵什么。因為他們雖然不一定熟悉當時的技術方案，但都是從2000年那個時代過來的，對Delphi的盛衰還是很熟悉的。

最終我們的判斷是：5年之內，泛HTML體系的組件化方案不會有一個相對穩(wěn)定的選擇，我們是做企業(yè)軟件產品的，并不害怕使用的技術相對過時，怕的是時常有劇烈變動，而且不能掌控。所以，打算用Adobe Flex這樣的東西，來做一個5-8年的支撐，在這段時期內，見機行事，在泛HTML體系里作一些探索，跟進可能會流行的技術，并且加以積累。另外，選擇一種輕量級的解決方案，用于構建面向個人用戶的門戶，這條線選擇的是jQuery和BootStrap。

當時在輕量級這條線的解決方案上，我也有一些意見，因為在我們當時的開發(fā)團隊中，大家對“控件”這個東西的依賴程度太高了，絕大部分人壓根不具備我們現在所說的前端工程師的基本能力，只有調用控件的能力。而我認為，輕量級的場景中，應當嚴格控制“控件”的使用，絕大部分場景都是用基本樣式加一些DOM操作就可以做到，當時我們的輕量場景是面向運營商的用戶們，他們登錄上去，查詢話費，辦理業(yè)務，兌換積分，購買一些服務或者禮品之類。

所以，當我后來發(fā)現這樣的場景也引入了上M的js庫的時候，我的心情是非常崩潰的，后來有的團隊考慮在這種業(yè)務場景下封裝一些服務端標簽，這個事情我并不贊同。很多時候，我們需要去使用服務端模板之類的方式生成界面，為的是頁面性能優(yōu)化之類，但我們所在的場景，并不需要這么苛刻的優(yōu)化，頁面DOM結構是比較簡單的，反倒是JS這塊需要嚴格控制。這么輕量級的場景，做服務端組件化的必要性也不是很大，只需引入js的模板庫就可以了。

回頭再看Flex這頭的狀況，我們用這個東西針對重量級的管理系統(tǒng)進行開發(fā)，但令人痛苦的是，絕大部分開發(fā)人員很難理解“組件化”這么一件事情，比如說，仍然保留“頁面”這個稱呼，越是老開發(fā)人員越是難改變思維，我有一次很激動地說：我們這種模式下，哪里來的頁面？我們做的是一個軟件系統(tǒng)，你可以把它理解為運行在瀏覽器中的桌面軟件，只存在組件，不存在頁面，頁面是HTML體系中特有的稱呼。

所以，做一個全業(yè)務組件化的實踐，需要一次又一次從理念上去向業(yè)務團隊灌輸，什么是組件，組件樹是怎樣的，組件跟數據層如何通信，組件之間如何通信等等，如何提取合適的組件，不把這些理念灌輸下去，整個產品也很難成功。

舉例來說，之前系統(tǒng)規(guī)劃人員增加了新模塊的時候，一般是把數據庫表結構截圖發(fā)出來，然后最多畫個草圖表示界面，但在組件化的開發(fā)方式中，這中間至少還有一步組件規(guī)劃、整合的過程，這一步應當需要嚴謹的考慮。

我所在的基礎技術團隊中，也有不少人對我們要面臨的問題看得不太清楚，把責任想得太輕。之前那種簡單的管理頁面，只需要基礎技術團隊提供基礎組件和公共庫，公共樣式的開發(fā)，但在全組件化的實踐中，做完這些事情也才完成了整個事情的30%。

除了這些，還需要對業(yè)務團隊培訓組件化的相關理念，需要跟蹤他們的開發(fā)過程，評審、觀察、糾偏，還需要構建組件的管控、測試平臺，否則，仍然是一種山寨的開發(fā)流程，而享受不到組件化所應當擁有的流水化生產體驗。這一步其實沒有做下去，投入還是太少了。

這個大產品版本以及附屬項目一共有好幾十名開發(fā)人員參與，歷時2年多，雖然離我心目中的目標還有不少差距，但在某些方面的提升是能夠感受得出來的，比如說開發(fā)效率的提升。除此之外，這個版本的美觀程度比之前所有版本都好，終于有現代氣息了，誰說企業(yè)用戶就都是土鱉的，甚至有一次還收到過外籍市場人員專門的郵件夸贊，這讓我們感到很振奮。

開發(fā)效率的提升另一方面還源自Flex自身的特點，獨立于瀏覽器的插件，可以說，大部分前端開發(fā)人員都會面臨跨瀏覽器的折騰，尤其是那幾年，亂得可怕，兼容問題會把人折磨死，我們面對的客戶，從歐美到亞非拉，各種低端高端瀏覽器并存，所以我們是繞開了這個問題，而這么復雜的組件界面，如果使用傳統(tǒng)Web技術，在IE6、7等瀏覽器下的性能會慘不忍睹，基于插件體系的另外一個優(yōu)點是，性能不受低端瀏覽器的制約，下限比較高。

在這個階段，我們實際上是做了比較取巧的選擇，但從長期角度看，還是必須回到泛HTML體系的。所以，從12年開始，我就開始考慮未來的產品技術選型。

在12年這個點上，我們能看到的東西還是比較多的，至少比幾年前有了很明顯的發(fā)展，比如說，jQuery終于一家獨大了，比如說，AMD和CMD之類js模塊封裝機制的出現，比如說，Backbone，Knockout，Angular分別出現了不少使用者，比如說，ES6和Web Components規(guī)范的落地快看到曙光了。

但實事求是地說，這些所有東西加起來，開發(fā)體驗還是比不過Adobe Flex，在重量級場景下，泛HTML體系的整合力度還是比較弱，對開發(fā)人員的技能要求也會高一些。我也關注Dart，關注TypeScript，（為什么不關注CoffeeScript，因為所在公司幾乎全是只懂Java的開發(fā)人員，跟Coffee的理念差別太大，推廣成本極高）。

感慨歸感慨，選型還是一直要做，只是這個選型在實際有項目應用前，一直還會處于動態(tài)調整中。

在這段時間中，我們考察了Backbone，Knockout和Angular，也持續(xù)關注了司徒正美的Avalon，最終還是比較傾向于Angular的。

傾向于Angular的主要原因是，開發(fā)團隊經過磨合，已經逐步習慣了組件化的開發(fā)方式和數據綁定所帶來的開發(fā)理念的改變，Angular在這方面與Flex比較接近，學習成本很低，而且那些稍微繁瑣的配置，對于這些習慣了Java的人員來說，并非負擔。

所以，當時我們的基礎技術團隊也花了不少時間來學習Angular，看源碼，踩坑，期間，團隊的大漠窮秋翻譯出版了國內第一本Angular中文書籍。

我們研究Angular，還有另外一個原因。在基于Flex的這代產品逐步穩(wěn)定之后，又實現了一個二次開發(fā)平臺，從數據模型的動態(tài)定義（類似ORM），到規(guī)則、流程、服務的動態(tài)定義，再到界面的可視化配置，動態(tài)的數據綁定。這個平臺的有些方面考慮是不夠成熟的，尤其是動態(tài)界面這塊，細節(jié)不展開了。

所謂的動態(tài)數據綁定，指什么呢，其實核心機制類似于Angular的這種綁定關系。在Flex體系中，數據綁定是通過Proxy機制實現的，對POJO有一定程度的封裝，比如Object就封裝為ObjectProxy，而Array封裝為ArrayCollection。我們當時需要創(chuàng)建的是：基于單個用戶（或者會話）的數據聯動體系。

這個是什么意思呢，對于某個登錄用戶來說，他所可能擁有的全部數據結構是可預測的，絕大部分是平級關系，沒有關聯，部分存在聯動關系，我們要做的就是把這些關系描述出來，用可視化的形式配置，掛接在ORM機制上作為外殼，并且提供給業(yè)務流程、業(yè)務規(guī)則和動態(tài)界面作為綁定數據源。

這個數據的定義和描述機制，用現有技術類比，就好像是Meteor或者Relay，但當時我們對有些東西沒有考慮清楚。因為對于某個用戶而言，他的所有數據結構與界面上的組件結構是無關的，這意味著，如果不把數據做拆解傳遞，一旦遇到組件樹上的不同層級指向數據源同一位置之類的情況，就不好辦。因為我們組件之間也是不共享數據的，類似現在的React。所以我們當時的問題就是數據中間層設計得不好。

以我們當時的設計，其實是適合Angular這種機制的，Angular里面，不同層級的組件之間，數據可以有穿透，比如說你在最頂層綁定了一個dataStore，在隔了很多級的葉子節(jié)點上仍然可以綁定到dataStore.a.b這樣的數據，這個a.b數據路徑可以與葉子節(jié)點在組件樹上的路徑毫無關系。

在這個過程中，我還是一直在嘗試考慮基礎框架與組件化業(yè)務開發(fā)的結合，包括整個組件和數據的規(guī)劃流程，管控機制等，也寫了幾篇文章，現在回頭看，有一些不成熟的地方，另外有些東西當時覺得有坑，但正好被近期出現的新技術填平了。

舉例來說，當時我覺得，不管是AMD還是CMD，都是在JS模塊自身代碼中聲明依賴項，如果是出現代碼路徑調整之類的情況，這些依賴項的變更就是個問題，所以我設想了一種類似npm的方式，用數據庫集中存放依賴關系，模塊自身的內容不維護這個關系，然后構建階段生成出來。

今年看到Webpack，里面提到module，bundle，entry chunk之間的關系，感到已經差不多把我當時考慮的那些東西全部做到了，社區(qū)的力量真是強大啊。

在之前爭論Flex方案的時候，反對方的有些觀點很典型，比如：Flex代碼編寫之后還需要編譯，JS的不用。但其實最近幾年我們看到，Web應用的開發(fā)過程逐漸離不開構建環(huán)節(jié)，不可能再像十年前那樣，寫完代碼之后，最多只做下壓縮就上線了，那是一種很原始的生產方式，所以，從這個方面看，組件化、構建過程，這些都是現代富Web應用開發(fā)方案中必不可少的部分，已經逐漸被廣泛接受了。最近兩三年，業(yè)界對前端工程化的關注度也已經比以前高很多了，令人欣慰。

前面這些年，我們還有一個大的缺陷，那就是一直對異步編程模型關注太少了，在早期我們一直使用同步的XMLHTTP，后來到了用Flex的時候，改用異步的HTTP通信，使用AMF協(xié)議傳輸數據，我們的經驗仍然停留在使用回調函數這種初級的方案上，間或使用事件，并不知道任何跟promise之類理念相關的東西，所以代碼有不少很不優(yōu)雅，這個跟眼界有關，還是缺少學習所致。

現在距離09年底已經整整6年過去了，回頭看來，6年前可能接觸到的任何前端領域的框架或者庫，到今天都已經全部是過時的。這6年時間，我們可能積累出一些經驗，但大部分東西都不可避免地失效了，這就是野蠻生長期的痛。

這6年里，我們看到AMD，CMD這些模塊機制逐步流行，然后又突然衰落，Angular為代表的前端MV*框架橫空出世，帶給前端社區(qū)巨大的沖擊，React挾組件化和Virtual DOM之力快速崛起，你方唱罷我登臺，亂花漸欲迷人眼。

兩年前我從之前公司離職，心中充滿迷茫，未來的Web技術會怎樣發(fā)展，重型Web應用應當采用怎樣的整體方案去建造，自己并不能說出一個精確答案。今天我們再要考慮未來的Web應用技術選型，已經沒有兩年前那么迷茫了，這兩年仍然在持續(xù)學習，持續(xù)思考，每次面臨選型，還是如履薄冰，一再審視項目類型，人員狀況。

未來的前端Web應用技術選型還有不小的變數，身為大齡前端技術人員，一方面感慨有些自己熟知的技術逐步落幕消亡，另外一方面又看到新事物不斷出現，以種種方式改進和沖擊著我們的開發(fā)方式。生在這個時代是一種不幸，也是幸運。毛主席教導我們：三天不學習，不如劉少奇。說到底，保持學習和思考，是現在這個階段最該做的。舊技術雖然消亡了，但它們留下的思維啟發(fā)永在。

后記：最近一直有種沖動，想把過去十年（2005-2015）時間所經歷的一些事情總結一下，昨晚開始寫，今天中午完善了一下，大致寫完，意猶未盡，與大家共勉。

原文鏈接：10年來感受的前端技術變化?版權所有，轉載時請注明出處，違者必究。
注明出處格式：前端開發(fā)博客 (http://caibaojian.com/10years-web-frontend-tech.html)

------北京網站建設公司 ?北京傳誠信------