自我描述一下，我大學畢業後自學java參加工作，leader要求我學會Angular，然後開始了一年半的開發，前後端都有寫過代碼，前端居多，使用Angular8/9。現在離職，準備跳槽拿一份更高的薪水，最近在家自學Vue和React，它們的一些用法，或者語法，讓我感覺有些不適。（希望不要用java程序員更喜歡Angular，或者Angular就是後端那一套這種答案來回答我，我認為不是這個原因，另外我只是個菜鳥，無法從底層深度去評價框架，只是覺得它們的語法/用法讓我不適）

先從Vue說起，其實一開始學Vue還是覺得挺不錯的，很多東西和Angular的用法很像，讓我產生嚴重排斥感的是Vuex：

  1. 首先，所謂狀態管理，也就是多組件共享變數，在Angular里直接創建一個service.ts文件就搞定，裡面直接寫你需要共享的變數和方法就可以，而Vue還需要安裝Vuex，裡面還分state，mutation
  2. 其次，Vuex的用法太奇怪了，取變數還好，但是當我要更新state里的變數，居然要用commit，如果有非同步更新還需要額外做一次action，還需要傳遞一個方法名字元串？這是什麼詭異的用法？
  3. Vuex可以分模塊，每個模塊里有各自的state，mutations，actions，在組件里要調用模塊里的state，就需要模塊的名字，而調用mutation或者action又不需要名字，也就是說它們是全局的，那就意味著不能出現重名，模塊的名字也不能和全局變數重名。我理解模塊化的思想，但是無法理解它的用法。

Vuex只是Vue的一個縮影，這半個月學下來，我覺得Vue的框架感，或者說規矩感太過濃重了，它規定了你數據要放在data里，方法要放在methods里，更新state需要commit，commit需要傳遞方法名，如果非同步更新需要額外dispatch一個action，調用模塊里的狀態有的需要模塊名，有的不需要，這些規矩，都需要人去遵守，去記憶。

React到現在我才學了兩天，但是這個JSX語法讓我甚至覺得比Vue還讓人不適，Vue是規矩性太強，但是它至少做到了html js css的分離，從結構上還是清爽的（雖然沒有做到文件上的分離），而JSX實在是讓我無語，從最初學前端老師就說style和script的三種引入方法，外部引入是最好的，可以解耦，JSX是在顛覆這種說法嗎？

最後說一下我覺得Angular對比它們的幾個讓人舒服的點：

  1. ts，css，html 徹徹底底的分離，Vue雖然也分離了，但還是放在了一個文件里的，而Angular中每一個component有它對應的html文件，ts文件，css文件，真的清爽
  2. 沒有亂七八糟的規矩，要求我必須把數據寫在哪個data里，方法寫在methods里，更新屬性還需要commit什麼的，都沒有。直接定義一個變數，直接用，直接修改，如果需要多個組件共享變數，就創建一個service.ts文件，把共享變數和方法放在service文件里就可以了
  3. 編輯器的支持很好，這一點真的是不對比不知道，用了vue和react，才發覺編輯器有多重要，webstorm或者idea對Angular的支持，甚至到了Java那種程度，就是你用了哪個變數或者方法，ctrl點擊一下就可以直接跳過去了
  4. 文檔，在我看來Angular&>Vue&>React

上面說了一大堆，我只是想問，你們用Vue和React的開發體驗到底是怎麼樣的，你們不會覺得不適嗎？Angular的開發體驗那麼好，為什麼國內用的人很少，國外好像也不是特別多呢？

首先的首先，Angular也有類似技術：ngrx,這只是一種近期以來web前端很流行的一種設計模式，不過確實侵入性很強，初學者很難理解。關於angular不溫不火的原因我覺得主要是因為Angular的受眾比較的尷尬

我來嘗試對前端開發歸個類，歡迎對號入座

  1. 切圖仔，切圖仔其實並不會太會前端開發，只是會單純的做一些靜態網頁，但是也常常被莫名歸類到前端開發中
  2. 三大框架嗤之以鼻，Jquery才是王者的開發，因為一直維護老項目，沒有興趣也沒有動力去研究三大框架

3. 沒接觸過老一代技術的三大框架初學者

4. 後端做前端的全棧

5. native做web的大前端開發者

6. 熟悉三大框架之一+原生js的開發者，熟手

7. 精通三大框架之一+原生js的開發者，經常給社區造輪子

8. 經歷過老技術，過渡技術以及現在最新技術的大佬，架構過不少項目

對於1-3的開發者而言，angular學習成本太高了，而且不太容易能理解

4-6的開發者而言，angular爽歪歪，特別是那些後端搞Java/C#的全棧，什麼IoC，service簡直就不用學，一看就懂，不過RxJS/ngrx也有很陡峭的學習曲線

對於7-8的開發而言，Angular侵入性太重了，不如自己控制靈活，但是做到最後和angular的功能最少也有60%的重複吧

最後的最後7-8一般負責選型，1-3幹啥都行，反正也不會，也懶得管，4-6隻能發表意見沒有啥話語權，所以。。。

占坑，上班了就來寫回答。

---華麗的分割線

作為一個資深三系框架搬磚碼農，我覺的這個問題我還是可以分享下個人看法，不喜勿噴。

首先，技術喜好是十分主觀的東西，你喜歡 NG，他喜歡 React 或者 Vue，當討論到 xx 框架為何比 xx 框架優秀這種月經問題的時候，很容易就會陷入到一種無休止的爭執中，但大部分觀點，無非是拿一個框架的優點，去比另外一個框架的缺點，大概就是這個樣子。其實你仔細想的話，你一直說一個框架多好多好，但另外一個人壓根就沒用過它，自然不會體會到你說的那些優點？換言之，你問題描述中所說的 NG 的優點，對於使用過人來說，懂的自然懂，對於沒用過的人來說，他們就不會懂。所以先回答樓主的第一個問題，用 React 和 Vue 的公司很多，不是你的問題，也不是其他公司的問題，而是很多其他客觀原因造成的：

  • Ng 2 正式發布的時間點落後於 React 和 Vue，同時學習門檻對於沒怎麼接觸過 OOP 的前端開發者來說，門檻較高，這還沒涉及 rxjs 之類的響應式編程的東西，所以國內用的人少是很正常的現象
  • Ng 2 和 Ng 1 在概念上，完全是兩個次元的框架，造成遷移成本較高，所以很多用 Ng 1 的公司可能至今還在用 1.5 或者 1.6 的版本，其實在之前，Ng 1 在國內是非常流行的，我接觸過的很多項目，都是用它來做的
  • 由於第一點的原因，國內的培訓機構，以及技術博主，肯定更傾向於投入時間和資源到 Vue 和 React 上面，畢竟用 Ng 2 的公司少，學的人自然也就少，我曾經在 SegmentFault 專欄寫過關於 Ng 的一些列文章，基本就沒什麼人看，但後來轉移到 React 和 Vue 上之後，瀏覽數相比較之前最少翻幾倍，一葉知秋，當時我就知道大概是個什麼情況了
  • 最後一點再說下題主個人的原因，你已經說了你有自學 java 的背景，同時題目描述也包含「希望不要用java程序員更喜歡Angular，或者Angular就是後端那一套這種答案來回答我」 這樣的描述，這足以證明，Ng 必然更受有服務端編程經驗的後端程序員的偏愛，因為它更加 OOP，雖然也不是太嚴格的 OOP，但相比較 Vue 和 React 足夠了，反過來說，沒有 OOP 概念的前端程序員必然更加排斥它

所以你能發現，Ng 在現在不那麼流行的原因，只是滾雪球沒滾過其他兩個框架罷了，雖然它足夠優秀和好用，我讀過小部分的源碼，能夠感受到 Ng 本身的架構和設計，都是非常先進和優秀的，只要你能夠熟練掌握 Ng，再回頭學習其他 mvvm 框架，你真的感覺和玩一樣。

然後我再來說幾點關於其他兩個框架的看法，算是幫助題主客觀認識另外兩個框架，而非有這麼多的偏見，就依次按你的描述來說就好。

先說 Vue：

  • 首先你排斥 vuex 的觀點是說狀態共享拿 service.ts 就能實現，但你有沒有仔細想過，vue 中也可以拿類似的方式實現，無非在於你需要手動把 service 導入到 SFC 文件中罷了，但這樣造成的問題是，service 和 SFC 文件耦合在了一起，而 Ng 中沒有這種強耦合性是因為它有 DI 機制，而 vue 是沒有的（其實也是有的，但沒有 Ng 那麼強大），所以為了更優雅地解決這個問題，才需要 vuex 來解決狀態管理的問題
  • 另一個方面，狀態管理這個訴求，是一個抽象的概念，其實現方式是不固定的，這意味著，你可能會寫一個 serviceA.ts，他可能寫一個 serviceB.ts，然後你倆做的事情實際上是類似的，這一定程度上造成了遷移成本，但如果開發者都共通遵守同一套開發模式，比如 vuex 提倡的這套，action/mutation/commit 等等，那麼遷移成本就小了很多，同理，對於各種命名規範，其所想達到的目的，也是這個，就是為了讓大家能夠更加順暢的合作，使項目的可維護性和遷移性更強。
  • 最後說下「我覺得Vue的框架感，或者說規矩感太過濃重了」，感覺這個有點沒說到點上，在我看來，Ng 可能才是框架感或者規矩感比較濃重的那個，你之所以覺的 Vue 或者 React 過於框架或者規矩，是因為 Ng 這種約定大於配置的理念，讓你置身於約束又不自知，如果連數據寫在 data 里，方法寫在 methods 這種語法層面的東西也算的約束的話，我覺的這有點抬杠了。

再說 React（感覺題主沒怎麼用過 React，就簡單說兩點吧）：

  • 首先，React 提倡的是 all-in-js 的開發理念，所以你能夠發現，它的模板是 jsx，它的 css 是各種 css-in-js 的實現方案，它們最終都要被編譯器轉化為 js 代碼，這在架構思想上，和 Ng 就不一樣，關於 template 和 jsx 孰優孰劣的問題，現在其實爭論也不少，我的觀點就是，蘿蔔青菜各有所愛吧
  • 實際上 React 中關於 style 的使用方式，完全可以使用傳統的外部引入 css 文件的方式來搞，很多流行的組件庫都是這麼搞的，並沒有使用 css-in-js 的方案

說了這麼多，大概就是這麼兩個建議：

  • Ng 很優秀，你有學習它和使用它的經驗，這不是你的問題，反而是優勢
  • React 和 Vue 本身也很優秀，你需要客觀地、不帶偏見地學習和認識它們，而不是排斥

我個人而言，比較看好 Vue，雖然我之前是一個 Ng 鐵粉，但經過幾次發布後，Vue 框架真的是越來越優秀了，足夠簡單，足夠好用，足夠強大，所以非讓我給個我心目中三大框架的排名，大概這個樣子：

  • Vue &>= Angular &> React

可是說這些有什麼用呢，發工資給我的還不是用 React 全家桶，算了，搬磚去了。（手動狗頭

首先，Angular是框架，而Vue和React是實現組件化的庫。從功能完備的角度框架和庫並不具備可比性。

所以從功能上對比Angular Component是與React和Vue解決相同問題的。

三大技術棧都從數據驅動的方式替代了上個時代以操作dom為核心的開發方式，只不過各個技術棧對數據的處理各不相同

  • Angular延續了Angular1的臟檢查機制，攔截了瀏覽器非同步api，在任務隊列的結尾檢查數據的變化以更新dom
  • Vue則通過定義對象的get，set方法監聽數據的變化，然後根據需要更新dom
  • React則更貼近函數式的方式，通過新的狀態生成新的dom

在Angular的架構中Service更適合編寫一些數據操作的邏輯，通過將這些邏輯脫離於Component實現，可以讓Component更專註於展示數據和響應用戶的交互行為，提高了組件的復用性，同時不同的Service處理不同的業務也讓Service之前也保持足夠的邊界。確實藉助Angular對DI的實現，Service可以以單例的方式緩存一些數據，但從設計上Service並不是做這件事的，所以可以發現在Angular官方的例子中使用了angular-in-memory-web-api作為數據緩存的方案。

在React和Vue中並沒有Service的概念，許多對數據的操作邏輯要麼寫在Component中，要麼寫在全局的狀態管理Vuex中，寫在組件中會降低組件的復用性，都寫在全局狀態中又讓全局狀態十分臃腫和繁瑣，該寫在哪從兩個庫的角度並沒有做限制和指導。相反的，從React的容器組件到Web hook，Vue的composition api都致力於將數據狀態剝離於組件，顯然二者更加關注組件本身。

Vue和React都很好解決了組件實現的問題，但沒有解決設計的問題，雖然Vue和React更易上手但如果沒有良好的架構設計，後面的維護工作將面臨更多挑戰。

隨著項目代碼越來越多，我們可以清晰的發現使用Angular開發應用更便於維護，這不僅僅是TypeScript的功勞，也因為Angular作為一個框架，其Component，Module，Service等功能架構設計意圖是完備的，在面對變化時更容易找到內置的方案，避免在項目膨脹的過程中對整個工程的架構設計的衝擊。

因為Angular的架構清晰，像對熟悉類似spring這樣同樣架構清晰的Java工程師來說自然更覺得親切。

技術沒有好壞之分，只有適合與否。短平快的項目，Vue、React更合適；長期的項目缺乏設計能力就使用Angular。

是你的問題。

我經常說一句話：程序開發首先是思想，然後才是敲鍵盤。

不同語言，不同框架，裡面蘊含的是不同思想。特別是當一個技術點處於爆發期，各種語言和框架層出不窮短兵相接的時候，百家爭鳴，百花齊放，思想的碰撞尤為強烈。最後思想會相互吸收、融合、沉澱，形成穩定的兩三家。

為什麼要有jQuery，因為jQuery的那個時代，他的思想能夠解決問題。

為什麼jQuery逐漸被淘汰了，然後出現了Angularjs、backbone、Ember？因為新的思想產生了。jQuery在新一批框架所秉承的共同思想下沒有他發揮的空間。

為什麼Google要壯志斷腕放棄自己的Angularjs，開始打造全新的Angular？而Facebook卻要開發React。另外有一個叫尤雨溪得人不認同Angular的發展方向，自己一個人出來干出個Vue？就是因為思想的上的衝突。道不同不相為謀，一個框架容不下不同思想，不同的道分別產生了自己的框架。

很多開源框架都是這樣，但凡思想上認同，只是覺得還不夠完美，就不會另起爐灶，而是會在原有框架上去貢獻。只有覺得起根想法上就不一樣，根本不能把自己的新想法貢獻在老框架上，才會有新框架出來。

什麼是「削足適履」？為了適應一雙不合腳的鞋，自己把腳削去一些。多難受，多痛苦...

你覺得Vue和React相比Angular用起來不那麼舒服，是因為你在削思想，為了去適應另外一撥思想不同的人寫出來的框架。

不僅僅是當前這個問題反應的前端框架，幾乎編程上的所有領域都是這樣。你要學會一項技術，必須首先認同這個技術背後所蘊含的思想，說白了就是發明這個技術的那波人到底是咋想的。

不同框架創始團隊的技術出身、工作經歷都會導致他們在新框架上所表達出來的不同思路。就好像你剛開始不認同一個人的觀點，硬著頭皮去理解也覺得這個人很怪。當你和他熟悉了之後，你了解了他是哪裡人，從小的家庭環境、生活環境是怎樣的，上學和工作的十幾年中遇到過什麼坎坷，你也許就能接受他現在的觀點，也能理解他現在為人處世的原則。

見過很多很多這樣的程序員。讓他們用一個新框架，他們一臉不情願，然後抱怨：這個框架不成熟！這個框架太爛！這個框架不適合我們的業務！

其實他就是抱著老框架的思想去用新框架，幻想著所謂的新框架和老框架一個套路，只是性能優化了一些，或者其他改變都發生在自己看不到體驗不到的地方。

林子大了什麼鳥都有，人多了什麼想法的都有，所以框架多了什麼套路的都有。你只用自己已經接受了思想的某一個框架去套用別的框架，就是削足適履。

所以，我說是你的問題。因為你用Angular的腳去適Vue和React的鞋。但好在思想不用削，思想是可以改變的。

終於找到了一個和我相同感受的，哈哈

寫了幾年AngularJs，和Angular後我同樣抗拒寫Vue，同樣抗拒使用Vuex。何況我所看到的Vue項目都是那麼雜亂無章，還美其名曰函數式編程；濫用Vuex，什麼東西都往裡面塞，把它當成萬能神器；缺少業務模塊劃分，缺少NgModule這一層設計

先佔坑後面補充。

推薦閱讀：
相关文章