你用AngularJS 做過項目後，下一個項目還用AngularJS嗎？

01-14

為什麼？有哪些絕對優勢？有哪些劣勢呢？

技術選型是不應當這麼看的，這個問題在我看來，等價於：你上一次是開車自駕出行的，下一次還會嗎？

很明顯這個關注點不合適，因為對於一次出行，你首先要考慮的是：

1 你去哪裡

2 去做什麼

3 能承受怎樣的成本

4 是否適合自駕

對應到一個Web前端項目，也就是要考慮：

1 這是一個什麼類型項目？（頁面型還是應用型，是否需要SEO）

2 給什麼人用的？（如果還要適應低版本IE，那不用想了）

3 不可否認，使用Angular對整體規劃能力需求較高，而且如果是不熟悉的人，搞出問題的概率很高，能否承擔？

4 團隊的現有技能如何，js技能偏弱的團隊用起來可能有些痛苦

如果上面這幾個問題都能慎重考慮到，都能回答適合的話，那使用Angular將會是一種很愉悅的體驗，並且，當你的項目規模增大的時候，更是如此。

優勢非常明顯：

分層導致業務邏輯特別清晰，在邏輯中不混雜視圖操作，UI層有很大自主權。

依賴注入導致組件化程度很高，可單獨測試，容易從整體上總覽所有模塊的依賴關係。

數據綁定導致上層代碼大量簡化，常規操作基本無需寫額外代碼。

劣勢主要是SEO方面，另外由於監控機制的實現方式，對於大數組和深層數據的綁定性能不夠高，這個可以通過一些細節優化來解決。

更細節的我在這篇里回答過：

AngularJS 有哪些優缺點？

下一個項目可以用 Vue.js，嗯

為了看上去不那麼像純廣告，和 Angular 對比一下：

Vue 的 directive、filter 等概念和 Angular 基本直接對應，但更加簡單一些。MVVM 的優點是共通的。最大的不同在於 Vue 是完全的 Component-oriented，即視圖完全由組件樹構成，提供近似於 Web Component 的開發體驗。Angular 1.x 沒有專門的 component 概念（近似於帶 controller 的 directive，但概念模糊），而 2.0 則 API 完全天翻地覆，而且看上去更加複雜。
Angular 的數據綁定是 dirty checking，應用整體性能受制於 watcher 的數量，而 Vue 是真正的 dependency tracking，頁面上 watcher 的數量多少隻影響初始化速度，不影響視圖更新時的性能。
Angular 自帶的模塊/DI系統和其他模塊系統重複，Vue 本身基於 CommonJS 構建，對於 AMD 也有很好的親和度。
相對 Angular，Vue 更專註於視圖層面，不對項目的結構做太多約束，也不包含路由 / ajax 方面的功能（但與第三方庫整合極其方便）。可以說用 Vue 的時候你需要做更多整體架構上的決定，但相對的也給你更多的靈活性。從定位上來說 Vue 和 React 更加類似。

可以改用 avalon.js 。

支持IE6及移動端；

性能上有優勢，angular只能撐到2000個指令，avalon達到14000個以上；

有核心帶薪的團隊在開發維護 http://ued.qunar.com/

有一整套UI庫（近50個組件，包括一個驗證框架，兩個GRID，一個樹） https://github.com/RubyLouvre/avalon.oniui

有完善的單元測試 RubyLouvre/avalon.test · GitHub

有各種教材

avalon學習教程
Avalon Learning
迷你MVVM框架 avalonjs 入門教程
前端MVVM的應用-UnitedStack.ppt
avalon最佳實踐
搜索 - 騰訊視頻(《avalon探索之旅》系列視頻教程)

更重要的是，已經有許多公司在用，框架注重向前兼容；有一個小社區，有什麼不懂的地方可以發問， QQ:79641290(註明來學avalon)

G 公司做前端的項目，大家看看過往比較出名的吧：closure、GWT。

這與 G 公司的開發基因有很大的關係，包括大家可看看 G+ 有 JavaScript 有多大。

思路都是後端開發語言開發前端代碼（如 GWT）。

所以，最擔心的莫過， G 公司的 Angularjs 未來又走上當年 GWT 的路。

這是 Angularjs 最大的風險與缺陷。

題外話，Facebook 的「類似」項目更象是真正 frend-end based 的項目。

Angularjs其實不無腦寫啊，做大型項目的時候很容易就變得很複雜，狀態很多代碼很亂。

這裡就需要強大的代碼組織能力了，而且個人認為它本身的很多規則和約定並不是很合理啊（基於服務端開發的思維而不是基於圖形界面開發的思維），稍不注意controller和全局環境沒啥區別，都是什麼狀態各種需要就寫。

說拆分，拆得如何合理，可閱讀性可維護性如何提高，應用的狀態管理如何清晰，把這些都結合在一起在項目開發中都深思熟慮的話，所耗時間成本會更多。

也許在我看來是因為它沒有明確提供對視圖的模塊化方法，當然，可以直接把每個視圖模塊劃分到service 里，開發人者本身能把邏輯理得比較清晰，但對別的同時那就悲劇了，因為不同人的技術能力和思維方式是一樣的，除非已經能做到完全做好一個約定範式來組織代碼，當然對於一個團隊這是應該做到的。

Angularjs 還是不錯的，能讓一般的開發人員也能完成一個能執行的應用。

其實，還是看個人的功力吧…

合則用，不合則棄，就拿我現在的項目來說，pc對外管理平台用php+reactjs，pc對內管理平台是nodejs+angularjs，移動端就使用vue，完全沒有衝突。所以題主也不用這麼糾結，留點時間，多學幾門語言，多用幾個框架，多做幾個項目，自然就不會有這種困惑了

用 AngularJS 做過項目之後,,, 我就自己造了個叫 DropJS 的輪子... 囧. (好吧其實在用 AngularJS 之前就已經嘗試造過了).

這裡我假設題主問的是相對於不用 MVVM 框架有什麼優勢和劣勢, 而不是相對於其他 MVVM 框架有什麼優勢和劣勢.

絕對的優勢就是降低了耦合, 讓開發者從複雜的各種事件中掙脫出來. 舉一個簡單地例子, 同一個狀態可能跟若干個事件的發生順序與發生時的附加參數都有關係, 不用 MVC (包括 MVVM) 的情況下, 邏輯可能非常複雜而且脆弱. 並且通常需要在不同的地方維護相關度非常高的一些邏輯, 稍有疏忽就會釀成 bug 不能自拔. 使用這類框架能從根本上降低應用開發的邏輯難度, 並且讓應用更穩健.

除此之外, 也免去了一些重複的體力勞動, 一個 {value} 就代替了一行 $(selector).text(value), 一些個常用的 directive 也能快速實現一些原本可能需要較多代碼才能實現的功能.

劣勢就是,,, 有學習成本... 另外對 SEO 不是特別友好 (不過應該可以通過添加相關伺服器端方案改善). 性能上在某些場景可能也存在一些問題... 不過具體的不清楚哈哈哈, 還是自己實現的東西瓶頸在哪兒最了解了~

必須用，太順手

會。開發效率高，可以專註於業務邏輯，這就夠了，有啥不足也都是浮雲了。

會，寫的比以前愉快多了。

我第一個產品用的是angularjs，確實大幅度提高了效率(前端大量數據交互)。第二個產品打算採用avalon，原因比較自私，我不喜歡angularjs那種斷崖式升級(雖然1.x還維護)，而avalon(1.4)才5k+行，代碼全部看完，可以完全把控。對於其他庫的融入方面，更開放。當然，avalon先(獲取)定義後使用，對於習慣angularjs的人需要稍微注意一點，插值表達式也不如angular那麼強大(畢竟對方有完整的「編譯」能力)。

這問題並不應該被回答，該不該繼續使用angular完全取決於它能給你帶來的好處和所造成的問題。

angular是谷歌頂尖工程學的造詣這我想應該沒有太多人有異議，但是它非常谷歌。

它像做很多事情，試圖提供一個近乎完美的腳手架，思路，框架，甚至開發模型。

為此谷歌很少考慮如下：

1 其他開發人員的水平

2 水平造成性能問題

3 是否能合適的耦合問題

4 各種挖坑問題

SEO此類的我想這是谷歌需要改進他的檢索引擎而不是網站要去適配這東西，方向錯了，谷歌一定會做事。

為此，有些東西也許會比一個什麼都做的超神的公司要合適一點，比如臉書出的react和flux體系。

乍看起來在工程上和谷歌沒法比，什麼垃圾架構，整一個就是散件集中營。什麼垃圾命名，store action都是什麼鳥，亂糟糟。完全沒啥分層的概念

但人家好理解，使用方便，性能好。你說怎麼辦呢。

谷歌總是個放大招的公司，大家都習慣了。

我們需要大招，但我們也不是總需要大招，特斯拉死的很慘不是嗎？重要的不是好，而是合適。架構就干這事，但估計還有很多架構師沒理解。

適合才是最好的

咋一眼看angular覺得簡單, 用的時候才發現好難...

用Angular開發有一個問題就是$http請求 WTTL時間太長，至今找不到原因，求解救。

根據項目大小和需求選擇框架，移動端的話ng就算了，用zepto更好。pc端的話，如果不是spa，不是很需要雙向綁定，也用不著ng出馬，倒是想試試react，還沒實戰過react

還在學習angular的路過。。。框架不斷冒出來啊～斷網靜下心來學精一兩個先好了。。