AngularJS真的那麼完美？ angularjs幾點問題的詳細分析

先不說AngularJS優略，至少大部分前端工作者還是對AngularJS有著狂熱的推崇的。因為它使開發變得簡單。那麼問題來了，為什麼很多知名網站都沒用到Angular呢？一起來看這篇文章吧

我們就從幾點說起：

1、最糟糕的SEO友善性

這一點無疑是非常致命的，這造成了許多年輕的新創公司都輕易不敢嘗試的一個重要原因。搜尋引擎爬蟲和社交預覽截圖無法識別使用JavaScript渲染的頁面，而且現有的解決方案非常複雜，非常緩慢。

事實上，通常一個頁面的載入是由五部分組成的(拿java為例)：

1. 瀏覽器像伺服器發送Http請求

2. 伺服器針對這個請求進行處理得到結果數據，得到Jsp模板，將這些數據通過模板build成瀏覽器認識的html文本並發送給瀏覽器

3. 瀏覽器解析HTML文字並將頁面內容呈現出來

可以看出，最後一步當瀏覽器拿到html文字時，也就是這個流程結束的時候，我們需要的數據都會呈現出來了。而使用Angular的過程是這樣的:

1. 瀏覽器像前端伺服器發送Http請求

2. 前端伺服器發送HTML模板到瀏覽器

3. 瀏覽器解析HTML並執行js腳本，向業務伺服器發送Http請求

4. #伺服器針對這個請求進行處理得到結果資料將結果數據封裝成Json格式並傳送給瀏覽器

5. 瀏覽器解析Json並將資料呈現在頁面中

這兩個流程，一個是把頁面build的操作放到了伺服器中執行，一個是放到了瀏覽器中執行。這是最明顯的差別，先不說多出來的互動次數，單單從搜尋引擎眼裡來看的話，它只能看到瀏覽器拿到的靜態內容，它不會去執行你的js程式碼。

前者搜尋引擎看到的是一篇文章，後者搜尋引擎看到的是一個個的花括號！這也是為什麼Angular渲染的頁面會被列入百度‘黑名單’的原因。那麼如何解決呢？

引用一段話：

有兩種方法可以讓爬蟲造訪你的網站。你可以在你的伺服器端執行一個瀏覽器實例，然後根據JavaScript執行後的DOM產生HTML頁面。或者你另外建一套為搜尋爬蟲類準備的HTML靜態頁面。
前一種方案需要你安裝WebKit(也有可能是Xvfb)，然後在頁面加載完成以後生成頁面（你也可以使用緩存，但這增加了更多的複雜性。）這樣會增加你的頁面載入時間，從而影響你的搜尋引擎排名。
 後一種方案（製作另一個伺服器端網站），可以滿足簡單的網站，但是如果你的頁面非常多樣，這將是一個惡夢。而且如果你的備用網站跟你的主站完全不一致，Google會狠狠地懲罰你的，你的流量會直線下降。

2、最糟糕的使用者體驗

在使用AngularJS後，頁面的呈現方式被拆分為了多個過程，這樣如果我訪問一個頁面，而這個頁面的內容有比較多的時候，我會明顯的感覺到瀏覽器的渲染過程，我有太多的內容要加載，這個過程是非常糟糕的，尤其是將加載過程放到客戶端的時候，它的延遲會非常大。

在富JavaScript應用程式中，頁面轉換通常是立即發生的，然後從伺服器上載入不同的元素。在伺服器端應用程式中，頁面沒有等到客戶端把全面資料下載完，就開始呈現資料。

聽起來像是客戶端的應用好一些，但實際上這是個假象。
想像一下，當使用者點了一個鏈接，客戶端的JS應用程式馬上出現了一個載入動畫，但這些資料需要載入５秒鐘。應用程式只是第一眼看起來快了，
先不討論有多少程式設計師想要在這一個頁面上添加功能。你很難要求人家必須透過非同步的方式很快的將內容呈現出來，其實頁面下面的東西晚一點加載出來人家也是不會關心的。

在伺服器端的應用程式中，如果一個API呼叫很慢，整個頁面的載入就變慢了。你無法忽視服務端的慢，因為他會影響到每一個人。但是客戶端的慢很容易被忽略。

你可以很輕鬆的解決掉服務端的慢，因為服務端是可控的，是在你配置的機器上運行的，你可以清楚的知道在這台機器上發生了什麼。而且服務端大都是在一個內部的集群網路中，這使他們之間的訊息傳遞非常的快，即使一個動作需要多次的訊息傳遞也可以在一瞬間完成。但是把這些傳遞放在客戶端的話會有諸多因素拖慢它的速度。
我們不能嚴格控制使用者使用什麼瀏覽器、也不能控制使用者機器的配置，但是我們可以控制自己伺服器的一切。

3、最重要的太過雞肋

雞肋？有人會說，AngularJS的各種好處，例如『易於維護』、『編碼方便』等等。但這是建立在犧牲效能和使用者體驗的前提下的。而所謂的『依賴注入』等後端的思想強行引到前端中來，這樣做看起來高大上了，但似乎哪裡不對？後端分架構、拆服務，以及使用各種框架等等，是為了更簡單的開發，而web前端，本身體現在瀏覽器中的就是HTML文字而已，它本身就是個靜態的、且不涉及業務的東西，我更認為他這麼做沒什麼實質的幫助。

從這些方便，或許不能說雞肋，但是，在任何場景下，幾乎都有一種方案可以完美的取代AngularJS，並且做的比它還要好。這。 。 。這就尷尬了！例如freemaker。

freemaker大家不會太陌生，它可以直接呼叫Java提供的freemakerApi函數，而不是透過ajax去執行http請求非同步取得資料。同樣，他的性能同樣也玩爆AngularJS 或許和它比性能有點兒欺負人了，但是同樣作為一款模板引擎而言，freemaker的確有資格在性能上碾壓AngularJS。

在易用上，freemaker除了可以直接呼叫Java函數以外，依然也可以透過http來取得數據，但他會把獲取出來的數據統一build成html文字後再交給瀏覽器去解析，最重要的是，他也支援依賴注入等相關特性，並且和後端程式完美結合，結合以上幾點，不管是從擴展性、可維護性、整體性能、用戶體驗等方面來說，都是碾壓了AngularJS。而唯一比不上AngularJS的，則是開發階段了。 freemaker開發相對於angular而言，更複雜一些，或者說angular相對而言，在開發過程中要簡單得多，如果僅是因為開發變得愉快而大量的捨去諸多性能方面的因素的話，這是非常可怕的，一部分人在追求性能的機制去不停的優化，一部分人為了更簡單的開發去優化，這不能說誰對誰錯，但我更偏向前者。

拋開freemaker不談，在nodejs中童同樣有大量的可取代的解決方案同樣有大量的mvc框架，這裡就不多講了。

我認為在瀏覽器中的js的作用更多的應該放到互動中去，而不是內容體現中，那不是正確的解決方式。

4、應用場景問題

AngularJS在前後端分離的場景中看起來是個不錯的選擇，但上面說了，在前後端分離時，AngularJS考慮的太過狹隘，我們分離後，除了開發變得方便了，但失去了原有的性能和體驗，這無疑是失敗的，結合這些原因，或許可以使用AngularJS的場景幾乎非常少了，但似乎在後台（後端管理控制面板）、WEBApp這兩個場景可以使用。

那麼問題來了，開發管理控制台頁的確不需要對效能考慮太多，也不需要針對SEO做最佳化，但同樣這個場景中的中點是在互動上，而不是內容展示上。 AngularJS作為一個前端模板引擎，他失去了他的定位。他的作用發揮的微乎其微了，這很尷尬。

而在開發WebApp時，她或許不用考慮SEO，對效能而言，App框架可以對效能做最佳化，因為我可以嚴格的控制使用者使用的客戶端版本。我可以選擇App框架 ，但既然可以自己選擇App開發框架了，那麼任何一種App框架幾乎都有超越AngularJS的方案，無論是性能和易用性上。所以這似乎比開發管理控制台頁面更糟。

綜合這幾點，我認為AngularJS的地位就很尷尬了。

而唯一沒有衝突的場景，可能就是體現在開發企業內部應用程式的場景上了。

這或許就是為什麼AngularJS看起來似乎很棒，卻很少有企業去選擇。追求性能是每個程式設計師都應具備的，尤其是從事後端開發工作的，他們考慮的會更多，不可能為了看起來開發方便而放棄體驗。如果真的放棄了的話，還分什麼國中高？哪裡還來的架構師？一堆代碼磋商去就開搞罷了。

同樣，這也造成了一些前端工程師面試時的尷尬：

問：會用AngularJs嘛？ 
 答：會！呃。 。但沒怎麼用過。 。但我真的會。 。呃

先不說AngularJS優略，至少大部分前端工作者還是對AngularJS有著狂熱的推崇的。因為它使開發變得簡單。那麼問題來了，為什麼很多知名網站都沒用到Angular呢？
下面我從幾點說起：

1、最糟糕的SEO友善性

這無疑是非常致命的，這造成了很多年輕的創業公司都輕易不敢嘗試的一個重要原因。搜尋引擎爬蟲和社交預覽截圖無法識別使用JavaScript渲染的頁面，而且現有的解決方案非常複雜，非常緩慢。

事實上，通常一個頁面的載入是由五部分組成的(拿java為例)：

1. 瀏覽器像伺服器發送Http請求

2. 伺服器針對這個請求進行處理得到結果數據，得到Jsp模板，將這些數據通過模板build成瀏覽器認識的html文本並發送給瀏覽器

3. 瀏覽器解析HTML文字並將頁面內容呈現出來

可以看出，最後一步當瀏覽器拿到html文字時，也就是這個流程結束的時候，我們需要的數據都會呈現出來了。而使用Angular的過程是這樣的:

1. 瀏覽器像前端伺服器發送Http請求

2. 前端伺服器發送HTML模板到瀏覽器

3. 瀏覽器解析HTML並執行js腳本，向業務伺服器發送Http請求

4. #伺服器針對這個請求進行處理得到結果資料將結果數據封裝成Json格式並傳送給瀏覽器

5. 瀏覽器解析Json並將資料呈現在頁面中

這兩個流程，一個是把頁面build的操作放到了伺服器中執行，一個是放到了瀏覽器中執行。這是最明顯的差別，先不說多出來的互動次數，單單從搜尋引擎眼裡來看的話，它只能看到瀏覽器拿到的靜態內容，它不會去執行你的js程式碼。

前者搜尋引擎看到的是一篇文章，後者搜尋引擎看到的是一個個的花括號！這也是為什麼Angular渲染的頁面會被列入百度‘黑名單’的原因。那麼如何解決呢？

引用一段話：

有兩種方法可以讓爬蟲造訪你的網站。你可以在你的伺服器端執行一個瀏覽器實例，然後根據JavaScript執行後的DOM產生HTML頁面。或者你另外建一套為搜尋爬蟲類準備的HTML靜態頁面。
前一種方案需要你安裝WebKit(也有可能是Xvfb)，然後在頁面加載完成以後生成頁面（你也可以使用緩存，但這增加了更多的複雜性。）這樣會增加你的頁面載入時間，從而影響你的搜尋引擎排名。
 後一種方案（製作另一個伺服器端網站），可以滿足簡單的網站，但是如果你的頁面非常多樣，這將是一個惡夢。而且如果你的備用網站跟你的主站完全不一致，Google會狠狠地懲罰你的，你的流量會直線下降。

2、最糟糕的使用者體驗

在使用AngularJS後，頁面的呈現方式被拆分為了多個過程，這樣如果我訪問一個頁面，而這個頁面的內容有比較多的時候，我會明顯的感覺到瀏覽器的渲染過程，我有太多的內容要加載，這個過程是非常糟糕的，尤其是將加載過程放到客戶端的時候，它的延遲會非常大。

在富JavaScript應用程式中，頁面轉換通常是立即發生的，然後從伺服器上載入不同的元素。在伺服器端應用程式中，頁面沒有等到客戶端把全面資料下載完，就開始呈現資料。

聽起來像是客戶端的應用好一些，但實際上這是個假象。
想像一下，當使用者點了一個鏈接，客戶端的JS應用程式馬上出現了一個載入動畫，但這些資料需要載入５秒鐘。應用程式只是第一眼看起來快了，
先不討論有多少程式設計師想要在這一個頁面上添加功能。你很難要求人家必須透過非同步的方式很快的將內容呈現出來，其實頁面下面的東西晚一點加載出來人家也是不會關心的。

在伺服器端的應用程式中，如果一個API呼叫很慢，整個頁面的載入就變慢了。你無法忽視服務端的慢，因為他會影響到每一個人。但是客戶端的慢很容易被忽略。

你可以很輕鬆的解決掉服務端的慢，因為服務端是可控的，是在你配置的機器上運行的，你可以清楚的知道在這台機器上發生了什麼。而且服務端大都是在一個內部的集群網路中，這使他們之間的訊息傳遞非常的快，即使一個動作需要多次的訊息傳遞也可以在一瞬間完成。但是把這些傳遞放在客戶端的話會有諸多因素拖慢它的速度。
我們不能嚴格控制使用者使用什麼瀏覽器、也不能控制使用者機器的配置，但是我們可以控制自己伺服器的一切。 （想看更多就到PHP中文網AngularJS開發手冊中學習）

#3、最重要的太過雞肋

雞肋？有人會說，AngularJS的各種好處，例如『易於維護』、『編碼方便』等等。但這是建立在犧牲效能和使用者體驗的前提下的。而所謂的『依賴注入』等後端的思想強行引到前端中來，這樣做看起來高大上了，但似乎哪裡不對？後端分架構、拆服務，以及使用各種框架等等，是為了更簡單的開發，而web前端，本身體現在瀏覽器中的就是HTML文字而已，它本身就是個靜態的、且不涉及業務的東西，我更認為他這麼做沒什麼實質的幫助。

從這些方便，或許不能說雞肋，但是，在任何場景下，幾乎都有一種方案可以完美的取代AngularJS，並且做的比它還要好。這。 。 。這就尷尬了！例如freemaker。

freemaker大家不會太陌生，它可以直接呼叫Java提供的freemakerApi函數，而不是透過ajax去執行http請求非同步取得資料。同樣，他的性能同樣也玩爆AngularJS 或許和它比性能有點兒欺負人了，但是同樣作為一款模板引擎而言，freemaker的確有資格在性能上碾壓AngularJS。

在易用上，freemaker除了可以直接呼叫Java函數以外，依然也可以透過http來取得數據，但他會把獲取出來的數據統一build成html文字後再交給瀏覽器去解析，最重要的是，他也支援依賴注入等相關特性，並且和後端程式完美結合，結合以上幾點，不管是從擴展性、可維護性、整體性能、用戶體驗等方面來說，都是碾壓了AngularJS。而唯一比不上AngularJS的，則是開發階段了。 freemaker開發相對於angular而言，更複雜一些，或者說angular相對而言，在開發過程中要簡單得多，如果僅是因為開發變得愉快而大量的捨去諸多性能方面的因素的話，這是非常可怕的，一部分人在追求性能的機制去不停的優化，一部分人為了更簡單的開發去優化，這不能說誰對誰錯，但我更偏向前者。

拋開freemaker不談，在nodejs中童同樣有大量的可取代的解決方案同樣有大量的mvc框架，這裡就不多講了。

我認為在瀏覽器中的js的作用更多的應該放到互動中去，而不是內容體現中，那不是正確的解決方式。

4、應用場景問題

AngularJS在前後端分離的場景中看起來是個不錯的選擇，但上面說了，在前後端分離時，AngularJS考慮的太過狹隘，我們分離後，除了開發變得方便了，但失去了原有的性能和體驗，這無疑是失敗的，結合這些原因，或許可以使用AngularJS的場景幾乎非常少了，但似乎在後台（後端管理控制面板）、WEBApp這兩個場景可以使用。

那麼問題來了，開發管理控制台頁的確不需要對效能考慮太多，也不需要針對SEO做最佳化，但同樣這個場景中的中點是在互動上，而不是內容展示上。 AngularJS作為一個前端模板引擎，他失去了他的定位。他的作用發揮的微乎其微了，這很尷尬。

而在開發WebApp時，她或許不用考慮SEO，對效能而言，App框架可以對效能做最佳化，因為我可以嚴格的控制使用者使用的客戶端版本。我可以選擇App框架 ，但既然可以自己選擇App開發框架了，那麼任何一種App框架幾乎都有超越AngularJS的方案，無論是性能和易用性上。所以這似乎比開發管理控制台頁面更糟。

綜合這幾點，我認為AngularJS的地位就很尷尬了。

而唯一沒有衝突的場景，可能就是體現在開發企業內部應用程式的場景上了。

這或許就是為什麼AngularJS看起來似乎很棒，卻很少有企業去選擇。追求性能是每個程式設計師都應具備的，尤其是從事後端開發工作的，他們考慮的會更多，不可能為了看起來開發方便而放棄體驗。如果真的放棄了的話，還分什麼國中高？哪裡還來的架構師？一堆代碼磋商去就開搞罷了。

同樣，這也造成了一些前端工程師面試時的尷尬：

問：會用AngularJs嘛？  

 答：會！呃。 。但沒怎麼用過。 。但我真的會。 。呃   

這篇文章到這就結束了（想看更多就到PHP中文網AngularJS使用手冊中學習），有問題的可以在下方留言提問。

以上是AngularJS真的那麼完美？ angularjs幾點問題的詳細分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！