上半年，我寫過一篇《2015前端元件化框架之路》，現在大半年過去了，這段時間一直在思考，未來的東西是怎樣的。
目前我主導著蘇寧的雲端計算相關的所有前端專案，這些專案以控制檯為主，幾乎都廣泛使用了Angular 1.x，一方面因為個人技能之前有積累，一方面因為產品的開發人員基本都是Java方向轉崗，對Angular的接受度較高，上手非常快，開發效率也非常高。
但2015年，前端的世界發生了很多變化，這些變化快得超出我想象。在這個鉅變的時代，產品的技術選型是個麻煩的事情，具體來說，有幾個方面：
- 如果2-3年後新開始一個業務專案，可能會有什麼樣的技術方案？
- 如果現在立刻開始一個新業務專案，可能會有什麼樣的技術方案？
- 如果持續維護老的專案，後面可能會對它們有怎樣的遷移方案？是逐步遷移，還是推倒重做？
- 在PC端專案為主體的業務體系裡，如果將來某個時機出現了移動端專案，該如何去選型，並且利用之前的業務程式碼？
我之前沒有預料到的，是ES6的普及之快。在此之前，對於新的語言特性，人們一般會等到支援的瀏覽器普及之後，才會大量使用，比如ES5，但由於Babel這樣轉譯的工具出現，我們可以漸進使用，所以，開發過程中可以完全使用ES6甚至ES7的特性編寫程式碼，然後通過構建去達到相容的結果。
有鑑於此，在未來的專案中，使用ES語言新特性進行開發，是一個必然要做的事情。但，這並不能算是整體方案。整體的方案應當包括但不限於：
- 使用什麼基礎框架
- 業務程式碼如何規劃
- UI元件如何規劃
- 樣式和主題如何規劃
- 構建方案怎樣
- 人員如何協作
- ……
所以，我們面臨的，還是基礎框架選型這麼一個重大問題。照理說，使用Angular 1.x，後續應當選擇往2.0版本過渡，但現在這個階段，亂花迷人眼，誰也不知道未來的事情怎樣，在這一層上，我個人覺得還是要再看看。
於是就卡在這裡了，這個選不了，後面的事情都沒法考慮做了嗎？
也不盡然，我考慮了一段時間，覺得雖然每個層面都比較麻煩，但至少可以分層隔離一下。比如說，我們選了某個UI層的元件化框架，並不意味著對下層的資料模型和業務邏輯就有很強約束，至少說，這層還是有很多可選方案。
通常我們在前端，可以對一個Web應用這樣分層：
UI層（View） — 業務邏輯層（ViewModel / Controller） — 資料層（Model）
比如說，資料層，有Relay，有GraphQL，有Falcor，但我們還可以繼續使用原先的RESTful API啊。我們可以不使用某框架自帶的請求庫，比如$.get，比如$http，但我們還可以使用super agent這樣獨立的，框架無關的輔助請求庫啊。甚至說，我們不想使用XHR了，還可以使用Fetch啊。
所以，把Web應用的前端先分層一看，發現每個層裡面，都有很多獨立的可選方案，而這些方案是可以組合的，比如說：
上層用React，下層用Falcor或者RESTful，然後把上層換成Vue，好像也沒有什麼不對啊？下層完全可以不動，也不需要就把每層程式碼都改一遍啊？
這樣一來，我們可以先不管UI層，直接先把下面兩層全部構建出來，這個部分不對DOM產生任何依賴，所以，跟上層框架沒有關係，也無需按照上層框架的約定。
我們引入一個框架，對整個系統來說，最大的影響是會產生一些約定。有時候我們需要這些約定來幫我們規範程式碼，但在現在這種形勢下，會盡可能希望框架本身不要產生約定，由我們自己，按照ES自身的一些機制來形成程式碼規範。
比如說，我們使用module，class之類的語法特性，基於傳統的OO方法論進行一些規劃，利用各種設計模式。或者，我們也可以基於函式式的理念，進行另外一個方向的規劃。總之，這個層面的東西是純業務的，可測試的，可獨立執行的。
在構建模型層和業務邏輯層的過程中，我們可以使用ES6，也可以使用TypeScript。之前我曾經有個斷言：如果ES6普及得快，TS的形勢就會不太好。這主要是因為考慮到如果一個開發者已經在使用ES6，他去使用TS的可能性並不會很大，而如果他到ES6流行的時候尚未接觸TS，後面接觸TS的可能性就比較小，直接用ES6的可能性比較多。
不過，當業務邏輯比較複雜的時候，使用TS會有一些優勢。即使不使用TS，我也建議把資料模型預先定義出來，在實體類裡面做一些事情，儘可能使用實體類來構建資料，而不是直接用字面量來定義。當應用規模變大的時候，“嚴謹性”變得更加重要。
另外一個角度，如果我們要儘可能構建框架中立的業務邏輯層程式碼，最好是脫離上層框架的繫結監控機制，自己通過比如getter，setter這樣的方式，實現資料模型的內部聯動，所以從這個角度，預定義資料模型也是必要的。
在這個基礎上，再回到我們的現實來，在文章開頭，我提出了幾個要考慮的可能，現在可以逐一回答了：
1. 如果2-3年後新開始一個業務專案，可能會有什麼樣的技術方案？
底層如上所述，上層根據當時情況判斷選擇
2. 如果現在立刻開始一個新業務專案，可能會有什麼樣的技術方案？
底層如上所述，上層使用Angular 1.4或者Vue之類的成熟框架，同時，使用ES6開發
3. 如果持續維護老的專案，後面可能會對它們有怎樣的遷移方案？是逐步遷移，還是推倒重做？
先逐步重構，維持UI層框架不變，把底層重構成上述那樣，然後引入ES6，先搞成方案2這樣，後續再考慮遷移上層。
4. 在PC端專案為主體的業務體系裡，如果將來某個時機出現了移動端專案，該如何去選型，並且利用之前的業務程式碼？
先把PC端重構如方案3，然後，PC端可繼續使用Angular，移動端上層選用Vue之類效能較好的輕量庫，PC端與移動端共用業務邏輯層。
以前有一段時間，我一直覺得Angular的all in one是一種挺好的策略，但最近考慮了很多事情之後，覺得將來這種方案的優勢會逐漸削弱，所以，現在我也覺得純粹做上層檢視框架的Vue之類有不少好處。在未來，約束越強的框架很可能越不受歡迎，基於ES自身的語言特性做業務程式碼約束才是王道。
這篇主要是比較籠統地談一些想法，後面會寫兩篇具體細節策略的考慮。