如何評價大漠窮秋的文章《Angular有哪些地方比Vue更優秀？》?

01-11

今天朋友推薦了一篇專欄，看了一下大吃一驚，如題，正文鏈接：Angular有哪些地方比Vue更優秀？
後續：
@大漠窮秋：為什麼只會Vue的都是前端小白？
@尤雨溪：回應『Angular有哪些地方比Vue更優秀？』

每個框架的使用者中，都有一些層次偏低但是特別喜歡挑事，又總是分不清充分，必要等條件，討論問題不貼代碼只起鬨的人。

我們爭論一些東西是為了探討對業務問題更優雅的解決方式，為了讓更多的人更便利地完成自己的工作，更容易協作，開發出更好的產品，不是為了黨同伐異，所以各方都克制一下比較好。

我想說的是，各框架的資深使用者，貢獻者，佈道師們不要被他們挑起情緒，互相攻擊。各框架解決的問題大體差不多，面對的領域也一樣，所使用的基礎環境又差不多，背後所依據的理論基礎更是透明公開，所以都是大同小異。

我個人，幾種東西都深度使用過，對每個東西的優點缺點都評價過，優點會不吝讚美，缺點也會狠命黑，黑大部分東西的時候一般都會帶論據。

很多人都知道我對一些東西帶有傾向性，也發生過某些事情，但基本上沒有因為這些而影響跟同行的交流。

現在我在螞蟻，主要技術棧是 React，但這並不影響我繼續關注其他幾個方向的進展，也在努力嘗試解決業務開發人員可能遇到的一些困擾。

記得剛入職那天， @偏右看到我，第一句話是：我不想吵架，吵架請找承玉。

後來我反思為什麼會給人帶來這樣的誤解，這應該來源於去年那場爭議，這件事也讓我後來每次談論一些觀點的時候，都儘可能更加詳細，並附帶一些例子。

國內的前端社區，其實是有機會更好的，聰明人很多，但也有很多不貢獻代碼，不翻譯文檔，不科普知識的人熱衷於挑事，恨不得天天看到大家打起來，這到底有什麼好處呢？打起來能讓你水平變高？工資翻倍？早點下班？

我覺得有些太極端的低水平用戶，大家就不要理了，每個框架的使用者里都有，大家要意識到，把時間花在跟這些人吵架上是沒有任何價值的，就算你說得有道理他也不會聽，有這時間，大家繼續按照自己的想法完善代碼，文檔，或者快些完成工作，早點下班不好嗎？

封神演義第七十五回，不知道大家看過沒有。資深開發者更應該克制，盡量擺事實，講道理，不要被有些人起鬨，害人害己。

有時間我也寫點最近對當前各類框架的思考，與大家共同進步。

@尤雨溪 @大漠窮秋

Vue的開發者應該都看過Vue的官方文檔中的這一段對比其他框架。

這裡和react, ng等主流框架都有對比。摘抄幾段：

React 社區為我們準確進行平衡的考量提供了非常積極的幫助，特別感謝來自 React 團隊的 Dan Abramov 。他非常慷慨的花費時間來貢獻專業知識來幫助我們完善這篇文檔。
React 社區在狀態管理方面非常有創新精神（比如Flux、Redux），而這些狀態管理模式甚至 Redux 本身也可以非常容易的集成在 Vue 應用中。
React 和 Vue 在大部分常見場景下都能提供近似的性能。通常 Vue 會有少量優勢，因為 Vue 的 Virtual DOM 實現相對更為輕量一些。如果你對數據感興趣，可以參考這個專門測試渲染和更新性能的第三方跑分。注意這個跑分並不包含針對大量複雜組件樹的情況，因此只建議作為參考。

兩者另一個重要差異是，Vue 的路由庫和狀態管理庫都是由官方維護支持且與核心庫同步更新的。React 則是選擇把這些問題交給社區維護，因此創建了一個更分散的生態系統。但相對的，React 的生態系統相比 Vue 更加繁榮。
最後，雖然 Vue 和 TS 的整合可能不如 Angular 那麼深入，我們也提供了官方的類型聲明和組件裝飾器，並且知道有大量用戶在生產環境中使用 Vue + TS 的組合。我們也和微軟的 TS / VSCode 團隊進行著積極的合作，目標是為 Vue + TS 用戶提供更好的類型檢查和 IDE 開發體驗。

在這裡面，全篇沒有像「可憐巴巴」、「天坑」、「抄得沒有那麼快了」、「就是一個新手工具」....類似這樣的攻擊性辭彙，都是基於事實、performance test和客觀態度來說話，也不避諱去讚揚對手的優點。這種對比才是中肯的，也是作為我們開發人員願意去看到的。

我相信這是題主的個人所為，實際上這篇文章是在給angular團隊的大神們臉上抹黑（我覺得他們不會屑於用這種方式來宣傳ng的優秀），效果適得其反。如果題主能代表angular團隊的話...那麼這樣真的有失一個「世界級前端框架」的風範。

我曾經問過我的老闆和Angular團隊的負責人這樣一個問題：在中國國內的網路上經常出現針對Angular的討論，有一些內容非常偏激，甚至可以說【惡毒】，作為Angular在國內推廣的負責人，我可以去和這些人針鋒相對嗎？
我的老闆是這樣跟我說的：「戰勝」競爭對手不是Angular團隊的目標，我們的目標是幫助開發者和企業更好地開發面向未來的WEB應用。
很平常的一句話，但是給我留下的印象非常深刻，因為我看到了一個全新的角度，原來他們是這樣去思考問題的。
反觀國內的很多技術討論區，很多情況下會非常快速地陷入人身攻擊和胡扯的境地，給人的感覺就像潑婦罵街一樣。尤其是前端社區，越來越像娛樂圈。

所有的參與者，包括提問題的人，請你們安靜一秒鐘，仔細想想，你自己想要什麼？在口水戰中戰勝對手能幫助你提高編碼技巧，還是能幫助你提高認識世界的高度？

知乎用戶：為什麼vue的高仿項目層出不窮，而React和angular卻很少？

其實大漠說的那幾個問題我在初次使用vue的時候也遇到了比如打包工具和非同步載入，但是通過簡單的文檔查詢和調試很快就解決了，並不是說算絕對的缺陷，而是框架本身的理念是不做這些額外的事，當然也可以反著說這是玩具的體現。我是在第一次使用的時候就關注到這兩個點了，我相信大漠老師還沒有真正的開始編寫複雜的vue項目，比如實際的編寫了超過500個，哦不對，50個吧，複雜的vue模塊，可能遇到的隱藏的坑會更多，組件之間通訊和vuex大漠老師都沒有說，應該是還沒有使用到，槽點應該也能寫一篇長文了，雖然大家都說vue上手簡單；但是都有一個熟能生巧的過程。

至於ts和ea6我還是覺得說得很對，但是我還沒有遇到過大型項目要在編譯階段來優化到底好處有多少這麼一個層次。所以我也覺得說ng和vue體積的事也是不對的。一張圖可能某些時候都比一個js類庫要大好多倍，所以在4g已經這麼nb的今天，這些體積大小的比較和收益都微乎其微。所以不要再黑ng體積大了，況且也並不是真的特別大。

團隊的問題我是認同的，但是其實大漠老師有一個致命的深層次的vue能這麼火爆的理由沒有看透。

使用vue的同學更喜歡養成一個框架的感覺，因為就像大漠老師說的一樣很多東西需要自己動手，社區解決。

使用ng的同學更喜歡開箱即用和強大的官方支撐，就像我們在開發一個web程序的時候什麼都沒幹，環境代碼就上萬了。這個情況我們都在java開發上的許多框架體會到了。

我使用過的第一個mvvm框架也是ng，不過是1.x。總的來說react，vue，ng的使用水平上我都屬於一個菜鳥，但是應該大家都能得到一個共識，框架的初衷就是解決某一單一領域的痛點和需求。大而全是一個賣點，簡而美也是。最終到底這三個框架哪個笑到最後都不是我想看到的，因為沒有競爭就沒有進步。

就語言用詞上來說，大漠老師說的還是有失偏頗，畢竟坦克車也好，玩具車也好，在公司里可以幫助大家穩定上分，少加班，早下班的都是好車。@clancyz的觀點我很同意，有失大師風範，不過vueconf啥的我也沒參加，太貴了…

並不知道是什麼梗，感覺都是土豪們的遊戲…（開玩笑，我只是反諷……

@大漠對不起他id太長了… 兄弟們一起玩耍…

看了下 @大漠窮秋的項目，有幾個點很有意思:

大漠窮秋/NiceFish - 碼雲

1. http://git.oschina.net/mumu-osc/NiceFish/blob/master/src/tsconfig.json 項目裡面的 tsconfig 是沒有開 strict: true 的，在工程上這幾乎意味著 ES5 時代寫 JavaScript 寫代碼不加 "use strict"

2. 雖然項目看起來是有 lint 的，但是 http://git.oschina.net/mumu-osc/NiceFish/blob/master/src/app/post/post-detail/services/post-detail.service.ts 這種格式明顯錯亂的文件有很多，可見 lint 明顯沒生效 (注，這個文件裡面 Partial import RxJS 的方式是錯的，切勿模仿)

3. 雖然我沒寫過幾天 Angular ，但是 http://git.oschina.net/mumu-osc/NiceFish/blob/master/src/app/post/post-detail/post-detail.component.ts#L27 這裡 Observable 的用法明顯是錯的。如果一個 Observable 是 map 自一個請求或者任何 lifecycle 裡面需要 cancel/off/unsubscribe 的東西，在任何框架裡面訂閱了它就應該在合適的時機取消訂閱，來達到 cancel/release memory 的目的，不然請用 Promise。我不知道 Angular 生態裡面應該如何消費 Observable，但好歹用 async pipe 都比這樣優雅的多。

4. 翻了好半天沒有看到一行單元測試，或者是集成測試

5. http://git.oschina.net/mumu-osc/NiceFish/blob/master/src/app/post/write-post/write-post.component.ts#L66 http://git.oschina.net/mumu-osc/NiceFish/blob/master/src/app/jsplumb-demo/jsplumb-demo.component.ts#L13 這裡基本上就是在瞎搞了，即使換成 Angular 10 這種代碼也是無可救藥的。

不知道大漠老師是不是忙於寫文章沒有時間維護這個項目，才導致工程化方面亂七八糟的。

所以啊，能不能寫出功能，工程化做的好不好，代碼優不優雅真的跟用什麼框架技術語言關係不大。

你們知道他在 Google 的工作就包含推廣 Angular 的話，就可以理解了嘛。

有很多東西一個事實可以從兩面去理解的，那麼人家面向自身需求或是面向工資去理解我們都是可以接受的。但是如果歪曲事實去攻擊競爭對手，那就很 low 了。比如大漠窮秋老師之前在文章中就曾經對「VueConf」的某個講師的一句「Angular 沒人用」表示非常憤慨。具體他自己的文章里有沒有類似的地方，文章評論里大家都能看見。

看著大家都在推崇自己不喜歡的技術，如果是我我也不爽啊，何況自己還背負了工作職責，那麼寫出這類的文章是很理所當然的。從傳播性（你看這不都有題主這個問題了么……）來看，遠遠要高於《Angular 有哪些優秀之處》，對於不了解不偏向 Vue 的受眾會有一定的正向效果，雖然會引起 Vue 社區的反感，但是你們這些人本來就不會用 Angular 的我管你們幹啥不是么……

白天看到文章那個，晚上回來冒個泡來蹭個熱點…哈哈哈

說實話文章如果不是大漠窮秋老師寫的，我真的以為是哪個為了黑而黑的作者來專門寫來給新手增加吐槽話題的…

先扔結論：目前文章里所說的angular的優勢，換個角度來說，都可以稱之為angular的劣勢

一：打包工具

vue-cli要做到@angular/cli這麼完善基本上沒有可能，因為人力和資金都夠不上。也正是因為vue-cli是如此簡陋，導致很多日常開發必備的功能都需要開發者自己去下載配置第三方的Node模塊。

噢，這裡要特別提一下，@angular/cli的底層集成了webpack，Angular項目組在此基礎上做了自己的封裝，如果你有興趣去看@angular/cli的源代碼，應該已經發現了這一點。

面對種類繁多的@angular/cli 命令，新手頭暈眼花是一定的，老手也不見得能記得住這些都是什麼。

就如同當年的yeoman，有無數多的模板，但是我卻愣是找不到我需要的那個，挨個試完，發現沒有一個能夠完全match我的項目的，最後還不是找一個形似的再改…

而vue-cli雖然很少，但是配合極少數但是目的比較明確的template list，我能快速的招到一個差不多的然後根據項目需求進行二次配置。

以及上面所說的，@angular/cli 底層集成了webpack，實際上是封裝簡化了很多webpack config的內容，當我發現官方提供的配置項無法滿足我需求的時候，就會非常麻煩：簡化了的那部分配置恰恰在某些特定場景下就是我需要的

二：非同步載入模塊

我用vue的第一天，在路由層進行code spliting就是一個基礎中的基礎，而且官方vue-router文檔早就寫明了：Lazy Loading · GitBook 。

PS：在vue 0.12.x之前，的確沒有官方vue-router的實現，所以一般也都是建議配合其他路由庫+組件的非同步載入來實現路由，當時這塊並沒有在vue官方文檔寫過，但是在issue里是可以找到當時尤大的建議的。

文中只列舉了vue非同步組件的載入方式，卻並沒有將vue-router中的說明拿出來解釋

且vue的非同步組件從最早就是基於Promise的實現，所以現在完全可以無縫切換到動態import的語法上。根據我一直以來的經驗，不管是從最原來基於require.js的非同步載入，還是基於webpack的require.ensure，還是現在的動態import，我都是可以清晰的知道我寫的這部分是非同步組件，反觀ng中的寫法，是自己給定的api，那麼這塊是否還會涉及到一個學習成本的問題

綜上，並沒有覺得非同步載入模塊ng比起vue有明顯的優勢，甚至站在寫法上來說，我反而覺得ng的寫法不那麼容易接受

三：單元測試和集成測試

這一點上大漠窮秋老師寫的我算比較認同

雖然我一直以來的團隊沒有做過集成測試相關的，但是對於單元測試這一塊來說，vue的確有一定程度上把複雜度交由開發者了。

但是就如同第一點裡面說的一樣，這一點上我們團隊在unit test的時候，基本是二次開發vue-cli模板解決了，並且並不算是什麼太難的工作，基本方式也是如同ng里提供的，組件與單測文件在同目錄下以命名方式進行區分。並且我想在大多數較成熟的團隊里，也都會有自己的一套單元測試編寫規範的

四：Typescript

Typescript來說vue之前的支持是稍微弱一些，但是現在並不是了：TypeScript Support — Vue.js

以及，到底要不要使用ts，這一點實際上是跟項目複雜度息息相關的，當我寫一個不那麼複雜的SPA的時候，TS可能反倒是劣勢（主要在於類型聲明以及團隊內部的推廣）

五：AOT and TreeShaking

這兩者都不屬於ng獨有的，在基於vue的項目中一樣可以使用，這點上可能ng的優勢就在於構建工具直接集成吧

六：團隊

這個…說句稍微風涼點的話，Google棄坑的項目還少么…不知道為什麼很多人總是對於大公司背書這件事有謎之熱愛。當年jQuery還是John Resig一人寫的呢，最後還不是成功成為使用率最高的js庫，且現在vue也有自己的核心開發團隊，並沒看到這點上ng的優勢在哪裡…且單人支柱型的模式，其實更能保證框架設計上的一致性

————————————————————此處為分割線————————————————————————————————

所以對於網上這麼多「xxx比xxx牛逼」的文章以及口水文，我只想說，能不能不要在這麼出來嘩眾取寵了，每個框架都有自己的使用場景的好么！不要人云亦云的直接下結論，請都先使用下，並且理解其設計理念，適用場景之後再出來看。沒有一個框架是只有優點沒有缺點的！！！舉幾個簡單的例子：

1.傻瓜式 VS 精細式：vue的observe + watcher，可以在很大程度上幫我避免手動優化場景（對比React的shouldComponentUpdate），但是在某些重數據展示/交互的組件，比如一個複雜的可編輯表格，這時候為了達到更高的性能，我就需要小心翼翼的避免watcher被收集，以此來繞過vue的render執行以及vdom diff，而在react里，一個shouldComponentUpdate就解決了…

2.靈活 VS 大而全：在前公司跟客戶端團隊交流的時候，他們對於ng的接受程度就遠遠大於vue和react，理由是：我們寫東西，最容易接受的就是一個大而全的框架，以前寫Spring的時候就習慣了，最好啥都有，別管是不是最好的，反正別讓我自己去找一堆其他的東西來弄…這時候靈活性對於他們反倒是一種劣勢，以及他們當時算是一個新起的項目，所以完全可以沒有歷史包袱，隨意選用自己喜歡的適應的技術。但是當時我們團隊的項目是MVP結構的重構，直接上ng就只能把整個項目推翻了重來，而使用vue以模塊為力度進行進行遷移，不管是PM還是技術團隊內部，都是最被認可的方式，畢竟沒誰會讓你業務停幾個月來重寫。

再題外話，為什麼大家都說前端圈浮躁，還不是這類口水戰實在太多了…我見過的大大們，更多的都是分析現有業務需求，根據團隊技術喜好，選擇合適的框架，不管是ng還是react還是vue

脫離實際業務來說框架優劣，本身就沒有什麼參考價值，不是么~

貴圈真亂。我們不爭誰好誰壞了。

咱們招前端，有興趣的來簡歷：weihua.lwh@alibaba-inc.com 我們什麼都用。哦對了我是大漠（w3cplus.com）

手淘招人啦_w3cplus

有圖有真相

文章的作者列舉了一些觀點支撐標題，但實際上同樣能列舉很多觀點反駁標題。這就是作者的工作，希望尤雨溪不要和大漠窮秋去撕。寫代碼的和銷售撕什麼撕。

關於 webpack文檔，中英文混雜的部分，中槍了，解釋下吧。

首先組織翻譯是一件耗時耗力的事情，如果大漠窮秋願意接手，可以把這個維護文檔的絕佳機會讓給他。

然後，本人最近很忙，沒太多時間組織翻譯 webpack，然而中文和英文又要時刻保持同步，中英文混雜是必然的，總不能中文一月都不合併一次，合一次就有十幾二十個文檔的衝突。

第三，說下 webpack 文檔的情況，別人是國外英文區一堆人維護，我們這邊就是中文區核心成員幾個人在弄，沒看到大漠窮秋對中文文檔翻譯社區有什麼貢獻，在這裡指責是否不太合適？

第四，長期不合併是有一定的利弊權衡的，一方面，是 webpack 更新很快，今天的翻譯的文檔可能明天就被官方改的面目全非，設想這樣一種情況，我們基於官方文檔倉庫的某個git節點進行完整的中文翻譯，然而官方文檔倉庫早就改了幾百遍。那我們這個文檔就是錯誤的，因為用戶看到的中文文檔，代碼很可能遇到跑不通的問題。這樣的中文文檔有何意義？

覺得不爽可以不看，或者幫忙翻譯啊，總比沒有中文翻譯強吧。一堆小白能有 webpack 文檔看就不錯了，要什麼自行車，覺得不好可以給我們提 pr 改進。

最後，本人最近主要維護的兩個中文文檔，歡迎大家來提 pr：

vuefe/vuejs.org（在於改進 vuejs.org 中文文檔質量，如果你覺得我翻譯的不好，歡迎來提 pr）

webpack-china/webpack.js.org（中英文混雜的情況，就要靠大家的積极參与來解決了，如果你覺得自己nb，或者身邊有nb的小夥伴，歡迎來提 pr）

很明顯：為了推廣

只有撕扯框架的對比才能引起各陣營支持者的發聲

然後讓中間派知道，哦，是不是這個框架還不錯啊

不管怎麼說，這樣的文章再進行多層次的傳播，作者的目的就達到了

我想說：知道自己想要什麼東西的還是知道自己的需求，不知道的還是不知道

爭論，對你我升職加薪毫無幫助

@大漠老師該來卸鍋了

我感覺這事兒也沒啥大不了的。

每個人都有自己喜歡和不喜歡的東西，不喜歡的拿來噴一噴也沒啥不好的嘛。

話說 @尤雨溪老師愛憎分明，得罪人也很多。我就曾經在 @蕭井陌的評論下看尤雨溪老師指責他是個靠裝逼出名的二流程序員大V。雖然尤老師說的是事實，但這麼直白的噴大V，也是很容易得罪人的。

而蕭井陌就比較機智了，只是刪評論忍了（確實在前端方面正面剛不過）。而遇到比自己弱小的程序渣渣出言不遜的時候，蕭大大可是會截圖開專欄噴的呀。所謂大智慧者，不過如此。

而尤雨溪大大就不太一樣了，只要噴vue的，誰都敢剛。說話也比較直，最終導致得罪了一些群體和個人，或許正是這種原因，導致今天這篇文章開撕。但維護自己作品據理力爭也是人之常情，也算是沒辦法的事情吧。

這種靠著貶低其他東西來宣傳自己的做法，其實並不能使人產生好感。

尤大對於其他的框架從來沒有表現出輕視和貶低，只是闡述了各框架的應用場景的不同，和個人喜好的不同。

大漠老師的文章個人覺得寫的適得其反

拿錢辦事，造話題營銷而已。忽略語氣，文章介紹了ag和vue的一些特點，ag龐大，vue精小，根據項目選合適的，這些大家都懂，大家就是單純的想看撕逼而已，觀眾看撕逼時都能學到兩個框架的一些東西，何樂而不撕呢？有劇情的技術交流對手戲。。。坐等看尤大怎麼懟了，哈哈哈

哎，其實有個事實在佐證 @大漠窮秋的觀點。

一年前前端培訓班的教學順序是，js原生，原型鏈，jq，jq源碼，angular/react/混合開發app。

現在前端培訓班的教學順序是，js原生，vue，vue源碼，jq使用，原型鏈，混合開發。

0基礎按照第一套方案，angular根本學不會，因為跟不上。

但是按照第二套則不然。vue對企業友好度很高。能出活兒，也就是可以當一條會算數的貓（訓練條件反射），背api就行了，現在市面上有部分人，說自己寫管理系統，用vue，不會css.....

前端的問題在於，如果企業要求你有vue/react/ng的經驗，可能你2-3年jq的經驗都餵了狗。

很容易被彎道超車。

大部分前端的工作就是實現ui，調介面，跳路由。從10-30k，大部分都在干這個，畢竟基礎庫，腳手架只要少部分人維護。當然，大部分後端其實也就是視圖仔，介面仔。

以上程序員的概念指能靠編程拿工資的。

參加開源中國的技術分享會的時候已經見識過大漠這人了，不熟悉的只知道他是Google ng團隊的人，接觸過的人都知道，就一個技術平庸，嘴上挺能逼逼的噴子，。還是多去給別人做做ng的培訓吧，少來噴別人東西不好。

為什麼這些大佬們都越來越閑了，難道都忘記程序員是幹嘛的了嘛？不管是Vue還是angular不都是為了方便我們程序員去寫代碼嗎，雖然個人有個人的喜好，但是沒必要把你的喜好展示給大眾吧，有那時間換不如多寫幾行代碼…

前端看起來要分四派了，不選邊站都不太現實了啊：Angular、Vue和React各一派，再有個當老師代表的JQ派……

這樣每個前端才能旗幟鮮明，各有山頭可依靠……

預計先是各種沸沸嚷嚷，最後有幾位「大牛」哥分別粉墨登場各下結論……

感覺就是各種套路……

--------------------- 談談對NG和Vue的感受 ---------------------

Angular雖然重，但很符合Java團隊的行事風格。從我的使用感受來看，雖然開發一個Todo都有好幾層，但很習慣，前提是習慣Java，因為感覺非常親近。Angular工具鏈完整，而且有了TS加持，團隊開發保障度很不錯，這個算是選對了。

Vue小巧簡潔，我的團隊現在主要用Vue，暫時尚未發現力所不逮的場景。規模複雜度不是特別高的場景下使用，能夠感受到開發效率高。

最後，我只想講3點：

1. 前端討論JS語言、ES標準的正逐漸變得不多了，都比較熱衷於三大框架。感覺不是太好。

2. 容得下沙子、容得下批評，哪怕說錯了，說得誇張了點，也不用太敏感。不要老是自覺不自覺地選邊站隊。

3. 因為前面兩點出了問題，前端圈比較亂。

《為什麼只會Vue的都是前端小白？》這篇文章看似理性客觀，但是其實完全可以去掉vue相關的內容，作者說的東西照樣成立。不去學TypeScript，英語不好，都是菜雞的原罪，活該菜，但是其實這些跟vue有關係嗎？vue相對來說門檻低，好上手，這是優點好吧？怎麼到了作者這裡，反而成了框架的錯了？部分菜雞不思進取，學個vue就出來混日子，不去批判他們，反過來說框架的問題？另外vue的中文文檔也是網友幫忙翻譯的，我還有幸參與了一點點，本身英文文檔就寫得好，Angular,react哪個沒中文文檔了？Angular挺好的，要誇就誇嘛，非要踩著別人說自己高就沒意思了，講真，喜歡一個東西就去幫忙充實他，作者也是個大牛，寫點插件提點pr比啥不強，何必呢。最後這段，明顯是利益相關嘛，吃相太難看。