我們早就知道這會有很多的困難，但是不知道到底有多難。在客戶端JS框架中存在著四個弊端（可觀看瘋狂軟件JavaScript視頻教程）

1、不可靠的統(tǒng)計(jì)和監(jiān)控

很多分析工具需要易于出錯，人工集成來使用HTML5 history API(pushState)用于導(dǎo)航。因?yàn)樗麄兒茈y自動檢測到你的應(yīng)用使用pushState導(dǎo)航到了新的頁面。即使可以做到，他們?nèi)匀恍枰却銘?yīng)用里的信號來收集新頁面的信息

如何解決這個問題呢?取決于你的客戶端用什么導(dǎo)航和你想集成什么分析工具。用Google分析+Backbone.js?嘗試一下 backbone.analytics。

還沒完事呢!你想追蹤起始頁面加載?也許你在雙向跟蹤他?你會跟蹤失敗的頁面記載嗎?如果你使用 replaceState代替pushState呢?如果你錯誤的配置了分析掛鉤或者屬于檢查導(dǎo)致依賴升級搞壞了事情。當(dāng)你發(fā)現(xiàn)的售后，很難去恢復(fù)你錯過 的分析數(shù)據(jù)(或者消除重復(fù)數(shù)據(jù))

2、又慢又復(fù)雜的構(gòu)建工具

前-后端JavaScript構(gòu)建工具，比如Grunt，需要復(fù)雜的配置而且很慢。還好我們有像ng-boilerplate這樣的project來幫 我們做配置，但是如果你想添加一個自定義的步驟還是逃不出又慢有復(fù)雜的怪圈(我為什么說Grunt復(fù)雜，看看這個配置文件就知道了)

一 旦你配置好了你的應(yīng)用，你仍然要忍受漫長的JavaScript構(gòu)建時間。你可以把dev和production構(gòu)建通道分開來提高開發(fā)速度，但是始終免 不了走這么一遭，用AngularJS尤其如此，他需要在丑陋的代碼前使用ngmin(如果你用了這個功能)。

3、慢，不可靠的測試

測試JavaScript-only的站點(diǎn)需要使用基于瀏覽器的測試框架，比如Selenium，PhantomJS，或者WebLoop。安裝這些 (除了PhantomJS)通常意味著安裝WebKit和Java依賴，配置Xvfb(機(jī)關(guān)新的PhantomJS移除了這些先決條件)，或者運(yùn)行一個本 地的VNC客戶端和服務(wù)器來測試。最后，你還需要在持續(xù)集成的服務(wù)器上設(shè)定所有東東。

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

如果你想聯(lián)合重量級瀏覽器來進(jìn)行(Selenium，加上Firefox或者Webkit)很復(fù)雜的測試(因?yàn)闉g覽器的異步特質(zhì))?你的測試需要很多配置，很長的時間來執(zhí)行，而且很不可靠

4、慢，可以緩解，但沒有解決

我 們來考慮如果開發(fā)人員想在那個頁面添加新功能。是很難讓她的功能必須快速加載的-因?yàn)槎际钱惒降?，所以誰會在意頁面底部過了幾秒才加載呢?如此反復(fù)幾次， 整個站點(diǎn)讓人感覺滯后很抖動在server-side 應(yīng)用中，如果一個API調(diào)用很慢，整個頁面就會停滯直到徹底完成。這個不容忽視的server-side慢節(jié)奏很容易被測量并會公平地影響每一個人。但是 在client-side應(yīng)用中很容易被忽略。你可以說，一個好的開發(fā)團(tuán)隊(duì)?wèi)?yīng)該避免這些錯誤，并且client-side JS 框架不是罪魁禍?zhǔn)?。是的，client-side JS框架提高了速度。這一點(diǎn)改變鼓勵了任何開發(fā)團(tuán)隊(duì)

下一步?

上面說得都不是大問題。我們已經(jīng)做了很多來減輕上述情況。想了解更多Javascript教程知識可登陸e良師益友網(wǎng)。