Google的Angular 迫使我放棄了 Web 開發

一直以來，Facebook 的 React、Google 的 Angular 和尤雨溪的 Vue，被諸多的開發者稱之為前端三大主流框架。去年，Facebook 修改了開源 React 的使用許可協議，即使用者不能做任何構成與 Facebook 競爭的事情，否則不再允許使用 ReactJS 或根據本許可證發布的任何 Facebook 軟體，這一更改，最終引發了一波各大平台棄用 React 的熱潮。如今繼 React 之後，又有人表達了對 Angular 的不滿，究其原因，本文作者從 Angular 的文檔、架構及應用開發等多維度分享那些年在使用Angular 時掉過的坑。

前言

判斷一個公司是否開始走下坡路的方法就是看長期以來他們產品效用的發展情況。比如蘋果公司在發布 iPhone 時產品的效用大幅增加，隨後的一段時間內也在上升，但最終在他們刪掉一些重要功能（如 3.5 毫米耳機插孔）後效用開始下滑。一般來說，大多數公司的產品效用曲線都會呈現S形或拋物線形：前者通常出現在產品穩定期，各種小的修修補補，運營可以平穩地盈利，但沒什麼創新；後者通常是產品搞砸了。

Angular。名字就佶屈聱牙。慢慢讀，/』e?gj?l?/。喉嚨得把自己扭曲成異常痛苦的形狀才能發出這個醜陋、刺耳、不自然的聲音。

在這裡，我想講述這個惡魔給我的心靈帶來的各種創傷，儘管它是 Google 的心血結晶：Angular Web 開發框架。

文檔

你有沒有過這樣的經歷，周六下午你想出了一個業餘項目的好點子，結果發現完成該項目至少需要六個月的時間？Google 在給 Angular Web 開發框架做內部文檔的時候就是這樣。他們用一杯咖啡收買了一個實習生，讓她加班加點趕出了一個 Hello World 指南，然後就把指南當作整個框架的文檔發布了。

這份文檔里沒有寫出任何使用 Angular 框架開發 Web 應用程序時可能遇到的問題。實際上，這份文檔甚至連開發時必須的核心概念和設計模式都很少提到。如果你想學習怎樣使用 Angular 開發，那麼不要以為你可以像 React 或 Vue 那樣立即開始寫代碼，你必須購買在線課程（我可以推薦 Maximillan Schwarzmueller的開發指南：https://www.udemy.com/the-complete-guide-to-angular-2/，這份教程挽救了我的工作），只有這些課程才能告訴你所需的一切經驗和可能出現的坑。

Angular 實際的文檔更像是一個函數，其偽代碼如下：

這一小段腳本用 Angular 編譯之後只有 5MB

注意到問題了嗎？沒錯：當需要在 Angular 中改 Bug 時，你要特別注意從所有搜索中去掉 Angularjs 一詞。你不能多寫一個 2（或者7），也不能妄想著只用「Angular」就能從搜索結果中去掉所有 Angular 生態系統中的第一版（這個奇葩的第一版）。更不用說這個開發本身會越來越繁瑣。

但接下來你就會適應 Stack Overflow 上人們貼出的各種「解決方案」，然後你就會發現，你寫的代碼和瀏覽器中運行的代碼之間的區別不僅僅是一個編譯器，而是一個黑盒子，你只能嚴格按照它的要求寫代碼，否則出了錯它也不告訴你，更糟糕的情況下它會產生一個風馬牛不相及的錯誤。你絕不能相信 Angular Web 開發框架告訴你的任何錯誤，因為甚至連它自己都不清楚自己的工作原理。你有沒有試過在某個 Module 里定義 EntryComponent 讓它延遲載入，而不是在根 Module 里定義（從而無法享受延遲載入的好處）？做不到！有沒有試過用雙向數據綁定而不是用 EventEmitter、Subscription 和 Service？也不行！

整個 Angular Web 開發框架的經驗大抵如此。你興沖沖地跑向前，結果不斷遭到碰壁，最後不得不學著用蝸牛的速度慢慢爬行，可憐兮兮地摸索著各種障礙，免得被框架踩在腳下。對付這個據稱是世界上最聰明的公司拼湊出的喜怒無常的怪物，讓人分外沮喪簡直無與倫比。

就像一輛汽車，引擎蓋永遠打不開，儀錶盤耀眼地顯示著「儀錶盤」幾個字卻無法關閉。這輛車壞了也沒法修，只能換掉，或者從外邊打補丁。不點火也會排放廢氣。也沒有保養手冊。你要想了解它的工作原理，那就去看這本 5280 頁的組裝說明書吧。祝你好運。

所謂「架構」

Angular 非常慢。寫程序需要花費很長時間，寫出來的程序本身一旦比 Hello World 複雜，就會慢得像蝸牛。如果 Angular 框架能給用戶或者開發者帶來任何好處也就罷了，比如在出現運行時錯誤的情況下優雅地失敗，編譯速度快，或者提供更好的安全性等。但 Angular 一樣也沒有。實際上，它在出錯時只會抱怨「Uncaught TypeError」。

基本上，理解 Angular 實際工作原理的唯一辦法就是閱讀開發者們在 GitHub 上提供的幾百萬行代碼。由於沒人實際閱讀過，Angular Web 開發者實際上都在用著自信不會出問題的設計模式，然後在這些模式上構建整個應用。就像用醫用塑膠手套建造的潛艇，估計也能用，只要有無限的手套供應就行。也不能說別無選擇，你還可以跳進那一堆毫無道理的東西中去研究下 Angular 的「工作原理」。

我來告訴你它的工作原理。Component 需要與 Service 通信，將數據通過應用導入的 Module 傳遞給其他的 Injectable。這有什麼不清楚的嗎？如果你需要證據，去看看 Material Design 的指南。他們提供了構建應用所需的一切 Component。那麼按理說實現像素級準確的設計應該很容易，因為 Material 和 Angular 都是 Google 設計的，兩者應該能完美配合使用。實際上看起來也不錯，列表項的余白會佔用整個三分之一的空間，打開下拉菜單也要花上 16 秒。你是不是開始懷念當年毫無限制的互聯網了？

在 Angular 的架構下編寫的代碼運行速度毫無保障。這個框架帶來的只有：複雜性，完成簡單任務所需的時間，還有——如果你能在不發瘋的前提下日復一日地寫麵條代碼的話——讓你和你的團隊不至於丟了工作。但別忘了一件事：當你面臨最後期限時，Angular Web 框架不會幫你任何忙。

Angular Web 開發經驗

碼農們，打開你的 IDE 看看！首先需要：

輸入 IntelliJ IDEA 的序列號（必須輸入序列號才能繼續）；

感謝您輸入序列號；

請選擇你想要使用的 TypeScript「Linter」來「清理」你的 TypeScript 代碼。

Angular Web DFGHSDFG FGSGDFSFDS 用的是 TypeScript，就是個帶類型的 JavaScript。這會讓 Angular 更好。你必須使用兼容 TypeScript 的 IDE 才行。TypeScript 還會經常更新。一更新就會破壞代碼和代碼中的依賴，這也是預料之中的。光修復這些問題就能領工資，多好！好好享受吧！

如果僅僅是因為遇到了一個從來沒有碰過的第三方庫中的某個類屬性出錯你就大驚小怪，那你可就脫離時代了。你只需要在每個構建步驟中加上一點點手工編輯即可。或者也可以把庫的版本凍結在某個兼容的版本，以後別更新了就好。感謝你使用 TypeScript 和 Angular。

Angular 會貼心地把各種亂七八糟的假 HTML 元素混在你真正的 HTML 元素里，因為反正整個應用都會被 AOT 編譯器打碎，所以亂一點又有什麼關係呢？但在寫 HTML 文件時，請務必使用 Angular 認證過的標記語言，裡面包含各種 Directive，它的作用就是讓你的調試工作更有意思。你還可以自己定義 Angular Directive 讓你敲下的每個字元都有不同的含義。最高級的功能就是所謂的「Angular 風格的 HTML」，與其他庫、框架或編程環境相比，跟蹤這種代碼的難度在指數級別。它們一定會給你提供錯誤的錯誤信息。你以為你要找缺少的關閉標記，那就慢慢找吧，最後你會發現真正的錯誤出在某個神秘地導入的 directive 中的某個條件語句中，而且你還沒辦法給別人解釋這個錯誤的原因，否則別人要麼覺得你不可理喻，要麼覺得你不可救藥。還有，你也沒辦法再用頁內錨點了，因為這個功能太好用了。好好享受用 JavaScript 實現手工頁面滾動的時光吧。

當然這一切都沒問題，你有大把的時間思考是不是該繼續使用這個完美的框架，因為每次修改哪怕一點點 HTML，都需要重新編譯整個應用程序。熱載入在小程序中運行得很好，不過一旦應用發展到一定的複雜度，編譯整個代碼就得等待 60 到 300 秒，因為編譯器需要處理完所有代碼，才能把某個彈出窗口中的某個元素上添加的一個 HTML class 加進去。大量的時間就這樣浪費了，因為你需要盯著控制台上的那行消息：「92% chunk asset optimization」。別等了，還是去看你喜歡的主播吧。

你討厭寫合法的 CSS 嗎？Angular 提供了各種混亂的方法，把良好的樣式規則轉化為偽 HTML 代碼，這樣才能在每次你修改元素的 class 時重新編譯。你甚至都不需要學 flexbox……當然，當你的經理要求你解釋為什麼你的布局沒有遵循「最新標準」——即 Material Design 的標準，然後你就會突然發現，你根本無法解釋黑盒子里的任何東西，整個應用程序都構建在一個隨時可能崩壞的假設上，但你卻束手無策——當然，花上幾個星期也能改好，但別忘了截止日期！別忘了截止日期！別忘了截止日期！

被 Google 的編程思想虐待一年後的教訓

Angular 使我成長為一名優秀的程序員，因為它讓我學會了在火山的熔岩坑中怎樣從一塊石頭跳到另一塊石頭，同時還需要寫出實用的應用程序。任何代碼改動，只要沒有遵循最有效的方案，就必然會導致速度降低。我嘗試過太多將數據對象 A 綁定到顯示元素 B 的方法，但只要比最基礎的解決方案複雜那麼一點點，就保證讓整個項目著火。沒錯——Angular 應用中的任何錯誤都會導致 Angular 應用的其他部分出現異常。最後我們只能決定在每次遇到未捕獲的錯誤時讓應用程序重新載入整個頁面，因為與拿著放大鏡審視一大堆 Bug 報告才能確定某個錯誤究竟是它自身的錯誤還是其他錯誤導致的結果相比，重新載入頁面要快得多。最後乾脆刪掉了修改：「非常簡單，代碼中沒有錯誤就好。你們用的不是測試驅動開發嗎？」

我這一輩子都會牢記 Angular Web 開發給我的教訓。終身難忘，它們像狗皮膏藥一樣緊緊粘著我，堵塞了我大腦中的每個溝回。我別無選擇，因為要養家糊口，就只能繼續做 Angular 開發。但我希望有一天我能夠得到一份使用其他框架的工作機會，如 React 或 Redux，或者工作可以給我指派某個不帶偏見的庫，比如 Vue 等。但至少目前，我還在努力，緊緊抓住那些依然屬於我的記憶，幹掉那些 Google 概念的入侵，因為它們佔據了我的一切。我們活著就要鬥爭到底。

現在我在 Whiteboard Dynamics 工作，工作時間內不需要再頻繁地複製粘貼 Angular 的命令行，更多時候我會為產品編寫乾淨、高效和能夠運行的代碼，而這些代碼不再需要每三個月重寫一次。總的來說，我找到了恢復人生希望的方法。如果有必要我們還會用 Angular 寫一些東西——就像我剛剛說過的那樣，Angular 的詛咒會伴隨我一生，但請相信我：最好還是選擇一個大家都喜歡的庫。這樣即可以節省時間和金錢，也能保護你不朽的靈魂。

原文：https://hackernoon.com/why-angular-made-me-quit-web-dev-f63b83a157af

作者：Tobias Merkle，軟體工程師。

譯者：彎月，責編：屠敏

微信改版了，

想快速看到CSDN的熱乎文章，

趕快把CSDN公眾號設為星標吧，

打開公眾號，點擊「設為星標」就可以啦！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！