如何看2015年1月Peter-Paul Koch對Angular的看法？

01-07

The problem with Angular
In the last six months or so I talked to several prospective clients that had a problem finding front-end consultants in order to help ...

感謝邀請。早上看到阮一峰老師轉發了這篇文章，中午手癢翻譯了一份：

［翻譯］Angular的問題 · Issue #15 · xufei/blog · GitHub

認真地說，這篇文章的很多觀點我還是很贊同的，而且令人印象深刻，比如說：

Angular更多地是面向企業的IT部門，而不是前端人員。

非前端人員做給非前端人員用的前端框架。

Angular更多的用戶是有Java背景的人員。

Angular是面向大型企業的IT後端和經理們的。

對很多前端人員而言，最大的問題是，Angular強迫自己用一種指定的方式去幹活。

當遵守AngularJS的約定時，生產力會更高。

對於一個前端人員，習慣於用特定方式來做事，遷移到Angular的方式可能比較痛苦。

整個文章比較深刻，該說的東西都說到了，但我還是有一些話要說。

首先，他把Angular想要面對的領域搞錯了。我想要先問幾個問題：

1. 有沒有適應所有場景的前端框架？

2. 目前的世界上，有經驗的Java開發人員更充裕，還是前端更充裕？

3. 為什麼多數Java開發人員害怕寫JS？

我自己來回答吧。

1. 在任何領域都不存在通用方案，所謂通用，也就意味著對某些特定場景缺乏關照。Angular的出現，並非是為了跟jQuery競爭，而是為了迎合企業應用領域，以及一些管控類項目的場景。這些場景有它的特殊性，對他們來說，模型層的複雜度高於普通網站，之前那種混雜DOM操作和業務邏輯的代碼更不易管控，從前端開發者的角度是不太容易意識到這些問題的，他不知道在這類場景下，談論某種庫或者某個框架都沒有意義，只有整體的一攬子解決方案才有意義。剛才這個文中所提到的移動端的考慮，更是太強人所難，到現在為止，哪個框架敢說自己成功解決了在PC版的Web和移動版之間的良好通用性？Vanilla？

2. 我在南京，在這裡，能把Java寫得規整，像模像樣的碼農至少幾萬個，前端寫得同樣規整有經驗的，至少差兩個數量級。這種情況下怎麼辦，不充分利用已有資源，坐著等天上掉餡餅嗎？所以在現在這個階段，必然有很大一部分Java開發人員要去寫JS。

3. 多數Java開發人員為什麼害怕寫JS？原因很簡單，他並不怕寫純邏輯，而是怕寫DOM操作代碼。這些東西對他來說很煩悶，而且JS代碼太過缺乏約束，也讓他很無所適從。之前很多企業軟體使用ExtJS這樣的框架，用寫Java的方式來寫Web前端，這種開發人員嚴格來說還是算Java開發人員，不能算前端。

ExtJS為什麼能被這些人接受，是因為它避免了對DOM的直接操作，所有東西都轉化為邏輯了，同理，如果一個框架能避免他們接觸DOM，但是又比ExtJS優點多，為什麼不用呢？與ExtJS相比，Angular是不是離前端更近點？

所以我認為，Angular的存在，基本上不是搶jQuery的飯碗，而是要搶ExtJS的。回憶一下用ExtJS時候遇到的問題，界面部分的代碼繁雜，UI人員基本沒法參與，現在換成Angular，是不是好得多了，只要認真封裝幾個控制項，萬事大吉。至於說性能，難道ExtJS的性能很好嗎？

如果要讓Java人員參與前端開發，必須處理好幾個問題：

1. 制定嚴格的代碼規範，寧可死板，絕不寬鬆

2. 從架構層面把各種問題擺平，切分任務為小塊，每個人只寫特定小塊代碼

3. 在前端作分層，確保每一層代碼的穩定

4. 跟真正懂前端的人一起把HTML、樣式、控制項好好規劃

再回頭看看，Angular給我們帶來了什麼？站在架構師的角度，你最害怕什麼？害怕的是項目失控。怎麼才能隨時知道沒有失控？分層，從下往上，逐次確保每個層面的穩定可靠，最上面的層出了問題，修復的代價最小。從這個角度出發，必須優先保證模型和業務邏輯不出問題。

Angular能讓你把可控的東西一路往上推到很極端的地方，除了特別薄的表面，其他所有東西都納入掌控，然後切切分分，丟給Java碼農去搞，然後轉身去跟真的懂前端的少數人一起把外面那層皮做好，協作一定是很愉快的。

剛才這些，我解釋了為什麼企業級的開發人員和架構師對Angular如獲至寶。現在談談文中提到的其他幾個問題：

1. 性能

這個問題一針見血，確實有性能問題，但我們提到，這個框架的主要應用場景還是企業應用領域，只要它不把範圍擴大，不會有什麼影響，因為在這類領域，這種程度的啟動性能問題壓根就不敏感。

在實際開發中，一定會遇到一些其他性能問題，比如大數組，複雜對象，這些才是真正有影響的，需要用不同的手段來優化。這個我後面專門寫文章講。

那麼，為什麼我認為這些不是關鍵問題呢？是因為目前的企業前端開發領域，最核心問題壓根不是性能，而是生產力，生產力處於嚴重低下的地步。收割機出來之前，人們手工收割，一行一行割過去，有了收割機，一次割一片。如果考慮細節效率，肯定收割機不如手工，因為收割機很容易漏收，掉在地上的也不少。那我們難道就因此堅守老的收割方式？火車出現之後，駕駛馬車的看不慣它，問題是，你怎麼知道你現在所謂的那些前端代碼風格就是好的，高效的？改變個代碼風格，一定錯了嗎？

況且，Angular的絕大多數性能問題處於非常上層的位置，這一層是有很多機會優化的，可以不影響業務代碼的實現。

2. 移動端

雖然目前也存在Ionic這樣的框架，但我自己對這方面還是比較保留，也從來不會推薦人使用Angular開發移動端的東西，除非只是表單類的系統。

事實上，我們目前也並沒有哪個框架真正解決了移動端高效生產，或者哪怕是開發得稍微舒心一點的問題，在這個事情上，大家只是五十步笑一百步。

3. Angular 2.0

與作者的觀點相反，我對2.0非常看好，認為它基本不會失去企業開發者的支持，同時會贏得更多移動端開發者。

在企業應用領域，甚至存在過GWT這麼奇怪的東西，也就是完全用Java寫界面，然後編譯到HTML和JS去，而且這個東西在這個領域還是有很多人認同。Flex和Silverlight也同樣有很大的用戶群，基於這個，憑什麼說AtScript就不會流行？我相信會有很多Java開發人員寧可寫AtScript，也不願意寫JS，更何況，ng2.0隻是自己用AtScript實現，業務開發人員一樣可以很好地用JS開發啊。

關於這一塊，我的兩篇文章也說得很清楚了：

有關Angular 2.0的一切 · Issue #8 · xufei/blog · GitHub

浴火重生的Angular · Issue #9 · xufei/blog · GitHub

題外話：在現實中，我們碰到很多處理不好前端代碼的項目，根本原因在於兩點：

前端開發者缺乏架構意識

項目負責人和架構師沒有足夠的前端知識

這兩點不解決，用什麼框架都一定做成渣。

當web業務進入紅海，用戶不再滿足於基本的功能需求，開始追求更好的體驗的時候，富前端的web應用需求變得旺盛之時，前端框架才有意義。

傳統服務端渲染的網站來說，使用jQuery加上各種插件就足以應付，而且可以更靈活的與Server端進行配合。代碼量基本是可控的，大多數複雜邏輯都可以依賴插件來完成。

但是對於富前端應用，插件雖然仍然可以解決諸如輪播圖、圖表、編輯器等較複雜的通用邏輯，但是大量本由Server端處理的應用層邏輯前移，這些邏輯並不通用，不適合封裝成插件，在沒有框架的情況下，往往一個充斥大量業務邏輯、好幾千行的JS文件就誕生了。

前端模塊化和前端框架都是基於富前端應用的需求才應運而生的，它們並不試圖解決傳統類庫插件時代的瀏覽器兼容和頁面效果，而是試圖解決前端代碼的合理組織和分層、降低代碼量、提高可維護性。

這一點上講，Angular是成功的，作為最負盛名的前端框架，它解決了富前端應用的代碼失控問題，基於Angular的組件生態圈也讓多人協作快速搭建應用成為可能。較為統一的編程模式更有規律可循，讓項目交接變得更輕鬆了。不排斥傳統的jQuery開發模式，兼容到IE8也讓更多的開發者可以接受。

總而言之，Angular可以解決富前端應用中可能的代碼失控和難以維護的風險，Angular本身存在的一些bugs或者使用中遇到的問題也往往可以暫時採用傳統方式繞過去，對於富前端應用來說，使用Angular或者類似的前端框架總的來說是利大於弊的。

但是對於前端開發者來說，Angular卻並非福音，一方面如文章所言，前端框架的流行讓後端寫出還不錯的前端展現成為了可能，Bootstrap解決了後端在CSS上的弱點、而Angular-Bootstrap讓後端也可以寫出原來只有前端高手才能搞定的富前端應用。像Rails這樣的後端框架還喪心病狂的集成了assets pipeline這樣的前端工程化組件。可以說，現在一個其它端的工程師依賴這些工具可以輕鬆的transfer到前端崗位上來。

而且前端工程師面前也出現了兩條路，一條是選擇精通各種DOM規範，JavaScript API、HTTP協議、演算法，一條是選擇精通Angular、Ember、Bootstrap等應用層框架，可以高效的搭建應用，解決或者規避開發過程遇到的各種坑。

顯然，大多數人更想走第一條道路，但現實中，絕大多數人只能走第二條。正如多數人都想成為高富帥，但最後基本都是屌絲一樣。畢竟選擇第二條，工作好找，不愁失業，學習成本低，就像滿大街精通SSH，精通CI框架一樣。框架的出現會讓很多工程師失去接觸底層實現的機會，尤其是身處業務密集的公司。

所以前端工程師本能抗拒Angular我認為是很正常的，畢竟關係到職業發展和切身利益，但是問題在於，不可能存在一套既足夠靈活，可以接觸底層，又可以控制複雜應用中項目失控風險的東西。不論前後端都是這樣，靈活，開放底層的框架必然功能不強使用不便，功能強大的框架必然底層開放度低，重而低效。

所以前端框架的發展是必然的，因為富前端應用的需求在這裡擺著，沒有Angualr也會有Bngular，Angualr有它的缺點，以後或許會被更好的框架取代，但是整體的趨勢我認為不會改變。前端工程師必須學會在項目中接受框架條條框框的存在，可以選擇的只是框架的重量級而已。引個jQuery隨便寫的時代該漸漸過去了。

作為前端開發，我認同裡面對於Angular的描述，同意Angular是非前端人員給非前端人員寫的前端框架，但不同意前端使用Angular是好事情。

複雜的前端應用需要架構這個毋庸置疑，但前端我們有著更好的解決方案與最佳實踐，那我們大可不必選Angular，這樣一個以JAVA思維進行組織的框架架構。

Angular的性能問題我也都不管了，但他整體的代碼結構風格我卻完全不能忍，用他編寫的代碼，喪失了太多的自由度（甚至有些常規需求都得使用Hack方式解決），然後完全以數據的角度看待WEB，而不是從用戶與具體的問題的角度出發，這也是Angular的奇葩之處。

也難怪文中說Angular前端顧問不好找，這完全是後端人員自以為的前端的設計，然後再找前端人員幫忙擦屁股，這種吃力不討好的事，反正我是不願意做的。

單純的前端框架，無法實現按需取值，只能處理簡單的數據關係，在數據源的問題上存在根本性不可簡單解決的問題。
單純的後端框架，沒有靈活的UI操控能力，只適合做一些靜態效果的界面。

對於C#有興趣的朋友可以試試前後端一體 WEB 視圖框架 - C# 高性能自動化服務端框架 - 凹凸架構，它是一個前後端一體自動化的框架。51nod 問題就是基於這個框架搭建的，web層的源代碼可見51nod WebView。

2014年我們團隊折騰了ionic一年，基本上實現了使用一套js代碼支撐了Android Phone，pad，iPad，iPhone四個平台，80%的html和js代碼復用，寫了大量的Cordova插件實現原生功能，整體來看基於AngularJs的ionic框架還是比較給力，我們的項目一直從ionic 1.0.0-beta3升級到beta13，目前最新版本是beta14。項目業務是電商類的，功能複雜度一般，目前各平台基本流暢，android低端機除外，iOS平台和原生差別不大。從開發成本看，比原生應用優勢明顯，架構方面也比較清晰，但在用戶體驗方面，和原生應用還是有差距的。

Hybrid App項目成功的前提是需要有熟悉移動原生開發和前端開發的高手，這種混合應用對人員能力的要求遠高於一般的Android／iOS原生項目和web前端項目，期望僅有熟悉前端開發的人員成功完成這種項目目前來看是不現實的。

對於移動App開發來看，基於HTML5的混合開發方式僅適合企業內部應用等對用戶體驗要求不高的項目，對於大多數面向大眾市場，競爭激烈的App來說，還是原生開發方式更靠譜，用戶體驗容易做好，並且現在有swift了，iOS的開發也相對容易了。

操作複雜DOM是非常困難的，為了簡化操作才有了mvvm，最直接的優點就是你不需要寫一大堆的選擇器了，好用不好用不是前端後端說了算的，而是哪個好用，mvvm直接用來控制css和dom，可以說靈活度僅次於jquery但好用很多，不是什麼ui能比的。