前端之路總結。[轉]

筆者從jQuery時代一路走來，經歷了以BootStrap爲表明的基於jQuery的插件式框架與CSS框架的興起，到後面以Angular 1爲表明的MVVM框架，以及到如今以React爲表明的組件式框架的興起。從最初的認爲前端就是切頁面，加上一些交互特效，到後面造成一個完整的webapp，整體的變革上，筆者覺得有如下幾點：

• 移動優先與響應式開發

• 前端組件化與工程化的變革

• 從直接操做Dom節點轉向以狀態/數據流爲中心

筆者在本文中的敘事方式是按照本身的認知過程，夾雜了大量我的主觀的感覺，看看就好，不必定要當真，畢竟我菜。梳理來講，有如下幾條線：

• 交互角度的從PC端爲中心到Mobile First

• 架構角度的從以DOM爲中心到MVVM/MVP到以數據/狀態爲驅動。

• 工程角度的從隨意化到模塊化到組件化。

• 工具角度的從人工到Grunt/Gulp到Webpack/Browserify。

React 並無提供不少複雜的概念與繁瑣的API，而是以最少化爲目標，專一於提供清晰簡潔而抽象的視圖層解決方案，同時對於複雜的應用場景提供了靈活的擴展方案，典型的譬如根據不一樣的應用需求引入MobX/Redux這樣的狀態管理工具。React在保證較好的擴展性、對於進階研究學習所須要的基礎知識完備度以及整個應用分層可測試性方面更勝一籌。不過不少人對React的意見在於其陡峭的學習曲線與較高的上手門檻，特別是JSX以及大量的ES6語法的引入使得不少的傳統的習慣了jQuery語法的前端開發者感受學習成本可能會大於開發成本。

Vue則是典型的所謂漸進式庫，便可以按需漸進地引入各類依賴，學習相關地語法知識。比較直觀的感覺是咱們能夠在項目初期直接從CDN中下載Vue庫，使用熟悉的腳本方式插入到HTML中，而後直接在script標籤中使用Vue來渲染數據。隨着時間的推移與項目複雜度的增長，咱們能夠逐步引入路由、狀態管理、HTTP請求抽象以及能夠在最後引入總體打包工具。這種漸進式的特色容許咱們能夠根據項目的複雜度而自由搭配不一樣的解決方案，譬如在典型的活動頁中，使用Vue可以兼具開發速度與高性能的優點。不過這種自由也是有利有弊，所謂磨刀不誤砍材工，React相對較嚴格的規範對團隊內部的代碼樣式風格的統1、代碼質量保障等會有很好的加成。

一言蔽之，筆者我的以爲Vue會更容易被純粹的前端開發者的接受，畢竟從直接以HTML佈局與jQuery進行數據操做切換到指令式的支持雙向數據綁定的Vue代價會更小一點，特別是對現有代碼庫的改造需求更少，重構代價更低。而React及其相對嚴格的規範可能會更容易被後端轉來的開發者接受，可能在初學的時候會被一大堆概念弄混，可是熟練以後這種嚴謹的組件類與成員變量/方法的操做會更順手一點。便如Dan Abramov所述，Facebook推出React的初衷是爲了可以在他們數以百計的跨平臺子產品持續的迭代中保證組件的一致性與可複用性。

先後端分離與全棧:技術與人

咱們常說的先後端分離會包含如下兩個層面：

• 將本來由服務端負責的數據渲染工做交由前端進行，而且規定前端與服務端之間只能經過標準化協議進行通訊。

• 組織架構上的分離，由早期的服務端開發人員順手去寫個界面轉變爲完整的前端團隊構建工程化的前端架構。

先後端分離本質上是前端與後端適用不一樣的技術選型與項目架構，不過兩者不少思想上也是能夠融會貫通，譬如不管是響應式編程仍是函數式編程等等思想在先後端皆有體現。而全棧則不管從技術仍是組織架構的劃分上彷佛又回到了按照需求分割的狀態。不過呢，咱們必需要面對現實，很大程度的工程師並無能力作到全棧，這一點不在於具體的代碼技術，而是對於先後端各自的理解，對於系統業務邏輯的理解。若是咱們分配給一個完整的業務塊，同時，那麼最終獲得的是無數個碎片化相互獨立的系統。

何謂工程化

所謂工程化，便是面向某個產品需求的技術架構與項目組織，工程化的根本目標便是以儘量快的速度實現可信賴的產品。儘量短的時間包括開發速度、部署速度與重構速度，而可信賴又在於產品的可測試性、可變性以及Bug的重現與定位。

• 開發速度：開發速度是最爲直觀、明顯的工程化衡量指標，也是其餘部門與程序員、程序員之間的核心矛盾。絕大部分優秀的工程化方案首要解決的就是開發速度，不過筆者一直也會強調一句話，磨刀不誤砍材工，咱們在追尋局部速度最快的同時不能忽略總體最優，初期單純的追求速度而帶來的技術負債會爲之後階段形成不可彌補的損害。

• 部署速度：筆者在平常工做中，最長對測試或者產品經理說的一句話就是，我本地改好了，尚未推送到線上測試環境呢。在DevOps概念深刻人心，各類CI工具流行的今天，自動化編譯與部署幫咱們省去了不少的麻煩。可是部署速度仍然是不可忽視的重要衡量指標，特別是以NPM爲表明的難以捉摸的包管理工具與不知道何時會抽個風的服務器都會對咱們的編譯部署過程形成很大的威脅，每每項目依賴數目的增多、結構劃分的混亂也會加大部署速度的不可控性。

• 重構速度：聽產品經理說咱們的需求又要變了，聽技術Leader說最近又出了新的技術棧，甩如今的十萬八千里。

• 可測試性：如今不少團隊都會提倡測試驅動開發，這對於提高代碼質量有很是重要的意義。而工程方案的選項也會對代碼的可測試性形成很大的影響，可能沒有沒法測試的代碼，可是咱們要儘可能減小代碼的測試代價，鼓勵程序員可以更加積極地主動地寫測試代碼。

• 可變性：程序員說：這個需求無法改啊！

• Bug的重現與定位：沒有不出Bug的程序，特別是在初期需求不明確的狀況下，Bug的出現是必然而沒法避免的，優秀的工程化方案應該考慮如何能更快速地輔助程序員定位Bug。

當咱們探究工程化的具體實現方案時，在技術架構上，咱們會關注於：

• 功能的模塊化與界面的組件化

• 統一的開發規範與代碼樣式風格，可以在遵循SRP單一職責原則的前提下以最少的代碼實現所須要的功能，即保證合理的關注點分離。

• 代碼的可測試性

• 方便共享的代碼庫與依賴管理工具

• 持續集成與部署

• 項目的線上質量保障

前端的工程化需求

當咱們落地到前端時，筆者在歷年的實踐中感覺到如下幾個突出的問題：

• 先後端業務邏輯銜接：在先後端分離的狀況下，先後端是各成體系與團隊，那麼先後端的溝通也就成了項目開發中的主要矛盾之一。前端在開發的時候每每是根據界面來劃分模塊，命名變量，然後端是習慣根據抽象的業務邏輯來劃分模塊，根據數據庫定義來命名變量。最簡單而是最多見的問題譬如兩者可能對於贊成義的變量命名不一樣，而且考慮到業務需求的常常變動，後臺接口也會發生頻繁變更。此時就須要前端可以創建專門的接口層對上屏蔽這種變化，保證界面層的穩定性。

• 多業務系統的組件複用：當咱們面臨新的開發需求，或者具備多個業務系統時，咱們但願可以儘可能複用已有代碼，不只是爲了提升開發效率，仍是爲了可以保證公司內部應用風格的一致性。

• 多平臺適配與代碼複用：在移動化浪潮面前，咱們的應用不只須要考慮到PC端的支持，還須要考慮微信小程序、微信內H五、WAP、ReactNative、Weex、Cordova等等平臺內的支持。這裏咱們但願可以儘可能的複用代碼來保證開發速度與重構速度，這裏須要強調的是，筆者以爲移動端和PC端自己是不一樣的設計風格，筆者不贊同過多的考慮所謂的響應式開發來複用界面組件，更多的應該是着眼於邏輯代碼的複用，雖然這樣不可避免的會影響效率。魚與熊掌，不可兼得，這一點須要因地制宜，也是不能一律而論。

關於跨界、全棧、公司定崗

常規公司裏，會配備好前端開發、iOS、Android、服務端開發這四種技術團隊，實際作項目時，幾支團隊是分工合做，只在必要的地方經過接口配合。在PC時代，不考慮C/S結構軟件，只存在前端和服務端。前端和服務端配合時，主要是經過前端提供模板，後端負責數據持久化和邏輯處理來合做的，雙方惟一可能起爭執的地方就是模板引擎由誰來套，這個模板引擎指的是服務端模板引擎，大部分公司裏，這個模板是由服務端來套的。雖然也有AJAX請求，服務端吐JSON數據的地方，但整體來講並非那麼多這種接口，渲染也只是局部渲染，通常到不了使用JavaScript模板引擎的地步。應該說，這個時期先後分離的需求並不高，而SEO的需求又很重，因此先後端兩支團隊也算涇渭分明井水不犯河水。

 

關於前端的核心競爭力

若是說服務端同窗進擊全棧是試試水，Native進擊全棧是試試水，那前端裏不少同窗進擊全棧就是在拿生命在玩全棧了。

服務端玩玩Node，不喜歡就算了，玩玩Angular和Bootstrap也就在後臺開開葷，前臺各位視覺設計，UAT還原檢查，各類動效，用Angular和Bootstrap能把本身玩死，然後臺基本上一直是服務端的自留地，不少作前端開發的同窗甚至沒開發事後臺界面吧？Django甚至都自動給你生成了。後端的核心競爭力在哪兒？在添刪改查，在數據庫設計，在性能優化，在shell腳本，在分佈式，在網絡安全。玩玩票不影響本身的大本營。

一樣能夠一門語言先後臺通吃的Android開發，你看看他們對全棧是否是像前端圈那樣熱情。從DNA來看，對Java語言可比JavaScript和Node更親吧？再往遠了說，看看C++客戶端的同窗對服務端有沒有那麼大熱情？

仍是那句話，好學是好的，前提是本身的大本營要守住，一專多長。你得先專注門，再想着橫向擴展其餘領域知識。前端開發的核心競爭力是什麼？2016年年中，我在微博上說，前端的核心競爭力在於一些HTML標籤、CSS，JavaScript的熟練度上。這些東西是前端本身領域的知識，好比Form2.0、Websocket、離線緩存、Webworker、Border-image、Canvas。一些同窗回覆說「核心競爭力竟然只是些API，這有什麼難度？」此言差矣。或許這樣認爲的，以跨界而來的「全棧」工程師居多。有些知識確實只是API，好比JSON.stringify和window.getComputedStyle之類，看了就會用，用起來也沒有什麼實踐方面的坑。但並不全是，好比Form2.0但是有一系列新東西，新標籤如output，新類型如number，新屬性如pattern，新的CSS僞類如:valid，須要融合在一塊兒考慮，造成一個Form2.0的解決方案。再好比Canvas2d，Canvas提供了像素級API，能夠直接存取顏色，能夠把像素導出成base64的字符串，提供了DOM沒有能力，但同時也徹底沒有了DOM的便利，好比Canvas上畫的某個按鈕該如何進行事件監聽呢？好比不能使用CSS了，該如何實現:hover僞類，又如何讓佈局實現自適應性呢？什麼樣的狀況下該使用Canvas，什麼狀況下該使用DOM，若是有某個功能必須依賴Canvas實現，好比在網頁上作個美圖秀秀，將產品的哪些元素放到Canvas上，哪些元素放到DOM上，二者又如何合做呢？換成純Canvas解決方案會不會更適合呢？前端的知識不一樣於服務端，大部分的工做量都在圖形界面上，而圖形界面是件很細的活，工做量和技術含量全在細節。我常常對非前端的同窗舉一個例子——你知道垂直居中有幾種方法，不一樣方法的優缺點嗎？有些跨界而來的同窗，以及部分前端圈的新同窗都不覺得然，嘲笑說這叫「回字的四種寫法」。其實，前端在實戰時，垂直居中有多種方法，基本上沒有方法是無反作用的，要看狀況，不一樣的狀況要選用不一樣的方式才能實現最好的自適應性。感興趣的同窗能夠去搜搜看前端的垂直居中方法整理。看完以後，就能明白前端CSS的精彩和玄妙。

我批評不少同窗基礎不紮實就開始亂折騰，不是說多學習很差，而是說大本營都未扎牢，如何實打實地高效完成平常工做？ES六、CoffeeScript、React、Webpack等，都解決不了你在實戰時遇到的具體挑戰。這全是些外圍功夫，並不是核心。先把核心學好，外圍功夫何時學均可以，又不難，你說對吧？

那麼什麼是核心呢？HTML、CSS和JavaScript。我指的是原生的這些東西，不用上來就跟我說React的JavaScriptx語法重定義了HTML，Sass改良了CSS，TypeScript給JavaScript帶來了靜態語言的語法，這些都是外圍，今天是React，明天能夠換成Angular，今天是Sass明天能夠換成Less，今天是TypeScript明天能夠是CoffeeScript，這些不重要。就像jQuery鼎盛時期，不少同窗不學原生JavaScript，上來直接就上手jQuery同樣，走不遠。要理解jQuery爲何這麼封裝，其實在底層發生了什麼，用原生會遇到什麼問題，直接用原生能解決嗎？把原生的技巧學熟了，這些外圍的東西上手很快，並且什麼狀況下用什麼，內心會很是有底。

過去，前端領域並不像現在這樣浮躁，不少人都知道基礎的重要性，也知道基礎是什麼。但當跨界的「全棧」進入前端圈之後，不少淺顯的道理都被有意無心地攪昏了。速成、革命、淘汰、全棧成了主旋律和政治正確。但是，就像投資界裏愛說的一句話同樣：「風起來了，在風口上豬都會飛。但是等風停了，還在飛的是老鷹，而豬會 
摔死。」風會停嗎？固然。該潛心修煉還得修煉，基本功不紮實之前，別糊里糊塗跟風浪費本身時間，缺什麼要惡補。

今天說得很熱鬧的HTML5實際上是從HTML4增強而來，二者不是替換關係，而是「強化」，就像ES6之於ES3同樣。不少新入行的同窗但願能夠速成，而後從哪兒熱門往哪兒入手，這其實不對，最好的學習方法是從HTML4學起，儘管在實踐時有不少HTML4時代的技巧，在HTML5時代有了更好的替換方案，但也有不少HTML4時代能夠一直 
用過來的技巧。讓我擔憂的是，HTML4時代的好書，到了HTML5時代已經再也不出版了，而HTML5相關的書籍基本上只講了HTML5相較於HTML4的增量部分。而HTML4時代的書和相關技巧就這麼失傳了。除了書，博客和所謂社區也是同樣，如今已經再也不討論之前的一些精華技巧了，有些技巧確實是淘汰掉了沒有什麼價值，好比IE6的hack技術，但也有些技術是很棒的CSS技巧，好比CSS滑動門依然適用。我推薦一下幾本書和學習步驟，給有心彌補基本功的同窗：

• 《CSS網站佈局實錄》——國產CSS2入門書，有些技巧已經淘汰，但仍不失爲最好的CSS入門教程。
• 《無懈可擊的Web設計》——講CSS應用技巧的書，國內外粉絲別多，說是開創了CSS技巧流派也不爲過。
• 《DOM JavaScript編程藝術——JavaScript最好的入門書，沒有之一，這本書是幫助你瞭解如何將DOM、CSS和JavaScript鏈接起來的一本書。嚴格來講，後端Node根本不算JavaScript，JavaScript是基於ES語法的一門脫水語言，如何實現的膠水？這本書將帶你入門。
• 《JavaScript高級程序設計》 ——JavaScript必讀的一本精典，讀完以後對JavaScript的理解和實 
  踐會上升很是大的一個臺階。
• 《編寫高質量代碼——Web前端開發修煉之道》 —— 舉賢不避親，這本書是我寫的。推薦的緣由是，這本書重點講團隊合做的注意事項。雖然一些具體的技巧，在今天已然過期，好比IE6的hack，但在團隊合做方面的思考，直到今天我也沒看到其餘書在講，這些思想沒有其餘書可替代。
• 《HTML5和CSS3權威指南》——目前爲止，我讀過的HTML5方面最好的一本原創書。配合實例進行API講解，很是詳細具體。連HTML5都提供了哪些底層的東西都不知道，又該如何去用好它呢？在我看來，是學習HTML5的必讀書。
• 《響應式Web設計：HTML5和CSS3實戰》——做者是《無懈可擊的Web設計》忠實粉絲，因此很天然地，這也是本CSS技巧流派的書，側重點在CSS3的實踐技巧上，讓人大開眼界。
• 《JavaScript設計模式》——JavaScript在實戰時的高級技巧。

前端很棒的書有不少，這只是幾本我以爲最不應錯過的書而已。從HTML4一路到HTML5和移動時代，一路上有了不少新技巧，也淘汰了一些舊技巧。當下的學習氛圍雖然史無前例的強烈，但急功近利和盲目無頭緒現象也很嚴重。在我看來，不少人不肯意作苦活累活紮紮實實打基本功，一句「那些都淘汰了」就拒絕了全部的優秀遺產，但願花少許時間看看流行時髦的新工具新框架，而後就迅速擠身行業頂端，這想法既偷懶又幼稚。什麼是外圍功夫，什麼是真核心技巧，什麼是珍珠什麼是盒子要分得清，自欺欺人並非什麼明智的想法。你能夠幾天幾個星期就掌握的東西，別人也能夠，就算人家比你笨，多花一倍的時間也能跟上你吧？要真的拉開和其餘人的距離，只有下苦功這一途。

這些話，恐怕沒有幾位前端老人願意說。當我問他們，拼命強調新風向，而再也不提基本功，形成知識斷層，形成這些同窗心高氣傲但完成不了工做怎麼辦時，一些老人的回答是「他們本身不重視基本功，怪我嘍」。若是你基本功很紮實了，想學什麼外圍功夫均可以，雖然多學總不是壞事，只是在決定投入使用時，還須要看團隊狀況再慎重決定，團隊合做要考慮的事情有不少，要有責任感，別隻顧着本身當Geek。

1：咱們可能在任何狀況下都須要聲明式的渲染功能，並但願儘量避免手動操做，或者說是可變的命令式操做，但願儘量地讓DOM的更新操做是自動的，狀態變化的時候它就應該自動更新到正確的狀態；

2：咱們須要組件系統，將一個大型的界面切分紅一個一個更小的可控單元；

3：客戶端路由——這是針對單頁應用而言，不作就不須要，若是須要作單頁應用，那麼就須要有一個URL對應到一個應用的狀態，就須要有路由解決方案；

4：大規模的狀態管理——當應用簡單的時候，可能一個很基礎的狀態和界面映射能夠解決問題，可是當應用變得很大，涉及多人協做的時候，就會涉及多個組件之間的共享、多個組件須要去改動同一份狀態，以及如何使得這樣大規模應用依然可以高效運行，這就涉及大規模狀態管理的問題，固然也涉及到可維護性，

5：還有構建工具。如今，若是放眼前端的將來，當HTTP2普及後，可能會帶來構建工具的一次革命。但就目前而言，尤爲是在中國的網絡環境下，打包和工程構建依然是很是重要且不可避免的一個環節。