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

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

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

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

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

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

• 
  

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

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

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

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

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

• ExtJS這樣的全整合框架

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

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

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

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

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

• 樹(shù)形表格

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

• 分頁(yè)

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

• 國(guó)際化方案

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

• 
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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