業(yè)務(wù)專線：13711534025
近二年的進展
前端發(fā)展日新月異, 甚至有一句戲言: "每六星期重寫一個前端框架", 行業(yè)是像火箭一樣, 但我們前端工程師該何去何從呢?
我們來談?wù)勥@個問題.
先來看看最流行的幾項技術(shù)棧:
AngularJS
首創(chuàng)的雙向數(shù)據(jù)綁定, 以及內(nèi)置的模塊注入, 以及組件化的支持, 種種優(yōu)勢, 使得它迅速發(fā)展起來. 在 2014-2015 年, 有調(diào)查顯示, 在使用了前端框架的項目, 有 50% 以上采用了 AngularJS. 但到底值不值我們繼續(xù)學(xué)習(xí), 我們再接下來看.
項目地址: https://angularjs.org/
EmberJS
受 Rails 全?？蚣艿膯l(fā), EmberJS 逐步發(fā)展成前端領(lǐng)域的另一個 "Rails", 成為另一個獨特的選擇, 理論上, 你選擇了 EmberJS, 就選擇了一個完整穩(wěn)定的生態(tài), 不用再折騰的輪子. EmberJS 不僅全面支持模塊化, MVC, 也實現(xiàn)了類似 AngularJS 的雙向綁定( 當(dāng)然原理不同 ), 甚至還做到了內(nèi)置的打包和發(fā)布應(yīng)用功能. 總而言之, 它是一個十分全面的前端框架. 事實上, 如果說 AngularJS 是當(dāng)前短暫的前端史的一個高峰, 它就是另一個高峰. 但最近, 人氣有一定的下降, 原因何在, 我們再分解.
項目地址: http://emberjs.com/
ReactJS
ReactJS 自發(fā)布之始, 就人氣很高, 它是第一個采用虛擬節(jié)點( virtual dom )技術(shù)的框架, 通過這個技術(shù)點, 它獨創(chuàng)性地整合了函數(shù)性編程的理念, 采用單向數(shù)據(jù)流來設(shè)計 dom 渲染與比對, 使得它輕量和靈活, 事實上, 它本身只專注于如何渲染 UI, 也不與AngularJS 和 EmberJS 有沖突. 換言之, 你可以將它整合到其他框架中.
隨著 ReactNative 和 Redux 方案的出現(xiàn), ReactJS 重新回到前端的浪尖, 因為其簡潔優(yōu)雅的實現(xiàn)和對 Native APP 的沖擊, 又一次成為新的弄潮兒.
但以后會怎么樣, 誰也不知道, 但我也會再給一些解讀.
項目地址: https://facebook.github.io/react/
流行不一定是發(fā)展最快, 我們再來看看近二年發(fā)展最快的幾項前端技術(shù)棧:
ReactJS
上文已經(jīng)提到, React 由于本身的簡潔性和對組件化專注的實現(xiàn), 一直沒有被新的 ES6 標(biāo)準(zhǔn)和前端思潮落下, 它幾乎不受 ES6 的影響, 以及前沿性的支持 native app 開發(fā)( 通過 ReactNative ), 所以一直發(fā)展趨勢良好.
而 AngularJS 則不一樣, 由于 ES6 的發(fā)布, 使得它的依賴注入特性成為雞肋, 以及 AngularJS第一版對組件化支持的蹩腳實現(xiàn)( 能支持是一回事, 好用是另一回事 ), 而組件化則學(xué)習(xí)成本過高, 過于復(fù)雜, 所以 AngularJS 決定推翻設(shè)計重新開發(fā)第二版, 而第二版過于激進的采用 Typescript, 完全不兼容的第一版的設(shè)計, 以及各種魔法的應(yīng)用, 使得它離前端越走越遠(yuǎn).
VueJS
VueJS 是近二年的新秀, 它起步之初, 只是一個簡化版的類似于 AngularJS 雙向綁定的實現(xiàn)的研究( 當(dāng)然原理并不同 ). 但其理念與 ReactJS 相近, 只是專注于實現(xiàn)數(shù)據(jù)綁定, 模塊化與組件化, 所以足夠的簡單靈活.
隨著生態(tài)的快速發(fā)展, VueJS 正好接了 AngularJS 第一版的班, 又改良了 AngularJS 的錯誤設(shè)計( 事后來看, 依賴注入與組件化兩部分是比較失敗的設(shè)計 ), 整體發(fā)展迅速, 逐步成為后起之秀.
項目地址: http://vuejs.org/
MeteorJS
MeteorJS 本不適合與上述幾個前端框架比較, 因為它實際是一個全?？蚣? 更像 Rails 這種角色, 但由于它是純 Javascript 的方案, 所以還是放在這里.
如果說上述前端框架都是解決前端工程化的產(chǎn)物, 那 MeteorJS 是一個顛覆思維的 web 開發(fā)框架, 它將Javascript 同構(gòu)技術(shù)應(yīng)用到極端, 再整合 websocket 進行實時數(shù)據(jù)通知與熱代碼更新, 不同于前后端分離的理念, 它在開發(fā)者角度完全沒有前后端的概念, API 既在前端又在后端, 再加它全生態(tài)的支持( 移動 app 支持, 應(yīng)用發(fā)布), 也是一個全新的視角, 由于它發(fā)展速度極快, 所以列在這里.
項目地址: https://www.meteor.com/
各大框架都在迅速發(fā)展中, 它們有幾個共性的發(fā)展方向:
ES6 支持
每一次 Javascript 的新標(biāo)準(zhǔn)發(fā)布, 都是各大框架更新的好機會, 所以 ES6 是肯定得到各大框架的良好支持, 建議大家一定要學(xué)好.
web 組件化
毋庸置疑, 組件化是現(xiàn)代前端工程化中極為重要的特性, 甚至 google 還專門出了 Polymer 這個只做組件化實現(xiàn)的框架. 所以每一個夠格的前端框架都非常重度支持它. 同時, 組件化也將作為 w3c 標(biāo)準(zhǔn)予于定義, 所以前端框架仍將不留余力地改進與標(biāo)準(zhǔn)的兼容.
Server-side Render
服務(wù)端渲染技術(shù)是 2016 年才開始火的概念, 它與傳統(tǒng)的后端渲染不同, 為了解決前端框架第一次加載慢的問題, 以及 SEO 問題, 而提出的解決方案. 之前有 prerender, 現(xiàn)在各大框架都在嘗試在內(nèi)部集成并支持它. 但我個人覺得, 帶來的問題遠(yuǎn)比解決的問題更多, 比如要求我們開發(fā)的時候有更多的限制.
App Render
現(xiàn)在有一種大前端的概念, 可以理解為 web 前端對 App 開發(fā)的支持, 包括 Ionic ( 基于 AngularJS ), React Native( 基于 React 理念 ), Meteor 都是針對 App 開發(fā)的痛點而生.
分析了眾多目前最流行的前端框架, 大家可能越來越胡涂了:
到底誰才是最值得我們?nèi)ネ度氲募夹g(shù)呢?
接下來, 我們?nèi)サ粢欢研g(shù)語, 來從前端的定義本質(zhì)來看它的發(fā)展.
前端就是面向用戶這一端的技術(shù), 然而, 隨著時代的發(fā)展:
用戶體驗要求越來越高( 加載速度快, 響應(yīng)快, 無閃爍 )
前端需求越來越多
前端代碼越來越龐大
移動端快速發(fā)展對 h5 前端的需求
而 jQuery, ProtoypeJS 等只解決了 Javascript 工具庫的問題, 但工程化需求無好的解決方案.
前端工程化迫在眉捷. 而且有以下要求:
最好是純 Javascript 方案
支持模塊化
業(yè)務(wù)代碼與框架代碼分離
可測性
于是, 產(chǎn)生了幾種不同的演進方案.
后端渲染技術(shù):
ajax -> pjax -> sjr ( 需要服務(wù)端提供支持 )
后端渲染技術(shù)很快就發(fā)展到頂了. 但技術(shù)理解還是足夠簡單的. 我們還是回到前端框架上.
NodeJS, AMD(CMD), ES6 的出現(xiàn), 使得組織起一個前端框架成為現(xiàn)實. 于是乎, 百團大戰(zhàn), 出現(xiàn)了上面眾多框架混戰(zhàn)的畫面.
無論是 AngularJS, EmberJS, ReactJS, VueJS 都是圍繞著這幾點進行的不同的嘗試.
但結(jié)果如何, 我們站在一個更高的高度重新思考 web 開發(fā).
對用戶
更快的響應(yīng)速度
更好的體驗
對開發(fā)者
更快的開發(fā)速度
更好的可維護性
再次思考, 我們要不要前后端分離? 哪些前端框架更滿足我們以上的條件?
作為 Rails 工程師, 我也一直在思考一個問題: Rails 是否在前端上走上了絕路?
對于不熟悉 Rails 的朋友, 我還是簡單回顧下 Rails 的前端是什么:
jQuery
UJS
Assets pipeline
SJR( 服務(wù)端 JS 生成技術(shù) )
Turoblinks( 一種極小成本實現(xiàn)的單頁效果的技術(shù) )
相比 php, java, python 等語言下的傳統(tǒng) web 框架來說, Rails 的前端技術(shù)還是非常豐富的.
關(guān)于各個框架我列了一個分?jǐn)?shù)比較, 10 分為滿分, 每個列會加在一起算成一個總分.
從上表可以看出:
Rails 這類的全?？蚣芴攸c有
優(yōu)勢:
開發(fā)效率極高
通過 Turoblinks 技術(shù), 體驗也不錯.
也能支持混合應(yīng)用開發(fā)
缺點:
前端代碼可維護差
ReactJS 學(xué)習(xí)成本較低, 通過 webpack 與 npm 的配合, 能夠達(dá)到不錯的可維護性, 但開發(fā)成本偏高, 這也是組件化的缺點之一.
而 EmberJS 學(xué)習(xí)門檻過高, 而且 EmberJS 發(fā)展也比較迅速, 不利于學(xué)習(xí)掌握, 相對而言, 總分也不會太高.
MeteorJS 也被我列在這里, 總分最低, 所以仍然不推薦學(xué)習(xí), 除非你的應(yīng)用屬于實時應(yīng)用.
我們再重新思考組件化, 組件化優(yōu)勢在于接口清晰, 可維護性高, 但開發(fā)成本是比較高的, 前端屬于工程而不是科學(xué), 所以, 我覺得組件化是對的, 但不要過于極端把所有的 dom 都組件化.
而且, 組件化也對現(xiàn)有的基礎(chǔ)技術(shù)棧進行了破壞.
通過以上的分析, 我們基本上了解了現(xiàn)有技術(shù)棧的情況. 那我們該繼續(xù)學(xué)什么? 這才是本文的重點.
所有的一切, 都是圍繞著組件化, 可維護, 高效開發(fā), 移動支持而生, 而它們的核心都是還是最基礎(chǔ)的東西:
Javascript ( ES6, NodeJS )
HTML
CSS
API
一句話, 還是應(yīng)該先把基礎(chǔ)打好.
應(yīng)當(dāng)好好掌握的內(nèi)容:
Javascript 語言( 直接看 ES6 相關(guān)的 )
NodeJS 生態(tài)( npm 與相關(guān)的包 )
webpack ( 了解如何打包, 發(fā)布 )
HTML ( 尤其是 form 標(biāo)簽, 以及 HTML5 的內(nèi)容 )
CSS ( 學(xué)習(xí)盒模型, 最新的 flex 布局, 以及 CSS3 )
API ( 掌握如何開發(fā) API )
你必須是前端工程師, 同時又是后端工程師, 才能真正摸清晰當(dāng)下時代的發(fā)展, 成為弄潮兒!
首先, 我在 2014 年分析 web 開發(fā)的文中提到的 gulp, grunt 都已經(jīng)成為過去式了. Bower 也已經(jīng)有點不合事宜了.
目前前端構(gòu)建建議使用 webpack 和 npm 足夠, 不需要更多的工具鏈, 應(yīng)該越簡單, 越順手!
列幾個關(guān)心的問題嘗試預(yù)測一下
NodeJS 做后臺開發(fā)怎么樣 ?
NodeJS 已經(jīng)是前端框架的一部分, 是極為成功的, 但對于 NodeJS 做后臺開發(fā)說實在的, 它能夠占一定的市場, 但將會非常少( 低于 5% ). 所以做 php 或 java 開發(fā)的朋友倒不用擔(dān)心, 但如果只是搬磚寫簡單 API 的話, 就有危險了.
Rails 還行不行 ?
Rails 已經(jīng)到了一定的頂點, 不可能再突破性增長, 但仍然是目前最為順手的 web 開發(fā)框架, 它的前端解決方案目前仍有不錯的體驗與開發(fā)效率, 但可維護性比較差, 如果是我的話, 我會帶領(lǐng)團隊采用混合式的開發(fā), 但現(xiàn)在不會是引入 AngularJS 而會是 VueJS.
但 Rails 已經(jīng)到達(dá)它的極限點了, 而眾多前端框架才剛剛開始.( 雖然拿 Rails 與前端框架比較不夠合適 )
AngularJS 還是 ReactJS ?
很簡單, 建議直接上手 VueJS.
AnguarJS 第一版是個好的框架, 但 Angular2 并不是, 所以還不如直接學(xué)習(xí) VueJS.
ReactJS 是個不錯的框架, 但絕不是終點. VueJS 與 ReactJS 在實現(xiàn)上各有利弊. 兩者可以擇其一學(xué)之.
MeteorJS 值不值得學(xué)習(xí) ?
我的建議是不值得, 因為它一開始就走在錯誤的道路上, 注定后面無路可走.
前端會取代 Native APP 開發(fā)么?
一定會的, 未來 3 年后, 至少有 70% 左右的 APP 會用前端開發(fā)方案, 比如使用類似于 Ionic 或 Meteor 這樣的框架.
真正能長遠(yuǎn)的前端技術(shù)一定是簡單的, 專注的, 比如 jQuery. 但目前幾個框架都或多或少存在著問題.
ReactJS 不是表面那么簡單, 而 AngularJS 更加復(fù)雜.
是否有更簡單有效的解決它們的問題, 則能夠成為下一代 web 前端框架.
via：http://yafeilee.me/blogs/86
