2015前端生態發展回顧

引用蘇寧前端架構師的一個總結做爲開篇

編程技術及生態發展的三個階段

• 最初的時候人們忙着補全各類API，表明着他們擁有的東西還很匱乏，須要在語言跟基礎設施上繼續完善
• 而後就開始各類模式，標誌他們作的東西逐漸變大變複雜，須要更好的組織了
• 而後就是各種分層MVC，MVP，MVVM之類，可視化開發，自動化測試，團隊協同系統等等，說明重視生產效率了，也就是所謂工程化

處在2015年這個時間段來看，前端生態已經進入了第三階段。看上去好像已經走的挺遠了，實則否則。若是再用人類歷史上的三次工業革命來類比，前端發展其實不過剛剛邁入了蒸汽機時代，開始逐步用工具來替代過往至關一部分的人肉做業，可是離電氣時代的自動化流水線做業還有很長一段路要走。回顧一下2015年前端的生態發展，我大體整理了幾個我以爲比較有歷史意義的事件。

按時間順序：

1. 年初React Native的發佈，引領React正式走上歷史舞臺。
2. 3月angular2.0第一個預覽版發佈
3. 5月 http/2.0標準正式發佈，同月 iojs 與 nodejs合併。
4. 6月 ES6 和 WebAssembly 落地
5. 7月 迄今爲止React生態圈影響最大的Flux實現redux發佈1.0版本
6. 8月 Facebook公開了在React上應用GraphQL的relay框架的技術預覽版
7. 9月 React Native for Andriod 發佈
8. 11月伊始，es標準委員會宣佈將歷時3年研究的Object.observe從草案中移除，儘管它本來已是stage2，幾乎已是ES7的事實標準。雙十一剛一結束，阿里手淘團隊發佈了名爲 無線電商動態化解決方案 的 Weex，也有人給了它一個更具象的名字，vue native。
9. 12月，趕在2015的尾巴，aurelia和angular2前後發佈beta版。

css方面，postcss & cssnext前後高調走到臺前。

觀念的變化

因爲近幾年前端的野蠻生長以及前端應用的多元化和複雜化，整個技術形態已經跟幾年前純作頁面的時代徹底迥異了。主要觀念的變化總結來看在於一點，如今的前端開發面向的是web app而不是web page。今天的前端開發模式跟傳統的GUI軟件(如C++、.NET開發的windows客戶端)已經很接近了，並且因爲如今前端領域爲了解決日益複雜的web業務需求及體量，愈來愈多的借鑑了傳統客戶端的開發經驗，致使二者變得愈來愈趨同。再加上前端一些獨特的特性(免安裝、增量安裝等)，工程上的複雜度有過之而無不及。前端現在已經脫離了茹毛飲血、刀耕火種的原始社會，開始步入了工業時代。

框架 & 類庫的變化

今年最火的框架/類庫毫無疑問當屬React了。React從2014年年中開始普遍受到開發者關注，可是真正開始在社區獨領風騷還得歸功於2015年初React Native的發佈。React Native的發佈使得js統一三端(前端、後端、移動端)開發成爲可能(如今這個時間點看可能仍是過於理想，可是總體方向仍是對的)，這一針強心劑吸引了大量開發者的眼球。筆者對此最大的感覺就是，我在社區發表一篇react的入門教程級別的軟文即可得到普遍關注及轉發，相應的寫angular源碼剖析的準乾貨大部分狀況則是門可羅雀😂。

咱們挑幾個主流的框架來說講這一層的變化。

React & Redux

React基本簡介能夠參考這篇文章React簡介，這裏再也不贅述。咱們挑幾個核心特徵簡單來說：

1. virtual dom
   這個能夠說是F家工程師超強工程能力的最佳體現了(Relay也算一個)，從本質來看它是經過用js object來模擬了一個dom tree，而後將這層virtual dom插在react組件跟真實dom之間，配合強勁的dom diff算法實現它一直標榜的高性能。
2. jsx
   一樣爲了配合react中的組件化開發模式，F家發明了一套新的語法jsx。乍看之下它像是html in js，這也是初接觸的開發者最難以接受的，典型的違背前端推崇多年的表現與業務分離的原則啊。其實這裏要換個角度來看jsx，它並非html in js，準確來講它是一個用來構建react組件樹的AST。這樣來想你就能理解react中這一看似怪異的設計了。
3. immutable object
   不可變對象是函數式編程中的重要概念，react的介入使得這一理念在前端社區中流行起來。從目前各類類庫的實現來看，不可變對象在大型應用中擁有傳統可變對象不具有的優點。尤爲在這個內存不值錢的年代。從目前immutable object的良好走勢來看，未來有可能被es歸入規範之中。目前能夠經過facebook的immutable.js來實現。

Redux則是目前react配套的Flux模式的各類實現(其實如今二者的關係愈來愈模糊了)中最火的一個，在此基礎上它引入了函數式編程、單一數據源、不可變數據、中間件等概念。必定程度來說，redux是今年react生態甚至整個前端生態中影響最大的一個框架，它給整個前端技術棧引入了不少新成員，儘管這些概念可能在其餘領域已經有了普遍的應用。雖然它們是否會在大規模的應用實踐中被廣大開發者承認還須要再檢驗，但至少給咱們帶來了一些新的思路。其中的單一數據源、不可變數據、中間件等思路目前來看仍是很是有價值的，尤爲是單一數據源跟不可變數據，頗有可能在未來成爲大型應用架構中的標配(目前來看至少在應用中構建Store層在當前的前端架構中是勢在必行的)。單一數據源就比如在前端構建了一個集中式數據庫，全部的數據存取操做對象都是它，不單如此它裏面還實現了觸發器，當有insert/update操做時它會對相應組件做rerender動做，這個在各組件之間有數據同步需求的場景下就很是有用了。

至於我對函數式編程的見解，後面單獨闡述。

在我看來，react的優點並不在組件化，組件化的實現方案多種多樣。react的優點在於virtual dom及一個幾乎構成閉環的強大生態，這歸功於Facebook工程師強大的工程能力跟架構能力。virtual dom將應用表現層從瀏覽器這個基於dom的上下文中抽離出來，經過原生js對象模型的方式使得react具有在任何環境支撐上層表現的能力。上層的渲染引擎能夠是canvas、native、服務端甚至是桌面端，只要相應的端提供基於react組件的渲染能力，便可達到一套代碼、或者只要不多的改動就能移植到任一終端環境的效果，這個就很是誇張了。react從0.14版本以後便將react-dom抽出來變成一個獨立的庫，可見react的野心並不侷限於瀏覽器，相反從這點來看，react反而是受到了dom的掣肘。

Angular2 & Vue.js

ng2跟ng1相比是一個徹底革命性版本而不是升級版，它是一個爲了迎合將來的標準及理念來設計的全新框架，而這些新的理念又沒法經過改進ng1.x的方式來實施，因此angular團隊作了這麼一個看似激進的決策，能夠理解成重構已經沒法知足需求只能重寫了。ng2也採用純組件化的開發思路，任何單元對於它來講都是組件。同時，ng2裏面也引入了一些全新的概念(對於前端而言)來提高框架的性能及設計，例如基於worker的數據檢測機制能大幅度提高渲染性能(對應實現是zone.js)，基於響應式編程的新的編程模型能更大的改善編碼體驗(對應實現RxJS)。趕在2015年的尾巴，ng2正式發佈beta版，對於angular的此次自我革命是否能成功，還有待後續檢驗。另外原angular團隊中出來的一個成員開發了一個類ng2的框架aurelia，有至關的開發者認爲它更配稱爲ng2，值得關注。

因爲阿里在背後的技術實踐及支持，Vue.js今年也開始獲得愈來愈多的關注。vue相對於angular1.x的優點在於輕量、易用、更優異的性能及面向組件化的設計，目前發展態勢也很是好，是移動端開發的一個重要技術選型之一。

標準 & 語言的變化

如今回顧起來，2015年是頗有意義的一年：這一年是Web誕生25歲週年，也是js誕生的20週年。同時又是ES6標準落地的一年。ES6是迄今爲止ECMAScript標準最大的變革(若是不算上胎死腹中的ES4的話)，帶來了一系列令開發者興奮的新特性。從目前es的進化速度來看，es後面應該會變成一個個的feature發佈而不是像之前那樣大版本號的方式，因此如今官方也在推薦 ES+年份 這種叫法而不是 ES +版本。

ES2015(ES6) & ES2016(ES7) & TypeScript

6月中ES2015規範正式發佈，從ES2015帶來的這些革命性的新語法來看，JS今後具有了用於開發大型應用的語言的基本要素：原生的mudule支持、原生的class關鍵字、更簡潔的api及語法糖，更穩定的數據類型。而這些new features中，有幾個我認爲是會影響整個前端發展進程的：

1. Module & Module Loader
   
   ES2015中加入的原生模塊機制支持可謂是意義最重大的feature了，且不說目前市面上五花八門的module/loader庫，各類不一樣實現機制互不兼容也就罷了(其實這也是很是大的問題)，關鍵是那些模塊定義/裝載 語法都醜到爆炸，可是這也是無奈之舉，在沒有語言級別的支持下，js只能作到這一步，正所謂巧婦難爲無米之炊。ES2016中的Module機制借鑑自CommonJS，同時又提供了更優雅的關鍵字及語法(雖然也存在一些問題)。遺憾的是一樣有重大價值的Module Loader在2014年末從ES2015草案中移除了，我猜想多是對於瀏覽器而言Module Loader的支持遭遇了一些技術上的難點，從而暫時性的捨棄了這一feature。可是一個原生支持的模塊加載器是很是有意義的，相信它不久後仍是會迴歸到ES規範中(目前由WHATWG組織在單獨維護)。

2. Class
   
   準確來講class關鍵字只是一個js裏構造函數的語法糖而已，跟直接function寫法無本質區別。只不過有了Class的原生支持後，js的面向對象機制有了更多的可能性，好比衍生的extends關鍵字(雖然也只是語法糖)。

3. Promise & Reflect API
   
   Promise的誕生其實已經有幾十年了，它被歸入ES規範最大意義在於，它將市面上各類異步實現庫的最佳實踐都標準化了。至於Reflect API，它讓js歷史上第一次具有了元編程能力，這一特性足以讓開發者們腦洞大開。

關於ES2016的最重磅的消息莫過於11月初es標準委員會宣佈將Object.observe從ES2016草案中移除了，儘管它已是stage2幾乎已是事實標準。官方給出的解釋是，這3年的時間前端世界變化實在太大，社區已經有了一些更優秀簡潔的實現了(polymer的observe-js)，並且React帶來的immutable object在社區的流行使得基於可變數據的Object.observe的處境變的尷尬，O.o再繼續下去的意義不大了。

除此以外，ES2016的相關草案也已經肯定了一大部分其餘new features。這裏提兩個我比較感興趣的new feature：

1. async/await
   
   寫過C#的同窗應該對這兩個關鍵字很熟悉了，async/await是爲了更優雅的異步編程作的一個關鍵字級別的封裝，術語叫協程。ES2016中 async/await 實際是對Generator&Promise的上層封裝，幾乎同步的寫法寫異步比Promise更優雅更簡單，很是值得期待。

2. decorator
   
   字面意思是裝飾器，其實等同於Java裏面的註解。註解機制對於大型應用的開發的做用想必不用我過多贅述了。用過的同窗都說好。

目前ES2015/ES2016都有了比較優秀的轉譯器支持(沒錯我說的是babel)，可是也不是all features supported，嘗新的過程當中須要注意。

至於Typescript，你能夠將它理解成加入了靜態類型的js的超集。不過我對於這種轉譯型語言一直不感冒(包括CoffeeScript)，有興趣同窗本身去了解下吧。。

WebAssembly

WebAssembly選擇了跟ES2015在同一天發佈，其項目領頭人是大名鼎鼎的js之父Brendan Eich。WebAssembly旨在解決js做爲解釋性語言的先天性能缺陷，試圖經過在瀏覽器底層加入編譯機制從而提升js性能。這個事情跟當時V8作的相似(有興趣的同窗能夠去了解下JIT)，V8也所以一躍成爲世界上跑的最快的js引擎。可是因爲js是弱類型的動態語言，V8很快就觸碰到了性能優化的天花板，由於不少場景下仍是免不了recompile的過程。所以WebAssembly索性將編譯過程前移(AOT)。WebAssembly提供工具將各類語言轉換成特定的字節碼，瀏覽器直接面向字節碼編譯程序。其實在此以前,firefox已經搞過asm.js作相似的事情，只不過WebAssembly的方案更激進。有人認爲WebAssembly多是2016年最大的黑馬，若是wa能發展起來，若干年後咱們看js編寫的應用會像如今看彙編語言寫出的大型程序的感受。WebAssembly項目目前由蘋果、谷歌、微軟、Mozila四大瀏覽器廠商共同推動，仍是很是值得期待的(寫不下去了我決定回去翻開我那本落灰的編譯原理。。)。

Web Components

webcomponents規範起草於2013年，w3c標準委員會意圖提供一種瀏覽器級別的組件化解決方案，經過瀏覽器的原生支持定義一種標準化的組件開發方式。webcomponents提出之際引起了整個前端圈的躁動，你們彷佛在跨框架的組件化方案上看到了曙光。可是前端這圈子發展實在太特麼快了，在當前這個時間點，webcomponents也遭遇到了跟Object.observe類似的尷尬處境。咱們先來看看webcomponents的幾個核心特性：

1. Shadow DOM
2. Custom Element
3. Template Element
4. HTML Imports

其中一、4如今都能很容易的經過自動化的工程手段解決了(shadow dom對應的是scoped css)，而自定義標籤這種事情不管是React仍是Angular這類組件框架都能輕鬆解決，那麼我用你webcomponents的理由呢？

另外webcomponents將目標對準的是HTML體系下的組件化，這一點跟React比就相對狹隘了(可是這並不代表React把戰線拉的那麼長就不會有問題)。

不過原生支持的跨框架的組件仍是有存在的意義的，好比基礎組件庫，只是在當前來看web components發展仍是有點養分不良。期待2016年能有實質上的突破吧。

架構的變化

2015年出現的新的技術及思路，影響最大的就是技術選型及架構了。咱們能夠從下面幾點來看看它對前端架構上都有哪些影響。

組件化

React的風靡使得組件化的開發模式愈來愈被廣大開發者關注。首先要確定的是，組件化是一個很是值得去作的事情，它在工程上會大大提高項目的可維護性及拓展性，同時會帶來一些代碼可複用的附加效果。但這裏要強調的一點是，組件化的指導策略必定是分治(分而治之)而不是複用，分治的目的是爲了使得組件之間解耦跟正交，從而提升可維護性及多人協同開發效率。若是以複用爲指導原則那麼組件最後必定會發展到一個配置繁雜代碼臃腫的狀態。若是以組件的形態劃分，能夠分爲兩個類型：基礎控件和業務組件。基礎控件不該包含業務邏輯否則達不到拿來即用的效果，所以它也會表現出可複用的價值，可是根本仍是爲了提升業務組件的可維護性。至於業務組件，可複用的價值就很低了。

1. 組件化指的是什麼
   
   組件化這個詞，在UI這一層一般指「標籤化」，也就是把大塊的業務界面，拆分紅若干小塊，而後進行組裝。
   
   狹義的組件化通常是指標籤化，也就是以自定義標籤（自定義屬性）爲核心的機制。這也是咱們一般認識的組件。
   
   廣義的組件化包括對數據邏輯層業務梳理，造成不一樣層級的能力封裝。它不必定是一個自定義語義標籤：它能夠是一個包含邏輯(js)、樣式(css)、模版(html)的功能完備的結構單元，也就是咱們常「口口相傳」的模塊(從術語準確性的角度來看模塊這個描述並不合適，應該稱之爲組件)；它也能夠是一個單純的js，好比http組件這種純邏輯單元。嚴格從概念上來說，css跟html是不具有單獨/組合成一個組件的，它們不具有描述邏輯的能力(非圖靈完備)。從這個層面來看，全組件化是沒有任何問題及疑義的。

2. 是否須要全組件化
   
   咱們一般說的組件指的是狹義上的組件，並且每每咱們理解的全組件化也是創建在狹義的組件基礎上的，
   
   表明框架是React。React＋Flux體系下，它提倡儘量將頁面做細粒度的組件拆分，組件的數據所有由父級組件經過props傳遞而來。這自己是一件很是有價值的事情，能有效的確保應用狀態的穩定及可預測性，可是應用一旦複雜龐大起來，組件樹變得「枝繁葉茂」致使葉子節點層級過深，當出現數據問題時，咱們必須一層層的回溯來定位bug。並且組件樹過於龐大也會增長組件之間的通信負擔。從狹義的組件來看，我對全組件化是存懷疑態度的，工程上的成本過高是最大的問題，並且大部分開發者很難拿捏合適的組件粒度，容易出現過細／過粗的拆分。不少場景其實並不適合實現成狹義上的組件，它以零散的模板的方式存在更合適。
   
   可是若是從廣義的組件來看，全組件的意義是很大的，咱們須要經過拆分頁面邏輯區塊的方式實現程序的解耦，從而提高應用的可維護性。

綜合來看，我以爲工程上更具可行的全組件化方案應該是：細粒度的基礎組件庫 + 粗粒度的模板/組件。

工程化

工程化是近年前端提到最多的問題之一，並且我的認爲是當前前端發展階段最有價值的問題，也是前端開發通往工業化時代的必經之路。這裏不贅述，有興趣的同窗看我前陣子整理的一篇文章前端工程化知識點回顧

應用架構層 MVVM & Flux

MVVM想必大部分前端都耳熟能詳了，表明框架是angular、vue、avalon。angular在1.2版本以後加入了controllerAs語法，使得controller能夠變成一個真正意義上的VM，angular整個架構也才真正能稱之爲嚴格的MVVM(以前只能說是帶有雙向綁定的MVC/MVP)。

Flux是facebook隨React一併推出的新的(準確來講實際上是改進的，並不是原創)架構模型，核心概念是單向數據流。Flux實質上就是一個演進版的中介者模式，不一樣的是它同時包裝了action、store、dispatcher、view等概念。關於Flux對應用分層、數據在不一樣層之間只能單向流轉的方式我是很同意的。應用的分層在業務稍複雜的應用中都是頗有必要的，它更利於應用的伸縮及拓展，反作用是會帶來必定的複雜度(在我看來這點複雜度根本就能夠忽略不計)。

今年被黑的最多的前端主流框架莫過於angular了。老實講前端圈真的挺善變的，去年各類大會都在分享angular黑jquery，今年就變成了都在分享react黑angular了。黑的點大體有三：

1. angular的部分實現太low
2. 太多Java身上帶來的臭毛病(並無在黑Java)
3. mvvm自身的缺陷

第一點第二點我並沒有異議。angular的髒值檢測機制相對於其餘mvvm框架的雙向綁定實現方式確實不太優雅，一樣有硬傷的還有失敗的模塊語法及過多過於複雜的概念。可是對於第三點，我有不一樣的見解。

大多數人黑mvvm會以Facebook那張經典的flux vs mvc的圖爲論據，對於雙向綁定形成的數據流紊亂及應用狀態的不肯定致使問題定位困難的觀點我是認同的，這一點我也有切身體會，可是單純的這一點就足以否認mvvm麼？就說flux比mvvm高明？

MVVM在富表格型(自造的詞😄)應用開發效率上是高於Flux的，典型的就是一些後臺管控平臺。並且最重要的是，MVVM跟Flux並不互斥，咱們在MVVM中照樣能夠引入Flux中的一些機制從而確保應用狀態的穩定。不少時候咱們對於框架／架構的孰優孰劣的爭論是沒意義的，拋開業務場景談解決方案都是耍流氓。

業務數據層 Relay & falcor

這一層對大部分前端來講多是比較新的概念，其實咱們能夠這樣理解：在一個完整的應用中，業務數據層指的就是數據來源，在angular體系中能夠等同於ngResource模塊(準確來講應該是$http)。

Relay是f家推出的在react上應用GraphQL的框架，它的大體思路是：前端經過在應用中定義一系列的schema來聲明須要的接口數據結構，後端配合GraphQL引擎返回相應的數據。整個事情對於前端來講意義簡直是跨時代的，工業化典範！不只能極大提高先後端協同的開發效率，還能增長前端對於應用完整的掌控力。可是目前來看問題就是實施過於複雜，並且還得後端服務支持，工程成本過高，這一點上Meteor顯然作的更好。

falcor則是Netflix出品的一個數據拉取庫，核心理念是單一數據源，跟Redux的單store概念一致。用法跟Realy相似，也須要前端定義數據schema。
另外還有一個新的W3C標準api：fetch，它的級別等同於XMLHttpRequest，旨在提供比ajax更優雅的資源獲取方式，目前幾個主流瀏覽器支持的都還不錯，也有官方維護的polyfill，幾乎能夠肯定是將來的主流數據請求api。

業務數據層是前端應用中比較新的概念，它的多元化主要會影響到應用的架構設計，這裏不細講後面再來講。

新的編程範式

函數式編程(FP)

函數式編程(functional programming)是近年比較火爆的一個編程範式，FP基於lambda演算，與以圖靈機爲基礎的指令式編程(Java、C++)有着明顯的差別。lambda演算更關注輸入輸出，更符合天然行爲場景，因此看上去更適合事件驅動的web體系，這點我也認同。但問題是，太多開發者看到redux那麼火爆就急着學redux用js去玩函數式，我以爲這個有待商榷。js做爲一個以基於函數(scheme，父親)跟基於對象(Self，母親)的編程語言爲藍本設計而後語法又靠近Java(隔壁老王)的「混血」語言，你非得用它去寫函數式，是否是過於一廂情願？尤爲是在如今瀏覽器還不支持尾調用優化的狀況下，你讓那激增的調用棧可如何是好😂若是你確實鍾情於函數式，能夠去玩玩那些更functional的語言(Haskell、Clojure等)，而不是從js入手。最近看到一個老外關於js的函數式編程的見解，最後一句總結很精闢：Never forget that javascript hate you.😂

函數式響應型編程(FRP)

函數式響應型編程(functional reactive programming)不是一個新概念，但也不過是近兩年才引入到前端領域的，表明類庫就是ng2在用的rxjs。FRP關注的是事件及對應的數據流，你能夠把它看做是一個基於事件總線(event bus)的觀察者模式，它主要適用於以GUI爲核心的交互軟件中。但FRP最大的困難之處在於，若是你想使用這樣的編程範式，那麼你的整個系統必須以reactive爲中心來規劃。目前微軟維護的ReactiveX項目已經有各類語言的實現版本，有興趣的同窗能夠去了解下。

工具鏈的變化

去年最主流的前端構建工具仍是grunt&gulp，2015年隨着react的崛起和web標準的快速推動，一切又有了新的變化。

webpack & browserify & jspm

webpack跟browserify本質上都是module bundler，差別點在於webpack提供更強大的loader機制讓其更變得更加靈活。固然，webpack的流行天然仍是離不開背後的react跟facebook(可見有個強大的乾爹多麼重要)。可是從如今HTTP/2標準的應用及實施進展來看，webpack/browserify這種基於bundle的打包工具也面臨着被歷史車輪碾過的危機，相對的基於module loader的jspm反而更具前景(雖然如今使用前二者的開發者都多於jspm)。

PostCSS & cssnext

PostCSS做爲新一代的css處理器大有取Sass/Less而代之的趨勢，Bootstrap v5也有着基於PostCSS去開發的計劃。但從本質來說它又不算一個處理器，它更像是一個插件平臺，能經過配置各類插件從而實現預處理器跟後處理器的效果。
cssnext官方口號是「使用來自將來的語法開發css，就在今天！」，可是cssnext又不是css4，它是一個能讓開發者如今就享受最新的css語法(包括自定義屬性、css變量等)的轉換工具。這一塊筆者尚未過具體實踐，暫很少言。

寫在最後

從前端的發展示狀來看，將來理想的前端技術架構應該是每一層都是可組裝的，框架這種重型組合的適用場景會愈來愈侷限。緣由在於各部件不可拆卸會增長架構的升級代價同時會限制應用的靈活性。舉個例子，我有一套面向pc端的後臺管控平臺的架構，view層採用angular開發，哪天我要遷移到移動端來，angular性能不行啊，我換成vue就行了。哪天以爲ajax的寫法太挫，把http層替換成fetch就行了。又有一天後端的GranphQL平臺搭好了，我把ngResource換成relay就OK了。

這種理想的方式固然是徹底正確的方向，可是目前來看它對 開發者/架構師 的要求仍是過高，工業級別上一套帶有約束性的框架仍是有至關的需求的(特別是當團隊開發者的水平參差不齊時。固然我以爲更正確的方式是流程上有一套完整的自動化方案用於確保團隊提交的代碼質量，只是目前基於動態分析的代碼質量檢測工具尚未出現，並且估計很長一段時間內都不會有)。雖然美好可是組合的方式也不是沒有問題，各類五花八門的搭配容易形成社區的分化跟內耗，必定程度上不利於整個生態圈的發展。

近年前端生態的野蠻發展影響最大的應該就是新產品的技術選型了，亂花迷人眼，咱們很難設計出一套適應大部分場景、並且短期內不會被淘汰的架構。前端的變化太快一般會致使一些技術決策的反覆，今天的最佳實踐極可能明天就被視爲反模式。難道最合適的態度是各類保留各類觀望，以不變應萬變？在這一點上即便如我這般在技術上一貫激進的人都有點畏手畏腳了。那句話怎麼說的來着？歷來沒有哪一個圈子像今天的前端同樣混亂又欣欣向榮了。有人說2015年或許是大前端時代的元年，目前看來，若是不是2015，那麼它也必定會是2016年。

最後引用計子winter的一句話做爲結語吧：

前端一直是一個變化很快的職能，它太年輕，年輕意味着可能性和機會，也意味着不成熟和痛苦。我常常擔憂的事情就是，極可能走到最後，咱們會發現，咱們作了不少，卻仍是一無所得。所幸至今回顧，每一年仍是總有點不一樣，也算給行業貢獻了些經驗值吧。

著做權歸做者全部。 商業轉載請聯繫做者得到受權，非商業轉載請註明出處。 原文連接：https://github.com/kuitos/kuitos.github.io/issues/32 來源：github