用戶端JavaScript的5個弊端

譯註：原來的標題是：“我們為啥不用AngularJS:…”，後來作者覺得不妥就改掉了，因為AngularJS是通常適用於單頁面程式架構(SPA) 很多人理解為對AngularJS的抨擊，但這並不是他的本意。 

幾個月前，當我們開啟Sourcegraph網站的時候，它是一個富AngularJS應用，伺服器只要把原始HTML和JSON endpoints返回，剩下的就交給Angular來搞定了。我們就這樣懵懵懂懂地做出了最初版本的Sourcegraph。

但是單頁single-page） JavaScript架構並不適用於每一個網站。Sourcegraph就是一個內容為主的網站，我們漸漸發現這個富js應用的開發還是弊大於利；下面是我們在探知這條路上遇到的溝溝坎坎，希望對有雷同遭遇的開發人員一些協助。

下周，我們來討論更多地關於我們是如何從AngularJS遷移server-side GO templates

用戶端JS架構的5個弊端

我們早就知道這會有很多的困難，但是不知道到底有多難

1. 搜尋排名和Twitter/Facebook預覽

搜尋引擎爬蟲和社交網站的預覽抓取器不能載入純Javascript網站，而如果提供替換版本又慢又複雜

有兩種方法可以允許爬蟲閱讀你得網站。你可以在伺服器端運行一個瀏覽器執行個體用以執行你的應用裡的Javascript，然後返回HTML結果PlantomJS或者WebLoop）。 或者你可以為你的網站專門建立一個HTML版本為爬蟲服務

第一個方法需要你為每一次頁面載入建立一個headless瀏覽器或者tab），比起直接產出HTML，這樣會花費很多的時間和系統資源。基於你用的架構，會花費很多的工作來決定什麼時候已經準備好的頁面將被渲染。 你可以快取頁面面，但是如果頁面經常改變，不但最佳化甚微而且會增大複雜度。

這樣做還會降低你的頁面載入速度好幾秒，對搜尋引擎排名也不利。PlantomJS需要Xvfb和WebKit）

第二個方法做一個伺服器端網站）對簡單地網站有效，但是如果頁面很多，那用這個方法就形同噩夢。

如果Google認為你的伺服器版本網站跟你的主站版本有很大的不同，那他就會狠狠的懲罰你，到時候你連怎麼死的都不知道

2. 不可靠的統計和監控

很多分析工具需要易於出錯，人工整合來使用HTML5 history APIpushState）用於導航。因為他們很難自動檢測到你的應用使用pushState導航到了新的頁面。即使可以做到，他們仍然需要等待你應用裡的訊號來收集新頁面的資訊

如何解決這個問題呢？取決於你的用戶端用什麼導航和你想整合什麼分析工具。用Google分析+Backbone.js？嘗試一下backbone.analytics。用Heap順便說一下，太酷了）和UI-Router？設定你自己的$stateChangeSuccess並調用heap.track

還沒完事呢！你想追蹤起始頁面載入？也許你在雙向跟蹤他？你會跟蹤失敗的頁面記載嗎？如果你使用replaceState代替pushState呢？如果你錯誤的配置了分析掛鈎或者屬於檢查導致依賴升級搞壞了事情。當你發現的售後，很難去恢複你錯過的分析資料或者消除重複資料）

3. 又慢又複雜的構建工具

前-後端JavaScript構建工具，比如Grunt，需要複雜的配置而且很慢。還好我們有像ng-boilerplate這樣的project來幫我們做配置，但是如果你想添加一個自訂的步驟還是逃不出又慢有複雜的怪圈我為什麼說Grunt複雜，看看這個設定檔就知道了）

一旦你配置好了你的應用，你仍然要忍受漫長的JavaScript構建時間。你可以把dev和production構建通道分開來提高開發速度，但是始終免不了走這麼一遭，用AngularJS尤其如此，他需要在醜陋的代碼前使用ngmin如果你用了這個功能）。其實，Sourcegraph因為這些醜陋的JavaScript表現代碼幾度被毀

還好，Gulp已經有了極大的提高

4. 慢，不可靠的測試

測試JavaScript-only的網站需要使用基於瀏覽器的測試架構，比如Selenium，PhantomJS，或者WebLoop。安裝這些除了PhantomJS）通常意味著安裝WebKit和Java依賴，配置Xvfb(機關新的PhantomJS移除了這些先決條件)，或者運行一個本地的VNC用戶端和伺服器來測試。最後，你還需要在持續整合的伺服器上設定所有東東

相反，測試伺服器端產生的頁面通常只需要類庫來或者URLs並解析HTML，安裝和配置起來簡單許多

一旦你開始寫瀏覽器測試，你必須處理非同步載入。你不能在頁面還沒有載入的時候就測試頁面上的元素，但是如果在一個特定時間端裡沒有載入，你的測試就會失敗。瀏覽器測試類別庫提供了很好地功能來處理這種情況，他們只能在負載的頁面裡使用這些功能

如果你想聯合重量級瀏覽器來進行Selenium，加上Firefox或者Webkit）很複雜的測試因為瀏覽器的非同步特質）？你的測試需要很多配置，很長的時間來執行，而且很不可靠

5. 慢，可以緩解，但沒有解決

在富JavaScript應用中，頁面轉化幾乎是瞬間發生，然後所有的特定元素非同步載入。在server-side應用中，完全相反：頁面在伺服器端載入完成前不會發送到用戶端

聽起來似乎是client-side應用勝利了，但是也許會是個坑也不一定

當使用者點擊一個連結，client-side應用會立刻載入頁面並呈現。如果使用者用sidebar導航到一個需要5秒鐘才可以載入的頁面。第一次感覺很快，但是如果一個使用者需要的資訊在sidebar裡，對使用者來說就感覺很難受。即使你需要的特定內容立即呈現，你仍需要忍受載入指標和頁面填充後的抖動

我們來考慮如果開發人員想在那個頁面添加新功能。是很難讓她的功能必須快速載入的-因為都是非同步，所以誰會在意頁面底部過了幾秒才載入呢？如此反覆幾次，整個網站讓人感覺滯後很抖動

在server-side 應用中，如果一個API調用很慢，整個頁面就會停滯直到徹底完成。這個不容忽視的server-side慢節奏很容易被測量並會公平地影響每一個人。但是在client-side應用中很容易被忽略

你可以說，一個好的Team Dev應該避免這些錯誤，並且client-side JS 架構不是罪魁禍首。是的，client-side JS架構提高了速度。這一點改變鼓勵了任何Team Dev

下一步？

上面說得都不是大問題。我們已經做了很多來減輕上述情況。

總而言之，上述種種以為這client-side JS 架構加大了我們開發的負擔。

而且要記住，每一個網站都是不同的。Sourcegraph是一個內容網站，他得頁面在載入後不會有太多的變化相較於富JS應用），我們依然愛著浙西技術，但是他們不一定是構建主要站台的正確工具。

譯文連結： http://blog.jobbole.com/61681/