如何正確地總結 2016 前端技術？
在反駁別人的文章中零散插入自己對 2016 前端技術的總結不免有些浪費，或許可以來直接討論一下您對 2016 前端技術有什麼樣的觀察？
有很多人邀我回答。其實要知道我的看法很簡單，看Hax 參加的活動。
第一，看我2016年做過哪些speech；
《如何看待leftpad事件》
《代碼時間：ES2015》
《如何寫一個 babel plugin》《前端構建的過去現在和將來》《ES2017實戰》《JS@2017》特別是最後一個在SFDC上的開場演講，本身就是總結和展望性質的，裡面涵蓋了JS的各方面發展。
註：其他有幾場speech（比如api設計）是和2016年這個時間點關係不大的。
第二，看我2016年組織過哪些技術活動；
BXT-007：請 @郭達峰講react native實踐
BXT-008：請 @尤雨溪講vue的設計
BXT-008：請 @徐飛講rxjsQCon前端專題，作為出品人，組織和選擇了以下主題：
PWA （黃玄）
Vue （尤雨溪）React同構 （蔣吉麟）3D技術運用 （仙羽）註：其他兩場（前後端分離、JS異常監控）偏工程實踐，還有DT時代的前端思考是涉及前端職業發展、團隊等綜合內容的，是和2016年這個時間點關係不大的（但是反應了相關領域到2016年的狀況）。
我列入候選議題但是因為時間和講師安排原因沒能放進去的主題：
HTTP2（這個最遺憾）
GraphQL/RelayWebComponentsWebVR另有一場關於TypeScript的因為最後放不下了，所以移到了另一個專題場。
當然，我肯定有未能涵蓋到的，特別是CSS領域的，比如昨天在CSSConf上大漠講的 CSS Grid Layout，這次未能請到嘉賓講的 CSS Houdini 等，都是對未來可能產生非常巨大影響的。
以上，謹供大家參考。說個語言上的看法: 2016 年 WebAssembly將會給前端帶來革命性的變化，但是同樣非常值得期待的是JavaScript 平台上終於有了第一個專業的靜態類型函數式編程語言bloomberg/bucklescript 我們正在和React 的核心團隊緊密合作 推出下一代的 ROR (React on Reason) 2017將會是非常值得期待的。
JavaScript 平台上目前相對成熟的語言是TypeScript 但是同樣受制於JS平台限制 TypeScript很多事情做不了。而 R B (Reason BuckleScript) 可以很成熟的編譯到 ARM(Android/iOS), X86, PPC 還有非常優化的JS 後端。
舉三個例子:
1. 編譯速度 （編譯55個文件）冷啟動只需要580ms 基本上可以吊打任何一個JS編譯器了
大家說的都是大趨勢，我說幾個不那麼顯眼的小趨勢吧。
第一，大家最近都注意到 flv.js 了吧？其實今年類似的應用有不少。2016 年，「在網頁上播視頻」這件事兒正在變的越來越複雜了。MSE、WebSocket、WebGL 這幾個東西在今年逐漸組成了一個完整的技術棧，socket-&>拆包組包-&>解碼-&>自繪渲染這套流程在瀏覽器端算是徹底走通了。尤其是主流線上項目的出現，為這類方案提供了很好的背書。
這是一個影響深遠的事情，因為它標誌著 web 前端在框架之外，從另一個方向趨近於傳統客戶端（實際上我覺得框架不是趨近於客戶端，而更像趨近於 java）。二進位回來了，2D3D 自繪也回來了，tcp 換了個馬甲回來了，sqlite 本來就在瀏覽器中。還有個東西可能很重要，就是 GraphQL，它如果流行起來會引起前後端厚度比例的巨大變動。
SPA 和各種前端框架興起之後，前端變得越來越重，但是更重的還在後面。上面這些東西會讓前端真正超越「列表頁」，超越「輕應用」，從而進軍行業軟體市場。
第二，WebRTC 16 年發展的也不錯，雖然編碼統一問題還是沒解決，但光是國內就出現了好幾個真正實用化的產品。現在，找工作時打開網頁面試已經不稀奇了。
第三，http2 和 rollup 在 16 年基本上進入了大家的共識，就看明年能不能全面開花了。這兩個東西可能會完全改變前端部署和優化的走向，目前看來，毫無疑問是簡化。
第四，我做個預測吧。明年（17年）可能會出現使用 WebGL 渲染的 JS 版瀏覽器內核。總結就是剛學會一樣，馬上它就過時了
最近兩個月里寫了兩篇相關的文章：
- 《從2016年11月期《技術雷達》看前端的未來》
- 一個是為 CSDN 《程序員》雜誌寫的《盤點 2016 年的移動 Web 發展》
本文僅代表 Phodal 的個人觀點，來聽聽一個前端程序員的 YY。
新一期的技術雷達有點出乎意料，使用new標籤的框架、工具、技術、語言等等超過了一半——Vue.js、ES2017上榜，Three.js憑著VR的火又上榜了，還有熟悉的Electron，以及微前端的概念。
讓我們先看看一些技術亮點~。
前端在可見的未來在那篇《最流行的編程語言JavaScript能做什麼？》的文章里，我們看到了JavaScript在各個領域的應用。在這一期里，仍然有很多亮點（new）：
Vue.js，如果你在使用Vue.js，那麼你更應該找到相當的自信了，現在它已經被列入了評估期了。Vue.js是一個簡單易上手的框架，並且相當的輕量，在最近的這段時間裡，它發揮得相當的出色。
可惜，寶寶現在在用Angular.js 和 Angular 2，畢竟我現在是開發混合應用的。不過相信在半年後，Angular 2 和 Ionic 2是會上榜的。
Ember.js，儘管沒有證據表明這個框架在國內將火起來的趨勢，我現在還對這個框架缺乏深入的了解。
ECMAScript 2017，儘管我現在已經傾向於使用TypeScript，不過 ES2017 還是會用到的，只是我覺得 Babel 對我來說就是個坑啊
Electron，如果你是一個老讀者，那麼你已經知道我在很多場合里使用了這個框架，從NodeWebkit開始寫編輯器，再到用Electron完成Growth 1.0的桌面版。
Physical Web，現在我們可以在瀏覽器上來控制真實世界，通過藍牙低功耗技術。
不過與此相比，我更看好 Progressive Web App，畢竟他可以讓Web應用接觸到更多的底層API，而不是局限於藍牙，還可以是Push Notification等等。
Three.js，它上榜的原因是因為 WebVR 的流行。這一點可以從我去年寫的那篇《Oculus + Node.js + Three.js 打造VR世界》，就可以看到一些趨勢。這些就和現在的單頁面應用一樣，雖然運行起來不是那麼流暢，但是還是行得通。因而在可見的未來使用 Web 技術來開發 VR 也有一點苗頭，未來瀏覽器上應該是可以運行編譯過後的代碼，而不是在運行時。
WebRTC，它可以讓我們在瀏覽器端實現實時視頻聊天。第一次接觸到這個視頻流技術是在兩年多以前，上一次接觸則是在半年多以前使用 WebRTC + Oculus，你可以在我博客的那篇《JavaScript在VR世界的應用》中了解到更多的詳細信息。當然如雷達所說，WebRTC將會形成未來在Web上進行AR/VR 協作的基礎。
接著再讓我們看看一些架構上的變化吧。
前端引起的架構變化在過去的兩三年里，前端火得一塌糊塗——對於後端程序員來說，這有點 winter is coming 的感覺。我在那篇《前端演進史》對前端的演進做了相當多的介紹，並在《後台即服務演進史》里對後台即服務開了個頭，在這篇文章里讓我們根據《技術雷達》來繼續補幾刀。
我們可以看到在中大型團隊里，已經分解為前端和後台兩個小組，溝通可以通過介面、契約等等的方式來進行。但是這一點兒也不精益，溝通在這時仍然是一個問題，讓我有點懷念起之前前後端都做的項目了——自己可以創建自己想要的介面。
不過，這意味著前端和後台在技術選型上更加獨立了。
臃腫的前端——微前端
在上一個項目里，我們一步步地將一個有近10年系統的系統替換掉。起初這是一個傳統的Spring + JSP網站，然後我們用JSP創建了JSON API，後來創建了一個新的 API 來服務移動應用和單頁面應用，再後來這個 API 被拆分成了幾個 API。我們的後台已經成一個單體應用變成了一個微服務架構的應用，但是這一點並沒有在前端上應用——前端應用正在變得難以維護。
因此在這一期的雷達里，你可以看到微前端的概念（micro frontends）。這也是在上一個項目里，我們嘗試做的一部分，遺憾的是並沒有成功完全實施。這是一個搜索類型的網站，網站的首頁承擔著大部分的訪問量，而詳情頁的主要流量來源則是搜索引擎。我們在首頁上使用jQuery + Require.js技術棧，而在其他頁面（搜索結果頁 + 詳情頁）使用 React.js，我們在最初的時候考慮過將詳情頁靜態化——因為需要 SEO 的緣故，這樣可以讓我們降低 SEO 帶來的複雜度。
後來，我也在我的博客上解耦了兩部分，為了更快的訪問首頁的速度——將首頁獨立出來，不使用JS，直接使用Pure.css來擔重任；在其他頁面里使用Material Design Lite作為 UI 部分。
有一點值得考慮的是：對於微服務架構來說，在一個系統的不同的部分使用不同的技術棧是一種不錯的體驗；而對於一個前端團隊來說，在同一個系統的使用不同的技術棧就不是一種不錯的體驗。
API 設計——應該變得簡單
如我們所見的Spring Boot已經變成推薦採用的程度了，按雷達上的習慣用語：「我們已經在多個項目上使用這個框架」——反正我最近的項目都是用這個框架。如果你考慮使用 Java，那麼你一定不要錯過這個框架，以及使用這個框架來實施前後端分享。
對於大部分不需要考慮 SEO 的應用來說，將後台變成一系列 RESTful 的 API 並不是一件複雜的事，但是在後台 API 上的設計就變成一件麻煩的事。因此儘管在實見的過程中，有契約來作為保證，但是不一定是可靠的。作為一個前端程序來說，我們在調用後台 API 的過程中，總會遇到這樣、那樣的問題。除此，還有介面不好用的問題——「要是你可以在這裡使用超媒體 API，那麼我的代碼就會更加簡單了」。
因此在 API 設計上，雷達上給出了兩個不錯的案例：
強化後台查詢
代表的例子就是 Facebook 的 GraphQL，它是在 Facebook 內部應用多年的一套數據查詢語言和 runtime。原本為了請求一個用戶及其好友信息的請求，需要發起多個 API 請求。現在，我們只需要在客戶端拼裝好對應的 Query語句，在這個語句里將大部分需要查詢的東西寫好，即 JSON 格式的數據，然後發給服務端來處理。而在我們客戶端上，我們所獲取到的結果都是我們所需要的，不需要再做特殊處理了。
這一切，看上去很美好——除了，在客戶端上拼查詢語句。
過去，我們使用搜索引擎來搜索數據，就需要在前端拼好對應的 Query，再傳給後台 API，由後台 API 返回我們需要的結果。在這個過程里，我們在Query做一些對應的數據處理。
反正，他們都是使用查詢語言來搜索結果。如果你考慮使用 QL 的話，不妨做一層 Wrapper，以後好做遷移。
前後端同時優化
Netflix對於這樣複雜的API請求下，創建了 自己的庫Falcor——它可以從多個數據源獲取數據，並在服務端上匯總成一個 JSON model；在客戶端上，請求的時候我們只需要在請求的時候加上對應的參數即可——可以將多個請求合併到一起，也可以只針對某一個部分發出請求。這樣可以減少發出多個請求，所帶來的複雜度。
我想，一種最實用的做法：就是將一些更新頻率較低的API合併成一個大的 API 了——大部分人都會這樣做吧。
簡化的後台——無伺服器架構
我就不多說了~，讀者可以自己去看。
在之前的那篇《從2016年11月期《技術雷達》看前端的未來》，我介紹了關於前端未來的一些想法。在這篇文章里讓我們來看看移動 Web，領域又有怎樣的變化 ？
第二篇 《盤點 2016 年的移動 Web 發展》本文為《程序員》2016年12月期原創文章，未經允許請勿轉載，更多精彩文章請訂閱2017年《程序員》。
在這一年裡，一些前端框架已經趨於穩定，我們可以看到諸如 React 這樣的框架在一些大型項目中的採用。除了這些常規的移動 Web 應用，在今年九月底微信小程序的火熱，也開啟了移動 Web 的一扇新門；Google 推出的 PWA 也讓越來越多的開發者看到了移動 Web 的更多可能性。
面臨的問題及考驗儘管網路速度正在變得越來越快，但是移動 Web 頁面的體積也越來越大。單頁面應用的體積在首次載入時，仍然值得我們好好研究——如何更快展示用戶需要的內容，而不是讓用戶在頁面載入的過程中等待著讓他們離開。除了使用服務端渲染來優化初次體驗，我們還需要設置緩存，使用一些技術策略來加快用戶打開的速度。
然而，我們仍然還面臨著一堆亟需解決的問題。比如在服務端採用微服務架構來加速開發，當我們需要在一個頁面里請求大量 API 時，微服務架構就會成為一個新的問題。當用戶在請求過程中切換頁面時，就需要中斷大量 Promise 請求。因此就需要使用 GraphQL 或 Falcor 這樣的 API 框架來減少客戶端 API 請求。
安全除去上面這些內部因素，移動 Web 應用還飽受外部因素困擾。在2016年，我們發現越來越多的移動站點正深受運營商劫持的影響，由於 HTTP 協議是明文的，而流量都要經過運營商，因此運營商可以輕而易舉地在頁面中植入廣告。這時，解決問題的有效辦法就是全站 HTTPS。
與此同時，對於安全的考慮也仍然值得注意。我們意外地發現一些移動 Web 網站只在前台做了數據校驗，而缺少後台的數據檢驗，這會帶來相當大的安全隱患。
臃腫的前端代碼前端項目正在變得越來越臃腫，體積讓人難以接受。在缺乏單元測試的項目里，維護這樣的一個前端項目正在變得舉步維艱。當後台走向微服務的同時，前端走向微前端也變得可以接受。一個應用程序可將基本需求分解為不同的幾個前端頁面，如面向用戶、面向管理員。
儘管已經有了如 React 這樣的 CSS in JS 的框架，維護 UI 組件仍然是一個相當大的考驗。移動 Web 對於屏幕大小有更高的要求，響應式設計會帶來更多代碼。樣式代碼數量的增加，對於前端的樣式架構有了更大挑戰。如我們所見 SCSS 或 SASS 這樣的 CSS 預編譯器可以帶來更少的代碼，而對於項目中的新人來說，仍然是個問題——在項目進行過程中，我們往往關注於如何更快地交付功能。
相似地，我們也可以在社區開發的開源庫上看到一些「微前端」趨勢。藉助於 ES6 的模塊化功能，我們可以在項目中只 import 所需的函數，在使用 webpack 打包的過程中也會刪去那些不需要的模塊。過去我們使用一個庫的某個方法時，可能就會考慮直接創建一個類似的庫，而不是引入——原因是這個庫對於應用來說太大了。
框架及工具從傳統 Web 網站到單頁面應用遷移的第一個難題是：是否真的需要單頁面應用？單頁面應用更多的是帶來用戶體驗的提升，然而很多網站並不需要這種變化，大部分網站只需要支持更好的響應式設計。
在上一個項目里，我們使用了 React 來替換之前的桌面及移動站點。除了代碼老舊之外，還有部分原因：業務變更時需要修改三份代碼。舊有的舊面網站代碼可以追溯到2010以前，難以維護；移動站點是在2013年底創建的，使用當時流行的 Backbone + Mustache + Require.js 技術棧；與此同時還有手機 App。
當我們決定做一個移動單頁面應用時，就需要開發考慮對於技術方案的選擇。
框架選型
而在這一年裡，開發人員在做技術選型時，發生了一些有趣的變化。首先是 React 對於大部分的開發人員來說，存在學習曲線比較陡峭的問題，JSX、虛擬 DOM、組件化、同構等，使其無法成為短期項目的首選；其次是 Angular 2.0 的跳崖性升級，使得相當多的開發人員無法選擇 Angular.js 1.x 的版本，而2.0在接近年底才完成，且周邊的組件還有待完善；因此，我們發現 Vue.js 由於其簡單並且容易上手，在今年顯得特別受歡迎。
幸運的是：上述三個框架，都有對於混合應用的應對方案。這使得我們在設計系統架構的時候，更容易復用代碼。
2016年里，在移動和桌面 Web 使用 Angular.js，移動端使用基於 Angular.js 的 Ionic 框架是非常不錯的技術選型。Ionic 擁有相當多設計優美的 UI 組件，這些組件可以讓我們輕輕鬆鬆地做出移動應用。並且，我們也可以和 Web 端共用 filter、directives、services 等的內容。相信在2017年，Angular 2.0 搭配基於 Angular 2.0 的 Ionic 仍然是好選擇。
我們也可以使用 React 框架來做類似的事。儘管有相當多的開發者選擇使用了 React Native，但是這不意味著我們需要在移動端使用它。在移動端使用 Cordova + React 也是一個不錯的選擇——既然可以使用 React 做響應式設計來匹配不同的屏幕大小，那麼也可以很輕鬆地使用 Cordova + React 來達到同樣的目的。
同理於 Vue.js，儘管 Weex 還不是很成熟，但是使用 Cordova + Vue.js 也仍然不錯。
開發工具越來越完善在這一年裡，我們發現能選擇的開發工具越來越多。不同的開發商都在不斷創造開發工具，這些工具可以幫助我們編寫出更好的代碼，開發出符合用戶需求的軟體。
現在市面上的主流前端開發工具都已經可以支持 ES6、TypeScript，並且不同的瀏覽器對於 ES6 的支持力度也在提高，Edge、Firefox、Chrome 對於 ES6 特性的支持度均在90%以上，而 Safari 瀏覽器則達到了100%。這也意味著對於面向 iOS 的移動 Web 應用，可以很隨意地在這些設備上使用 ES6 語言了。
並且各瀏覽器對於移動設備的調試能力都在不斷提高。在開發移動 Web 頁面時，我們使用 Chrome 瀏覽器來匹配移動設備。而在新版本的 Safari 里也提供了「進入響應式設計模式」的功能，它可以模擬常見 iPad、iPhone 顯示網頁，甚至可以模擬 iPhone 橫屏。
Adobe 在今年推出了 UX 工具 Experience Design（官方縮寫XD），可以為 UX 設計師快速創建出用於移動設備的網站或者應用程序。這個工具除了具備響應式設計能力，還可以實現簡單的 App Demo，如在桌面上點擊某個頁面跳轉，並具備有頁面間跳轉的效果。這可以讓開發者更容易理解產品的設計原型，創建出更符合需求的產品。
提供更好的用戶體驗對於在早期已經採用單頁面應用的團隊來說，他們面臨的一項新挑戰是：如何提供更好的用戶體驗。
更好的用戶交互
相當有意思的一點是，我們發現業務人員對於移動 Web 的要求更高了，他們希望有著類似於移動應用的用戶體驗。過去，在移動 Web 領域使用 Tap 事件來代替 Click 事件只是一個開始——使用 FastClick 這樣的庫來規避 Click 事件的延遲。
手勢交互： 下拉時刷新在移動 Web 上已經不是新鮮的事，我們還要類似於微信的左右滑動切換不同的頁面，除此還會有旋轉、縮放等功能。
適配屏幕大小： 對於移動設備來說，屏幕是個大問題，應用既要支持 iPhone 這樣的小屏幕，還要匹配上 iPad 這樣的設備。可以使用媒體查詢來解決，但設置合適的字體還是問題。px、em 已經很難滿足要求了，我們還需要 rem 這樣可以根據網頁的根元素來設置字體大小的單位。
更流暢的體驗過去，我們關注的移動 Web 流暢度主要集中於緩存。當緩存已經成為了業界的通用模式時，人們便開始尋求更多的解決方案。如對於流量來自 Google 的網站來說，他們可以使用 Accelerated Mobile Pages（AMP）技術來加快網頁的載入，這可以為新聞和博客網站帶來更快的訪問速度。
與桌面相比，移動 Web 頁面對流暢度有著更高的要求，這主要是受限於移動設備。儘管新 iPhone 提供了相當快的處理能力，各大 Android 設備生產商在競爭中也在不斷提高設備的處理能力，但是仍然有相當多的用戶使用舊版移動設備。
在移動網頁上，除了採用支持 Virtual DOM 的框架來提高性能，還可以採用 Virtual Scroll 機制——只渲染足夠填充 Viewport 大小的數據集，頁面滾動時再渲染新數據，以此改善移動端列表頁面數據過多的問題。
除了對於頁面本身的優化，還有相當多的內容是對於資源和 API 優化。Facebook 創建了 GraphQL 來減少 API 的請求，一次請求多個需要的 API；Netflix 創建了 Falcor 來合併多個數據源。這些都可以加快移動應用的響應速度，除此我們還注意到 Service worker 開始受到開發者追棒。
Service worker 是在 Web 應用和瀏覽器與網路之間的代理伺服器，旨在創建更好的離線體驗。並且可以依據當前網路是否可用、伺服器是否有內容更新來採取合適的策略。同時它還支持通知推送及後台 API。
2017年移動 Web 展望在這一年裡，我們也看到了一些新東西正在展露頭角，Google 推出了 Progressive Web Apps（PWA），微信也推出了小程序。
微信小程序如微信小程序官方介紹所說：
微信小程序是一種全新的連接用戶與服務的方式，它可以在微信內被便捷地獲取和傳播，同時具有出色的使用體驗。
用戶只需要在微信客戶端下載相應的小程序，就可以直接使用，用完即可離開。由於微信本身的封閉屬性，小程序的運營和推廣上仍然會有相當多的難點，同時也造成了一些傳播上的難題。
不過微信自帶了 WebView，開發者在開發時只需要針對不同操作系統的設備開發軟體即可，不容易再遇到不同版本上的瀏覽器差異。同時微信小程序使用自己的 Web 框架，開發者需要重新上手這個框架，由於小程序還處於測試版，仍然還有相當多的 Bug。
PWA
PWA 是 Google 在 Google I/O 2016 大會上強調的移動 Web 應用程序方向，我們可以翻譯為「漸進式應用」。它結合了 Web 和原生應用程序的優勢，提供了更好的用戶體驗：
- 應用程序不需要安裝；
- 不依賴網路連接，可以支持離線使用；
- 提供類原生應用的體驗；
- 自帶響應式用戶界面；
- 持續更新，通過 Service worker 讓應用程序保持在最新的狀態；
- 可安裝在桌面等。
它為開發混合應用的開發者提供了一個新方向，雖然受限於國內 Chrome 普及率，但是我們仍然很看好這項技術。
在這一年裡，我們也看到了 Google 正在推進 Web NFC API、Web Bluetooth API、Web USB API 等原生 API 的發展。現在，已經可以在 Chrome 瀏覽器上通過編寫 JavaScript 來開發藍牙應用，這也使得 PWA 可以製作出更富有質量的移動 Web 應用。
轉載保留（原文鏈接：《從2016年11月期《技術雷達》看前端的未來》）
訪問 Technology Trends for 2016 獲取最新一期ThoughtWorks技術雷達。（PS：如果你訪問不了原文鏈接，可以修改DNS為 8.8.8.8，或者放在我的GitHub Page上的備份：http://radar.phodal.com/2016.pdf ）
還沒看到前端和人工智慧的交集，這才是革命性的
這裡我只說一個點，就是關於前端三大框架選型的事情，也是昨晚 D2 幾位嘉賓討論過的問題。
接著一年前的問題，我們還是看社區的增長和完善度 vue、react和angular 2.x誰是2016年的主流？。
vue 增長非常快，從去年 react 的 0.039720768 到縮短到今年的 0.101673795 左右，但體量上還是要小很多。可以看下明年的數據會發生什麼變化。
angular 包括 angular 1 的數據相比去年自己增長了一倍，仍然是社區數量最多的，但相比 react 來說，react 從去年的 0.45711277 的比率，現在縮短到了 0.780372575，很有可能明年會超越 angular。
@徐飛量子通訊
上了衛星，突破未來超乎想像這是我前兩天看到的由StuQ小夥伴總結的技術圖譜（下面鏈接會有高清大圖）：
另外還有對需要學習內容的歸檔。在此附上截圖和鏈接。
GitHub 鏈接：
https://github.com/TeamStuQ/skill-map我只是搬運工。但是如果大家看著不錯，回來點個贊。
先聊一聊框架，個人會一點點Vue 和 react， 對於這兩個框架這一年看法有幾點：
- 倉庫本身
- Vue 更新到了 2.0， 可以做後端渲染了。主要 feature 除此之外就是 transition 了。其他我認為主要是對易用性的更新，這些都很細節了。Vue 本身對於易用性 和 性能這兩方面都有做過努力。
- react 更新到15，解決了一些歷史問題，比如data-reactid，這是因為瀏覽器的版本不同，之前的實現會更快，現在更換了實現，主要是性能方面的提升。react 的倉庫本身設計了一套版本演進系統，這個系統讓社區和開發者有一個好的 API 變更機制。
- 社區發展
- Vue 在國內的社區發展應該是比較明顯好過於 react 的，因為 Vue 在易用性上做了很多的功夫，很多細節上的開發體驗很棒，有各種各樣的語法糖縮寫。比如申明模板 classname 的時候可以用變數 { show: isShow, active: isActive }, react 想要做到類似的效果也是可以的，但是要引入一個叫 classnames 的三方庫。這些細節在學會之後的開發體驗真的很好，react 相對會面臨比較難的配置問題。各種方面來看，很多人對易用性的需求是高過一些抽象概念的需求的，這個也和前端開發的內容相關。
- react 本身主要目標是優化性能和去除一些歷史性的冗餘設計。其他部分都會交給社區來做，react的版本變更機制是有意識的引導社區在參與更多的東西。但是壞處很明顯就是react作為一個系統會演化的相當複雜，比如模板會產生很多，然後有的會逐漸沒有人維護，但是仍然會有高star，這些對於新手來說是非常難理解的。還有redux relay的發展也讓很多人不知道應該怎麼選擇，facebook 本身是要用 relay 的，但是社區更喜歡redux。所以這一段時間來說，react 官方出了 create react app， 試圖解決這個問題，但是對於數據流方案來說，對於新手仍然需要一些努力才能理解。在易用性上來說個人覺得是沒有 Vue 好的。社區上也出現了mobx 這樣的庫，致力於易用性，之前好像叫mobserveX 什麼的，也是有比較好的反響。
小菜鳥說下一下感受吧，準備發點火爆朋友圈的文章
一個驚人發現，出現了只會react和vue，不會jquery的面試者！
震驚了，vue發布了2.0絕世angular發布了2.0，並且年後要搞4.0世界上最火的react版本號干到15了震撼！webpack一直說2.0，現在還是beta版知乎成功居然還能搞了幾場前端的live，很成功ES6成為基礎技能的秘籍RXJS的其他用途年底某專家有噴了前端所有流行技術 告訴你從未公開過的刷存在感的訣竅分隔符還是python堅挺，3發布了七八年，社區還是很多人用2.7不是黑python，我雖然是前端，但是平時寫東西還是用python（2.7） 囧希望明年前端圈不要有那麼多撕逼事件了，沒啥意義，借鑒一句很喜歡的話 ，talk is cheap,show me the money總結一下，需求的不停改變，導致實現需求的方式總是在不停改變。
個人觀點感受，歡迎交流：
1.框架（和庫）方面：最火的幾個框架，無非就是Angular，vue，react等。想想他們為了解決什麼樣的需求？這裡有篇文章vue作者 @尤雨溪 13年寫的開源前端框架縱橫談-CSDN.NET，在我看來，最基本的需求是不變的。那變得是什麼呢？13年3月react最初的版本發布，那時候react還是個孩子。大家寫網頁的方式可能就跟阿當老師說得那一套，基於jquery的封裝，或者基於jquery的混亂編程。而我對angular不了解就不說了。而現在vue和react在做什麼呢？可以看看尤老師的那篇文章我看到滿滿vue的影子。然後剩下我的理解- 無非就是提高代碼的可維護性復用性
- 在頁面的複雜度很高的狀態下，更好的管理頁面的的狀態。
- 更好的控制數據的流向。
- …
那為什麼以前沒有這樣的框架或者庫嗎？是寫前端的人變厲害了嗎？我想應該不是，應該是當時沒有這樣那樣的需求？同時瀏覽器的應用場景沒有那麼多，瀏覽器還沒有發展到現在的程度。現在條件剛剛好，"客戶"剛好有這麼一些需求，當然前端的複雜度就提上去了。
所以我認為正確對待框架或者庫的方式——按應用場景分類，用不同的框架，一切拋開實際情況的選擇都是耍流氓。當然個人喜好除外比如徐大大。2.工具方面
因為node語法對前端的友好，和打開方式的簡單。衍生出很多構建工具：gulp/grunt/webpack（webpack叫構建工具可能不太恰當），然後他們背後有很多牛人寫的插件，解決不同的問題——js/css/html等預處理器啊、打包啊、等開發者需求。所以我認為工具的不停改變為了滿足開發者的在生產環境源源不斷的需求。3.JS/CSS/HTML自身語言方面
先說我熟悉的js，ES7定稿了，ES6很多不停升級的瀏覽器已經支持大部分特性。大部分人可能說ES6就是一些語法糖，這裡可以去聽聽 @賀師俊賀老的對ES6看法的音頻（鏈接找不到了，大家自己去找找，關鍵字代碼時間BTW我特別喜歡賀老說技術的風格），那為什麼有ES6，因為原來JS的缺陷，加上生產環境中實實在在需要著這些東西（就算沒有，也有很多的庫去fix，還不如有。）這又是滿足開發者和語言的需求。然後CSS，我僅僅是了解會寫的階段你可以多去看看張鑫旭和大漠的css的文章。還有現在的HTML5.1,甚至HTML5.2 眾成翻譯。那為什麼在不停的發展變化呢？首先證明這個社區的繁榮，然後的的確確有這樣的需求才會發展。4.其他node讓js不僅僅在前端。WebAssembly or wasm is a new portable, size- and load-time-efficient format suitable for compilation to the web.
……
總結：
當然我這些理解都是基於我接觸到的。可能某些技術不是2016才出來的，但是的確是我2016才接觸到的。我的看法是阿當老師一半，懷著好學的心，打好基礎，面對不斷變化的技術，保持本心，理解新技術為了解決什麼樣的需求，方可遊刃有餘。========================================================題外話：我寫的都是很淺顯，想到什麼說什麼，不過真正要總結起來估計要很長時間和很大版面，之後在填坑吧。然後最後因為在考試複習，就不怎麼想寫。然後最近在研究演算法覺得計算機方面還有很多有意思的事情。然後下個學期想找前端實習，坐標上海，大三。不知道哪位大大給個發簡歷面試的機會。仰望星空，腳踏實地。
根據場景選框架。
少撕逼，不要整天腦子裡想著騷代碼，不要整天想著用什麼框架，想想不用框架怎麼寫。
擺脫對框架的依賴，認真思考可維護，可復用，可擴展，靈活性好的代碼該怎麼寫。回歸編程的本質。打好基礎，與時俱進，根據項目需求選擇框架。
前端技術效率和性能的提升當然不是僅靠前端框架都能解決的，還需要其他各方面輔助工具的支持，例如高效的調試工具、構建自動化工具、自動發布部署工具等。所以未來前端發展過程中各種高效工具的探索仍會不斷地出現，來解決特定場景下的問題，最後進行一個優勝劣汰的過程。黑板報貫穿瀏覽器、服務端和移動端，前端正朝著多端、多技術實現的方向發展。這意味著前端這套技術棧能做的事情可能更多，涉及的平台更廣，但作為整套技術開發生態的一部分，每一項技術的出現都必不可少的要去考慮開發效率、維護成本、性能、擴展性這幾個方面的問題，所以尋找並發展更優的開發生態體系仍是前端未來的大方向，對於新技術的出現，我們也會從下面幾個方面去評價它的意義。
感覺國內大牛湧現 各成一派 大有引領前端風騷之勢 我等小白因中文文檔和社區的完善 也大大受益 贊
學習速度跟不上技術的變更速度，幸好我不是前端。
一直原生ES5，自己造輪子……
VR很好，技術還要繼續研發。國內應該避免相關資本泡沫，手機接個大屏幕放眼睛上不叫VR自動駕駛很好，技術漸成熟。國內應該避免相關資本泡沫，百度的自動駕駛最近比較低調，可取。人工智慧很好，依然是外國獨大。國內應該避免相關資本泡沫，BTA最近都很低調，可取。電動汽車很好。國內電動汽車很扯淡，政策和企業技術都很扯淡，不看好樂視，應避免相關資本泡沫。
?(′ω`?)別怎麼看怎麼總結了 打好基礎，與時俱進，根據項目需求選擇框架。天天撕逼不累嗎？如果真的要撕逼。。。。PHP是世界上最吼的語言！！！
推薦閱讀：
※Mary Meeker 發布的《2016 年互聯網趨勢報告》中都有哪些亮點？
※2016 年的藝術界有何值得留意之處？
※2016年互聯網找工作到底有多難？
※2016 年，醫學領域出現了哪些極具發展潛力的研究方向？
※2016 年，物理學界發生了哪些大事件？