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

07年底，我所在的團(tuán)隊(duì)需要重構(gòu)一個(gè)產(chǎn)品，在此之前，我們的前端框架是這樣的：

• 使用html?Components（htc）作為基礎(chǔ)控件的實(shí)現(xiàn)方式，包括選項(xiàng)卡，樹形表格，日期選擇等控件。

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

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

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

• 
  

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

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

所以我們覺得需要把這個(gè)事情做一下，因?yàn)楫?dāng)時(shí)判斷，IE的份額可能會(huì)下降到70%左右，F(xiàn)ireFox可能會(huì)占有25-30%的份額，這個(gè)兼容是有可能需要的，雖然以我們的場景，幾乎全部面向行業(yè)用戶，可以把瀏覽器限制得很死，但也有部分用戶自服務(wù)的產(chǎn)品，將來還有擴(kuò)大的趨勢。

這時(shí)候我們問題就很大了，因?yàn)榍岸说幕A(chǔ)功能面臨大改，一些校驗(yàn)之類的庫好辦，通信封裝也好辦，基于htc的控件就是個(gè)大問題了，必須全部重寫。

當(dāng)時(shí)幾個(gè)成員產(chǎn)生了熱烈的討論，jQuery那時(shí)候還沒有一家獨(dú)大，也沒有產(chǎn)生這種趨勢，可選項(xiàng)包含：

• ExtJS這樣的全整合框架

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

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

所以我們就決定選一個(gè)核心js庫，然后自己開發(fā)外圍控件。那么，選誰呢？最終選的是prototype，因?yàn)榇蠹遗袛啵覀儾恍枰愃芻lass的機(jī)制，這樣就把后面兩個(gè)排除了，而我們不需要太多DOM方面的封裝，因?yàn)樽詈髽I(yè)務(wù)上需要直接操作DOM的東西不會(huì)很多，都會(huì)被我們封裝掉，所以又把jQuery排除了。

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

• 數(shù)據(jù)表格

• 樹形表格

• 日期選擇（我們的日歷需求比較變態(tài)，因?yàn)橛幸晾屎湍岵礌柨蛻簦詴?huì)有波斯日歷和尼泊爾日歷之類。。。）

• 分頁

• 動(dòng)態(tài)表單

• 國際化方案

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

• 
  

最后，因?yàn)橼s時(shí)間，這個(gè)版本的框架最終并未跨瀏覽器，部分控件的功能還是使用了IE only的特性……更致命的是，我們因?yàn)闆]時(shí)間，所以在業(yè)務(wù)開發(fā)指引上花的時(shí)間很少，這導(dǎo)致業(yè)務(wù)開發(fā)人員趕工的時(shí)候，整個(gè)就不可控了，因?yàn)槲覀兒竺孢€參與了業(yè)務(wù)開發(fā)，十多個(gè)寫HTML和JS的人，被業(yè)務(wù)壓著走，壓根沒人有時(shí)間看FireFox的狀況……

后面幾年中，這個(gè)大版本被作為基礎(chǔ)版本，拉了無數(shù)分支出來，期間，面臨了IE8之類的兼容性修改，除此之外，已經(jīng)沒有機(jī)會(huì)再修改基礎(chǔ)庫的部分了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當(dāng)時(shí)我有個(gè)比喻，我們相當(dāng)于在2000年選擇了使用Delphi。這個(gè)比喻是為了向公司高層說明，我們到底是在干什么，大家在這么激烈地吵什么。因?yàn)樗麄冸m然不一定熟悉當(dāng)時(shí)的技術(shù)方案，但都是從2000年那個(gè)時(shí)代過來的，對Delphi的盛衰還是很熟悉的。

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

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

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

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

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

舉例來說，之前系統(tǒng)規(guī)劃人員增加了新模塊的時(shí)候，一般是把數(shù)據(jù)庫表結(jié)構(gòu)截圖發(fā)出來，然后最多畫個(gè)草圖表示界面，但在組件化的開發(fā)方式中，這中間至少還有一步組件規(guī)劃、整合的過程，這一步應(yīng)當(dāng)需要嚴(yán)謹(jǐn)?shù)目紤]。

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

除了這些，還需要對業(yè)務(wù)團(tuán)隊(duì)培訓(xùn)組件化的相關(guān)理念，需要跟蹤他們的開發(fā)過程，評(píng)審、觀察、糾偏，還需要構(gòu)建組件的管控、測試平臺(tái)，否則，仍然是一種山寨的開發(fā)流程，而享受不到組件化所應(yīng)當(dāng)擁有的流水化生產(chǎn)體驗(yàn)。這一步其實(shí)沒有做下去，投入還是太少了。

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

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

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

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

但實(shí)事求是地說，這些所有東西加起來，開發(fā)體驗(yàn)還是比不過Adobe Flex，在重量級(jí)場景下，泛HTML體系的整合力度還是比較弱，對開發(fā)人員的技能要求也會(huì)高一些。我也關(guān)注Dart，關(guān)注TypeScript，（為什么不關(guān)注CoffeeScript，因?yàn)樗诠編缀跞侵欢甁ava的開發(fā)人員，跟Coffee的理念差別太大，推廣成本極高）。

感慨歸感慨，選型還是一直要做，只是這個(gè)選型在實(shí)際有項(xiàng)目應(yīng)用前，一直還會(huì)處于動(dòng)態(tài)調(diào)整中。

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

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

所以，當(dāng)時(shí)我們的基礎(chǔ)技術(shù)團(tuán)隊(duì)也花了不少時(shí)間來學(xué)習(xí)Angular，看源碼，踩坑，期間，團(tuán)隊(duì)的大漠窮秋翻譯出版了國內(nèi)第一本Angular中文書籍。

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

所謂的動(dòng)態(tài)數(shù)據(jù)綁定，指什么呢，其實(shí)核心機(jī)制類似于Angular的這種綁定關(guān)系。在Flex體系中，數(shù)據(jù)綁定是通過Proxy機(jī)制實(shí)現(xiàn)的，對POJO有一定程度的封裝，比如Object就封裝為ObjectProxy，而Array封裝為ArrayCollection。我們當(dāng)時(shí)需要?jiǎng)?chuàng)建的是：基于單個(gè)用戶（或者會(huì)話）的數(shù)據(jù)聯(lián)動(dòng)體系。

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

這個(gè)數(shù)據(jù)的定義和描述機(jī)制，用現(xiàn)有技術(shù)類比，就好像是Meteor或者Relay，但當(dāng)時(shí)我們對有些東西沒有考慮清楚。因?yàn)閷τ谀硞€(gè)用戶而言，他的所有數(shù)據(jù)結(jié)構(gòu)與界面上的組件結(jié)構(gòu)是無關(guān)的，這意味著，如果不把數(shù)據(jù)做拆解傳遞，一旦遇到組件樹上的不同層級(jí)指向數(shù)據(jù)源同一位置之類的情況，就不好辦。因?yàn)槲覀兘M件之間也是不共享數(shù)據(jù)的，類似現(xiàn)在的React。所以我們當(dāng)時(shí)的問題就是數(shù)據(jù)中間層設(shè)計(jì)得不好。

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

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

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

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

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

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

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

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

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

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

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

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

------北京網(wǎng)站建設(shè)公司 ?北京傳誠信------