上半年，我寫過一篇《2015前端組件化框架之路》，現(xiàn)在大半年過去了，這段時間一直在思考，未來的東西是怎樣的。

目前我主導(dǎo)著蘇寧的云計算相關(guān)的所有前端項目，這些項目以控制臺為主，幾乎都廣泛使用了Angular 1.x，一方面因為個人技能之前有積累，一方面因為產(chǎn)品的開發(fā)人員基本都是Java方向轉(zhuǎn)崗，對Angular的接受度較高，上手非?？欤_發(fā)效率也非常高。

但2015年，前端的世界發(fā)生了很多變化，這些變化快得超出我想象。在這個巨變的時代，產(chǎn)品的技術(shù)選型是個麻煩的事情，具體來說，有幾個方面：

• 如果2-3年后新開始一個業(yè)務(wù)項目，可能會有什么樣的技術(shù)方案？
• 如果現(xiàn)在立刻開始一個新業(yè)務(wù)項目，可能會有什么樣的技術(shù)方案？
• 如果持續(xù)維護(hù)老的項目，后面可能會對它們有怎樣的遷移方案？是逐步遷移，還是推倒重做？
• 在PC端項目為主體的業(yè)務(wù)體系里，如果將來某個時機出現(xiàn)了移動端項目，該如何去選型，并且利用之前的業(yè)務(wù)代碼？

我之前沒有預(yù)料到的，是ES6的普及之快。在此之前，對于新的語言特性，人們一般會等到支持的瀏覽器普及之后，才會大量使用，比如ES5，但由于Babel這樣轉(zhuǎn)譯的工具出現(xiàn)，我們可以漸進(jìn)使用，所以，開發(fā)過程中可以完全使用ES6甚至ES7的特性編寫代碼，然后通過構(gòu)建去達(dá)到兼容的結(jié)果。

有鑒于此，在未來的項目中，使用ES語言新特性進(jìn)行開發(fā)，是一個必然要做的事情。但，這并不能算是整體方案。整體的方案應(yīng)當(dāng)包括但不限于：

• 使用什么基礎(chǔ)框架
• 業(yè)務(wù)代碼如何規(guī)劃
• UI組件如何規(guī)劃
• 樣式和主題如何規(guī)劃
• 構(gòu)建方案怎樣
• 人員如何協(xié)作
• ……

所以，我們面臨的，還是基礎(chǔ)框架選型這么一個重大問題。照理說，使用Angular 1.x，后續(xù)應(yīng)當(dāng)選擇往2.0版本過渡，但現(xiàn)在這個階段，亂花迷人眼，誰也不知道未來的事情怎樣，在這一層上，我個人覺得還是要再看看。

于是就卡在這里了，這個選不了，后面的事情都沒法考慮做了嗎？

也不盡然，我考慮了一段時間，覺得雖然每個層面都比較麻煩，但至少可以分層隔離一下。比如說，我們選了某個UI層的組件化框架，并不意味著對下層的數(shù)據(jù)模型和業(yè)務(wù)邏輯就有很強約束，至少說，這層還是有很多可選方案。

通常我們在前端，可以對一個Web應(yīng)用這樣分層：

UI層（View） — 業(yè)務(wù)邏輯層（ViewModel / Controller） — 數(shù)據(jù)層（Model）

比如說，數(shù)據(jù)層，有Relay，有GraphQL，有Falcor，但我們還可以繼續(xù)使用原先的RESTful API啊。我們可以不使用某框架自帶的請求庫，比如$.get，比如$http，但我們還可以使用super agent這樣獨立的，框架無關(guān)的輔助請求庫啊。甚至說，我們不想使用XHR了，還可以使用Fetch啊。

所以，把Web應(yīng)用的前端先分層一看，發(fā)現(xiàn)每個層里面，都有很多獨立的可選方案，而這些方案是可以組合的，比如說：

上層用React，下層用Falcor或者RESTful，然后把上層換成Vue，好像也沒有什么不對啊？下層完全可以不動，也不需要就把每層代碼都改一遍??？

這樣一來，我們可以先不管UI層，直接先把下面兩層全部構(gòu)建出來，這個部分不對DOM產(chǎn)生任何依賴，所以，跟上層框架沒有關(guān)系，也無需按照上層框架的約定。

我們引入一個框架，對整個系統(tǒng)來說，最大的影響是會產(chǎn)生一些約定。有時候我們需要這些約定來幫我們規(guī)范代碼，但在現(xiàn)在這種形勢下，會盡可能希望框架本身不要產(chǎn)生約定，由我們自己，按照ES自身的一些機制來形成代碼規(guī)范。

比如說，我們使用module，class之類的語法特性，基于傳統(tǒng)的OO方法論進(jìn)行一些規(guī)劃，利用各種設(shè)計模式。或者，我們也可以基于函數(shù)式的理念，進(jìn)行另外一個方向的規(guī)劃?？傊?，這個層面的東西是純業(yè)務(wù)的，可測試的，可獨立運行的。

在構(gòu)建模型層和業(yè)務(wù)邏輯層的過程中，我們可以使用ES6，也可以使用TypeScript。之前我曾經(jīng)有個斷言：如果ES6普及得快，TS的形勢就會不太好。這主要是因為考慮到如果一個開發(fā)者已經(jīng)在使用ES6，他去使用TS的可能性并不會很大，而如果他到ES6流行的時候尚未接觸TS，后面接觸TS的可能性就比較小，直接用ES6的可能性比較多。

不過，當(dāng)業(yè)務(wù)邏輯比較復(fù)雜的時候，使用TS會有一些優(yōu)勢。即使不使用TS，我也建議把數(shù)據(jù)模型預(yù)先定義出來，在實體類里面做一些事情，盡可能使用實體類來構(gòu)建數(shù)據(jù)，而不是直接用字面量來定義。當(dāng)應(yīng)用規(guī)模變大的時候，“嚴(yán)謹(jǐn)性”變得更加重要。

另外一個角度，如果我們要盡可能構(gòu)建框架中立的業(yè)務(wù)邏輯層代碼，最好是脫離上層框架的綁定監(jiān)控機制，自己通過比如getter，setter這樣的方式，實現(xiàn)數(shù)據(jù)模型的內(nèi)部聯(lián)動，所以從這個角度，預(yù)定義數(shù)據(jù)模型也是必要的。

在這個基礎(chǔ)上，再回到我們的現(xiàn)實來，在文章開頭，我提出了幾個要考慮的可能，現(xiàn)在可以逐一回答了：

1. 如果2-3年后新開始一個業(yè)務(wù)項目，可能會有什么樣的技術(shù)方案？

底層如上所述，上層根據(jù)當(dāng)時情況判斷選擇

2. 如果現(xiàn)在立刻開始一個新業(yè)務(wù)項目，可能會有什么樣的技術(shù)方案？

底層如上所述，上層使用Angular 1.4或者Vue之類的成熟框架，同時，使用ES6開發(fā)

3. 如果持續(xù)維護(hù)老的項目，后面可能會對它們有怎樣的遷移方案？是逐步遷移，還是推倒重做？

先逐步重構(gòu)，維持UI層框架不變，把底層重構(gòu)成上述那樣，然后引入ES6，先搞成方案2這樣，后續(xù)再考慮遷移上層。

4. 在PC端項目為主體的業(yè)務(wù)體系里，如果將來某個時機出現(xiàn)了移動端項目，該如何去選型，并且利用之前的業(yè)務(wù)代碼？

先把PC端重構(gòu)如方案3，然后，PC端可繼續(xù)使用Angular，移動端上層選用Vue之類性能較好的輕量庫，PC端與移動端共用業(yè)務(wù)邏輯層。

以前有一段時間，我一直覺得Angular的all in one是一種挺好的策略，但最近考慮了很多事情之后，覺得將來這種方案的優(yōu)勢會逐漸削弱，所以，現(xiàn)在我也覺得純粹做上層視圖框架的Vue之類有不少好處。在未來，約束越強的框架很可能越不受歡迎，基于ES自身的語言特性做業(yè)務(wù)代碼約束才是王道。

這篇主要是比較籠統(tǒng)地談一些想法，后面會寫兩篇具體細(xì)節(jié)策略的考慮。