一直以来，Facebook 的 React、Google 的 Angular 和尤雨溪的 Vue，被诸多的开发者称之为前端三大主流框架。去年，Facebook 修改了开源 React 的使用许可协议，即使用者不能做任何构成与 Facebook 竞争的事情，否则不再允许使用 ReactJS 或根据本许可证发布的任何 Facebook 软件，这一更改，最终引发了一波各大平台弃用 React 的热潮。如今继 React 之后，又有人表达了对 Angular 的不满，究其原因，本文作者从 Angular 的文档、架构及应用开发等多维度分享那些年在使用 Angular 时掉过的坑。
1.前言
判断一个公司是否开始走下坡路的方法就是看长期以来他们产品效用的发展情况。比如苹果公司在发布 iPhone 时产品的效用大幅增加，随后的一段时间内也在上升，但最终在他们删掉一些重要功能（如 3.5 毫米耳机插孔）后效用开始下滑。一般来说，大多数公司的产品效用曲线都会呈现S形或抛物线形：前者通常出现在产品稳定期，各种小的修修补补，运营可以平稳地盈利，但没什么创新；后者通常是产品搞砸了。
Angular。名字就佶屈聱牙。慢慢读，/’eŋgjəlɚ/。喉咙得把自己扭曲成异常痛苦的形状才能发出这个丑陋、刺耳、不自然的声音。
在这里，我想讲述这个恶魔给我的心灵带来的各种创伤，尽管它是 Google 的心血结晶：Angular Web 开发框架。
2.文档
你有没有过这样的经历，周六下午你想出了一个业余项目的好点子，结果发现完成该项目至少需要六个月的时间？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 页的组装说明书吧。祝你好运。
3.所谓“架构”
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 框架不会帮你任何忙。
4.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 的标准，然后你就会突然发现，你根本无法解释黑盒子里的任何东西，整个应用程序都构建在一个随时可能崩坏的假设上，但你却束手无策——当然，花上几个星期也能改好，但别忘了截止日期！别忘了截止日期！别忘了截止日期！
5.被 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 投稿，联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（guorui@csdn.net）。
