2016前端開發技術巡禮【摘自前端之巔】

前言

2016 年立刻過去了，像過去六年中的每年同樣，Web前端領域又產生了「面目全非」而又「耳目一新」的變化，不但舊事物持續不斷地被淘汰，新事物也難保坐久江山，大有朝不保夕之勢。開源界如羣雄逐鹿，不斷生產新的概念、新的框架、新的工具，去年中一些流行的技術今年大多獲得了進一步的演進和升級，活躍度很是高，卻仍然不能保證前端的將來屬於它們。在今年總體資本市場冷卻的大環境下，to B的創業公司顯現出了較強的生命力，這種類型的業務也給Web前端的工做帶來了明顯的差別性，工程師總體技能方向也展露出一絲不同的分支。

1、更新的網絡與軟件環境

1.1 HTTP/2 的持續普及

 

今年中，幾乎全部的現代桌面瀏覽器都已經支持了HTTP/2協議，移動端依靠降級爲SPDY依舊能夠覆蓋幾乎全部平臺，這樣使得從協議上優化頁面的性能成爲了可能。

同時，前端靜態資源打包的必要性成爲了必定程度上的爭論焦點，打包合併做爲傳統的前端性能優化方案，它的存留對前端工程化影響極大，Facebook公司著名的靜態資源動態打包方案的優越性也會被弱化。社區上多篇文章紛紛發表對HTTP/2的性能實驗數據，卻不盡相同。

在2017年，我相信全部大型站點都會切換HTTP/2，但依舊不會放棄對靜態資源打包合併的依賴。並且，對於Server Push等高級特性，也不會有太多的應用。

1.2 Internet Explorer 8

 

三年前還在考慮兼容IE6的前端技術社區，在前不久天貓宣佈再也不支持IE8後又引發了一股躁動。IE8是Windows XP操做系統支持的最高IE版本，放棄IE8意味着放棄了使用IE的全部XP用戶。

其實在2016年的今天，前端社區中框架、工具的發展早已不容許IE8的存在，Angular 早在1.3版本就果斷放棄了IE8，React 也在年初的v15版本上宣佈放棄。在PC領域，你依舊可使用像Backbone.js同樣的其餘框架繼續對IE進行支持，但不管是從研發效率上仍是從運行時效率上，放棄它都是更好的選擇。

因爲對HTML5兼容性不佳，在2017年，相信IE9也會逐漸被社區放棄，以取得更好的性能、更少的代碼體積。

2、如何編寫(Java)Script

2.1 ES2016？ES2017？Babel!

 

 

去年定稿的ES2015（亦稱ES6）帶來了大量使人激動的新語言特性，並快速被V8和SpiderMonkey所實現。但因爲瀏覽器版本碎片化問題，目前編寫生產環境代碼仍然以ES5爲主。今年年中發佈的ES2017帶來的新特性數量少的可憐，但這正好給了瀏覽器廠商消化ES2015的時間，在ES2017到來以前喘口氣——是的，明年的ES2017勢必又會帶來一大波新特性。

JS解釋引擎對新特性的支持程度並不能阻礙狂熱的開發者使用他們，在接下來的很長時間，業界對Babel的依賴必然有增無減。Babel生態對下一代ECMAScript的影響會進一步加大，人們經過先增長新的Babel-plugin，後向ECMA提案的方式成爲了ECMAScript進化的常態。開發者編寫的代碼能直接運行在瀏覽器上的會愈來愈少。

但使用Babel致使的編譯後代碼體積增大的問題並無被特別關注，因爲polyfill可能被重複引入，部署到生產環境的代碼帶有至關一部分冗餘。

2.2 TypeScript

 

做爲ECMAScript語言的超集，TypeScript在今年取得了優異的成績，Angular 2放棄了傳說中的AtScript，成爲了TypeScript的最大客戶。人們能夠像編寫Java同樣編寫JavaScript，有效提高了代碼的表述性和類型安全性。

但凡事有兩面，TypeScript的特性也在不斷升級，在生產環境中，你可能須要一套規範來約束開發者，防止濫用致使的不兼容，這反而增長了學習成本、應用複雜性和升級安全性。箇中優劣，仍需有大量的工程實踐去積累經驗。

此外，TypeScript也能夠看作一種轉譯器，與Babel有着相似的新特性支持。在2017年，咱們期待TypeScript與Babel會發展成怎樣的一種微妙關係。

2.3 promise、generator 與 async/await

 

在回調地獄問題上，近兩年咱們不斷被新的方案亂花了眼。過去咱們會利用async來簡化異步流的設計，直到「正房」Promise的到來。但它們只是callback模式的語法糖，並無徹底消除callback的使用。

ES2015帶來的generator/yield彷佛成爲了解決異步編程的一大法寶，雖然它並不是爲解決異步編程所設計的。但generaor的運行是十分繁瑣的，所以另外一個工具co又成爲了使用generator的必備之選。Node.js社區的Koa框架初始就設計爲使用generator編寫洋蔥皮同樣的控制流。

但曇花一現，轉眼間async/await的語法，配合Promise編寫異步代碼的方式當即席捲整個前端社區，雖然async/await仍然在ES2017的草案中，但在今天，不寫async/await馬上顯得你的設計落後社區平均水平一大截。

在Node.js上，v7已經支持在harmony參數下的async/await直接解釋，在明年4月份的v8中，將會正式支持，屆時，Koa 2的正式版也會發布，幾乎徹底摒棄了generator。

2.4 fetch

受到回調問題的影響，傳統的XMLHttpRequest有被fetch API 取代之勢。現在，成熟的polyfill如whatwg-fetch、node-fetch、isomorphic-fetch在npm上的每日下載量都很是大，即使對於兼容性很差的移動端，開發者也不肯使用繁瑣的AJAX。藉助async/await的語法，使用fetch API能讓代碼更簡潔。

3、Node.js服務與工具

Koa 2

 

Koa與流行的Express屬於「同根生」的關係，它們由同一團隊打造。相比Express，新的Koa框架更輕量、更靈活。但Koa的設計在短期內曾經出現了較大的變更，這主要受到了async/await語法對異步編程的影響。在v2版本中，Koa的middleware拋棄generator轉而支持async，全部第三方middleware實現，要麼自行升級，要麼使用Koa-convert進行包裝轉換。

目前Koa在Node.js社區的HTTP服務端框架中受到關注度比較高，不過其在npm上latest目前仍處於1.x階段，預計在2017年4月份發佈Node.js v8後，就會升級到2.x。

Koa的輕量級設計意味着你須要大量第三方中間件去實現一個完整的Web應用，目前鮮有看到對Koa的大規模重度使用，所以也就對其無從評價。相信在明年，愈來愈多的產品應該會嘗試部署Koa 2，屆時，對第三方資源的依賴衝突也會尖銳起來，這須要一個過程才能讓Koa的生態完備起來。預計在2018年，咱們會獲得一個足夠健壯的Koa技術棧。這會促進Node.js在服務端領域的擴展，輕量級的Web服務將會逐漸成爲市場上的主流。

4、框架紛爭

4.1 jQuery已死？

 

今年六月份jQuery發佈了3.0版本，距離2.0發佈已經有三年多的時間，但重大的更新幾乎沒有。因爲老舊瀏覽器的逐漸放棄和升級，jQuery須要處理的瀏覽器兼容性問題愈來愈少，專一於API易用性和效率愈來愈多。

隨着如Angular、React、Ember、Vue.js等大量具有視圖數據單雙向綁定能力的框架被普及，使用jQuery編寫指令式的代碼操做DOM的人愈來愈少。早在2015年便有人聲稱jQuery已死，社區中也進行了大量雷同的討論，今天咱們看到確實jQuery的地位已大不如前，著名的sizzle選擇器在今天已徹底可由querySelector原生方法替代，操做DOM也能夠由框架根據數據的變更自動完成。

明年jQuery在構建大型前端產品的過程當中的依賴會被持續弱化，但其對瀏覽器特性的理解和積澱將對現有的和將來的類Angular的MVVM框架的開發依舊具備很大的借鑑意義。

4.2 Angular 2

 

好事多磨，Angular 2的正式版終於在今年下半年發佈，相比於1.x，新的版本幾乎是徹底從新開發的框架，已經很難從設計中找到1.x的影子。陡峭的學習曲線也隨之而來，npm、ES2015 Modules、Decorator、TypeScript、Zone.js、RxJS、JIT/AOT、E2E Test，幾乎都是業界這兩年中的最新概念，這着實給初學者帶來了不小的困難。

Angular 2也更面向於開發單頁應用（SPA），這是對ES2015 Modules語法描述的模塊進行打包（bundle）的必然結果，所以Angular 2也更依賴於Webpack等「bundler」工具。

雖然Angular 聲稱支持TypeScript、ECMAScript和Dart三種語言，不過顯然業界對Dart沒什麼太大興趣，而對於ECMAScript和TypeScript，兩種語言模式下Angular 2在API和構建流程上都有着隱式的（文檔標註不明的）差別化，這必然會給開發者以困擾。加上業界第三方工具和組件的支持有限，TypeScript幾乎是如今開發者惟一的選擇。

此外，Angular團隊已聲明並無徹底放棄對1.x組件的支持，經過特有的兼容API，你能夠在2.x中使用針對1.x開發的組件。鑑於不明確的風險，相信不多有團隊願意這樣折騰。

如今在產品中使用Angular 2，在架構上，你須要考慮生產環境和開發環境下兩種徹底不一樣的構建模式，也就是JIT和AOT，這須要你有兩套不同的編譯流程和配置文件。在不一樣環境下模塊是否符合指望，能夠用E2E、spec等方式來進行自動化測試，好的，那麼Angular 2的測試API又可能成了技術壁壘，它的複雜度可能更甚Angular自己。能夠確信，在業務壓力的迫使下，絕大部分團隊都會放棄編寫測試。

總之，Angular 2是一個很是具備競爭力的框架，其設計很是具備前瞻性，但也因爲太過複雜，不少特性都會成爲雞肋，被開發者所無視。因爲React和Vue.js的競爭，Angular 2對社區的影響確定不如其前輩1.x版本，且其更高級的特性如Server Render尚未被工程化實踐，所以相信業界還會持續觀望，甚至要等到下一個4.x版本的發佈。

4.3 Vue.js 2.0

 

Vue.js 絕對是類MVVM框架中的一匹黑馬，由做者一人打造，更難得的是做者仍是華人。Vue.js在社區內的影響很是之大，特別是2.0的發佈，社區快速生產出了無數基於Vue.js的解決方案，這主要仍是受益於其簡單的接口API和友好的文檔。可見做爲提供商，產品的簡單易用性顯得尤其重要。在性能上，Vue.js基於ES5 Setter，獲得了比Angular 1.x髒檢查機制成倍的性能提高。而2.0在模塊化上又更進一步，開發難度更低，維護性更好。能夠說Vue.js準確地戳中了普通Web開發者的痛點。在國內，Vue.js與Weex達成了合做，期待能給社區帶來怎樣的驚喜。

4.4 React

 

目前看來，React彷佛還是今年最流行的數據視圖層解決方案，而且幾乎已經成爲了每名前端工程師的標配技能。今年React除了版本從0.14直接躍升至15，放棄了IE8之外，並無更多爆發式的發展。人們對於使用JSX語法編寫Web應用已經習覺得常，就像過去十年間寫jQuery同樣。

React的代碼在維護性能上顯而易見，若是JSX編寫得當，在重渲染性能上也具有優點，但若是隻部署在瀏覽器環境中，那麼首屏性能將會受到負面影響，畢竟在現階段，純前端渲染仍然快不事後端渲染，何況後端具有天生的chunked分段輸出優點。咱們在業界中能夠看到一些負面的案例，好比某新聞應用利用React所有改寫的case，就是對React的一種誤用，徹底不顧其場景劣勢。

圍繞着React發展的替代品和配套工具依舊很活躍，preact以徹底兼容的API和小巧的體積爲賣點，inferno以更快的速度爲賣點，等等。每一個框架都想在Virtual DOM上有所創新，但它們的提高都不是革命性的，由此而帶來的第三方插件不兼容性，這種風險是開發者不肯承擔的，筆者認爲它們最大的意義在於能爲React的內部實現提供另外的思路。就像在天然界，生物多樣性是十分必要的，雜交能帶來珍貴的進化優點。

4.5 React-Native

 

今年是React-Native（如下簡稱RN）支持雙端開發的第一年，不斷有團隊分享了本身在RN上的實踐成果，彷佛前途一片大好，RN確實有效解決了傳統客戶端受限於發版週期、H5受限於性能的難題，作到了魚和熊掌兼得的理想目標。

但咱們仍然須要質疑：

首先，RN目前以兩週爲週期發佈新版本，沒有LTS，每一個版本向前不兼容。也就是說，你使用0.39.0的版本編寫bundle代碼，想運行在0.35.0的runtime上，這幾乎會100%出問題。在這種狀況下，如何制定客戶端上RN的升級策略？若是升級，那麼業務上如何針對一個以上的runtime版本編寫代碼？若是不升級，那麼這意味着你須要本身維護一個LTS。要知道目前每一個RN的版本都會有針對前版本的bug fix，相信沒有團隊有精力能夠在一個老版本上同步這些，若是不能，那業務端面對的將是一個始終存在bug的runtime，其開發心理壓力可想而知。

其次，雖然RN聲稱支持Android與iOS雙端，但在實踐中卻存在了極多系統差別性。有些體如今了RN文檔中，有一些則體如今了issue中，包括其餘一些問題，GitHub上RN的近700個issue足以讓人望而卻步。若是不能高效處理開發中遇到的各類匪夷所思的問題，那麼工期就會出現嚴重風險。此外，RN在Android和iOS上的性能也不盡相同，Android上更差一些，即使你完成了整個業務功能，卻還要在性能優化上消耗精力。而且不管如何優化，單線程模型既要實現流暢的轉場動畫，又要操做一系列數據，須要很高的技巧才能保證可觀的性能表現。在具體的實踐中，對於H5，每每因爲時間關係，業務上先會上一個還算過得去的版本，事後再啓動性能優化。然而對於RN，頗有可能達到「過得去」的標準都須要大量的重構工做。

再次，RN雖然以Native渲染元素，但畢竟是運行在JavaScript Core內核之上，依舊是單線程，相對於H5這並無對性能有革命性質的提高。Animated動畫、大ListView滾動都是老生常談的性能瓶頸，爲了解決一些複雜組件所引發的性能和兼容性問題，諸多團隊紛紛發揮主動能動性，本身建設基於Native的高性能組件，這有兩方面問題，一是不利於分發共享，由於它嚴重依賴特定的客戶端環境，二是它仍依賴客戶端發版，仍須要客戶端的開發，違背了RN最最重要的初衷。能夠想象，在大量頻繁引用Native組件後，RN又退化成了H5+Hybrid模式，其UI的高性能優點將會在設備性能不斷升級下被削弱，同時其無stable版本反而給開發帶來了更多不可預測的風險變量。

最後，RN仍然難以調試和測試。特別是依賴了特定端上組件以後，本地的自動化測試幾乎成爲了避免可能，而絕大多數客戶端根本不支持自動化測試。而調試只能利用remote debugger有限的能力，在性能分析上都十分不便。

能夠說RN的出現帶給了移動開發以獨特的新視角，使得利用JavaScript開發Native成爲了可能，NativeScript、Weex等相似的解決方案也發展開來。顯然RN目前最大的問題仍然是不夠成熟和穩定，利用RN替代Native依然存在着諸多風險，這對於重量級的、長期維護的客戶端產品可能並非特別適合，好比Facebook本身。RN的優點顯而易見，但其問題也是嚴重的，須要決策者對個方面利弊都有所瞭解，畢竟這種試錯的成本不算小。

因爲時間關係，市場上並無一個產品在RN的應用上有着足夠久的實踐經驗，大部分依然屬於「咱們把RN部署到客戶端了」的階段，咱們也沒法預測這門技術的長久表現，如今評價RN的最終價值還爲時尚早。在2017年，期待RN團隊能作出更長足的進步，但不要太樂觀，以目前的狀態來看，想達到stable狀態仍是有着至關大的難度。

4.6 Redux 與 Mobx

 

Redux 成功成爲了 React 技術棧中的最重要成員之一。與Vue.js同樣，Redux也是憑藉着比其餘Flux框架更簡單易懂的API才能脫穎而出。不過已經很快有人開始厭煩它每寫一個應用都要定義action、reducer、store以及一大堆函數式調用的繁瑣作法了。

Mobx也是基於ES5 setter，讓開發者能夠不用主動調用action函數就能夠觸發視圖刷新，它只須要一個store對象以及幾個decorator就能完成配置，確實比Redux簡單得多。

在數據到視圖同步上，不管使用什麼樣的框架，都有一個相當重要的問題是須要開發者本身操心，那就是在衆多數據變更的情形下，如何保證視圖以最少的但合理的頻率去刷新，以節省極其敏感的性能消耗。在Redux或Mobx上都會出現這個問題，而Mobx尤甚。爲了配合提高視圖的性能，你依然須要引入action、transaction等高級概念。在控制流與視圖分離的架構中，這是開發者無可避免的關注點，而對於Angular、Vue.js，框架會幫你作不少事情，開發者須要考慮的天然少了許多。

4.7 Bootstrap 

 

BootstrapBootstrap 4處於alpha階段已經很是久了，即便如今3.x已經中止了維護，它彷佛受到了Twitter公司業務不景氣的影響，GitHub上的issue還很是多。Bootstrap是建設內部平臺最佳的CSS框架，特別是對於那些對前端不甚瞭解的後端工程師。咱們不清楚Bootstrap還能堅持多久，若是Twitter不得不放棄它，最好的歸宿多是把它交給第三方開源社區去維護

5、工程化與架構

5.1 Rollup 與 Webpack 2

Rollup是近一年興起的又一打包工具，其最大賣點是能夠對ES2015 Modules的模塊直接打包，以及引入了Tree-Shaking算法。經過引入Babel-loader，Webpack同樣能夠對ES2015 Modules進行打包，因而Rollup的亮點僅在於Tree-Shaking，這是一種可以去除冗餘，減小代碼體積的技術。經過分析AST（抽象語法樹），Rollup能夠發現那些不會被使用的代碼，並去除它。

不過Tree-Shaking即將不是Rollup的專利了，Webpack 2也將支持，並也原生支持ES6 Modules。這能夠說是「旁門左道」對主流派系進行貢獻的一個典型案例。

Webpack是去年大熱的打包工具，儼然已經成爲了替代grunt/gulp的最新構建工具，但顯然並非這樣。筆者一直認爲Webpack做爲一個module bundler，作了太多與其無關的事情，從而表象上看來這就是一個工程構建工具。經典的構建須要有任務的概念，而後控制任務的執行順序，這正是Ant、Grunt、Gulp作的事情。Webpack不是這樣，它最重要的概念是entry，一個或者多個，它必須是類JavaScript語言編寫的磁盤文件，全部其餘如CSS、HTML都是圍繞着entry被處理的。估計你很難一眼從配置文件中看出Webpack對當前項目進行了怎樣的「構建」，不過彷佛社區中並無人提出過異議，一切都運行得很好。

題外話：如何使用Webpack構建一個沒有任何JavaScript代碼的工程？

新的Angular 2使用Webpack 2編譯效果更加，不過，已經提了一年的Webpack 2，至今仍處於beta階段，好在如今已經rc，相信離release不遠了。

5.2 npm、jspm、Bower與Yarn

在模塊管理器這裏，npm依舊是王者，但要說明的是，npm的全稱是node package mamager，主要用來管理運行在Node上的模塊，但如今卻託管了大量只能運行在瀏覽器上的模塊。形成這種現象的幾個緣由：

1. Webpack的大量使用，使得前端也能夠並習慣於使用CommonJS類型的模塊；

2. 沒有更合適的替代者，Bower之前不是，之後更不會是。

前端的模塊化規範過去一直處於戰國紛爭的年代。在Node上CommonJS沒什麼意見。在瀏覽器上，雖然如今有了ES2015 Modules，卻缺乏了模塊加載器，將來多是SystemJS，但如今仍處於草案階段。不管哪一種，都仍處於JavaScript語言層面，而完整的前端模塊化還要包括CSS與HTML，以及一些二進制資源。目前最貼近的方案也就只能是JSX+CSS in JS的模式了，這在Webpack環境下大行其道。這種現象甚至影響了Angular 二、Ember 2等框架的設計。從這點看來，jspm只是一個加了層包裝的殼子，徹底沒有任何優點。

npm自己也存在着各類問題，這在實踐中總會影響效率、安全以及一致性，Facebook果斷地出品了Yarn——npm的替代升級版，支持離線模式、嚴格的依賴版本管理等在工程中很是實用的特性。

至於前端模塊化，JavaScript有CommonJS和ES2015 Modules就夠了，但工程中的組件，可能還須要在不一樣的框架環境中重複被開發，它們依舊不兼容。將來的話，WebComponents多是一個比較優越的方案。

5.3 同構

同構的設計在軟件行業早就被提出，不過在Web前端，仍是在Node.js、特別是React的出現後，才真正成爲了可能，由於React內核的運行並不依賴於瀏覽器DOM環境。

React的同構是一個比較低成本的方案，只要注意代碼的執行環境，先後端確實能夠共享很大一部分代碼，隨之帶來的一大收益是有效克服了SPA這種前端渲染的頁面在首屏性能上的瓶頸，這是全部具有視圖能力的框架Angular、Vue.js、React等的共性問題，而如今，它們都在一種程度上支持server render。

能夠想到的作先後端同構面臨的幾個問題：

1. 靜態資源如何引入，CSS in JS模式須要考慮在Node.js上的兼容性；

2. 數據接口如何fetch，在瀏覽器上是AJAX，在Node.js上是什麼；

3. 如何作路由同構，瀏覽器無刷新切換頁面，新路由在服務端可用；

4. 大量DOM渲染如何避免阻塞Node.js的執行進程。

目前GitHub上star較多的同構框架包括Vue.js的nuxt和React的next.js，以及數據存儲全包的meteor。能夠確定的是，不論它們是否能部署在生產環境中，都不可能知足你的全部需求，適當的從新架構是必要的，在這個新的領域，沒有太多的經驗能夠借鑑。

6、將來技術與職業培養

6.1 大數據方向

 

愈來愈多作toB業務的公司對前端的需求都是在數據可視化上，或者更通俗一些——報表。這個部分在從前一般都是前端工程師嗤之以鼻的方向，認爲無聊、沒技術。不過在移動端時代，特別是大數據時代，對此類技能的需求增多，技術的含金量也持續提高。根據「面向工資編程」的原則，必定會有大量工程師加入進來。

對這個方向的技術技能要求是Canvas、WebGL，但其實絕大多數需求都不須要你直接與底層API打交道，已經有大量第三方工具幫你作到了，不乏很是優秀的框架。如百度的ECharts，國外的Chart.js、Highcharts、D3.js等等，特別是D3.js，幾乎是大數據前端方向的神器，很是值得學習。

話說回來，做爲工程師，心存憂患意識，必定不能以學會這幾款工具就知足，在實際的業務場景中，更多的須要你擴展框架，生產本身的組件，這須要你具有必定的數學、圖形和OpenGL底層知識，能夠說是很是大的技術壁壘和入門門檻。

6.2 WebVR

 

今年能夠說是VR技術爆發式的一年，市場上推出了多款VR遊戲設備，而淘寶更是開發出了平民的buy+購物體驗，等普及開來，幾乎能夠顛覆傳統的網上購物方式。

VR的開發離不開對3D環境的構建，WebVR標準還在草案階段，A-Frame能夠用來體驗，另外一個three.js框架是一個比較成熟的構建3D場景的工具，除了能在將來的VR應用中大顯身手，一樣也在構建極大豐富的3D交互移動端頁面中顯得必不可少，淘寶就是國內這方面的先驅。

6.3 WebAssembly

 

asm.js已發展成WebAssembly，由谷歌、微軟、蘋果和Mozilla四家共同推進，彷佛是很是喜人樂見的事情，畢竟主要瀏覽器內核廠商都在這裏了。不過合做的一大問題就是低效，今年終於有了能夠演示的demo，容許編寫C++代碼來運行在瀏覽器上了，你須要下載一大堆依賴庫，以及一次很是耗時的編譯，不過好歹是個進步。

短期內，咱們都不太可能改變使用JavaScript編寫前端代碼的現狀，Dart失敗了，只能指望於將來的WebAssembly。有了它，前端在運行時效率、安全性都會上一個臺階，其餘隨之而來的問題，就只能等到那一天再說了。

6.4 WebComponents

 

WebComponents能帶給咱們什麼呢？HTML Template、Shadow DOM、Custom Element和HTML Import？是的，很是完美的組件化系統。Angular、React的組件化系統中，都是以Custom Element的方式組合HTML，但這都是假象，它們最終都會被編譯成JavaScript纔會執行。但WebComponents不同，Custom Element原生就能夠被瀏覽器解析，DOM元素自己的方法均可以自定義，並且元素內部的子元素、樣式，因爲Shadow DOM的存在，不會污染全局空間，真正成爲了一個沙箱，組件化就應該是這個樣子，外部只關心接口，不關心也不能操縱內部的實現。

當前的組件化，無不依賴於某一特定的框架環境，或者是Angular，或者是React，想移植就須要翻盤推倒重來，也就是說他們是不兼容的。有了WebComponents，做爲瀏覽器廠商共同遵循和支持的標準，這一現狀將極有可能被改寫。

將來的前端組件化分發將不會是npm那麼簡單，可能只是引用一個HTML文件，更有可能的是包含CSS、HTML、JavaScript和其餘二進制資源的一個目錄。

目前只有最新的Chrome徹底支持WebComponents的全部特性，因此距離真正應用它還尚需時日。因爲技術上的限制，WebComponents polyfill的能力都很是受限，Shadow DOM不可能實現，而其餘三者則更多須要離線編譯實現，能夠參考Vue.js 2的實現，很是相似於WebComponents。

6.5 關於微信小程序

微信小程序對於今年不得不說，但筆者卻也無話可說。依託於龐大的用戶量，微信官方出品了自有的一套開發技術棧，只能說給繁雜的前端開發又填了一個角色——微信前端工程師。

7、總結

最後還有幾點須要說明。

7.1 工程化

首先，如今業界都在大談前端工程化，人人學構建，個個會打包。鄙人認爲，工程化的要點在於「平衡諸方案利弊，取各指標的加權收益最大化」。僅僅加入了項目構建是遠遠不夠的，在實踐中，咱們常常須要考慮的方向大能夠分爲兩種：一是研發效率，這直接應該響應業務需求的能力；二是運行時性能，這直接影響用戶的使用體驗，同時也是產品經理所關心的。這兩點都直接影響了公司的收入和業績。

具體到細節的問題上來，好比說：

1. 靜態資源若是組織和打包，對於具有衆多頁面的產品，考慮到不斷的迭代更新，如何打包能讓用戶的代碼下載量最少（性能）？不要說使用Webpack打成一個包，也不要說編譯common chunk就萬事大吉了，難道還須要不斷地調整編譯腳本（效率）？改錯了怎麼辦？有測試方案麼？

2. 利用Angular特別是React構建純前端渲染頁面，首屏性能如何保證（性能）？引入服務端同構渲染，好的，那麼服務端由誰來編寫？想來必是由前端工程師來編寫，那麼服務端的數據層架構是怎麼樣的？運維角度看，前端如何保證服務的穩定（效率）？

3. 組件化方案如何制定（效率）？若是保證組件的分發和引用的便捷性？如何保證組件在用戶端的即插即用（性能）？

對於工程師來講，首先須要量化每一個指標的權重，而後對於備選方案，逐個計算加權值，取最大值者，這纔是科學的技術選型方法論。

然而在業界，不多能看到針對工程化的更深刻分享和討論，大多停留在「哪一個框架好」，「使用XXX實現XXX」的階段，每每是某一特定方向的優與劣，不多有科學的全局觀。甚至只看到了某一方案的優點，對其弊端和可持續性避而不談。形成這種現狀的緣由是多方面的，一是技術上，工程師能力的緣由並無考慮獲得，二是政治上，工程師須要快速實現某一目標，以取得可見的KPI收益，完成團隊的績效目標，但更多的多是，國內絕大多數產品的複雜性都還不夠高，根本無需考慮長久的可持續發展和大規模的團隊合做對於技術方案的影響。

所以，你必須接受的現狀是，不管你是否使用CSS預處理器、使用Webpack仍是Grunt、使用React仍是Angular，使用RN仍是Hybrid，對於產品極有可能都不是那麼地敏感和重要，每每更取決於決策者的我的喜愛。

7.2 角色定位

確實，近兩年，Web前端工程師開始不夠老實，要麼用Node.js插手服務端開發，要麼用RN插手客戶端開發。如何看待這些行爲呢？

鄙人覺得，涉足服務端開發是沒問題的，由於只涉及到渲染層面，仍是屬於「前端」的範疇的。何況，在實際的工程實踐中，已經能夠證實，優秀的前端研發體系確實離不開服務端的參與，想一想Facebook的BigPipe。不過，這須要服務端良好的分層架構，數據與渲染徹底解耦分離，後端工程師只負責業務數據的CRUD，並提供接口，前端工程師從接口中獲取數據，並推送到瀏覽器上。數據解耦是比接口解耦更加優越的方案。所以如今只要你的服務端架構容許，Node.js做爲Web服務已經比較成熟，前端負責服務端渲染是徹底沒有問題的。

前端涉足客戶端開發也是合理的，畢竟都運行在用戶端，也屬於前端的範疇。拋開阿里系的Weex鄙人不甚瞭解，NativeScript、RN都還缺少大規模持續使用的先例，這是與涉足服務端領域的不一樣，客戶端上的方案都還不夠成熟，工具的限制阻礙了前端向客戶端的轉型，仍然須要時間的考驗。不過期間可能不會不少，將來的Web技術依託高性能硬件以及普及的WebGL、WebRTC、Payment API等能力，在性能和功能上都會挑戰Native的地位。最差的狀況，還能夠基於Hybrid，利用Native適當擴展能力，這就是合做而非競爭關係了。

總以前端工程師的本仍然在瀏覽器上，就這一點，範圍就足夠廣使得沒人有敢言本身真正「精通」前端。若是條件容許的話，特別是技術成熟以後，涉獵其餘領域也是鼓勵的。

7.3 寫在最後

在各類研發角色中，前端註定是一個比較心累的一個。每年的年底，咱們都能看到幾乎徹底不同的世界，這背後是無數前端人燒腦思考、激情迸發的結果。不管最終產品的流行與否，都推進着前端技術領域的高速更新換代。正是印證了那一句「惟有變化爲不變」。做爲業務線的研發工程師，咱們的職責是甄選最佳組合方案，取得公司利益最大化。這個「最佳」的涉獵面很是廣，取決於設計者的技術視野廣度，也有關於決策者的管理經驗，歷來都不是一件簡單的事。

將來的Web前端開發體驗必定是更豐富的，依託WebComponents的標準化組件體系，基於WebAssembly的高性能運行時代碼，以及背靠HTTP/2協議的高速資源加載，前端工程師沒必要在性能上、兼容性上分散太多精力，從而能夠專一於開發具有豐富式交互體驗的下一代Web APP，多是VR，也多是遊戲。

在迎接2017的同時，咱們仍然要作好心理準備，新的概念、新的框架和工具以及新的語法依舊會源源不斷的生產出來，不完美的現狀也依舊會持續。