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

　　

　　Web 發展了幾十個春秋，風起雲涌，變幻無窮。我很慶幸本身沒有完整地經歷過這些年頭，而是站在前人的肩膀上行走。Web 技術發展的速度讓人感受那幾乎不是繼承式的迭代，而是一次又一次的變革，一次又一次的創造。這幾年的前端，更爲之甚！我從 12 年末開始接觸前端，12 年以前的前端發展狀況只能從上一輩的筆觸中領會。本文會盤點從 09 年開始到 15 年間前端技術的革新，同時也會從多個角度，解讀近幾年前端技術發展的潛在因素，其中穿插了若干對前端演進的拙見，不免會有錯誤和疏漏，忘讀者能夠補充和斧正。

 

下面，花一些篇幅簡單回顧下 09 年到 15 年前端的發展歷程。

 

 

 

 

 

 

 

 

最開始，咱們看到的 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 也將成爲歷史，被開發者遺棄在代碼的註釋之中。這些都是規範和標準的魅力，它的存在，就是讓開發者把精力投入到本身的業務之中，編程和範式的工做交給它。

在 這裏（http://www.w3.org/TR/tr-date-all） 能夠看到，W3C 各個小組最近都在幹啥。標準不能囊括一切。

 

技術的更迭過於頻繁，咱們可以清晰地看到，不少人還在用更迭前一波甚至是前好幾波的產品。

　　當年的 IE6，在戰場上鏖戰了 10 多個年頭，依然屹立不到，而如今它在市面上依然有百分之一左右的佔有率，這種小強精神不得不讓人肅然起敬。「只要用戶在，咱們就得追隨」，這多是不少公司的服務理念，由於用戶就是潛在的利潤。正是由於這種服務理念，成就了 IE6 一個又一個的 5 年！

　　然而低本版的 IE 已經不只僅是被前端從業人員抵制和排斥了，網絡安全、網絡運維、QA 等等，各個技術崗位的人員都開始對他不屑，它的存在對工做效率、對安全、對不少方面產生了極爲不良的影響，甚至影響到一些核心內容的推廣，因此 2016 將是低版本 IE 消亡的一年，我也呼籲業界全部的朋友舉起義旗反抗起來！

　　慶幸的是，也有人開始吃螃蟹了。從支付寶到天貓到淘寶，阿里巴巴在不少業務上已經主（bei）動（bi）地放棄了對 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，咱們爲它編寫的插件不可勝數，而在工程化的需求衝擊下，它卻顯得那麼的弱不由風，由於它關注的點和當前的發展態勢不太吻合，僅此而已。

 

記得當年拿着 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 年，我以爲技術上的新創造會稍微緩和些，這兩年不少人已經被新技術衝擊得有些找不着方向了，同一類東西，前者還沒學完，後者就開始火爆了，緊接着又是一陣技術的凋零和新技術的出現，這樣搞久了也會有一絲的疲倦。而更多的會關注，如何更好地服務多端，如何更大幅度地提高開發體驗和用戶體驗，不少技術都會往性能、往極致這個方向上鑽研。

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

 

 

做者：Barret Lee

連接：http://www.barretlee.com/blog/2015/12/10/after-framework-we-gonna-to-hug-data/