大約五年前，那時候我還是一個小小講師（蘋果 AATC 培訓認證），完全不懂編程為何物的菜鳥，一個偶然的機會讓我進入了公司的開發(fā)部門，任職什么呢？用戶體驗設(shè)計師，原因很操蛋——我以前干過廣告設(shè)計，做過餐飲服務(wù)行業(yè)，因而我有兩個優(yōu)勢：能聆聽和揣摩客戶的需求，然后能做一些圖。

那時候很多像我們公司一樣的中小 IT 企業(yè)（200人左右，組成成分主要是大大小小的項目團隊）都有要做自主產(chǎn)品的訴求，這是市場決定的：出門找生意越來越難了。于是很多野路子出家的產(chǎn)品研發(fā)團隊就這樣誕生了……

說是產(chǎn)品研發(fā)團隊，其實都只是一群習慣了聽命于人去按照 RFP 實現(xiàn)功能的碼農(nóng)罷了，和其他項目組相比唯一的差別大概就是“尚有夢想的咸魚”而已。所以研發(fā)過程中的種種幼稚和操蛋，你用腳趾頭都能猜想得到。

一開始我就是把各位老大的設(shè)想整理成人人看得懂的需求，然后把它們串起來畫成草圖（mockup）再交給各種工程師去實現(xiàn)好了，這個角色類似于如今很時髦的“產(chǎn)品經(jīng)理”。然而很快我發(fā)現(xiàn)大家老是加班，為什么呢？調(diào) CSS 樣式！

做慣了平面設(shè)計的我并不懂得把畫出來的東西變成瀏覽器里的東西會有多麻煩。（今天，我在面試一些切圖頁面仔時，聽他們大談特談像素級還原尚覺得好笑，但想想五年前的自己還是很有些羞愧的……然而更令我無語的是：到了如今初出茅廬的小前端們還把像素級還原的切頁面當成是至高無上的本事，這件事情本身是不是很令人“沮喪”呢？）當寫頁面的同事一再告訴我我畫的東西不實際之后，我憋不住了——我就不信我畫的東西實現(xiàn)不出來！

抱著一口“怨氣”，我義無反顧的踏上了 HTML＋CSS 這條路，其中過程不用多講，唯一的金玉良言只有一條：別看國內(nèi)的教程，別信 w3school 之類的拼湊資源站。總之這事兒的結(jié)果是半年以后整個項目組幾乎所有的頁面都是我來寫了。（今天，已然成為前端架構(gòu)師的我，所有頁面的自定義樣式還是得我親自寫，我不怪任何人因為我知道在很多工程師內(nèi)心里還是瞧不上寫 HTML＋CSS 的技術(shù)的，你們不愿意學我不勉強，我來。我還要感謝你們，為了能把飯喂到諸位的嘴里，我花費大量的時間學習 CSS 框架的開發(fā)，從而精通了整個生態(tài)鏈，從 pre-processing 一直到 post-processing）。

這個世界就是這樣：一旦你專精了一項技能，你會很容易看出相關(guān)的技能在目前的水準如何。古人說：水漲船高。誠不欺我也。

所以成天耳濡目染 HTML＋CSS 的我，經(jīng)受著各種國外大神的視頻＋教程耳提面命的我，很快就明白了一件事：我做的這個叫前端開發(fā)，HTML＋CSS 只是起了一個頭，后面還有一座叫 JavaScript 的大山等著我。而我們做的前端開發(fā)還很嫩，活該你成天加班改樣式，修 bug，因為你一開始就沒走對路數(shù)。

幸好還不晚，不過這篇的主題是前后分離，所以我得按下快進按鈕直奔主題而去。

JavaScript 對我來講太難太難了，但是 jQuery 尚可，因為它有非常棒的 API 設(shè)計和兼容性處理，很適合我這樣的菜鳥入門。那時候有一個叫 Jeffery Way 的家伙錄制了一套 30 天學會 jQuery 的教程讓我受益匪淺，我認為他講得好，主要是兩個原因：

他不主要講各種 API 如何用，他從一開始就給我貫徹了一個重要的思想：學會看文檔；

他主要講如何分析一個功能的實現(xiàn)，如何組織以 jQuery 為核心的代碼邏輯；

在這里先插一段旁述。各位能在工作中使用 Rails 的同行們，你們是無比幸運的！因為 Rails 已經(jīng)把 View－Template 這一環(huán)節(jié)梳理的足夠簡單，哪怕完全不懂 Rails 的頁面仔，你稍微提點提點，他也能很快學會如何把靜態(tài)頁面套進 Rails 的模版里去。

而我則是很不幸的，在那時我碰上了非常討厭的 JSP！你們千萬別笑，隨便去問那些寫頁面出身的前端們對 JSP 是什么感受，絕對不會有好臉色的。對，我承認自己很菜。寫靜態(tài)頁面我行，但轉(zhuǎn)成 JSP 模版這件事在那時真的能把我難死！更要命的是，如果你把寫好的頁面交給后端工程師去套模版，最終的結(jié)果就是一塌糊涂！沒錯，他們根本不會細心周到的照顧你精心設(shè)計的每一個標簽，他們會做出各種各樣奇葩的事情來破壞原本完美的頁面結(jié)構(gòu)，逼迫你不停的修改樣式和腳本來適應(yīng)這些“補丁”。

更要命的是調(diào)試！原本寫 HTML＋CSS 一個輕量級編輯器就搞定了，但等他們轉(zhuǎn)成 JSP 之后你再想去調(diào)試就沒那么簡單了。你需要：

運行環(huán)境，比如 Java＋Tomcat，不懂吧？沒事，學！

生態(tài)鏈，比如 Maven 或 Gradel，不懂吧？沒事，學！

IDE，比如 eclipse 或 IDEA Intellij，不懂吧？沒事，學！順便一提，知道沒接觸過 Java 的人想跑起一個應(yīng)用來有多難嗎？我就是為此才愛上 Rails 的！

……

就這樣，為了調(diào)試 HTML＋CSS，你最終變成除了不會寫 Java 代碼外其他全都會的 Java 開發(fā)工程師。

你們這些從后端出身的家伙們能體會到前端頁面仔們邁出這一步需要多大的勇氣和毅力嗎？

你們能想象他們之所以不得不學做這些，就是因為你們無法認真對待 HTML＋CSS＋JavaScript 嗎？

為什么要在后端的環(huán)境下做前端的事情？其實就為了三個字：擦屁股！

你可以說我們這一群人都很菜，我也承認，可是你要知道：環(huán)境不是時時處處都可以給你各種選擇的，有時候你唯一能做的選擇就是改變自己。那么作為一個只懂 HTML＋CSS＋皮毛 JavaScript 的我，能做出什么？不知從何時開始，“如果可以不再依賴任何環(huán)境就可以做好我們的份內(nèi)之事就好了”這樣幼稚的念頭開始縈繞在我的腦袋里……

回到 Jeffery 的視頻教程，在其中的一節(jié)他演示了 Ajax 獲取遠程數(shù)據(jù)然后動態(tài)修改 DOM 的例子，當時的例子里用的是 Twitter 的 API，然后每隔一段時間拉取幾條新數(shù)據(jù)讓頁面即時刷新這樣子……

不要笑，知道我當時有多震驚嗎？我覺得我們就他媽的是一群傻逼好嗎？

第二天我慌不擇路的把這段視頻拿給后端架構(gòu)師看，問他實現(xiàn)這樣的東西，可行？他憋了半天：我們都是直接去數(shù)據(jù)渲染到 JSP 的，API 沒做過……

操！沒做過難道不能做？我趕緊拋出了誘餌：如果搞的出來，以后你們再也不用套模版了！

這貨立馬答應(yīng)了……

此后就是翻天覆地的折騰，我搜遍了所有能找到的資料，把它們翻成中文或者直接當面講給后端聽，有些東西我們都無法理解就先記下來，晚上回去我上 SO 問，上 Youtube 搜會議等資料看。

然后他們告訴我，如果換 Spring 的話可能會比較簡單，因為他們能百度到用 Spring 開發(fā) API 的例子。于是我們就開始改造了。

改造的第一步是不用寫 JSP（或者少量的寫），但是靜態(tài)資源其實還是放在 Tomcat 容器里的，因為我們經(jīng)過嘗試發(fā)現(xiàn)跨域問題解決不了（是的，當時就是菜，連反向代理都不懂），不過沒關(guān)系，反正我已經(jīng)學會了本地跑 Tomcat 了，至少我們可以不用寫 JSP 了嘛。現(xiàn)在回想一下當初搞前后分離的原始動機竟然就是為了不再去寫 JSP，多么滑稽啊！然而反過來想想，這也映襯了一個事實：前端工程師們的生態(tài)環(huán)境是有多糟糕！

再然后就是把 jQuery 修煉到滿級開始無腦刷副本的無聊過程，當然在這個過程中也體驗了一些新東西，比如前端的模版引擎（Jade／Handlebars／Art等），模塊系統(tǒng)（SeaJS／RequireJS）等等，JavaScript 的水平和理解有了長足的進步，終于開始有一個工程師的樣子了。

再之后就是大家都知道的劇本，node.js 橫空出世，一下子 HTTP Server，API Service，Shell Scripting……等等這些統(tǒng)統(tǒng)都可以用 JavaScript 來搞了，npm bower grunt gulp……等等這些應(yīng)運而生，忽然間前端開始有了自己的生態(tài)系統(tǒng)！盡管它還很弱小還很混亂，但是它給了我們這些野路子出身摸爬滾打渾身泥水的家伙們一道希望之光，它讓我們看到：

我們可以不依賴后端的運行環(huán)境：node.js

我們可以有自己的生態(tài)圈：npm

我們可以隨心所欲使用各種方便的開發(fā)工具：所以我后來成了 vim 黨

……

我們可以有很多可能，我們可以把我們擅長的事情做得更棒而不需要后端哥哥們操心，我們可以省去很多后端要 cover 的工作讓他們專心寫好自己的代碼，我們設(shè)想中的分離是有搞頭的，不僅僅是為了分離而分離，而是為了更好的專精、多能、協(xié)作、管理而分離！

何以如此狹隘的看待前后分離？時至今日我也不懂為什么有那么多人抱持著種種懷疑與偏見。

你們不用擔心數(shù)據(jù)層邏輯會有冗余，因為把 Model 的邏輯分攤到前端身上可以省去后端的部分代碼和處理工作，而前端也可以更容易地按照業(yè)務(wù)來組合自己需要的 Model
你們不用擔心視圖層的緩存，因為分離后前端只存在靜態(tài)資源，我們可以利用 CDN，利用 負載均衡，利用很多很多技術(shù)分攤過去必須讓后端來承擔的工作
你們不用擔心頁面渲染速度，首頁怕慢我們可以交給服務(wù)端來渲染，或者在中間加一個很簡單的 node server 來做首頁靜態(tài)化渲染，后面的事情交給前端就是，只快不慢
你們不用擔心要為多個客戶端做不同的資源調(diào)度，只要 API 規(guī)劃得到，一套 Service 可以支持多個客戶端的業(yè)務(wù)體系，而前端行有余力甚至可以寫出多個版本來做 A／B 測試
你們不用擔心 ……

優(yōu)點多了去了。

不是說這些優(yōu)點目前都很成熟，也不是說實現(xiàn)它們沒有代價，但是你不去做就不可能成熟，代價也不是不可以有但關(guān)鍵是要看長遠的收益。

很現(xiàn)實的例子就是我們有一套系統(tǒng)本來是為自己做的，后來讓客戶知道了覺得很感興趣希望為自己定制一份。我們分析了一下，發(fā)現(xiàn)現(xiàn)有的 API 已經(jīng)可以滿足用戶的需求，只需要針對幾個具體的業(yè)務(wù)邏輯再擴充幾個接口讓數(shù)據(jù)負載更合理便可，于是我們只用了三天就給客戶出了一個完全可用且相當穩(wěn)定的 demo。客戶覺得滿意，開始按照他們的 VI 重新設(shè)計一套 UI，然后剩下的事就是找?guī)讉€頁面仔把頁面寫出來，現(xiàn)成的 Angular 邏輯往上一套小改幾處即可。

你會覺得不值得？

當然了，我在這里不是鼓吹前后分離信仰，不是強求所有的事情都需要分離來做。一個產(chǎn)品的軌跡是需要產(chǎn)品研發(fā)團隊自己把控的，如果人云亦云流行什么用什么那也就和無腦兒沒啥區(qū)別了。有些場景也的確不需要分離，比如說門戶網(wǎng)站，CMS，Mini Site 這類的需求就可以沿用成熟的開發(fā)體系。不過我之前談到過，探索和實踐分離體系還有一個重要的好處，就是能夠讓你現(xiàn)有的前端開發(fā)團隊摸索和整理出一套單兵作戰(zhàn)的環(huán)境體系，即便是不用分離架構(gòu)，我單純用 node.js 寫一套門戶網(wǎng)站，CMS，Mini Site 這樣的東西也不會比 Rails 慢啊！這樣一來，我還是可以把后端的資源用在更重要的底層服務(wù)或業(yè)務(wù)邏輯去，把那些和頁面 UI 交互相關(guān)，但又和數(shù)據(jù)層有著小小關(guān)聯(lián)的業(yè)務(wù)交給前端獨立完成，又有什么不好呢？
前后分離＝SPA？SPA＝臃腫框架？

這一點我覺得有必要分析清楚，標題里的兩個問號是我見到過最多的誤解。

首先，前后分離是架構(gòu)上的事情，第一次做肯定很痛苦，但做一遍之后好處還是很多的。舉實例說明：

我們做過一個會議的應(yīng)用，這個應(yīng)用一開始設(shè)計是沒有 web 端的前臺的，只有一個管理后臺，前臺都是移動端。基于這個原因，我們還是分離的（因為你得提供 API 給移動端，不分離還能怎么搞呢？），后臺用成熟的 Angular 很快就做好了。

沒想到后來有一個額外的要求，用戶要在創(chuàng)建會議的時候生成一套在線的會議手冊，這個會議手冊就是一個簡單的多頁面 CMS 系統(tǒng)，當用戶創(chuàng)建新會議的時候在后臺填寫手冊相關(guān)的內(nèi)容，我們就要為它生成一系列的頁面來顯示（類似于 Mini Site），它有兩個特定要求：

不需要登錄，公開訪問。然而最初的設(shè)計是沒有賬號就不能參加會議，需要報名，所以我們后臺和移動 App 都是直接先要求登錄或注冊的，相應(yīng)的 API 請求也是如此，有鑒權(quán)控制的。

要能多端訪問，還要能嵌套在原生應(yīng)用的 webview 里，因為加功能來不及了，只有一天時間。

傳統(tǒng)的架構(gòu)你的寫頁面然后套模版去調(diào)試，雖然只有不到10頁，但也是很費時間的。但我們已經(jīng)分離了，現(xiàn)在為了這么一個額外的需求也不值得再倒退回去，那么怎么做的呢？

單獨建一個會議手冊的項目；

模版用 Sass＋Handlebars 很快搞定；

里面的接口請求為每一個會議服務(wù)商綁定一個 token（后來還在后臺允許管理員重新生成和綁定 token），渲染頁面時寫死在 <meta> 標簽里（就好像 CSRF 的處理），以此繞過鑒權(quán)

寫一個簡單的 node service，就干一件事：渲染handlebars模版

創(chuàng)建會議的時候，Java API 傳會議 ID 給 node service，把渲染好后的頁面單獨保存在靜態(tài)資源服務(wù)器下（用 ID 創(chuàng)建獨立目錄），然后返回調(diào)用地址

后臺收到會議地址，嵌入一個 iframe 做手冊預覽

一天搞定，完事。值得一提的是，整個手冊用了許多 HTML5 的新特性，比如 History API，SessionStorage，OfflineCache，GeoLocation，DesktopNotification，沒有用 Polyfill，因為這些都是可選特性，不支持就不作用，關(guān)鍵是：從頭到尾就是沒用 jQuery——不是我跟 jQuery 過不去，的確用不著，還嫌大。更不要提 SPA 框架了，完全沒有。

所以你看，分離架構(gòu)可以讓我們很快完成這樣的小任務(wù)，并且可以單獨維護管理，也可以直接共享現(xiàn)有的 API 資源，它不一定只是為了 SPA 才分離，而且也沒有什么技術(shù)難度。能用很短的時間完成還能保證質(zhì)量，是因為我們有成熟的構(gòu)建和CI，如果換成是當初 JSP 那一套，光配置個本地環(huán)境就夠夠的了，其他我都不敢想象。

分離是架構(gòu)選擇，決定了你如何管理、分配與協(xié)調(diào)現(xiàn)有的資源，至于你分離后要做 SPA 還是其他模式的應(yīng)用那完全是你的自由，并不是捆綁一加一的強制性決策。去構(gòu)建一個分離體系當然會有挫折有代價，沒有人否認這個，然而一）這是可選的；二）你能否看到和利用它的好處。

至于 SPA 一定是臃腫的嗎？保持這種思想的我只能說你目光所見過淺。相比十年前的 web 開發(fā)，我能說現(xiàn)在 Rails 很臃腫嗎？別說十年前了，就是今天一樣也有人說 Rails too heavy！你覺得呢？那又怎樣呢？還不是該用就用？水平高的自然知道拆分和減肥，連 Rails 自己都知道瘦身一個 Rails API 出來，你以為所謂“臃腫”是 SPA 框架的專利嗎？SPA 之所以臃腫是有兩個主要的現(xiàn)階段環(huán)境因素決定的：

非常多的新特性層出不窮，為我們開發(fā)更豐富強大的應(yīng)用程序提供了武器和彈藥。但是瀏覽器（及其他運行環(huán)境）和設(shè)備碎片化的問題導致這些新特性無法提供始終一致的表現(xiàn)或性能，于是各種框架就要在底層做兼容性的補充與改良，順便還要為尚未形成標準的新特性重新封裝 API 接口。比如說 Ember 干嘛要造一個 Object 接口出來？不就是因為 Observable 接口沒有嗎？有什么大不了的？ES2016就有了（非常可能），或者你可以不用 Ember 自己的，用第三方的 Observable 組件來代替也行。
jQuery 做的事情和這有多大區(qū)別？沒錯，jQuery 是相對輕了，可是它負責的面兒也少啊，哪位用 jQuery 的不都得附帶十個八個插件的？合在一起就輕了？

相對的，前端工程這塊業(yè)界整體的水平差距很大，牛的特牛，菜的特菜；但是菜的也希望用牛的工具，可又沒那個底蘊解決牛的能解決的問題，于是牛的就把一個一個特性統(tǒng)統(tǒng)封裝好聯(lián)系在一起，讓你盡可能快速簡單的就能用到。
如果大部分的工程師都成長起來了，也就沒有必要非得搞大而全的方案了，React 及其生態(tài)體系不就是一個很好的例子嗎？不給你搞大而全，只給你搞小而專，你以為你把那一堆連起來用就不叫 SPA 了？幼稚！

再說一遍，SPA 是一種產(chǎn)品的技術(shù)形態(tài)，而不是特定某（幾）種框架下的產(chǎn)物，滿足這種技術(shù)形態(tài)的工具鏈可以臃腫也可以簡潔，這是因為環(huán)境和人決定的。

Single Page Application，not Some Particular Application

前后分離還有一方面的作用。前端工程師都有一個普遍的特點：你讓他們寫個頁面信手拈來，但是你讓他們負責一個完整的業(yè)務(wù)多半就得抓瞎。為什么？因為他們太偏門。最近一兩年我開始大量的面試和儲備新人，十有八九都是這樣的：HTTP？不懂！Ajax？懂！（你覺得合理嗎？）jQuery 請求 API？會！Promise 用過？……沒。換個說法，deferred 對象？哦哦，見到過！（你覺得合理嗎？）

諸如此類的問題屢見不鮮，讓我對前端這個行業(yè)的未來充滿憂慮。當初我也是從一竅不通的菜鳥開始，若那時沒有“一定要擺脫 JSP”的幼稚理想，我怎么可能通過摸索前后分離讓自己擁有今天這樣相對全面的見識和理解？我走過的路讓我明白，探索前后分離并不是像很多旁觀者說的“為了分離而分離”，反而是“為了更好的理解 web 開發(fā)這回事而分離”。

因為當你開始摸索這條路，你就不得不面對許多根本性的問題，拿跨域資源共享來說吧，以前的架構(gòu)前端工程師是極少需要面對這種問題的，但你只要一分離就必然會碰到，然后你就要去學諸如 JSONP，CORS，HTTP 協(xié)議，瀏覽器安全機制，PreFlight Request，反向代理等等技術(shù)細節(jié)。看似加重了學習成本（要我說，這些原本應(yīng)該是學校的責任！），但作為同事，你希望你身邊做的是個只會“追求像素級還原”的頁面仔呢？還是對上述知識點有著扎實的理解和實踐經(jīng)驗的工程師呢？

說到這，就昨天有人在 SF 上問了個問題，大致是問：JavaScript 怎樣才算學好了？總覺得需要自己能寫一個庫或框架出來才算學好了，大家怎么看？

我剛好和人吵完了架，靜下心想了想之后作出了如下回答：

少年苦練 10 年拳術(shù)欲下山揚名立萬，路遇一使刀漢子，數(shù)招后不敵慘敗而歸……回山后找?guī)煾祮栐?/p>

“師傅，為何我苦練十年還會輸？”

“因為你不知道打架不止可以用拳頭。”

“可你也沒告訴我啊！”

“你只說要學拳法，又沒說學打架！”

“那我不學拳法了，我要學打架！”

“那就不只是要學拳法了，打架想要贏就得十八般武藝都學，你未必要門門精通，但你最起碼得有這些見識。除此之外，還得學挨打，學療傷，學逃跑，學追蹤，學暗器，學使毒……想贏？哪有那么簡單的！”

“那我還能成拳法宗師嗎？”

“呵呵，如果你打架再也不會輸，誰敢說你不是宗師？”

這個寓言想表達的意思是不言而寓的，我很贊同這里一位朋友說的：我們不應(yīng)該有前端后端之分，我們可以有專精之處，但是對于 web 開發(fā)這回事該懂的都應(yīng)該要懂，否則你怎么可能打得贏？同理，如果說后端工程師需要靠寫頁面來了解前端的話，那么前端也應(yīng)該有類似的方式來了解后端做的一些事情。在這里探索前后分離就是一個很好的教學與實踐相結(jié)合的手段。沒有哪個頁面仔會甘于永遠切圖寫頁面，他們也很羨慕后端哥哥們大神般的風騷，只是他們所處的環(huán)境造成了他們只知道數(shù)十年如一日的就懂切頁面了，如果能多給他們一些提攜與幫助，誰敢說他們以后不會成為江湖高手？

很多人拿工作忙，缺人手，創(chuàng)業(yè)公司求效率等借口來回避在技術(shù)道路上的探索和進取，說真的我個人非常非常可以理解，我當初所做的事情其實和創(chuàng)業(yè)什么的也沒多大區(qū)別，我們?nèi)耸忠埠芫o缺——今天我們只有三個人維護著四款前后分離架構(gòu)的中大規(guī)模產(chǎn)品，這些產(chǎn)品有 Saas 版本的，還有大大小小十幾個在客戶那里獨立部署的，你沒看錯就三個人！一個 Java 工程師，一個懂 Java 的前端工程師，再加上我這個什么都懂一點但什么都不專精的萬金油。

我們做的還不夠好，但我們已盡力做到自己能做的最好，與我們這五年來碰到的風風雨雨相比較，探索前后分離這真的不算個大事兒好嗎？

作為前端工程師（并且是懂得和尊重后端開發(fā)的），我很欣慰能活躍在這個時代，就像有人說的：這是前端最好的時代，也是前端最壞的時代。然而歷史無數(shù)次證明：真金不怕火煉，英雄應(yīng)運而生。那些后端語言環(huán)境和框架體系難道沒有經(jīng)歷過同樣的革新與變遷？就因為我們過去是只會寫 jQuery 的頁面仔，所以我們就應(yīng)該永遠這樣停滯不前？

這就是我探索前后分離的過程和心得感想，主要是在離職前為過去五年做一個總結(jié)。寫得比較凌亂也沒什么技術(shù)含量，根本的意思還是要鼓勵眾多的前端同行們：學校沒有我們的專業(yè)課，社會對我們的工作沒有準確的認知和評價，這都不要緊！重要的是我們自己不能看輕自己的能力，不能放棄自己的價值。在學習和工作尚有余力的時候勇于探索吧，別管別人說什么，本事學到手才是最重要的，要記住：你是一個工程師，你不是一個頁面仔！