近幾年前端技術盤點以及 2016 年技術發展方向

　　Web 發展了幾十個春秋，風起雲湧，千變萬化。我很慶幸自己沒有完整地經歷過這些年頭，而是站在前人的肩膀上行走。Web 技術發展的速度讓人感覺那幾乎不是繼承式的迭代，而是一次又一次的變革，一次又一次的創造。這幾年的前端，更為之甚！

　　我從 12 年底開始接觸前端，12 年之前的前端發展情況只能從上一輩的筆觸中領會。本文會盤點從 09 年開始到 15 年間前端技術的革新，同時也會從多個角度，解讀近幾年前端技術發展的潛在因素，其中穿插了若干對前端演進的拙見，難免會有錯誤和疏漏，望讀者可以補充和斧正。

　　那些年，一度追捧，一度放棄

　　下面，花一些篇幅簡單回顧下 09 年到 15 年前端的發展歷程（Update: 2016/01/03, 感謝@法海 師兄對文章部分內容的校稿，很多技術出現的時間有所偏差，但不影響閱讀）。

　　09 年，基礎類庫完善，尋求突破

　　09 年之前，JavaScript 還處於對自身語言的完善過程中，而到了 09 年，JavaScript 類庫已經頗為成熟，jQuery/Prototype//Dojo 等都已經發布了好幾個 stable 版本，各大類庫也是相互吸收優點，不斷完善並提高自身效能，然而功能上已經沒有太多增加的勢頭。部分框架開始了思想上的轉變，更加註重前端開發的組織和結構，條理性強了很多，如 YUI 等。

　　從 ECMAScript 規範的爭執，開啟了瀏覽器引擎大戰，各大廠商也趁機瓜分 IE 份額，Chrome 和 Firefox 在這場戰役中取得大勝，V8 也敲響了前端的大門。為了迎合市場的激烈競爭，IE 開始了升級之旅，09 年初發布 IE8，全面相容 CSS2.1。

　　而此時，Node.js 和 3G Mobile 這兩隻巨獸開始浮出水面，Web 標準也開始向 HTML5、ECMAScript5.0 靠攏。

　　10 年，看齊標準，關注 Web 效能

　　毫無疑問，這一年，各大巨頭都看清了 HTML5 是 web 發展的未來，在保留原來前端技術的狀態下，都簇擁著拉扯 HTML5 的裙襬。富客戶端應用也在這一年蓬勃生長，ExtJS/Dojo 搖身變為企業級框架，各類元件化概念和產品如約而至。

　　延續著 09 年的變化，10 年的前端顯得頗為沉寂，然而在標準的運用和推動上，各大廠商也是十分賣力。IE 9 出來了預覽第三版，iPhone 的 Safari 已經能夠支援眾多 HTML5 內容：Canvas/Video/Audio/Geolocation/Storage/Application Cache/Web SQL Database 等。

　　W3C 宣佈成立 Web 效能工作組，Google 和 Mozilla 紛紛推出應用商店，瀏覽器除錯工具也豐富了起來，人們開始更多地關注開發體驗和效能問題。

　　11 年，HTML5 扛大旗，Flash 堪憂

　　2011 年 HTML5 的技術發展和推廣都向前邁進了一大步，語義明確的標籤體系、簡潔明瞭的富媒體支援、本地資料的儲存技術、canvas 等等各類技術被廣泛應用。這一年，很多 web 開發者也面臨一項技術的抉擇，HTML5 or Flash？從 Flash Player 11.1 開始，Adobe 不再繼續開發面向移動裝置瀏覽器的 Flash 外掛，積極投身於 HTML5，這意味著 Flash 技術的凋零。

　　這一年，HTML5 遊戲火爆到了一個高潮，移動端開發工具和除錯工具也日益成熟。jQuery 已經成為大小公司日常開發的標配，成千上萬的 JQ 外掛讓網頁開發變得尤為輕鬆，而隨之而來的也是頁面的臃腫和效能調優的深入探索。

　　Node.js 已經悄然崛起，在 github 上的訪問量已經超過了 Rails，國內的雲應用開始嘗試使用 Node.js，Node.js 相關工具也紛紛出來。

　　12 年，響應式開發，工程化推進

　　隨著硬體技術的發展，各手機廠商又開始騷動起來，為了佔有更多的市場，不斷提高產品的價效比，體驗也得到了不斷的優化。藉著先前兩年 HTML5 颳起的東風，移動端上的 web 開發也顫抖了起來。移動端的開發挑戰不亞於 PC 上對多個瀏覽器的支援，這一年，萌生了眾多移動端框架，如 Sencha Touch/Zepto.js/JQ Mobile 等，相對 PC 端框架，它們更加輕便。

　　而移動端的崛起，帶來了許多終端開發難題：多終端適配，多解析度適配，遠端除錯等等，而隨著這些難題一個個被解決，移動端生長的勢頭變得更加強盛。此時 Twitter 也推出了 Bootstrap， 這個前端開發工具包不僅方便了前端，也方便了後端同學，它的出現讓快速建站更加簡單。

　　程式設計思想的切換，迎來了 CoffeeScript 和 TypeScript，這兩個預處理語言的出現又為 JavaScript 引來了不少其他方向轉型過來的開發者。JavaScript 的兄弟 Node.js，也在命令列領域開拓了一片不小的疆域，甚至有動搖 Perl 和 Ruby 地位的趨勢。

　　在前端工程化上，幾個派系相互爭鬥，產出了 AMD、CMD、UMD 等規範，也衍生了 SeaJS、RequireJS 等模組化工具。前端在這一年很有跳躍感。

　　13 年，爆發式增長，百花齊放

　　規範和標準上有不少產出。Web Components 的出現給前端開發開闢了新思路；WebDriver 規範的出來推動了自動化測試的程式，ECMAScript 6 的規範草案落地，Webapp 工作小組在這一年也是相當活躍。

　　Chrome 瀏覽器在這一年也有了很大的突破，開始支援 SPDY，使用 Blink 取代 webkit 作為 Chromium 的新渲染引擎，Chrome DevTools 的除錯體驗大幅度提升。這一年中，Chrome 連同其他瀏覽器廠商快速推動了各項草案規範的實現。

　　語言能力上依舊在增強，並且從 JS 開始擴散到 CSS，LESS、SASS 和 Stylus 等 CSS 預處理語言開始走俏，Web 開發變得更加緊湊。

　　而在無線端，應用不再侷限於 Webapp，由於流暢度、效能等方面不能滿足使用者體驗的需求，各大公司開始轉向 Native 方向的研究，進而出現了 Hybrid 和 PhoneGap 的繁榮，它們為 JS 呼叫了提供更多的裝置 API。

　　Node.js 大放異彩，很多公司在生產環境中使用 Node.js，同時也出現了諸如 Express、Meteor 等小巧的快速搭建 Node.js Server 的應用框架。

　　各瀏覽器的除錯也是種類繁多、功能豐富，PhantomJS 在自動化測試上開始取代 Selenium，出現了眾多的遠端除錯方案和工具。

　　前端工程化開始普及，各公司開始推出自己的前端整合開發解決方案。

　　14 年，移動端的崛起，HTML5 和 ES6 落地

　　HTML5 正式定稿，這意味著，web page 正式演變為 web application。ES6 華麗麗走進前端，走的很穩重，它的 Module/Class 等特性已經完全讓這門語言具備了開發大型應用的能力。

　　大而厚的基礎庫難以滿足靈活場景，Mobile 要求極致體驗，MV* 庫鋪卷而來，如 vue/angular/knockout 等。

　　Web Components 跨終端元件快速發展，移動端開發迎來一次昇華。Node.js 前後端分離的流行，中間層的出現改變了前後端的合作模式。2014 是顛覆式的一年，前端發展在這一年開始形成了一個短暫的穩定格局。

　　15 年，觀念的轉變，步入前端工業化生產

　　今年格外引人注目的框架是，類 React。Facebook 在 React.js Conf 2015 大會上推出了基於 JavaScript 的開源框架 React Native，它結合了 Web 應用和 Native 應用的優勢，可以使用 JavaScript 來開發 iOS 和 Android 原生應用。在 JavaScript 中用 React 抽象作業系統原生的 UI 元件，代替 DOM 元素來渲染等。敲一次程式碼，能夠執行在多個平臺上，其優勢可見一斑。除了 React ，還有手機淘寶推出的 Weex 框架，它吸收了 vue.js 的程式設計精華，程式設計風格更加簡約。

　　在眾多構建工具中，如今瀟灑存活的並不多。體驗完 grunt 和 browserify 後，gulp 順勢而至，爾後又出現了 webpack、jspm 等。而包管理工具，經歷了 components、bower、spm 後，npm 開始主導整個市場。

　　Node.js 的應用已經鋪天蓋地，各大公司前端都把 Node.js 作為分離前後端的主要手段，並且在測試、監控等方面沉澱了大量內容。不過，這個市場是很苛刻的，Node.js 的效能難以達到 C/C++ 的水平，那麼接下來要做的就是要提升效能，至少得接近 C/C++。

　　@法海 師兄批註：對時間點的總結是，其實很多技術方案很早就出現了，只不過沒有大規模應用，因此，對於上文中時間點的謬誤，你可以將語句從「xxx 出現了」改成「xxx 得到廣泛應用」。其實我發現，問題在於，一個技術領域的新起和發展並不是一年內能完成的，一個技術方案的出現和廣泛應用也不是一年內能落地的，所以執著於以「年」為時間點來編史，會畫地為牢。

　　Web 規範和標準

　　最開始，我們看到的 JavaScript 還只是一個簡單的指令碼語言，配合著 AJAX，在網頁上翻騰了好幾個年頭。隨著網際網路趨勢越來越明顯，網際網路業務量和業務複雜度不斷增加，很多網頁變得相當複雜，如讓我們震驚了好一會兒的 Gmail，互動複雜，體驗優良。為了更好的多人協作，程式碼中的 Utils 庫越來越大，在這些庫中，基礎部分更多的是對 JavaScript 語言本身的擴充，比如給 String 加一個 repeat 函式，再加一個 trim 函式，再加一個 endWith 函式等等。

　　複雜的業務中會經常看到一層又一層的回撥處理，回撥的巢狀讓程式碼的可讀性變的很差，而且很難將多個非同步並行處理。為了改變這種程式設計正規化，我們做了很多的思考，使用事件監聽，使用各種手段拉直回撥，平坦地呼叫。

　　慢慢的，如果你在關注 W3C 小組的動向，會發現，那些被認可的，並且被廣泛重複定義的東西，都被納入了標準。最開始的 jQuery/prototype，前者主要是對瀏覽器做相容處理，讓開發者不再把精力放到瀏覽器的差異上；後者是對語言本身的擴充，對 JavaScript 各種型別做擴充，並且提供了一套擴充任何物件的功能集。而現在的開發，我們很大程度上不再依託這些類庫。規範和標準已經把這些差異都統一了，String 中自帶了 includes/startsWith/endsWith/repeat/padStart/padEnd 等函式，Array 自帶了 from/forEach/of/keys/values/find/findIndex 函式…

　　規範的標準是為了讓開發者得到更好的程式設計體驗，程式設計不是目標，目標是將程式設計生產力轉化成實際效益，越少的阻礙對開發者越有利。各瀏覽器廠商當然也認識到了這一點，他們不斷地提升自己產品的體驗，將標準中的新特性都融合進去，比如 ES6 中的 Promise/Generator/Class/Module 等等。在這些內容普及之前，我們不需要加入 jQuery/prototype 這些「不純粹」的東西，而是新增兩個 shim 和 polyfill，如 es5-shim，html5shiv 等等。待到山花爛漫時，再輕鬆刪掉這些補丁程式。

　　這兩年工程化很熱，W3C 小組也看到了，這就是市場的需求，為了完成一個大型應用的程式設計，就必須模組化、元件化，於是在規範中也出現了 Module & Module Loader；Node.js 的到來，讓很多前端工程師開始接觸資料庫操作，面對巨量的非同步，我們忍氣吞聲寫了無數的回撥地獄，儘管使用了很多 Promise 相關的操作，程式結構依然鬆散難以閱讀，於是規範中也開始出現了 async/await 等對 Generator 的上層封裝。文字已經不能滿足當代人的溝通需求，音視訊等富媒體傳輸走進了我們的生活，於是規範中也出來了 WebRTC/WebAudio 等規範。

　　只要規範出來了，後續市面上就會根據規範來實現一套 shiv，這些 shiv 提供了同樣的 API，提供了同樣的程式設計體驗。當瀏覽器自我進化完成之後，這些 shiv 也將成為歷史，被開發者遺棄在程式碼的註釋之中。這些都是規範和標準的魅力，它的存在，就是讓開發者把精力投入到自己的業務之中，程式設計和正規化的工作交給它。

　　在 這裡 可以看到，W3C 各個小組最近都在幹啥。標準不能囊括一切。

　　生態的自我完善和自我擴充

　　技術的更迭過於頻繁，我們能夠清晰地看到，很多人還在用更迭前一波甚至是前好幾波的產品。

　　當年的 IE6，在戰場上鏖戰了 10 多個年頭，依然屹立不到，而現在它在市面上依然有百分之一左右的佔有率，這種小強精神不得不讓人肅然起敬。“只要使用者在，我們就得追隨”，這可能是很多公司的服務理念，因為使用者就是潛在的利潤。正是因為這種服務理念，成就了 IE6 一個又一個的 5 年！然而低本版的 IE 已經不僅僅是被前端從業人員抵制和排斥了，網路安全、網路運維、QA 等等，各個技術崗位的人員都開始對他不屑，它的存在對工作效率、對安全、對很多方面產生了極為不良的影響，甚至影響到一些核心內容的推廣，所以 2016 將是低版本 IE 消亡的一年，我也呼籲業界所有的朋友舉起義旗反抗起來！

　　慶幸的是，也有人開始吃螃蟹了。從支付寶到天貓到淘寶，阿里巴巴在很多業務上已經主（bèi）動（bī）地放棄了對 IE6 和 IE7 的支援，甚至在統一接入層直接做了 302 跳轉，提示使用者更新瀏覽器或者引導流量到無線端。這是一個好的開始，我們期望這也是業界達成共識的開始！

　　HTTP 協議，從 1.0 快速過度到了 1.1，整個網際網路的上層建築變的十分穩固。當然，我也瞭解到依然有很多產品還是保持了 1.0 的狀態，據說電信公司的很多產品就是使用 HTTP/1.0 進行通訊，這無疑讓人驚愕。為了追求更高的效率，減少網路傳輸中的無效流量，W3C 工作組對 HTTP 協議也做了重新的定義，SPDY 就是 13 年比較火熱的一個話題，Firefox 和 Chrome 都陸續開始支援 SPDY，後來在 SPDY 的基礎上做了升級，正式定義為 HTTP/2.0，它的一個很大特點就是多路複用，這個小小的特點改變了我們前端程式設計的很多優化模式，比如

• 域名不是越多越好，為了能夠充分利用瀏覽器的連線數，我們給 JS 和 CSS 開一個域名，給 img 開好幾個域名，網頁開啟的時候，恰到好處的利用瀏覽器的連線數上限限制。HTTP/2.0 的多路複用，就是可以在一個 HTTP 請求中進行多個資源的傳輸，如果域名雜湊，反而不能利用這個特性
• 資源合併沒有任何優勢，以前的資源合併是為了減少請求數以節約建立 TCP 連結的網路開銷和頭部傳輸的流量開銷，而在 HTTP/2.0 中，一個 HTTP 請求上完全可以把所有的資源全部推送過來，如果合併了資源，反而不能良好運用瀏覽器對資源的快取。

　　當然，除了多路複用，還有很多其他的優化，比如傳輸的資料為二進位制流，HEAD 頭會被壓縮處理，伺服器可以向客戶端推送內容等。在這個技術水平指數式增長的年代，我相信以後的革新不會比消滅 IE6 痛苦。

　　模組載入上，經過了各派系的爭論之後，流傳下來幾個不錯的產品 SeaJS、RequireJS 等，那麼那個模組載入器將成為工具平臺中短暫的終點呢？似乎這些都不是。當我們按照規範中的方式進行模組定義，按照規範中的方式載入定義的模組時，載入這個流程就顯得不那麼重要了，因為這些事情最後都會變成 shiv/polyfill 的事情，最終會變成瀏覽器的固有屬性。

　　當一個東西在社群中被暴力追捧的時候，會有很多衍生的產品出來，當這些衍生物根深蒂固時，可能又會出現一個更加原生更加符合開發習慣的東西出來。就像 jQuery，我們為它編寫的外掛不計其數，而在工程化的需求衝擊下，它卻顯得那麼的弱不禁風，因為它關注的點和當前的發展態勢不太吻合，僅此而已。

　　Mobile 的發展驅動著戰場的轉移

　　記得當年拿著 Nokia5230 學完了 HTML 和 JavaScript 的入門，那螢幕尺寸也就是三個手指的寬度，緊緊攥在手裡看著頁面混排效果極差的網頁文件。

　　現如今，iPhone 都出到 6s 了，一個版本一個尺寸，而且尺寸越來越大，還有各種寬高不一的 Android 機器，種類繁多。以前的觸屏是電阻式，只支援單點觸碰；而現在電容式的觸屏精度更高，還支援多指觸控，這如絲般順滑的體驗在三四年前是完全體會不到的。曾經手機開一個程式久了就會卡，動不動還會自動重啟；而現在的手機開一堆程式，完全無感知，這就是硬體發展前後的差異。

　　手機已經成為了人們生活中不可或缺的一部分，甚至成為了一些人身體的一部分，淘寶今年雙十一的資料顯示，國內移動端的消費比例已經遠遠超過了 PC 端，佔比 68%。面對龐大的使用者，我們的技術是否做好了充足的準備，這裡還得打一個問號。

　　PC 上那一套經驗不是直接搬到移動端就可以使用了，在移動端還需要解決更多的問題：

• 多解析度問題，這裡涉及到了響應式設計和前端響應式技術
• 不同網路環境的網頁載入優化問題，2g/3g/4g/wifi
• 手指互動帶來的一系列體驗問題
• 為了提升使用者體驗，將 Web Native 化 —— 類 React 技術帶來的一系列問題
• 遠端除錯問題
• 移動安全問題等等

　　上面提到的問題很多已經有了優秀的解決方案，當然也有很多未提及的。WebApp 的效能、流暢度和穩定性遠遠不如原生應用，同時它也無法良好地運用裝置提供的原生功能，這些都是大家轉投 Native 的原因。

　　端的融合

　　不同解析度的手機，不同物理尺寸的終端，為了保持良好的視覺體驗和使用者體驗，我們不得不為每一個尺寸寫一份 Media Query 程式碼，那麼對應的，設計師也需要設計多套版式供前端使用，這給設計師、前端和測試帶來了無盡的麻煩。為此，我們通過前端技術重塑螢幕，重新定義畫素尺寸，使用流式佈局，通過百分比來響應不同的終端尺寸。這是端的融合。

　　後續的 Mobile 的技術發展方向上，應該是相當明確的。很多公司都是三套人馬維護三端的程式，iOS、Android 和 Web，而這三端做的事情都是一樣的，一樣的介面，一樣的後端介面，一樣的互動方式。為了能夠快速響應業務的變更，我們不得不將三端合併為一端對待，用一套程式程式設計成三端程式碼，然後釋出到三個平臺上。這也是端的融合。React 系列技術發展到此，絕對不是終點，它只是一個探路燈，給我們照明瞭方向。

　　技術需要為業務做保障，而好的技術是能夠及時響應業務的變化，我們不可能投入大量的人力在 Web 的修補工作上，通過開發統一工具，遮蔽端和端之間的差異，統一開發模式和開發體驗，這才是 Mobile 的未來。

　　當然，回到我們之前說的規範和標準，我們目前所做的「遮蔽差異」工作，今後，也會有統一的標準來規範，目前手機廠商沒有這個共識，是因為還處於當年 Chrome、Firefox 搶佔 IE6 市場份額的階段。端的最終融合在於一個統一的標準，以及強有力的執行。

　　棧的融合

　　我剛接觸前端的時候，還沒有聽說「全棧」，Web 技術棧往小裡說，包含了從前端設計、互動、前端實現、網路資料傳輸、後端實現、後端運維和資料庫等幾個方面，能短時間內從無到有實現這麼一套系統，並且能夠抗得住一定流量衝擊的人，我們可以稱之為全棧工程師。能夠有架構有條理地實現這套系統，並且抗得住大流量、有整合測試、有監控的，這種我們可以稱之為資深全棧工程師。現在不乏這種人才，也不乏自吹為這種人。

　　棧的融合得益於 Node.js 的出現，作為前後端分離的橋樑，它拉近了前端工程師與後端的距離，有的人在這座橋樑上賣力行走，漸漸的也從前端走進 了後端，甚至走進了後端的運維。至此，前端也擁有了部署和釋出整個應用的能力，這是一個質的突破。

　　使用 Node.js，簡單幾行程式便能實現一個 web 伺服器、便能搭建一個多人聊天的網頁，它的便捷性可見一斑。NPM 社群的發展，沉澱了成千上萬的元件包，一行命令即可獲取，這種元件拼湊式的開發，任何功能的實現都不會顯得太複雜，而這裡的「不復雜」也蘊含了無數的坑坑窪窪，在這一層的融合上也會遇上不少阻礙：

• 冗餘的龐大的包內容，為了使用一個小功能，我們從網路上拉取下來一個巨大的包，而且這裡的「巨大」對很多人來說都是無感知的，很少會有人進入 node_modules 去檢視依賴的第三方包是如何實現的，實際情況可能會相當震撼，第三方包還引用了一堆第三方包，這些包都會在 Node.js 執行的時候被收納進去，放在記憶體中。
• 猛烈的迭代，今年的 Node.js 被人嫌棄迭代太慢了（當然，這是表面原因），走出了一個分支 io.js，發展了一會兒，進度趕超了 Node.js，後來覺得一家人不幹兩家活，又合併回去了。雖說上層 API 幾乎沒有變化，但是底層卻被翻了一個天。
• 偶爾的巨大漏洞，每隔一端時間就會暴露 Node.js 存在漏洞，這些漏洞的補救措施就是立即升級版本號，比較讓人擔心受怕。
• 後端意識不強烈，前端佔領了中間層的開發，有的時候還幹這後端的活兒，然而卻沒有後端沉澱多年固有的意識，測試和監控做的相當潦草。

　　JavaScript 從客戶端的指令碼語言縱身躍進進入了後端行列，而今也開始深入到移動端 Native 領域，確實是無孔不入，這可能就是語言的特性，也可能是技術本身就在尋求融合點，把有差異的地方全部躺平，然後用統一的方式去關注業務，關注使用者。端和棧也在融合。

　　後端服務化，雲資料，雲安全

　　使用者體驗變得越來越重要，響應式技術的發展也是後續網頁應用的一大特點，端和端之間的差異只是在表現上，資料這一層差異不是特別大，很多應用 PC 和 Mobile 共用一套介面，或者 Mobile 的介面在 PC 介面的基礎上做了一層包裝，對介面欄位做了些許刪減。後端為了響應各個端之間的資料需求，也需要關注資料的可利用性，介面包裝的擴充性等，這是後端服務化的一個表現。移動端的開發上，前後端間隙十分明顯，越來越多移動端應用的釋出已經脫離了後端，前端完全通過非同步方式獲取資料。

　　業務變化很快很快快，今天這個產品被併購，明天那個業務被砍掉，每個人負責的業務線可能冷不丁地就變了。很多大公司的決策是由上往下的，上面微動，下面可能就是大動，可能某個部門就不存在了，也可能被劃分成幾個產品部門。

　　所以「大後臺，小前臺」的趨勢必然形成。前端，毫無疑問，在這個前臺之中。前臺的特點是靈活的，多變的，可快速重組的。對後臺而言，為了響應前臺的變化，需要提供更細粒化的 API，將資料打散，打得更加零碎，零碎的資料易於重組，這是在考驗後端的架構能力。如今，很多前端也都是半棧工程師，盤踞在前後端中間層上，然而如何迎接這種後端服務化的模式，似乎這個準備還是不夠充足的。

　　GraphQL 的出現場景跟 React 類似，React 是前端應對不同場景的一種強有力手段，而 GraphQL 則是後端應對不同需求場景的一次嘗試，Web APIs 將會成為 Web App 和 Mobile App 的一箇中心點，前端基於後端的 RESTful 服務構建應用，這裡面存在太多未知的問題需要探索，這是一個大資料下探索的新起點，也給前端開發者創造了無數的可能。

　　　這幾年各類網盤，各個雲服務商都在搶佔市場，有提供圖片儲存的，有提供 CDN 靜態資源快取的，有提供大檔案儲存的，也有賣資料庫服務的。種類繁多，而歸根到底都是，你付錢給我，我提供儲存和安全，還提供方便的 SDK 讓你獲取自己的資料。雲服務賣的是一套服務，它是把所有人的資料風險集於一身，用強硬的技術做安全防禦。雲，賦予了我們無窮的想象空間。

　　三輛馬車，我們還差一輛

　　開發功能對很多人來說是輕鬆活兒，基本的前端語言加些複雜的特效，實現成本不會很高；即便是搭建一個網站，使用 Node.js 社群中的框架也能夠輕鬆實現。然後極少人會去關注每個功能點的測試，一個專案下來基本看不到測試用例，更不用說會去做監控相關的事情。結果就是，踏過了無數的坑窪之後終於上線了，而後續加功能的時候發現，加了東西就跑不通，新內容影響了之前的邏輯，只好去修復之前的邏輯，修好之後發現更早之前的邏輯又不通了，整個修復過程就像玩多米諾骨牌。

　　程式開發三板斧：功能、測試和監控。在 github 上可以看到很多程式都加入了持續整合，這是一個好兆頭，意味著我們寫的程式也越來越健壯，至少貢獻給世人使用的程式是健壯的。很多程式的程式碼覆蓋率也達到了 90%+，這些資料都是重視測試的證據。

　　然而，三輛馬車，我們最後一輛依然沒有開動起來。很多公司都會有自己的 log 平臺，每個使用者訪問頁面中的任何一個連結都會將使用者資訊和訪問資訊以 log 日誌形式收集到 log 平臺上，然後通過監控平臺或者離線分析的方式，獲取業務資料或者技術資料，進行分析和二次開發。這些東西在大公司見的很多，而這方面的東西在前端，尤其是使用 Node.js 做程式開發的前端身上，看到的並不多。

　　最後

　　2016 年，我覺得技術上的新創造會稍微緩和些，這兩年很多人已經被新技術衝擊得有些找不著方向了，同一類東西，前者還沒學完，後者就開始火爆了，緊接著又是一陣技術的凋零和新技術的出現，這樣搞久了也會有一絲的疲倦。而更多的會關注，如何更好地服務多端，如何更大幅度地提升開發體驗和使用者體驗，很多技術都會往效能、往極致這個方向上鑽研。

　　寫長文真不輕鬆。寫到這裡，感覺說的不通透，還有很多想說的，但是個人理解力有限，也難以表達全面。技術的變化很快，今天說過的東西，到了明天就可能過時了。我們猜不透未來，只能把現有的東西好好消化吸收下，留下一個話柄，給讀者吧。