2020 年 Angular 的困境

Angular 团队正遭受重创

Angular 生态系统正在崩溃

大量未解决的问题和拉取请求

没有公开的路线图

封面照片由Pixabay在 Pexels 上拍摄。

本文仅代表我个人观点，不代表任何组织。

你正沿着一条黑暗、泥泞、湿滑的道路前行，却迷路了。你会怎么做？假装一切安好，继续前行？还是停下来寻求帮助？

整个 Angular 社区，尤其是 Angular 团队的剩余成员，在 2020 年都会走上这条路。看起来并非总是那么美好。我认为我们应该停下来，重新振作。是时候停止假装一切都很好了。事实并非如此。

Angular 团队正遭受重创

过去几年里，似乎有无数的优秀人才离开了 Angular 团队。人数太多，无法一一列举，但以下是其中一些：

• 马蒂亚斯·涅梅拉
• 卡拉·埃里克森
• 罗布·沃尔默尔德
• 亚历克斯·伊格尔
• 维克拉姆·苏布拉马尼安
• 布拉德·格林
• 本·莱什
• 布兰登·罗伯茨
• 奥利维尔·库姆
• 汉斯·拉森
• 杰森·阿登
• 迈克·布罗基
• 维克多·萨夫金
• 杰夫·克罗斯
• 罗伯·艾森伯格

这简直就是一支梦之队。他们中的一些人是不是因为 Ivy 项目而受到了影响？在 Angular 的第一个稳定版本发布之前，Ivy 项目拖延了 Angular 生命周期的一半以上时间？

虽然 Ivy 可能是问题的一部分，但我们确实看到一些离开 Angular 团队的人谈到倦怠、嘲笑甚至焦虑。这不仅仅是范围蔓延和过于乐观的截止日期造成的。

有关背景信息，请参阅 Jeff Cross 在“ Jeff 致 Angular 团队和社区的信”中的个人账户以及最近 Twitter 上有关此事的讨论[1] [2]。

这类严重的人身伤害源于公司最糟糕的团队文化，这种文化使员工能够事无巨细地管理、辱骂和骚扰同事。领导力在于赋能团队，而不是阻碍他们。

由于 Angular 团队内部人员不断流动、冲突不断，他们似乎永远无法突破Tuckman 团队发展阶段中的“风暴阶段”。每当团队中的大部分成员被替换，团队就会重新回到“形成阶段”。

最重要的是，整个 Angular 团队都在不断努力了解他们所拥有的庞大且高度复杂的代码库。

Angular 生态系统正在崩溃

多年来，Angular 团队的努力一直集中在 Ivy 运行时和编译器的开发上，错误地试图跟上永无止境的“我的框架比你的框架更快/更小”的声望之争。

在同一时期，谷歌投入了大量精力来使用和支持 Bazel——一个专为谷歌打造的工具链的开源版本。最终，Angular 经过多年尝试，试图将 Bazel 打造成一个谷歌内部和外部都可用的通用工具链，但最终失败了，最终与 Bazel 分道扬镳。

与此同时，该电池的许多其他部分（包括应用框架）都被废弃了。

TSLint 宣告终结

Angular CLI 预置了一些工具，其中之一就是 TSLint。由于 TSLint 现已弃用，我们预计拥有如此丰富工具的生态系统不会再使用它。遗憾的是，Angular CLI 的 lint 构建器和 Codelyzer 的 lint 规则仍然需要使用 TSLint。

最初，Angular 10 版本计划支持 ESLint 。现在我们不禁要问，Angular 能否在2020 年 12 月 1 日之前实现这一目标，届时 TSLint 甚至会停止接受安全性/TypeScript 兼容性 PR。根据 TypeScript 的创建者 Anders Hejlsberg 的说法，ESLint 比 TSLint 更快，而且他们将其用于 TypeScript 本身。Angular 团队仍然担心内存消耗和速度问题。

对于 Angular 来说，TSLint 末日时钟仍在滴答作响。

Angular Material 被重写

Angular Material 正在转向包装Material Design Components for the Web 的实现，这是一个与框架无关的 Google 库。从外部角度来看，这需要大量工作，但并无明显差异。

对于许多组件，Angular 团队对 DOM 结构和 CSS 类的影响较小。为了缓解这种情况，他们提出了组件测试工具。如果您的测试依赖于 Angular Material 的 DOM 结构，则必须重写所有测试以使用该库的组件工具，否则当 Angular Material 的内部结构被替换时，您的测试将会中断。

组件线束必须由所谓的线束环境支持。虽然TestbedHarnessEnvironment大多数测试框架的单元测试都支持，但 Angular 仅附带了用于ProtractorHarnessEnvironment端到端测试的 ，而且即使这样也只是部分实现。如果您使用 Protractor 以外的其他端到端测试框架，则必须实现自己的线束环境，这说起来容易做起来难。

图书馆作者们不禁疑惑

我曾尝试为Angular 库概述从 View Engine 到 Ivy 的过渡计划，但最终放弃了。即使在 Angular 10 中，Angular CLI 和文档也建议库作者不要编译到 Ivy 指令集。可能是因为 Ivy 指令集尚未稳定和最终确定。最初的计划是 Ivy 指令集在 Angular 10 中最终确定。

ng build my-angular-library --prod
Building Angular Package
******************************************************************************
It is not recommended to publish Ivy libraries to NPM repositories.
Read more here: https://v9.angular.io/guide/ivy#maintaining-library-compatibility
******************************************************************************

我问了 Angular 团队的人，但他们不知道这个计划。可能是因为 Google 自己还在努力将超过 2600 个应用程序迁移到 Ivy。

Protractor 推出新版本

显然，Angular 团队现在拥有了 Protractor。尽管问题数量不断增加（仅 2019 年就有约 200 个未解决的问题），并且其包装的 Selenium WebDriver API 也发生了重大变化，但 Protractor 在 2019 年几乎没有受到任何影响。

Angular 团队成功发布了 Protractor 7.0 版本，并将其与 Angular 10.0 版本捆绑在一起。目前看来，该版本仍然支持已弃用的同步 Selenium WebDriver API，用于与浏览器交互。未来仍有改进空间。

Angular Elements 在许多用例中仍然无法使用

Angular Elements 是几年前推出的。Angular 仍然不支持将 Angular 自定义元素输出到单个 bundle 中，也不支持在多个 Angular 自定义元素之间轻松共享公共 bundle。此外，即使是 Ivy 的编译输出，其开箱即用的大小仍然过大，导致 Angular 自定义元素无法在需要关注 bundle 大小的环境中正常使用。此外，正如上一节所述，仍然不建议使用 Ivy 指令集构建库。

Zone.js 末日时钟

Zone.js 可以对全局 API 进行 monkeypatch，但无法拦截 async-await 之类的语法。Angular 的NgZone默认变更检测策略严重依赖 Zone.js 来拦截所有可能改变 Angular 应用程序状态的任务。

这阻止我们输出 ES2018 包，因为这会将原生的 async-await 语句保留在包中。原生的 async-await 语句不会被拦截，这NgZone会导致 Angular 应用程序与 DOM 不同步。

这一事实多年来一直为人所知，但直到最近才被 Angular 团队忽视。我所说的 Angular 团队，实际上是指 Angular 团队的管理层，或者任何真正推动 Angular 框架发展方向的决策者。

被遗弃的包裹

虽然 Angular 的许多子包和相关工具在过去几年中一直保持更新并获得了新功能，但有些子包和相关工具近年来已被完全放弃或很少受到关注和关注：

• 角度卧推
• Angular Flex 布局
• Angular 应用外壳
• Angular 移动版
• Angular 预启动
• Angular PWA
• Angular 通用套接字引擎
• Angular 通用 ASP.NET Core 引擎
• Angular Web Worker 平台
• 茉莉花
• Protractor 辅助功能插件
• Protractor 控制台插件
• 量角器食谱
• Protractor 时间线插件

大量未解决的问题和拉取请求

如图 1 所示，Angular 主 GitHub 存储库中的未解决问题和未解决的拉取请求的数量已达到令人担忧的水平。

图 1. angular/angular、angular/angular-cli和angular/components存储库中随时间推移的未解决问题。

Angular 团队和 Angular 合作者经过集中努力，将其降低到 2020 年 6 月和 7 月所见的水平，但这必须是一项持续的努力，才能将数字降低到合理的水平。

截至 2020 年 7 月底，、和 GitHub 代码库中的未解决问题数量angular/angular已angular/angular-cli接近angular/components5,000 个。具体来说，这相当于 React、Svelte 和 Vue 代码库中未解决问题数量总和的两倍多。

未解决的拉取请求数量约为 1,000 个。这比 React、Svelte 和 Vue 代码库中未解决的拉取请求数量总和还多 65%。

最重要的是，许多问题在关闭后一个月内无人评论，都会被 Angular 团队的 GitHub lockbot 锁定，以供进一步讨论，无论问题创建者是否对结果满意或仍在寻求 Angular 团队的反馈。

没有公开的路线图

Ivy 的承诺难以捉摸，却未能给人留下深刻印象。Ivy 究竟能带来什么？过去 3 年，其核心框架几乎没有变化。

需求量很大的功能请求要么因为与框架无关而被拒绝，要么没有得到回应，要么没有在路线图中列出。

以下是一些示例：

• 强类型反应形式
• 可观察的生命周期时刻
• 可观察的输入属性
• 无区域应用程序
• 无区域 Angular 元素
• 动态渲染无需ComponentFactoryResolver
• 可选的 Angular 模块——除了公共 API 之外，我们仍然缺少以下无 NgModule 选项：
  • 路由组件
  • 喷油器管理
  • 支持可摇树的提供商
  • 样式编译和封装
  • 可声明依赖项的本地组件范围
  • 编译模式
  • 内容投影
  • 引导组件，包含运行和应用所需的所有必要依赖项
• 运行时语言切换
• 翻译文本的动态加载
• 通过数据绑定进行动态组件渲染

当被问及路线图时，Angular 团队回答说正在制定中，请关注他们的博客以获取更新。

我们仍在等待……

正如前文所述，这些技术问题的例子预示着更大、更重要的问题。更多详情，请参阅“不，我不想成为 Angular GDE ”。