转载：2016前端开发技术巡礼
本文轉(zhuǎn)自前端之巔，作者殷勇。
2016年馬上過去了，像過去六年中的每一年一樣，Web前端領(lǐng)域又產(chǎn)生了“面目全非”而又“耳目一新”的變化，不但舊事物持續(xù)不斷地被淘汰，新事物也難保坐久江山，大有岌岌可危之勢。開源界如群雄逐鹿，不斷生產(chǎn)新的概念、新的框架、新的工具，去年中一些流行的技術(shù)今年大多得到了進(jìn)一步的演進(jìn)和升級，活躍度非常高，卻仍然不能保證前端的未來屬于它們。在今年整體資本市場冷卻的大環(huán)境下，to B業(yè)務(wù)的創(chuàng)業(yè)公司顯現(xiàn)出了較強(qiáng)的生命力，這種類型的業(yè)務(wù)也給Web前端的工作帶來了明顯的差異性，工程師整體技能方向也展露出一絲不一樣的分支。本文將從下至上、由低到高的維度盤點(diǎn)過去一年中Web前端領(lǐng)域發(fā)生的重要事件以及影響未來2017的關(guān)鍵性因素。視野所限，不盡完整。
一、更新的網(wǎng)絡(luò)與軟件環(huán)境
1.1 HTTP/2 的持續(xù)普及
今年中，幾乎所有的現(xiàn)代桌面瀏覽器都已經(jīng)支持了HTTP/2協(xié)議，移動端依靠降級為SPDY依舊可以覆蓋幾乎所有平臺，這樣使得從協(xié)議上優(yōu)化頁面的性能成為了可能。
同時，前端靜態(tài)資源打包的必要性成為了一定程度上的爭論焦點(diǎn)，打包合并作為傳統(tǒng)的前端性能優(yōu)化方案，它的存留對前端工程化影響極大，Facebook公司著名的靜態(tài)資源動態(tài)打包方案的優(yōu)越性也會被弱化。社區(qū)上多篇文章紛紛發(fā)表對HTTP/2的性能實(shí)驗(yàn)數(shù)據(jù)，卻不盡相同。
在2017年，我相信所有大型站點(diǎn)都會切換HTTP/2，但依舊不會放棄對靜態(tài)資源打包合并的依賴。而且，對于Server Push等高級特性，也不會有太多的應(yīng)用。
1.2 Internet Explorer 8
三年前還在考慮兼容IE6的前端技術(shù)社區(qū)，在前不久天貓宣布不再支持IE8后又引起了一股躁動。IE8是Windows XP操作系統(tǒng)支持的最高IE版本，放棄IE8意味著放棄了使用IE的所有XP用戶。
其實(shí)在2016年的今天，前端社區(qū)中框架、工具的發(fā)展早已不允許IE8的存在，Angular 早在1.3版本就果斷放棄了IE8，React 也在年初的v15版本上宣布放棄。在PC領(lǐng)域，你依舊可以使用像Backbone.js一樣的其他框架繼續(xù)對IE進(jìn)行支持，但無論是從研發(fā)效率上還是從運(yùn)行時效率上，放棄它都是更好的選擇。
由于對HTML5兼容性不佳，在2017年，相信IE9也會逐漸被社區(qū)放棄，以取得更好的性能、更少的代碼體積。
二、如何編寫(Java)Script
2.1 ES2016？ES2017？Babel！
去年定稿的ES2015（亦稱ES6）帶來了大量令人激動的新語言特性，并快速被V8和SpiderMonkey所實(shí)現(xiàn)。但由于瀏覽器版本碎片化問題，目前編寫生產(chǎn)環(huán)境代碼仍然以ES5為主。今年年中發(fā)布的ES2017帶來的新特性數(shù)量少的可憐，但這正好給了瀏覽器廠商消化ES2015的時間，在ES2017到來之前喘口氣——是的，明年的ES2017勢必又會帶來一大波新特性。
JS解釋引擎對新特性的支持程度并不能阻礙狂熱的開發(fā)者使用他們，在接下來的很長時間，業(yè)界對Babel的依賴必然有增無減。Babel生態(tài)對下一代ECMAScript的影響會進(jìn)一步加大，人們通過先增加新的Babel-plugin，后向ECMA提案的方式成為了ECMAScript進(jìn)化的常態(tài)。開發(fā)者編寫的代碼能直接運(yùn)行在瀏覽器上的會越來越少。
但使用Babel導(dǎo)致的編譯后代碼體積增大的問題并沒有被特別關(guān)注，由于polyfill可能被重復(fù)引入，部署到生產(chǎn)環(huán)境的代碼帶有相當(dāng)一部分冗余。
2.2 TypeScript
作為ECMAScript語言的超集，TypeScript在今年取得了優(yōu)異的成績，Angular 2放棄了傳說中的AtScript，成為了TypeScript的最大客戶。人們可以像編寫Java一樣編寫JavaScript，有效提升了代碼的表述性和類型安全性。
但凡事有兩面，TypeScript的特性也在不斷升級，在生產(chǎn)環(huán)境中，你可能需要一套規(guī)范來約束開發(fā)者，防止濫用導(dǎo)致的不兼容，這反而增加了學(xué)習(xí)成本、應(yīng)用復(fù)雜性和升級安全性。個中優(yōu)劣，仍需有大量的工程實(shí)踐去積累經(jīng)驗(yàn)。
此外，TypeScript也可以看做一種轉(zhuǎn)譯器，與Babel有著類似的新特性支持。在2017年，我們期待TypeScript與Babel會發(fā)展成怎樣的一種微妙關(guān)系。
2.3 promise、generator 與 async/await
在回調(diào)地獄問題上，近兩年我們不斷被新的方案亂花了眼。過去我們會利用async來簡化異步流的設(shè)計(jì)，直到“正房”Promise的到來。但它們只是callback模式的語法糖，并沒有完全消除callback的使用。
ES2015帶來的generator/yield似乎成為了解決異步編程的一大法寶，雖然它并非為解決異步編程所設(shè)計(jì)的。但generaor的運(yùn)行是十分繁瑣的，因此另一個工具co又成為了使用generator的必備之選。Node.js社區(qū)的Koa框架初始就設(shè)計(jì)為使用generator編寫洋蔥皮一樣的控制流。
但曇花一現(xiàn)，轉(zhuǎn)眼間async/await的語法，配合Promise編寫異步代碼的方式立即席卷整個前端社區(qū)，雖然async/await仍然在ES2017的草案中，但在今天，不寫async/await立刻顯得你的設(shè)計(jì)落后社區(qū)平均水平一大截。
在Node.js上，v7已經(jīng)支持在harmony參數(shù)下的async/await直接解釋，在明年4月份的v8中，將會正式支持，屆時，Koa 2的正式版也會發(fā)布，幾乎完全摒棄了generator。
2.4 fetch
受到回調(diào)問題的影響，傳統(tǒng)的XMLHttpRequest有被fetch?API 取代之勢。如今，成熟的polyfill如whatwg-fetch、node-fetch、isomorphic-fetch在npm上的每日下載量都非常大，即便對于兼容性不好的移動端，開發(fā)者也不愿使用繁瑣的AJAX。借助async/await的語法，使用fetch API能讓代碼更簡潔。
三、Node.js服務(wù)與工具
3.1 Koa 2
Koa與流行的Express屬于“同根生”的關(guān)系，它們由同一團(tuán)隊(duì)打造。相比Express，新的Koa框架更輕量、更靈活。但Koa的設(shè)計(jì)在短時間內(nèi)曾經(jīng)出現(xiàn)了較大的變動，這主要受到了async/await語法對異步編程的影響。在v2版本中，Koa的middleware拋棄generator轉(zhuǎn)而支持async，所有第三方middleware實(shí)現(xiàn)，要么自行升級，要么使用Koa-convert進(jìn)行包裝轉(zhuǎn)換。
目前Koa在Node.js社區(qū)的HTTP服務(wù)端框架中受到關(guān)注度比較高，不過其在npm上latest目前仍處于1.x階段，預(yù)計(jì)在2017年4月份發(fā)布Node.js v8后，就會升級到2.x。
Koa的輕量級設(shè)計(jì)意味著你需要大量第三方中間件去實(shí)現(xiàn)一個完整的Web應(yīng)用，目前鮮有看到對Koa的大規(guī)模重度使用，因此也就對其無從評價。相信在明年，越來越多的產(chǎn)品應(yīng)該會嘗試部署Koa 2，屆時，對第三方資源的依賴沖突也會尖銳起來，這需要一個過程才能讓Koa的生態(tài)完備起來。預(yù)計(jì)在2018年，我們會得到一個足夠健壯的Koa技術(shù)棧。這會促進(jìn)Node.js在服務(wù)端領(lǐng)域的擴(kuò)展，輕量級的Web服務(wù)將會逐漸成為市場上的主流。
四、框架紛爭
4.1 jQuery已死？
今年六月份jQuery發(fā)布了3.0版本，距離2.0發(fā)布已經(jīng)有三年多的時間，但重大的更新幾乎沒有。由于老舊瀏覽器的逐漸放棄和升級，jQuery需要處理的瀏覽器兼容性問題越來越少，專注于API易用性和效率越來越多。
隨著如Angular、React、Ember、Vue.js等大量具備視圖數(shù)據(jù)單雙向綁定能力的框架被普及，使用jQuery編寫指令式的代碼操作DOM的人越來越少。早在2015年便有人聲稱jQuery已死，社區(qū)中也進(jìn)行了大量雷同的討論，今天我們看到確實(shí)jQuery的地位已大不如前，著名的sizzle選擇器在今天已完全可由querySelector*原生方法替代，操作DOM也可以由框架根據(jù)數(shù)據(jù)的變動自動完成。
明年jQuery在構(gòu)建大型前端產(chǎn)品的過程中的依賴會被持續(xù)弱化，但其對瀏覽器特性的理解和積淀將對現(xiàn)有的和未來的類Angular的MVVM框架的開發(fā)依舊具有很大的借鑒意義。
4.2 Angular 2
好事多磨，Angular 2的正式版終于在今年下半年發(fā)布，相比于1.x，新的版本幾乎是完全重新開發(fā)的框架，已經(jīng)很難從設(shè)計(jì)中找到1.x的影子。陡峭的學(xué)習(xí)曲線也隨之而來，npm、ES2015 Modules、Decorator、TypeScript、Zone.js、RxJS、JIT/AOT、E2E Test，幾乎都是業(yè)界這兩年中的最新概念，這著實(shí)給初學(xué)者帶來了不小的困難。
Angular 2也更面向于開發(fā)單頁應(yīng)用（SPA），這是對ES2015 Modules語法描述的模塊進(jìn)行打包（bundle）的必然結(jié)果，因此Angular 2也更依賴于Webpack等“bundler”工具。
雖然Angular 聲稱支持TypeScript、ECMAScript和Dart三種語言，不過顯然業(yè)界對Dart沒什么太大興趣，而對于ECMAScript和TypeScript，兩種語言模式下Angular 2在API和構(gòu)建流程上都有著隱式的（文檔標(biāo)注不明的）差異化，這必然會給開發(fā)者以困擾。加上業(yè)界第三方工具和組件的支持有限，TypeScript幾乎是現(xiàn)在開發(fā)者唯一的選擇。
此外，Angular團(tuán)隊(duì)已聲明并沒有完全放棄對1.x組件的支持，通過特有的兼容API，你可以在2.x中使用針對1.x開發(fā)的組件。鑒于不明確的風(fēng)險，相信很少有團(tuán)隊(duì)愿意這樣折騰。
現(xiàn)在在產(chǎn)品中使用Angular 2，在架構(gòu)上，你需要考慮生產(chǎn)環(huán)境和開發(fā)環(huán)境下兩種完全不同的構(gòu)建模式，也就是JIT和AOT，這需要你有兩套不一樣的編譯流程和配置文件。在不同環(huán)境下模塊是否符合期望，可以用E2E、spec等方式來進(jìn)行自動化測試，好的，那么Angular 2的測試API又可能成了技術(shù)壁壘，它的復(fù)雜度可能更甚Angular本身。可以確信，在業(yè)務(wù)壓力的迫使下，絕大部分團(tuán)隊(duì)都會放棄編寫測試。
總之，Angular 2是一個非常具有競爭力的框架，其設(shè)計(jì)非常具有前瞻性，但也由于太過復(fù)雜，很多特性都會成為雞肋，被開發(fā)者所無視。由于React和Vue.js的競爭，Angular 2對社區(qū)的影響肯定不如其前輩1.x版本，且其更高級的特性如Server Render還沒有被工程化實(shí)踐，因此相信業(yè)界還會持續(xù)觀望，甚至要等到下一個4.x版本的發(fā)布。
4.3 Vue.js 2.0
Vue.js 絕對是類MVVM框架中的一匹黑馬，由作者一人打造，更可貴的是作者還是華人。Vue.js在社區(qū)內(nèi)的影響非常之大，特別是2.0的發(fā)布，社區(qū)快速生產(chǎn)出了無數(shù)基于Vue.js的解決方案，這主要還是受益于其簡單的接口API和友好的文檔。可見作為提供商，產(chǎn)品的簡單易用性顯得尤為重要。在性能上，Vue.js基于ES5 Setter，得到了比Angular 1.x臟檢查機(jī)制成倍的性能提升。而2.0在模塊化上又更進(jìn)一步，開發(fā)難度更低，維護(hù)性更好。可以說Vue.js準(zhǔn)確地戳中了普通Web開發(fā)者的痛點(diǎn)。在國內(nèi)，Vue.js與Weex達(dá)成了合作，期待能給社區(qū)帶來怎樣的驚喜。
4.4 React
目前看來，React似乎仍是今年最流行的數(shù)據(jù)視圖層解決方案，并且?guī)缀跻呀?jīng)成為了每名前端工程師的標(biāo)配技能。今年React除了版本從0.14直接躍升至15，放棄了IE8以外，并沒有更多爆發(fā)式的發(fā)展。人們對于使用JSX語法編寫Web應(yīng)用已經(jīng)習(xí)以為常，就像過去十年間寫jQuery一樣。
React的代碼在維護(hù)性能上顯而易見，如果JSX編寫得當(dāng)，在重渲染性能上也具備優(yōu)勢，但如果只部署在瀏覽器環(huán)境中，那么首屏性能將會受到負(fù)面影響，畢竟在現(xiàn)階段，純前端渲染仍然快不過后端渲染，況且后端具備天生的chunked分段輸出優(yōu)勢。我們在業(yè)界中可以看到一些負(fù)面的案例，比如某新聞應(yīng)用利用React全部改寫的case，就是對React的一種誤用，完全不顧其場景劣勢。
圍繞著React發(fā)展的替代品和配套工具依舊很活躍，preact以完全兼容的API和小巧的體積為賣點(diǎn)，inferno以更快的速度為賣點(diǎn)，等等。每個框架都想在Virtual DOM上有所創(chuàng)新，但它們的提升都不是革命性的，由此而帶來的第三方插件不兼容性，這種風(fēng)險是開發(fā)者不愿承擔(dān)的，筆者認(rèn)為它們最大的意義在于能為React的內(nèi)部實(shí)現(xiàn)提供另外的思路。就像在自然界，生物多樣性是十分必要的，雜交能帶來珍貴的進(jìn)化優(yōu)勢。
4.5 React-native
今年是React-native（一下簡稱RN）支持雙端開發(fā)的第一年，不斷有團(tuán)隊(duì)分享了自己在RN上的實(shí)踐成果，似乎前途一片大好，RN確實(shí)有效解決了傳統(tǒng)客戶端受限于發(fā)版周期、H5受限于性能的難題，做到了魚和熊掌兼得的理想目標(biāo)。
但我們?nèi)匀恍枰|(zhì)疑：首先，RN目前以兩周為周期發(fā)布新版本，沒有LTS，每個版本向前不兼容。也就是說，你使用0.39.0的版本編寫bundle代碼，想運(yùn)行在0.35.0的runtime上，這幾乎會100%出問題。在這種情況下，如何制定客戶端上RN的升級策略？如果升級，那么業(yè)務(wù)上如何針對一個以上的runtime版本編寫代碼？如果不升級，那么這意味著你需要自己維護(hù)一個LTS。要知道目前每個RN的版本都會有針對前版本的bug fix，相信沒有團(tuán)隊(duì)有精力可以在一個老版本上同步這些，如果不能，那業(yè)務(wù)端面對的將是一個始終存在bug的runtime，其開發(fā)心理壓力可想而知。
其次，雖然RN聲稱支持Android與iOS雙端，但在實(shí)踐中卻存在了極多系統(tǒng)差異性，有些體現(xiàn)在了RN文檔中，有一些則體現(xiàn)在了issue中，包括其他一些問題，GitHub上RN的近700個issue足以讓人望而卻步。如果不能高效處理開發(fā)中遇到的各種匪夷所思的問題，那么工期就會出現(xiàn)嚴(yán)重風(fēng)險。此外，RN在Android和iOS上的性能也不盡相同，Android上更差一些，即便你完成了整個業(yè)務(wù)功能，卻還要在性能優(yōu)化上消耗精力。并且無論如何優(yōu)化，單線程模型既要實(shí)現(xiàn)流暢的轉(zhuǎn)場動畫，又要操作一系列數(shù)據(jù)，需要很高的技巧才能保證可觀的性能表現(xiàn)。在具體的實(shí)踐中，對于H5，往往由于時間關(guān)系，業(yè)務(wù)上先會上一個還算過得去的版本，過后再啟動性能優(yōu)化。然而對于RN，很有可能達(dá)到“過得去”的標(biāo)準(zhǔn)都需要大量的重構(gòu)工作。
再次，RN雖然以Native渲染元素，但畢竟是運(yùn)行在JavaScript Core內(nèi)核之上，依舊是單線程，相對于H5這并沒有對性能有革命性質(zhì)的提升。Animated動畫、大ListView滾動都是老生常談的性能瓶頸，為了解決一些復(fù)雜組件所引起的性能和兼容性問題，諸多團(tuán)隊(duì)紛紛發(fā)揮主動能動性，自己建設(shè)基于Native的高性能組件，這有兩方面問題，一是不利于分發(fā)共享，因?yàn)樗鼑?yán)重依賴特定的客戶端環(huán)境，二是它仍依賴客戶端發(fā)版，仍需要客戶端的開發(fā)，違背了RN最最重要的初衷。可以想象，在大量頻繁引用Native組件后，RN又退化成了H5+Hybrid模式，其UI的高性能優(yōu)勢將會在設(shè)備性能不斷升級下被削弱，同時其無stable版本反而給開發(fā)帶來了更多不可預(yù)測的風(fēng)險變量。
最后，RN仍然難以調(diào)試和測試，特別是依賴了特定端上組件之后，本地的自動化測試幾乎成為了不可能，而絕大多數(shù)客戶端根本不支持自動化測試。而調(diào)試只能利用remote debugger有限的能力，在性能分析上都十分不便。
可以說RN的出現(xiàn)帶給了移動開發(fā)以獨(dú)特的新視角，使得利用JavaScript開發(fā)Native成為了可能，NativeScript、Weex等類似的解決方案也發(fā)展開來。顯然RN目前最大的問題仍然是不夠成熟和穩(wěn)定，利用RN替代Native依然存在著諸多風(fēng)險，這對于重量級的、長期維護(hù)的客戶端產(chǎn)品可能并不是特別適合，比如Facebook自己。RN的優(yōu)勢顯而易見，但其問題也是嚴(yán)重的，需要決策者對個方面利弊都有所了解，畢竟這種試錯的成本不算小。
由于時間關(guān)系，市場上并沒有一個產(chǎn)品在RN的應(yīng)用上有著足夠久的實(shí)踐經(jīng)驗(yàn)，大部分依然屬于“我們把RN部署到客戶端了”的階段，我們也無法預(yù)測這門技術(shù)的長久表現(xiàn)，現(xiàn)在評價RN的最終價值還為時尚早。在2017年，期待RN團(tuán)隊(duì)能做出更長足的進(jìn)步，但不要太樂觀，以目前的狀態(tài)來看，想達(dá)到stable狀態(tài)還是有著相當(dāng)大的難度。
4.6 Redux 與 Mobx
Redux?成功成為了 React 技術(shù)棧中的最重要成員之一。與Vue.js一樣，Redux也是憑借著比其他Flux框架更簡單易懂的API才能脫穎而出。不過已經(jīng)很快有人開始厭煩它每寫一個應(yīng)用都要定義action、reducer、store以及一大堆函數(shù)式調(diào)用的繁瑣做法了。
Mobx也是基于ES5 setter，讓開發(fā)者可以不用主動調(diào)用action函數(shù)就可以觸發(fā)視圖刷新，它只需要一個store對象以及幾個decorator就能完成配置，確實(shí)比Redux簡單得多。
在數(shù)據(jù)到視圖同步上，無論使用什么樣的框架，都有一個至關(guān)重要的問題是需要開發(fā)者自己操心，那就是在眾多數(shù)據(jù)變動的情形下，如何保證視圖以最少的但合理的頻率去刷新，以節(jié)省極其敏感的性能消耗。在Redux或Mobx上都會出現(xiàn)這個問題，而Mobx尤甚。為了配合提升視圖的性能，你依然需要引入action、transaction等高級概念。在控制流與視圖分離的架構(gòu)中，這是開發(fā)者無可避免的關(guān)注點(diǎn)，而對于Angular、Vue.js，框架會幫你做很多事情，開發(fā)者需要考慮的自然少了許多。
4.7 Bootstrap 4
Bootstrap 4處于alpha階段已經(jīng)非常久了，即使現(xiàn)在3.x已經(jīng)停止了維護(hù)，它似乎受到了Twitter公司業(yè)務(wù)不景氣的影響，GitHub上的issue還非常多。Bootstrap是建設(shè)內(nèi)部平臺最佳的CSS框架，特別是對于那些對前端不甚了解的后端工程師。我們不清楚Bootstrap還能堅(jiān)持多久，如果Twitter不得不放棄它，最好的歸宿可能是把它交給第三方開源社區(qū)去維護(hù)。
五、工程化與架構(gòu)
5.1 Rollup 與 Webpack 2
Rollup是近一年興起的又一打包工具，其最大賣點(diǎn)是可以對ES2015 Modules的模塊直接打包，以及引入了Tree-Shaking算法。通過引入Babel-loader，Webpack一樣可以對ES2015 Modules進(jìn)行打包，于是Rollup的亮點(diǎn)僅在于Tree-Shaking，這是一種能夠去除冗余，減少代碼體積的技術(shù)。通過分析AST（抽象語法樹），Rollup可以發(fā)現(xiàn)那些不會被使用的代碼，并去除它。
不過Tree-Shaking即將不是Rollup的專利了，Webpack 2也將支持，并也原生支持ES6 Modules。這可以說是“旁門左道”對主流派系進(jìn)行貢獻(xiàn)的一個典型案例。
Webpack是去年大熱的打包工具，儼然已經(jīng)成為了替代grunt/gulp的最新構(gòu)建工具，但顯然并不是這樣。筆者一直認(rèn)為Webpack作為一個module bundler，做了太多與其無關(guān)的事情，從而表象上看來這就是一個工程構(gòu)建工具。經(jīng)典的構(gòu)建需要有任務(wù)的概念，然后控制任務(wù)的執(zhí)行順序，這正是Ant、Grunt、Gulp做的事情。Webpack不是這樣，它最重要的概念是entry，一個或者多個，它必須是類JavaScript語言編寫的磁盤文件，所有其他如CSS、HTML都是圍繞著entry被處理的。估計(jì)你很難一眼從配置文件中看出Webpack對當(dāng)前項(xiàng)目進(jìn)行了怎樣的“構(gòu)建”，不過似乎社區(qū)中并沒有人提出過異議，一切都運(yùn)行得很好。
題外話：如何使用Webpack構(gòu)建一個沒有任何JavaScript代碼的工程？
新的Angular 2使用Webpack 2編譯效果更加，不過，已經(jīng)提了一年的Webpack 2，至今仍處于beta階段，好在現(xiàn)在已經(jīng)rc，相信離release不遠(yuǎn)了。
5.2 npm、jspm、Bower與Yarn
在模塊管理器這里，npm依舊是王者，但要說明的是，npm的全稱是node package mamager，主要用來管理運(yùn)行在Node上的模塊，但現(xiàn)在卻托管了大量只能運(yùn)行在瀏覽器上的模塊。造成這種現(xiàn)象的幾個原因：
前端的模塊化規(guī)范過去一直處于戰(zhàn)國紛爭的年代。在Node上CommonJS沒什么意見。在瀏覽器上，雖然現(xiàn)在有了ES2015 Modules，卻缺少了模塊加載器，未來可能是SystemJS，但現(xiàn)在仍處于草案階段。無論哪種，都仍處于JavaScript語言層面，而完整的前端模塊化還要包括CSS與HTML，以及一些二進(jìn)制資源。目前最貼近的方案也就只能是JSX+CSS in JS的模式了，這在Webpack環(huán)境下大行其道。這種現(xiàn)象甚至影響了Angular 2、Ember 2等框架的設(shè)計(jì)。從這點(diǎn)看來，jspm只是一個加了層包裝的殼子，完全沒有任何優(yōu)勢。
npm本身也存在著各種問題，這在實(shí)踐中總會影響效率、安全以及一致性，Facebook果斷地出品了Yarn——npm的替代升級版，支持離線模式、嚴(yán)格的依賴版本管理等在工程中非常實(shí)用的特性。
至于前端模塊化，JavaScript有CommonJS和ES2015 Modules就夠了，但工程中的組件，可能還需要在不同的框架環(huán)境中重復(fù)被開發(fā)，它們依舊不兼容。未來的話，WebComponents可能是一個比較優(yōu)越的方案。
5.3 同構(gòu)
同構(gòu)的設(shè)計(jì)在軟件行業(yè)早就被提出，不過在Web前端，還是在Node.js、特別是React的出現(xiàn)后，才真正成為了可能，因?yàn)镽eact內(nèi)核的運(yùn)行并不依賴于瀏覽器DOM環(huán)境。
React的同構(gòu)是一個比較低成本的方案，只要注意代碼的執(zhí)行環(huán)境，前后端確實(shí)可以共享很大一部分代碼，隨之帶來的一大收益是有效克服了SPA這種前端渲染的頁面在首屏性能上的瓶頸，這是所有具備視圖能力的框架Angular、Vue.js、React等的共性問題，而現(xiàn)在，它們都在一種程度上支持server render。
可以想到的做前后端同構(gòu)面臨的幾個問題：
目前GitHub上star較多的同構(gòu)框架包括Vue.js的nuxt和React的next.js，以及數(shù)據(jù)存儲全包的meteor。可以肯定的是，不論它們是否能部署在生產(chǎn)環(huán)境中，都不可能滿足你的所有需求，適當(dāng)?shù)闹匦录軜?gòu)是必要的，在這個新的領(lǐng)域，沒有太多的經(jīng)驗(yàn)可以借鑒。
六、未來技術(shù)與職業(yè)培養(yǎng)
6.1 大數(shù)據(jù)方向
越來越多做toB業(yè)務(wù)的公司對前端的需求都是在數(shù)據(jù)可視化上，或者更通俗一些——報(bào)表。這個部分在從前通常都是前端工程師嗤之以鼻的方向，認(rèn)為無聊、沒技術(shù)。不過在移動端時代，特別是大數(shù)據(jù)時代，對此類技能的需求增多，技術(shù)的含金量也持續(xù)提升。根據(jù)“面向工資編程”的原則，一定會有大量工程師加入進(jìn)來。
對這個方向的技術(shù)技能要求是Canvas、WebGL，但其實(shí)絕大多數(shù)需求都不需要你直接與底層API打交道，已經(jīng)有大量第三方工具幫你做到了，不乏非常優(yōu)秀的框架。如百度的ECharts，國外的Chart.js、Highcharts、D3.js等等，特別是D3.js，幾乎是大數(shù)據(jù)前端方向的神器，非常值得學(xué)習(xí)。
話說回來，作為工程師，心存憂患意識，一定不能以學(xué)會這幾款工具就滿足，在實(shí)際的業(yè)務(wù)場景中，更多的需要你擴(kuò)展框架，生產(chǎn)自己的組件，這需要你具備一定的數(shù)學(xué)、圖形和OpenGL底層知識，可以說是非常大的技術(shù)壁壘和入門門檻。
6.2 WebVR
今年可以說是VR技術(shù)爆發(fā)式的一年，市場上推出了多款VR游戲設(shè)備，而淘寶更是開發(fā)出了平民的buy+購物體驗(yàn)，等普及開來，幾乎可以顛覆傳統(tǒng)的網(wǎng)上購物方式。
VR的開發(fā)離不開對3D環(huán)境的構(gòu)建，WebVR標(biāo)準(zhǔn)還在草案階段，A-Frame可以用來體驗(yàn)，另一個three.js框架是一個比較成熟的構(gòu)建3D場景的工具，除了能在未來的VR應(yīng)用中大顯身手，同樣也在構(gòu)建極大豐富的3D交互移動端頁面中顯得必不可少，淘寶就是國內(nèi)這方面的先驅(qū)。
6.3 WebAssembly
asm.js已發(fā)展成WebAssembly，由谷歌、微軟、蘋果和Mozilla四家共同推動，似乎是非常喜人樂見的事情，畢竟主要瀏覽器內(nèi)核廠商都在這里了。不過合作的一大問題就是低效，今年終于有了可以演示的demo，允許編寫C++代碼來運(yùn)行在瀏覽器上了，你需要下載一大堆依賴庫，以及一次非常耗時的編譯，不過好歹是個進(jìn)步。
短時間內(nèi)，我們都不太可能改變使用JavaScript編寫前端代碼的現(xiàn)狀，Dart失敗了，只能期望于未來的WebAssembly。有了它，前端在運(yùn)行時效率、安全性都會上一個臺階，其他隨之而來的問題，就只能等到那一天再說了。
6.4 WebComponents
WebComponents能帶給我們什么呢？HTML Template、Shadow DOM、Custom Element和HTML Import？是的，非常完美的組件化系統(tǒng)。Angular、React的組件化系統(tǒng)中，都是以Custom Element的方式組合HTML，但這都是假象，它們最終都會被編譯成JavaScript才會執(zhí)行。但WebComponents不一樣，Custom Element原生就可以被瀏覽器解析，DOM元素本身的方法都可以自定義，而且元素內(nèi)部的子元素、樣式，由于Shadow DOM的存在，不會污染全局空間，真正成為了一個沙箱，組件化就應(yīng)該是這個樣子，外部只關(guān)心接口，不關(guān)心也不能操縱內(nèi)部的實(shí)現(xiàn)。
當(dāng)前的組件化，無不依賴于某一特定的框架環(huán)境，或者是Angular，或者是React，想移植就需要翻盤推倒重來，也就是說他們是不兼容的。有了WebComponents，作為瀏覽器廠商共同遵循和支持的標(biāo)準(zhǔn)，這一現(xiàn)狀將極有可能被改寫。
未來的前端組件化分發(fā)將不會是npm那么簡單，可能只是引用一個HTML文件，更有可能的是包含CSS、HTML、JavaScript和其他二進(jìn)制資源的一個目錄。
目前只有最新的Chrome完全支持WebComponents的所有特性，所以距離真正應(yīng)用它還尚需時日。由于技術(shù)上的限制，WebComponents polyfill的能力都非常受限，Shadow DOM不可能實(shí)現(xiàn)，而其他三者則更多需要離線編譯實(shí)現(xiàn)，可以參考Vue.js 2的實(shí)現(xiàn)，非常類似于WebComponents。
6.5 關(guān)于微信小程序
微信小程序?qū)τ诮衲瓴坏貌徽f，卻也無話可說。依托于龐大的用戶量，微信官方出品了自有的一套開發(fā)技術(shù)棧，只能說給繁雜的前端開發(fā)又填了一個角色——微信前端工程師。
七、總結(jié)
最后還有幾點(diǎn)需要說明。
7.1 工程化
首先，現(xiàn)在業(yè)界都在大談前端工程化，人人學(xué)構(gòu)建，個個會打包。鄙人認(rèn)為，工程化的要點(diǎn)在于“平衡諸方案利弊，取各指標(biāo)的加權(quán)收益最大化”。僅僅加入了項(xiàng)目構(gòu)建是遠(yuǎn)遠(yuǎn)不夠的，在實(shí)踐中，我們經(jīng)常需要考慮的方向大可以分為兩種：一是研發(fā)效率，這直接應(yīng)該響應(yīng)業(yè)務(wù)需求的能力；二是運(yùn)行時性能，這直接影響用戶的使用體驗(yàn)，同時也是產(chǎn)品經(jīng)理所關(guān)心的。這兩點(diǎn)都直接影響了公司的收入和業(yè)績。
具體到細(xì)節(jié)的問題上來，比如說：
對于工程師來說，首先需要量化每個指標(biāo)的權(quán)重，然后對于備選方案，逐個計(jì)算加權(quán)值，取最大值者，這才是科學(xué)的技術(shù)選型方法論。
然而在業(yè)界，很少能看到針對工程化的更深入分享和討論，大多停留在“哪個框架好”，“使用XXX實(shí)現(xiàn)XXX”的階段，往往是某一特定方向的優(yōu)與劣，很少有科學(xué)的全局觀。甚至只看到了某一方案的優(yōu)勢，對其弊端和可持續(xù)性避而不談。造成這種現(xiàn)狀的原因是多方面的，一是技術(shù)上，工程師能力的原因并沒有考慮得到，二是政治上，工程師需要快速實(shí)現(xiàn)某一目標(biāo)，以取得可見的KPI收益，完成團(tuán)隊(duì)的績效目標(biāo)，但更多的可能是，國內(nèi)絕大多數(shù)產(chǎn)品的復(fù)雜性都還不夠高，根本無需考慮長久的可持續(xù)發(fā)展和大規(guī)模的團(tuán)隊(duì)合作對于技術(shù)方案的影響。
因此，你必須接受的現(xiàn)狀是，無論你是否使用CSS預(yù)處理器、使用Webpack還是grunt、使用React還是Angular，使用RN還是Hybrid，對于產(chǎn)品極有可能都不是那么地敏感和重要，往往更取決于決策者的個人喜好。
7.2 角色定位
確實(shí)，近兩年，Web前端工程師開始不夠老實(shí)，要么用Node.js插手服務(wù)端開發(fā)，要么用RN插手客戶端開發(fā)。如何看待這些行為呢？
鄙人以為，涉足服務(wù)端開發(fā)是沒問題的，因?yàn)橹簧婕暗戒秩緦用?#xff0c;還是屬于“前端”的范疇的。況且，在實(shí)際的工程實(shí)踐中，已經(jīng)可以證明，優(yōu)秀的前端研發(fā)體系確實(shí)離不開服務(wù)端的參與，想想Facebook的BigPipe。不過，這需要服務(wù)端良好的分層架構(gòu)，數(shù)據(jù)與渲染完全解耦分離，后端工程師只負(fù)責(zé)業(yè)務(wù)數(shù)據(jù)的CRUD，并提供接口，前端工程師從接口中獲取數(shù)據(jù)，并推送到瀏覽器上。數(shù)據(jù)解耦是比接口解耦更加優(yōu)越的方案。因此現(xiàn)在只要你的服務(wù)端架構(gòu)允許，Node.js作為Web服務(wù)已經(jīng)比較成熟，前端負(fù)責(zé)服務(wù)端渲染是完全沒有問題的。
前端涉足客戶端開發(fā)也是合理的，畢竟都運(yùn)行在用戶端，也屬于前端的范疇。拋開阿里系的Weex鄙人不甚了解，NativeScript、RN都還缺乏大規(guī)模持續(xù)使用的先例，這是與涉足服務(wù)端領(lǐng)域的不同，客戶端上的方案都還不夠成熟，工具的限制阻礙了前端向客戶端的轉(zhuǎn)型，仍然需要時間的考驗(yàn)。不過時間可能不會很多，未來的Web技術(shù)依托高性能硬件以及普及的WebGL、WebRTC、Payment API等能力，在性能和功能上都會挑戰(zhàn)Native的地位。最差的情況，還可以基于Hybrid，利用Native適當(dāng)擴(kuò)展能力，這就是合作而非競爭關(guān)系了。
總之前端工程師的本仍然在瀏覽器上，就這一點(diǎn)，范圍就足夠廣使得沒人有敢言自己真正“精通”前端。如果條件允許的話，特別是技術(shù)成熟之后，涉獵其他領(lǐng)域也是鼓勵的。
7.3 寫在最后
在各種研發(fā)角色中，前端注定是一個比較心累的一個。每一年的年末，我們都能看到幾乎完全不一樣的世界，這背后是無數(shù)前端人燒腦思考、激情迸發(fā)的結(jié)果。無論最終產(chǎn)品的流行與否，都推動著前端技術(shù)領(lǐng)域的高速更新?lián)Q代。正是印證了那一句“唯有變化為不變”。作為業(yè)務(wù)線的研發(fā)工程師，我們的職責(zé)是甄選最佳組合方案，取得公司利益最大化。這個“最佳”的涉獵面非常廣，取決于設(shè)計(jì)者的技術(shù)視野廣度，也有關(guān)于決策者的管理經(jīng)驗(yàn)，從來都不是一件簡單的事。
未來的Web前端開發(fā)體驗(yàn)一定是更豐富的，依托WebComponents的標(biāo)準(zhǔn)化組件體系，基于WebAssembly的高性能運(yùn)行時代碼，以及背靠HTTP/2協(xié)議的高速資源加載，前端工程師不必在性能上、兼容性上分散太多精力，從而可以專注于開發(fā)具備豐富式交互體驗(yàn)的下一代Web APP，可能是VR，也可能是游戲。
在迎接2017的同時，我們?nèi)匀灰龊眯睦頊?zhǔn)備，新的概念、新的框架和工具以及新的語法依舊會源源不斷的生產(chǎn)出來，不完美的現(xiàn)狀也依舊會持續(xù)。
?
轉(zhuǎn)載于:https://www.cnblogs.com/fortunel/articles/6512716.html
總結(jié)
以上是生活随笔為你收集整理的转载：2016前端开发技术巡礼的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 如何使用Total Recorder录制
- 下一篇： MongoDB主从+php实现