最近有位（大家都知道是誰）的『前輩』在微博上天天叫喚，相信很多人都看煩了。我跟他也算是吵了一架，污染了大家的時(shí)間線，先說聲抱歉。但是我覺得讓這么一個撒潑的人誤人子弟，實(shí)在看不下去，所以咱上點(diǎn)干貨以正視聽。
對待新事物的態(tài)度問題
我這個人在技術(shù)討論的時(shí)候信奉很簡單的一個道理：沒有研究過就沒有發(fā)言權(quán)。對于我不懂的東西，我要么閉嘴，要么去研究、試用之后再開口。在我看來，這是進(jìn)行技術(shù)討論的一種基本涵養(yǎng)。技術(shù)這個行當(dāng)，永遠(yuǎn)會有新東西出來，不進(jìn)則退。更關(guān)鍵的是，前端比起整個軟件工程乃至計(jì)算機(jī)科學(xué)體系來說，是個相對新生草莽的領(lǐng)域，近年來前端生態(tài)的發(fā)展其實(shí)都是在向其他領(lǐng)域吸收和學(xué)習(xí)，不論是開發(fā)理念、工程實(shí)踐還是平臺本身（規(guī)范、瀏覽器）。所謂的『根正苗紅』的前端，不過是整個發(fā)展進(jìn)程中探索的一個階段而已，那個時(shí)代的最佳實(shí)踐，很多到今天都已經(jīng)不再適用。過往的經(jīng)驗(yàn)固然有價(jià)值，但這些經(jīng)驗(yàn)如果不結(jié)合對新事物本身的了解，就很難產(chǎn)生正確的判斷。這里需要強(qiáng)調(diào)的是，學(xué)習(xí)新事物并不是為了不考慮實(shí)際需求的濫用，而是為了獲取足夠的信息從而作出更靠譜的判斷。在這一點(diǎn)上，某人的態(tài)度是不停強(qiáng)調(diào)自己過去的八年資歷，強(qiáng)調(diào)『經(jīng)驗(yàn)和觀察』的重要性，卻對新事物本身采取蔑視和抗拒到了夸張的程度，寧可在微博上撕逼，也不愿意花一兩個小時(shí)翻墻了解一下外面的世界。舉例來說，他在批評 Angular/React 的時(shí)候是以『就是把服務(wù)器 MVC 那一套搬到了前端』這樣的預(yù)設(shè)去批判的，完全雞同鴨講；在闡述他自己那套 Widget + OO 的時(shí)候，也壓根不了解這套思維和現(xiàn)在基于組件的新框架的共通點(diǎn)。這樣偏頗的思維方式，如何做得出靠譜的決策？作為一個技術(shù)負(fù)責(zé)人簡直可以說是不負(fù)責(zé)任。盲目跟風(fēng)不可取，盲目抗拒也不可取，要有自己的判斷，但是這個判斷要建立在足夠的一手信息量基礎(chǔ)上。
為什么要用『新技術(shù)』？
說完態(tài)度，我們來深入談?wù)劄槭裁催@些『新技術(shù)』會有市場。首先明確一點(diǎn)：任何技術(shù)都有針對的適用場景取舍。在對一個技術(shù)進(jìn)行評估后發(fā)現(xiàn)不適合，這很正常，比如項(xiàng)目的類型、規(guī)模、歷史包袱，以及團(tuán)隊(duì)的學(xué)習(xí)能力，都是制約技術(shù)選型的因素。但這并不妨礙我們分析一項(xiàng)技術(shù)本身解決了什么問題，以及我們的實(shí)際需求中是否存在這些問題。接下來我們一項(xiàng)項(xiàng)分析：
1. CSS 預(yù)/后處理器
比如：Sass, Less, Stylus, PostCSS。CSS 本身的設(shè)計(jì)有很多不利于工程化、影響開發(fā)效率的地方，這正是 CSS 預(yù)/后處理器要解決的問題。
(1) 默認(rèn)的全局 namespace。在全局 namespace 下，任何一條規(guī)則都可能產(chǎn)生全局的影響，不利于模塊化的多人協(xié)作；同時(shí)選擇器的優(yōu)先級如果沒有嚴(yán)格的書寫規(guī)范，很快就會難以管理，然后產(chǎn)生各種 !important hack。這一點(diǎn)借助預(yù)處理器雖然不能完全解決，但借助 nesting 可以讓書寫體驗(yàn)得到改善。
(2) 作為一個 DSL 缺乏抽象能力：沒有變量，沒有函數(shù)，沒有運(yùn)算符，沒有混入和繼承，代碼的可復(fù)用性差，經(jīng)常需要大量重復(fù)，而通過組合類名的方式來復(fù)用靈活性非常有限。這些都可以借助預(yù)處理器進(jìn)行緩解，甚至可以抽象出常用技巧的混入，比如一個混入解決垂直居中，大大加強(qiáng) CSS 代碼的書寫效率和可維護(hù)性。
(3) 文件組織：通過原生的 @import 引入其他文件會產(chǎn)生過多的請求，而預(yù)處理器可以直接合并成一個文件，在文件組織上不再有顧慮。
(4) 智能避免重復(fù)勞動：自動根據(jù)目標(biāo)瀏覽器范圍添加前綴。
2. Java 編譯器
比如：Babel, Coffee, Type。為什么要編譯 Java，本質(zhì)上目標(biāo)依然是：提高開發(fā)效率，提高可維護(hù)性。以 Babel 為例，JS 本身的 prototype 原型繼承，之前幾乎每個人都有自己實(shí)現(xiàn)一套 OO 模擬，現(xiàn)在有原生的 class extends 語法，從語言層面進(jìn)行統(tǒng)一；函數(shù)的參數(shù)結(jié)構(gòu)和默認(rèn)值，避免了手動的默認(rèn)值分配和參數(shù)為 0 的坑；箭頭函數(shù)避免了 this 上下文的坑；塊級的 let/const 避免了 var hoisting 的坑；templateString 避免繁瑣的手動字符串拼接；更好的 Unicode 支持；ES2015 模塊（為什么，見這個演講 //benjamn.github.io/empirenode-2015/#/) ; 還有 async await 對于異步流程處理本質(zhì)上的改善。一個更好的語言，一個已經(jīng)正式發(fā)布的標(biāo)準(zhǔn)，瀏覽器支持情況不一，有人寫了工具讓你今天就能用，某人對此的態(tài)度居然是『沒有問題也要創(chuàng)造問題』…
Coffee 和 Type 很顯然有各自的主要受眾：Ruby 開發(fā)者和 Java/C# 開發(fā)者。這時(shí)候某人又要搬出『偽前端』的大帽子來了，問題是，誰能搞前端并不是你說了算，前端的風(fēng)氣也不會因?yàn)檫@兩個東西而受什么影響。這兩個東西的意義就在于它們能夠提高特定人群的開發(fā)效率，會去用它們的人很少是因?yàn)楦L(fēng)，而是因?yàn)樗鼈兇_實(shí)符合了一部分人的開發(fā)習(xí)慣。你不屬于那部分人，不代表這些東西沒有意義，它們被噴真是躺著也中槍。
3. 模塊化/構(gòu)建工具
比如：RequireJS, SeaJS，Webpack, Browserify, SystemJS。模塊化的重要性想必不必多言了，連某『前輩』都在用 RequireJS。前面那兩個現(xiàn)在已經(jīng)漸漸式微了，那為什么要有后面這三個？其中一個核心價(jià)值在于基于模塊規(guī)范的包管理方案。由于對于 Node 包格式的兼容，使得后面三個方案都可以利用 npm 作為包管理的機(jī)制。有了包管理器，你可以將跨項(xiàng)目的基礎(chǔ)庫進(jìn)行細(xì)粒度的單獨(dú)封裝，通過 semver 版本保證 API 兼容性，在多個項(xiàng)目中按需復(fù)用代碼邏輯，還可以直接使用發(fā)布在 npm 上的海量第三方庫。更進(jìn)一步，配合下面要提到的組件化框架，更可以實(shí)現(xiàn) UI 組件的跨項(xiàng)目復(fù)用。SeaJS/spm 和 Arale 其實(shí)有這個愿景，但是玉伯明智的發(fā)現(xiàn)了社區(qū)的方向而選擇了避免重復(fù)的努力。
另一方面，是在于后面這些新工具強(qiáng)大的擴(kuò)展機(jī)制（尤其是 Webpack）所帶來的一種新的前端打包思路：不僅僅是 Java，而是將 HTML、CSS 和其他靜態(tài)資源統(tǒng)統(tǒng)作為『模塊』來看待。因?yàn)樵趯?shí)際開發(fā)中，不僅僅是 Java 的模塊之間存在依賴關(guān)系，HTML、CSS 和其他靜態(tài)文件之間也會有依賴關(guān)系。實(shí)際開發(fā)中，開發(fā)環(huán)境和生產(chǎn)環(huán)境中這些靜態(tài)資源之間的相對路徑關(guān)系經(jīng)常是不一樣的，這就導(dǎo)致我們以往在開發(fā)環(huán)境到生產(chǎn)環(huán)境的上線過程中有很多繁瑣的步驟，比如改寫靜態(tài)資源引用的 URL（版本戳，靜態(tài)資源域名/CDN），圖片優(yōu)化，根據(jù)文件大小做成內(nèi)聯(lián)、模塊的切分和按需加載等等，這些瑣碎的事情固然可以手動解決，但我們要的是效率！效率！一次配置完畢，讓開發(fā)者能夠?qū)⒑罄m(xù)精力專注于應(yīng)用本身而不是其他東西。除了上面提到的幾個國外方案，國內(nèi)也有優(yōu)秀的類似方案 FIS。 最后，就是基于構(gòu)建工具我們能夠提供更好的開發(fā)體驗(yàn)。Webpack 的熱重載，在修改代碼后不重載頁面的情況下替換單一模塊，對開發(fā)體驗(yàn)帶來質(zhì)的提升。舉例來說，你在修改一個打開應(yīng)用后需要 N 次操作才能看到的組件，如果你改一次就要重復(fù)這些操作，那樣效率實(shí)在太低。
4. 組件化框架
比如：React, Angular 2, Vue。在我看來現(xiàn)代化的組件化框架提供三個核心價(jià)值：
(1) 數(shù)據(jù)到 DOM 的聲明式映射。無論是 virtual dom render 還是模板，其本質(zhì)都是聲明式地描述『基于這樣的數(shù)據(jù)，最終應(yīng)該呈現(xiàn)給用戶這樣的界面』。在大部分場景下，用戶通常不需要再進(jìn)行命令式的 DOM 操作。聲明式的代碼比命令式的代碼更簡潔，更容易維護(hù)。
(2) 組件的組織方式。一個組件的各個部分是分散在多個文件中，還是有合理的組織方式？組件如何發(fā)布、如何在多個項(xiàng)目中復(fù)用？對此，React 的選擇是把所有東西都放進(jìn) JS，而 Vue 則是基于構(gòu)建工具實(shí)現(xiàn)類似 Web Component 的單文件組件格式（也可以拆分，同時(shí)支持預(yù)處理器）。Angular 2 目前要么分開多個文件，要么直接將 HTML/CSS 作為字符串內(nèi)聯(lián)。
(3) 組件之間如何組合與溝通。這里的共同要點(diǎn)也是聲明式 > 命令式：通過在 render function / 模板中用標(biāo)簽形式在父組件中渲染子組件，讓數(shù)據(jù)驅(qū)動組件的存在，從而自然地得到樹狀的組件樹結(jié)構(gòu)，而不是命令式地用 this.add(child) 這樣的方法去管理組件樹。數(shù)據(jù)溝通方面，通常都采用了從上至下的單向數(shù)據(jù)傳遞，而子組件則可以通過事件冒泡或是傳遞一個回調(diào)的方式來對父組件做出反饋。注意這里的重點(diǎn)是，子組件并不能任意地改寫父組件的狀態(tài)，無論是觸發(fā)事件還是調(diào)用回調(diào)，最終父組件發(fā)生了什么還是由父組件自身來決定的，這就保證了子組件對父組件的解耦，從而使得子組件可移植/復(fù)用。在大型應(yīng)用里，還要考慮如何讓一個事件的后果能夠被清晰的理解，讓一個開發(fā)者可以迅速理解另一個人的代碼的意圖，讓應(yīng)用不會隨著規(guī)模的增長而失控？這則是 Flux Redux 這樣的狀態(tài)管理方案試圖解決的問題。其核心在于讓副作用可控，最終目的也是可維護(hù)性。
除了以上三點(diǎn)之外，還有額外的一點(diǎn)，那就是 CSS 和組件的關(guān)系。理想情況下，一個高內(nèi)聚的組件應(yīng)當(dāng)包含這個組件所需要的 js 邏輯、HTML 結(jié)構(gòu)和 CSS。但是由于之前提到過的 CSS 全局 namespace 的問題，使得跟隨組件的局部 CSS，尤其是可移植性，一直是一個難題。這一點(diǎn)上目前有幾個方案：React 為代表的 CSS in JS，CSS modules，Shadow DOM（依賴瀏覽器實(shí)現(xiàn)），以及 Vue/Angular 2 的編譯時(shí)局部 CSS/模板改寫。幾個方案各有千秋，但核心是都一定程度上解決了 CSS 全局 namespace 的問題，使得跟隨組件的 CSS 不再影響外部，獲得了可移植性，從而讓組件達(dá)成真正的高內(nèi)聚。而高內(nèi)聚的組件才可以獨(dú)立作為包分發(fā)，實(shí)現(xiàn)跨項(xiàng)目復(fù)用。
5. 測試/代碼規(guī)范工具
據(jù)某『前輩』自己說，他因?yàn)闀r(shí)間不夠，所以是放棄寫測試的。為什么時(shí)間不夠呢，因?yàn)楣ぞ呗浜?，開發(fā)效率太低唄。而且用古老的比如 Qunit / YUI test 寫的測試，必須手動打開一個一個瀏覽器測，也沒有代碼覆蓋率信息。現(xiàn)在呢，代碼規(guī)范有 ESLint，單元測試有 Karma，集成測試有 CasperJS/Nightwatch，代碼覆蓋率用 istanbul，配置完畢后一行命令自動多瀏覽器測試匯報(bào)結(jié)果和覆蓋率，如果搭好持續(xù)集成環(huán)境，甚至不用你自己手動跑，push 到倉庫就行了。這些東西也不需要團(tuán)隊(duì)人人都懂，架構(gòu)師搭好底子，新人只要用就行了，但是卻可以大幅提高整體的代碼質(zhì)量。
說了這么多，無非是為了說明，新技術(shù)的出現(xiàn)，永遠(yuǎn)是因?yàn)橛袑?yīng)的問題可以解決才出現(xiàn)的，其核心訴求都是提高開發(fā)效率和可維護(hù)性，這正是作為工程師應(yīng)該追求的東西。在研究、配置、推廣任何新技術(shù)的過程中，肯定會有成本，你覺得為了解決這些問題不值得付出這些成本，不代表別人也是這樣，更不代表你有資格去蔑視別人為解決問題做出的努力。至于揣測他人是『靠信息不對等闖名聲』，除了小人之心我還能說什么呢？
