摘要：客戶端框架的個(gè)痛點(diǎn)我們?cè)缰罆?huì)面臨很多的困難，但是不知道會(huì)有這么難。這是對(duì)的，但是總體上來(lái)說(shuō)，客戶端框架降低了遲緩的開(kāi)銷(xiāo)。但是，這些問(wèn)題加在一起就是另一回事了，可以說(shuō)，客戶端框架成為了我們開(kāi)發(fā)工作的一大負(fù)擔(dān)。

更新： 本文原本的標(biāo)題是“為何我們棄用AngularJS：……”，現(xiàn)在把它去掉了。因?yàn)檫@些痛點(diǎn)主要是針對(duì)單頁(yè)JS應(yīng)用框架的。有些人認(rèn)為本文是專(zhuān)門(mén)批判AngularJS的，這可不是我的本意。-- Quinn

幾個(gè)月前我們的Sourcegraph網(wǎng)站向公眾開(kāi)放，它是一個(gè)富AngularJS應(yīng)用。服務(wù)器傳輸原始的HTML頁(yè)面和JSON端點(diǎn)，剩下的就交給Angular來(lái)處理。這是一個(gè)創(chuàng)建Sourcegraph的簡(jiǎn)易方式，當(dāng)時(shí)我們不知道Sourcegraph會(huì)變成什么樣。

但是單頁(yè)JavaScript框架并不適用于每一個(gè)站點(diǎn)。Sourcegraph是一個(gè)內(nèi)容為主的站點(diǎn)，我們漸漸發(fā)現(xiàn)富js應(yīng)用弊大于利。富js應(yīng)用的好處眾所周知，下面是我們體會(huì)到的一些意料之外的困難。希望對(duì)面臨類(lèi)似選擇的開(kāi)發(fā)人員能有一些幫助。

我們?cè)缰罆?huì)面臨很多的困難，但是不知道會(huì)有這么難。

搜索引擎爬蟲(chóng)和社交網(wǎng)站的預(yù)覽抓取器不能加載純Javascript站點(diǎn)，提供替代版本又慢又復(fù)雜。

有兩種方式可以允許爬蟲(chóng)閱讀你的站點(diǎn)。你可以在服務(wù)器端運(yùn)行一個(gè)瀏覽器實(shí)例來(lái)執(zhí)行你的應(yīng)用里的Javascript，然后從DOM中卸下HTML（使用PlantomJS或者WebLoop）?；蛘吣憧梢詣?chuàng)建一個(gè)服務(wù)端生成的專(zhuān)供爬蟲(chóng)的替代性HTML版本。

第一個(gè)方法需要你為每一個(gè)頁(yè)面加載建立一個(gè)headless瀏覽器（或者tab），比起直接產(chǎn)出HTML，這樣會(huì)花費(fèi)很多的時(shí)間和系統(tǒng)資源。取決于你使用的框架，需要不少精力來(lái)決定什么時(shí)候頁(yè)面已經(jīng)準(zhǔn)備好了。 你可以緩存頁(yè)面，但是如果頁(yè)面經(jīng)常改變，那么緩存只能起到非常有限的優(yōu)化作用，而且會(huì)增大復(fù)雜度。這個(gè)方法會(huì)將你的頁(yè)面加載速度拖慢好幾秒，對(duì)搜索引擎排名也不利。

第二個(gè)方法（創(chuàng)建一個(gè)替代性的服務(wù)器端站點(diǎn)）對(duì)簡(jiǎn)單站點(diǎn)而言足夠了，但是如果頁(yè)面很多，這將是一個(gè)噩夢(mèng)。況且如果Google認(rèn)為你的服務(wù)器版本站點(diǎn)跟你的主站版本有很大的不同，那他就會(huì)狠狠的懲罰你。糟糕的是，直到你的訪問(wèn)量直線下降的時(shí)候你才會(huì)意識(shí)到你已經(jīng)過(guò)界了。

很多分析工具需要使用易于出錯(cuò)、手工集成的HTML5 history API（pushState）來(lái)導(dǎo)航。這是因?yàn)樗鼈儫o(wú)法自動(dòng)檢測(cè)到你的應(yīng)用使用pushState導(dǎo)航到了新的頁(yè)面。即使可以做到，它們?nèi)匀恍枰却銘?yīng)用的信號(hào)來(lái)收集新頁(yè)面的其他信息（例如頁(yè)面標(biāo)題和其他頁(yè)面特定的指標(biāo)）。

你如何解決這個(gè)問(wèn)題？同時(shí)取決于你的客戶端路由庫(kù)和你集成的分析工具。用Google分析和Backbone.js？嘗試一下backbone.analytics。用Heap（順便說(shuō)一下，Heap很棒）和UI-Router？設(shè)置你自己的$stateChangeSuccess鉤子然后調(diào)用heap.track

還沒(méi)完！你想追蹤起始頁(yè)面加載？也許你重復(fù)跟蹤了？你會(huì)跟蹤失敗的頁(yè)面加載嗎？如果你使用replaceState代替pushState呢？即使要獲知你是否錯(cuò)誤地配置了分析鉤子——或者是否依賴(lài)升級(jí)搞亂了系統(tǒng)——也是相當(dāng)困難的，除非交叉檢查分析。當(dāng)你發(fā)現(xiàn)問(wèn)題后，很難去恢復(fù)你錯(cuò)過(guò)的分析數(shù)據(jù)（或者消除重復(fù)數(shù)據(jù)）。

前端JavaScript構(gòu)建工具，例如Grunt，需要復(fù)雜的配置而且會(huì)很慢。還好我們有像ng-boilerplate這樣出色的項(xiàng)目來(lái)幫忙，但是它們很慢。并且如果你想添加一個(gè)自定義的步驟的話你還是無(wú)法避免復(fù)雜性。（我為什么說(shuō)Grunt復(fù)雜，看看這個(gè)配置文件就知道了。）

一旦你配置好了你的應(yīng)用，包括Gruntfiles等等。你仍然要忍受漫長(zhǎng)的JavaScript構(gòu)建時(shí)間。你可以把dev和production構(gòu)建通道分開(kāi)來(lái)提高開(kāi)發(fā)速度，但是你終將深受其苦。用AngularJS尤其如此，他需要在壓縮代碼前使用ngmin（如果你用了特定功能）。事實(shí)上，我們有幾次就是因?yàn)檫@些壓縮的JavaScript和開(kāi)發(fā)時(shí)的代碼表現(xiàn)不同而把SourceGraph搞砸了。

事情正在改善，Gulp是一個(gè)巨大的提升。

測(cè)試JavaScript-only的站點(diǎn)需要使用基于瀏覽器的測(cè)試框架，比如Selenium，PhantomJS，或者WebLoop。安裝這些（除了PhantomJS）通常意味著安裝WebKit和Java依賴(lài)，配置Xvfb（雖然新版的PhantomJS移除了這些依賴(lài)），也許運(yùn)行一個(gè)本地的VNC客戶端和服務(wù)器來(lái)測(cè)試。最后，你還需要在持續(xù)集成服務(wù)器上配置這些東西。

相反，測(cè)試服務(wù)器端生成的頁(yè)面通常只需要類(lèi)庫(kù)來(lái)獲取URL和解析HTML，安裝和配置要簡(jiǎn)單許多。

一旦你開(kāi)始編寫(xiě)瀏覽器測(cè)試，你必須處理異步加載。你不能在頁(yè)面還沒(méi)有加載的時(shí)候就測(cè)試頁(yè)面上的元素，但是如果在一個(gè)特定時(shí)間段里沒(méi)有加載，你的測(cè)試就會(huì)失敗。瀏覽器測(cè)試類(lèi)庫(kù)提供了一些幫助函數(shù)來(lái)處理這種情況，但是對(duì)于復(fù)雜頁(yè)面它們只能幫上一點(diǎn)小忙。

你想組合很重的瀏覽器測(cè)試工具（Selenium，加上Firefox或者Webkit）和很大的測(cè)試復(fù)雜度（由于瀏覽器測(cè)試的異步本性）？你的測(cè)試需要很多配置，很長(zhǎng)的時(shí)間來(lái)運(yùn)行，而且很不可靠。

在富JavaScript應(yīng)用中，頁(yè)面轉(zhuǎn)換幾乎是瞬間發(fā)生，然后所有的特定元素異步加載。服務(wù)器端應(yīng)用恰恰相反：頁(yè)面在服務(wù)器端加載完成前不會(huì)發(fā)送到客戶端。

聽(tīng)起來(lái)似乎是客戶端應(yīng)用勝利了，但是也許這不過(guò)是一個(gè)偽裝的詛咒。

考慮客戶端JS應(yīng)用，當(dāng)用戶點(diǎn)擊一個(gè)鏈接，頁(yè)面會(huì)立刻加載并呈現(xiàn)。如果用戶導(dǎo)航到一個(gè)側(cè)邊欄需要5秒鐘才可以加載的頁(yè)面，第一眼感覺(jué)很快，但是如果用戶需要的信息在側(cè)邊欄里，對(duì)用戶來(lái)說(shuō)就太慢了。即使你需要的特定內(nèi)容能立即加載，你仍需要忍受轉(zhuǎn)動(dòng)的加載指示器和頁(yè)面填充時(shí)的抖動(dòng)。

現(xiàn)在考慮一下這樣的情況：如果開(kāi)發(fā)人員想在那個(gè)頁(yè)面添加新功能。很難確定這個(gè)功能是否必須快速加載——因?yàn)橐磺卸际钱惒降?，所以誰(shuí)會(huì)在意頁(yè)面底部過(guò)了幾秒才加載呢？如此反復(fù)幾次，整個(gè)站點(diǎn)就會(huì)讓人覺(jué)察到遲緩和抖動(dòng)。

在服務(wù)器端應(yīng)用中，如果一個(gè)API調(diào)用很慢，整個(gè)頁(yè)面就會(huì)阻塞直到頁(yè)面完成。服務(wù)器端的緩慢不可能被忽視，因?yàn)檫@很容易被測(cè)量，并且會(huì)公平地影響每一個(gè)人。但是在客戶端應(yīng)用中這很容易被忽略。

你可以爭(zhēng)論說(shuō)，一個(gè)好的開(kāi)發(fā)團(tuán)隊(duì)?wèi)?yīng)該避免這些錯(cuò)誤，并且客戶端 JS 框架不是罪魁禍?zhǔn)?。這是對(duì)的，但是總體上來(lái)說(shuō)，客戶端JS框架降低了遲緩的開(kāi)銷(xiāo)。這一點(diǎn)觸動(dòng)了開(kāi)發(fā)團(tuán)隊(duì)的激勵(lì)機(jī)制。

上面說(shuō)的問(wèn)題，本身都不算大問(wèn)題。我們可以做很多工作來(lái)減輕上述情況（事實(shí)上我們確實(shí)做了很多）。但是，這些問(wèn)題加在一起就是另一回事了，可以說(shuō)，客戶端JS框架成為了我們開(kāi)發(fā)工作的一大負(fù)擔(dān)。

同時(shí)要牢記，每一個(gè)站點(diǎn)都是不同的。例如，Sourcegraph是一個(gè)內(nèi)容站點(diǎn)，這意味著頁(yè)面在加載后不會(huì)有太多的變化（和富應(yīng)用相比）。我們依然喜愛(ài)這些技術(shù)，但是它們不是構(gòu)建我們的主站的合適工具。

原文 5 surprisingly painful things about client-side JS
翻譯 SegmentFault