關於Angular和vue的對話，對前端圈子到底起到什麼作用，能不能推進前端的發展？
這兩天vue和Angular貌似溝通的挺多，其實我感覺前端的發展就是要靠不斷的取其精華去其糟粕，並通過自己接下來的不斷更新、創新來的進步，不管是抄襲還是有一樣的框架思想，都是為了有更好的更完美的東西呈現給大家，一個優秀而又被廣泛應用的框架，必然要汲取各方精華不斷磨練，就算它裡面有1%是自己的創新，那麼多整個圈子來說都是好事，值得別人講這個創新拿來用，一個再好的框架得不到大家廣泛應用那麼只能淪落為別人的借鑒的demo
===============================
語言簡直是胡七亂八的，但關鍵是思想
這種風氣一旦流行的話很容易讓人放棄思考。
雖然看上去不論是原文、回應還是回應回應，都會帶一些技術名詞，好像真的是在說理一樣，實際上基本都是浮於表面，僅僅限於什麼是有的，什麼是沒有的，（順便強行總結）什麼是好的，什麼是不好的。而根本不會去涉及一個技術被採用的原因，適用的範圍，實現的成本等等真正有價值的內容。
這裡舉一些例子，看看我們其實能討論哪些真正有意義的內容。
關於 TypeScript
Angular 雖然從正式發布開始就推薦的使用 TypeScript，但這並不是最初的計劃，Angular 團隊曾經設計了一門自己的語言叫做 AtScript，那麼問題來了，AtScript 與 TypeScript 有哪些區別？
- AtScript 支持運行時的類型檢查，而 TypeScript（對官方工具而言）僅僅支持編譯時的類型檢查；
- AtScript 支持 Annotation 以及對應的自省，而 TypeScript 支持語法類似的 ES Proposal 中的 Decorator。
那麼我們可以深入下，運行時的類型檢查到底是不是真的有意義，為什麼 TypeScript 官方不提供這個功能？為什麼 React 要把 prop-types 默認移除？為什麼 ECMAScript 的 interface／protocol（michaelficarra/ecmascript-interfaces-proposal）提案會遭到很多質疑？
如果經過一些深入討論，我們可能會得到諸如：
- 預處理步驟可以便於同時保證開發效率和執行效率；
- 瀏覽器中一丁點性能提升都是重要的；
- 編譯時類型檢查提供的保證已經足夠有效；
- 對於編譯時不可控的內容（如用戶輸入，網路請求），可以進行額外的運行時檢查步驟。
而不是一味的「TypeScript 大法好，動態類型火葬場」或者「JavaScript 就應該是動態腳本語言，為了蔚藍而清凈的世界」這種無端吐槽。
以及關於 Annotation 與 Decorator，為什麼 Angular 使用兩種（除了語法相似之外）完全無關的語言特性都能實現相同的功能？使用 Decorator 時是如何進行自省獲取內容的？
然後我們可以得到：
- Decorator 基本可以完全模擬出 Annotation 的功能特性；
- Angular 使用 Decorator 就只是為了簡化 API，並沒有任何功能依賴。
然後我們知道 Angular 和 TypeScript 能夠良好的集成，那也可以考慮一下為什麼一些其它的框架不能和 TypeScript（這裡可以放大到靜態類型檢查）良好的集成？
諸如：
- Angular 的組件是唯一的類型，而其它一些框架中對每個組件還需要額外的兩個 Props、State 類型作為泛型參數，使得類型標註成本提升；
- Angular 基於 OO 的思想，雖然有很多 class，但是每個 class 的 API 約束性很強；而某些傾向於 FP 的 API 設計可以需要大量使用 Union Type，導致對開發輔助的幫助有限，仍然需要不少文檔閱讀或者調試才能確實使用方式。
關於 CLI
既然 Angular CLI 提供了這麼多命令，那麼就可以順便了解下對於一個完整的工程項目我們究竟需要／能夠進行哪些操作：
- generate：基於模版建立新項目；
- serve：啟動開發伺服器；
- build：構建項目；
- test：執行單元測試；
- e2e：執行 e2e 測試；
- lint：代碼格式檢查；
接著可以考慮一下自己的項目中有沒有用到這些特性，使用這些特性能夠為工程效率帶來多大的提升？
以及直接使用封裝後的 CLI 和 eject webpack config 各自的取捨：
- Webpack：對於了解 Webpack 的用戶而言實現清晰，利於擴展，但不利於參數化，對於多環境支持往往需要建立多個配置文件以及大量的 NPM Scripts；
- CLI：無需了解 Webpack 原理，對（已經支持的）動態參數友好，但不便於功能擴展。
實際上也並不只有直接用 CLI 和直接暴露 Webpack 這兩個選項，對於大團隊而言，自己維護一個定製過的 CLI 也是完全可行的，並不一定非要走某個極端，一定程度上還能同時享受兩者的優勢。
關於 Lazy Loading
Webpack 支持多種 Code Splitting 的方式（Code Splitting），每種方式使用的語法／API 是從何而來的？
- require.ensure()：Webpack 的私有 API；
- System.import()：曾經的 ES Loader 提案（並沒有進入過規範），不推薦；
- import()：當前 Stage 3 的 Dynamic Import 提案。
以及 Angular Router 的 API 支持哪些方式？
- String：抽象後的模塊路徑，用於屏蔽運行時與編譯時載入的區別（但事實上只用運行時載入才會真正用到）；
- ()=&>Promise／()=&>Observable：非同步返回模塊的函數，需要載入時執行。
那麼 Angular CLI 是怎麼做的呢？其實就是通過 Webpack Loader，把 String 替換成對應的 Webpack API 的封裝。
關於 AOT
我們知道，AngularJS 是使用的 DOM-based template，也就是說，先把 HTML 模版交給瀏覽器渲染，然後再從 DOM API 里獲取相應的內容並進行處理。
而對 Angular 而言，使用的是 JavaScript-based template，先把 HTML 模版處理成 JavaScript 代碼（對於 AOT 實際上是 TypeScript），然後運行時僅僅處理 JavaScript 代碼，瀏覽器永遠也見不到 HTML。
所以簡單地說，也就是一個代碼預處理的過程，那麼 Angular 為什麼特別需要 AOT？
- Angular 的 AOT 編譯的不僅僅是模版，還有 Component Style、DI、Data Binding、Event Listening、Change Detection 等等，整個框架可以說是完全基於編譯來實現的；
- （和上面一條其實並不是並列，而是因果）Angular 的 Compiler 較大，且執行時間較長；
- TypeScript 不保留運行時類型信息（除了 emitDecoratorMetadata 那個），不使用 AOT 也就無法為模版進行類型檢查；
- 沒有 AOT 的情況下無法確定會用到哪些功能，因此無法進行 Tree-Shaking（這裡通例，不是 Angular 特有）。
因此換句話說，因為使用了 AOT 能夠得到：
- 對模版內容的 TypeScript 全功能類型檢查，哪怕所有 strict 選項都能支持，這點確實是其它任何模版預處理框架都不具備的。
所以，實際上對於 Angular 而言，非 AOT 的使用方式可以說是完全沒有意義的，可以參考 Svelte（sveltejs/svelte），僅僅提供了命令行工具編譯一條路可選。但是由於早期 Angular Compiler 並不完善（其實現在也還不足夠完善），純粹 AOT 會有很多問題（編譯速度慢，沒有 watch 模式，開發體驗不友好等等）。
所以說，Angular 的 AOT 並不是什麼亮點，從選擇重編譯的這條道路開始，就已經是必需品了，如果沒有 AOT 支持，那 Angular 根本算不上一個 Production-Ready 的框架。
不過隨著現在 Compiler 的不斷完善，在 v5 中 Angular 會把 AOT 設為默認方式，以後不論是開發、測試、打包甚至 Plunker 都會使用 AOT。（是不是很好奇 Plunker 里如何 AOT 呢？）
總結
每個（有意義的，不考慮 mingeXXX 之類的）框架都有很多值得學習和借鑒的地方，很多真正有價值的部分不是靠幾個截圖幾句話就能真正說明的，也正因為如此，這類無意義的討論中也都基本不會涉及到有價值的技術部分。
而且實際上，技術上的方案多數時候都是取捨，很少能有從一而終完美的方案。而主流的站隊方式是，把 XXX 用到而 YYY 沒用到的內容好處說一遍，XXX 沒用到 YYY 用到的內容壞處說一遍，並且美名其曰理性的技術討論。
換句話是，對於前端這個領域而言，那些不同框架里站隊吵架的可能才是一個圈子，哪怕他們之間是相互拉黑的。
說句可能不友善的，但凡把自己的視野局限在某個框架的人，都是小白。
對前端界起到什麼作用很難講，對我作用還是蠻大的。因為被 @徐飛 老師在 如何評價大漠窮秋的文章《Angular有哪些地方比Vue更優秀？》? 里 @ 了，漲了幾百個粉。
前端界多懟幾次，大 V 指日可待。
當然有影響了，這幾天雖然我沒說話，但是我一直在看，這裡面有仍然堅持努力從技術角度深入分析問題的，我就發個私信過去問要不要來我們這做weex。
對於新手或者非該領域的開發者來說, 應該是有用的, 畢竟平時也不會有人密集地對不同的方案有哪些特性有哪些優劣做細緻的分析. 國外以前會看到不少文章對 Angular React 之類的方案做深入的對比來強勢推廣新方案, 目前大局已定, 反而很少看到驚心動魄的大作了. 這類技術方面的討論對於新手和其他領域的人來說理應是有好處的.
對於已經在 Vue 跟 Angular 挖掘多年的同學就很難說了, 甚至已經站隊的話也許每個人心思都不一樣. 不小心說多就會得罪人. 不同陣營的人說話多多少少會帶著推廣的目的, 各自為戰, "對事不對人"是早說過的. 對比一下手機行業這些年發布會的較量, 小米做推廣時候要說友商, 錄了老長的視頻連公證處都拉出來了, 這種事情還是做得嚴謹點比較好.
現在看來 React 都已經在戰場外了, 我作為 2014 年寫過低版本 Vue 和 React 的中年前端真有點誠惶誠恐, Vue 藉助本土化的優勢已經發展到這個程度了. 我個人看法這種技術爭論應該以核心開發團隊之間的爭論為準, 畢竟能代表兩方最高標準對於框架本身理解的層次做的論戰. 不過不在小圈裡看不清, 至少從 Twitter 上看 Vue 核心團隊, React 核心團隊, Angular 甚至其他框架的開發者, 大部分還是一團和氣來著看不懂...
建議觀戰的同學眼界再放寬一點, 廣大 React 開發者還在邊上密切關注呢. 還有就算你們 JavaScript TypeScript 開發者自己吵起來, 我們 ClojureScript, 還有友鄰的 Elm 和 ReasonML 還在戰場外面盤桓呢. 當年 React 剛出來的時候狂開發布會拿 FP 社區嚴謹成果隔空懟 Backbone 和 Angular 你們沒看到, Clojure Conf 上整個演講在酸 JavaScript 你們也沒看到, 還有 Elm 和 ReasonML 也沒少沖著 JavaScript 哀聲嘆氣.
就前端目前的一些需求來說, 提供充足的勞動力資源, 完善和推出開發方案, 構建和拓展理論框架, 國內而言 Vue 在前兩個方面做出了巨大的貢獻, 另外兩位英文社區為主的框架應該好好學學, Angular 算是有本土化的努力, 剩下那個幾乎全靠社區在撐本土化的事情. 與其說對於國內開發者有什麼影響, 我還更覺得國外社區應該好好重視中文區開發者的市場了. 可惜我們中文寫他們看不到 
昨天在時間線上看到有同學轉了國外關於JS框架的文章過來：
JS框架真牛逼 https://medium.com/@mattburgess/javascript-frameworks-are-great-2df4a3f0b24d
所有JS框架都是垃圾 https://medium.com/@mattburgess/all-javascript-frameworks-are-terrible-e68d8865183e 其實我們根本無法客觀地評價JS框架 https://medium.com/@mattburgess/javascript-frameworks-a-futile-attempt-at-objectivity-adf6e75d2fbe這三篇文章其實都是同一個作者寫的，作者的目的是想表明任何一個人在任何情況下想捧一個框架或者黑一個框架都是非常簡單的事，如果你想捧一個框架，那麼可以只無腦地說它表面的優點，多好用，多輕量，跑分多高啥的；如果你想黑一個框架，可以指責它語法奇葩，在解決問題的同時創造了更多新問題，還從其他領域或框架抄襲概念。捧或者黑的同時還能保證說出來的都是「正確的話」，但這並不代表這種捧或者黑就是客觀公正的。
對於框架的評價和對其他領域作品的評價沒有任何區別，夾雜了個人非常多主觀的想法，要知道我們大多數情況下寫文章都是先確定自己的觀點再去找相關的論據，而不是依據客觀的事實去總結觀點。不管別人如何評價，還是希望同學們能夠在總愛搞大新聞的前端屆保持一顆淡泊寧靜的心好好學習天天向上。
至於學什麼框架，得看你公司用什麼，或者挑自己喜歡的就好。另外僅僅學習如何使用任何一個框架是沒法讓你得道成仙的，最多在熟練掌握以後讓你早點下班。真的想要提升自己的話你要去了解背後的概念、原理、實現，你自然就會形成自己獨立的觀點，甚至到你能夠親手擼一個框架的時候也就不會在意這些爭論了。（說不定還有機會招別人黑你呢
人家站隊都是有利益問題，你呢？
最近，我在用 React Native，求不打我
什麼叫「圈子」呢？就是一幫人，研究的是同一件事，所以話能夠說到一處去。出了這個圈子，沒人認識你，也沒人關心你的話題。
既然是圈裡人，有話好好說不行嗎？
還真不行。
前端這個圈子，是非多，因為前端發展快，越是發展快的地方，越是容易有人渾水摸魚嘩眾取寵，所以，我沒覺得前端圈子會因為這事改變什麼，該有的噴子還會噴。
我只希望被無端噴的人不要氣餒，如果因為被噴就偃旗息鼓了，那噴子就真贏了。
其實靠嘴真不大可能說服一個人，尤其是隔著一個互聯網，所以咱們就做好自己的事，以身作則，噴子來了就狠狠地扇回去，讓知道什麼叫做真的言論自由。
其實這世界五顏六色，所以註定各種想法很多，重要的是淘汰那些劣質的想法，如果某些人就是不放下劣質的想法，那他自身會被淘汰，就這麼簡單。
為了這個圈子的健康發展，就要淘汰這些累自己的想法，或者堅持劣質想法的人。
———更新分割線———
為避免誤會還是說一下，我並不是說站出來發表批評的就是噴子，毛主席都說過要批評和自我批評，批評沒問題，但是不要捏造事實批評，或者不說事而只攻擊人，這就不對，如果你攻擊人，必備人攻擊。作為React黨，這次我是堅決站Vue的，為什麼？因為像大漠窮秋這樣的潑髒水對社區根本沒有任何幫助。
開源社區本身是"見賢思齊"的，哪怕大家思路相同，不管是先來還是後到，能在這個思路上做好了、做出自己的特色，都值得稱讚。
比如按照大漠的標準，inferno抄react抄到姥姥家去了，但是react團隊的人看到的是什麼？是inferno有一些API設計非常棒，甚至感嘆當初寫react的時候也這麼做就好了。(twitter上看到的，懶得去翻了，大意如此)。
後來呢？你們也看到了，直接把inferno作者招進了React團隊。作為React的用戶我當然開心了，相信在他的幫助下React在性能、體積上的表現一定會有提升的。
這個過程有撕逼嗎？如果有，會是現在這樣的happy ending嗎？
前面我說了，目前我是React黨，這幾年Vue的迅速崛起同樣從React社區搶走了大量用戶，甚至在 @題葉 建的React群里都經常有人問起Vue，可以說我們隔三差五就中出一個叛徒(我就不說某人直接打入我軍內部了)
可是React的用戶們攻擊Vue了嗎？沒有。相反我看到有人拿Vue作對比，從文檔、功能、生態等角度分析現在的Vue哪些做得比React好，是如何從React這兒搶走用戶的
比如Vue的SSR更早支持了stream render，React沒有官方支持(註：還在beta的React@16 已經支持)
那為什麼不支持呢？ @工業聚 指出了是checksum的問題
社區有沒有方案呢？找了下真有：FormidableLabs/rapscallion
他們是怎麼做的呢？看這段：FormidableLabs/rapscallion#rendererchecksum 原來是渲染後在客戶端用dom操作打上正確的checksum，還有這種操作，嘖嘖
(註：在React@16 中移除了data-reactid 和 data-react-checksum，見：Settle on Heuristic/API for Choosing Hydration · Issue #10189 · facebook/react ，此處感謝 @張克炎 補充 )
話題到這兒，你找到了新工具，也學到了新的知識、思路，這難道不比撕逼潑髒水有意思有價值多了？
作用有限，自薦一篇感悟《Angular、Vue、React 和前端的未來》。
起作用呀，讓大家覺得前端圈更浮躁了。
如果非要說起了什麼好作用，那大概就是讓新手（這裡沒有貶低攻擊的意思）大致了解了下兩個框架
沒什麼作用...並沒有把react一起拉進來亂戰.
當時徐飛離職那個話題下關於技術選型的討論比這個效果好多了...
哪有什麼積極影響？吵來吵去夠負面的了。
該有經驗的程序員他的技術棧都成型了；新手在Angular跟Vue中隨便挑一個深入專註地持續研究，出來都沒人敢小看你。
從早年的天涯、貓撲到技術論壇CU、大富翁、CSDN，有幾次這種爭論有結果有意義？消失的是司徒正美的阿瓦龍 我也覺得很無奈啊
這就是明顯運營活動大於產品設計的典範，但凡國內一個社區沒有什麼新鮮事兒了 運營就會這樣搞事情 不是說不好 只是我不喜歡這樣而已
小右我還是聽說過的 也用過vuejs 對animation模塊的設計還是比較喜歡的 整個前端DSL的設計也不錯 在之前設計機器人應用生命周期的時候 也參考過
至於大漠 好像有這麼一個名字吧 但是確實不知道是做什麼的 看了點歷史 聽說的國內宣傳angular的吧 不過要是我是他 我是堅決不會這樣懟小右和vue的 就像他自己說的 用vue的都是小白 門檻低 那麼是不是angular要想的是我的用戶在哪兒 因為小白市場上vue確實做的比你好呀（你自己都承認了）然後針對你自己的定位 做好產品 做好技術
另外對於那些因為他們打架就不用vue或者ng的 我也覺得不好的 技術選型最重要的還是什麼框架最適合你的團隊和你這階段的業務需求 而不是他們倆~不能，只能暴露出前端圈的浮躁，和不包容的心態。以後在知乎隨便誰一句vue不好，都要被群起而攻之了。
等他們吵完我都用jquery寫完一個項目了
托 Vue 的福，漲了不少粉。
框架的選型相信每個架構師都會經過深思熟慮，並不是幾篇撕文能左右，他們更關注的是技術本身能否有效解決業務問題。
不過不管怎樣，這個對話讓國內更廣泛的人開始思考 Angular。
我們從 alpha 版一路踩坑過來，也看著Angular 及其周邊平台一步一步變得成熟穩定。其實不怕某些人噴學不會（我認為是個人問題），怕的是你們不來學 Angular。論經驗學習，Angular平台集成了很多業界廣受好評的方案，如DI、CSS Module、TypeScript、RxJS、測試框架、webpack2/3，甚至是一些非技術方案，如團隊協作支撐等等，即使你不用 Angular，了解 Angular 也能讓你習得 Google 大廠內部沉澱的局部最佳實踐。
其實想說挺好的。至少比上次噴nodejs好。
因為nodejs是真差。你看真後端幾個鳥nodejs的。nodejs解決了後端不能解決的問題嗎？沒有。只解決了前端不想學其他語言的問題。對。既沒有解決更好招人的問題（會寫nodejs的前端並不便宜），沒有解決更高的開發效率問題（說真的python/ruby在後端比js的開發效率高更多。即使是Java8後。其實真正開發效率也不差到哪裡去）。沒有解決更好的代碼維護問題。更不要說效率問題和其他問題。
那麼用nodejs。在我看來。收益&<成本。而且是遠小於。引入nodejs後。代碼維護。復用。低耦合，高內聚，機器的部署，擴容。。這種全是蛋蛋。而這些才是後端的關鍵。你真想多塊好省。用python都好一點。
再說一個事，當時前端佈道師們宣傳nodejs扛過了雙十一。經過了淘寶系大規模應用。實際了，被噴了以後才發現nodejs只做回源，流量都扛在了cdn後面了，請大規模宣傳nodejs好用的前端們？請問你們知道cdn用的什麼技術什麼語言？nodejs能做cdn嗎？你們小公司能用nodejs扛並發扛性能嗎？
小公司用nodejs的就是扯。
噴完了nodejs說這件事。
其實這次噴也沒啥用。主要是大漠的文章有一種濃濃的「C++不好用是因為你技術太差」這種文章的low感。這種文章在後端早沒有存在感了。
你看後端都大佬們心裡特清楚。除了高性能低延遲的應用。能用機器擴容解決的問題就絕不用C++。為啥。人家心裡實在。請個高級工程師比機器擴容貴多了。你java能解決的問題幹嘛用c++解決。
你看大部分的前端問題不能用vue和React搞定嗎？既然能搞定。文檔多。上手容易。這種事情多好。怎麼成為壞事了？
那Vue和React搞不定而Angularjs搞的定的問題有什麼了？暫時前端一圈票友的文章裡面沒看到。至少這次噴的沒看到。
那這不就扯淡嗎。前端喜歡哪個用哪個。挺好的。框架解決不了的問題才是真問題。
那這種沒區別的情況下。當然是哪個好用用哪個。
還有一個噁心的邏輯就是：用框架的人技術水平差跟框架質量的好壞有什麼關係。
後端就很明確：Spring框架挺好的。很多人從小白開始就是接觸的Spring的後端框架？但是你看後端就沒有人說Spring框架挺差的。
這個邏輯就是扯。真的。
繼續噴前端：
前端高手是有的。但是前端真正的高手和被技術圈認為的高手差距挺大的。
每次看到前端圈的某些高端文章以及評論。就是一個感覺。拿著某些已經在後端其實已經玩過了的東西，然後認為這些東西是最時髦的技術。有著最先進的思想。可以解決一些複雜的問題。你們這些後端老人不肯學。不肯懂。才 瞧不起前端。
這才是前端圈的口水常態。真心浮躁。
真的。不要以為學了框架就很厲害啦。這才是真浮躁。
能看到很多平常不懟看不到的人，心態，技術細節。
推薦閱讀：