一份关于Angular的倡议清单-InfoQ

本文要点

本文提出了一份对 Angular 未来功能提升的倡议清单。

基于 Angular 灵活的渲染基础架构，建议开发新的渲染器，包括共享平台（Platform-
shared，用来与远程用户共享 app）、文档平台（Platform-Documents，用来渲染 PDF 或 ODF 文档）以及服务端显示平台（Platform-DisplayServer，用来使 App 完全在服务端运行）。

Angular 工作区间可以提供工作区功能并允许多个 App 用单个浏览器 session 运行。

Angular 作为一个优秀的 UI 框架而闻名，但是必须意识到它的基础是一个功能强大的系统编程框架。

Angular 目前主要侧重于客户端，但应该尝试探索用 Angular Host（一种基于 V8 引擎的服务端引擎）代替 Node 来提升 Angular 的系统编程能力。

Angular 是一个用来创建大型 Web 应用的优秀的 Web 框架。许多 Angular 支持者都期望它能快速发展以解决更复杂的应用场景。因此，不如进行一次头脑风暴来提出一些可行性的想法。

本文的目的是提出一份清单，并稍后进行完善并划分优先级。本文是作者的最原始的想法清单，但广大读者肯定也会有些其他的想法和建议。广大读者可以在原文评论处留言自己的想法。作者也欢迎能听到读者对于已经提出的清单的看法以及哪些想法值得作为 Angular 未来更新的一部分。

在决定广泛应用的框架该如何演化时，都会有是否该增加某项新特性的矛盾。尽管目标是提供更综合的解决方案来更好地应对各种各样的问题，但总会担忧框架可能会因此而变得臃肿。毫无疑问，开发者们更关心的是，提出的某项新特性是否为他们自己 App 的开发带来切实的好处。

就算同意添加某项特性，但在哪里添加这个特性也是一个难题。新特性可以被添加在 Angular 主项目中，也可以作为 Angular 的一个子项目，甚至可以作为一个完全独立于 Angular 的项目。总的来说，作者更希望 Angular 主项目能够保持精简，因此剩下的两个选择似乎更为可取，尤其是作为 Angular 子项目的方案，类似于 Angular CLI 或者 Angular Material 项目。

渲染

我们将尝试探索 Angular 如何在渲染层面进行扩展。Angular 提出可配置渲染器的概念被更高层次的 Angular 功能和程序组件用来以更灵活的方式将内容渲染到显示器。渲染器需要实现 Angular rendering API 。Angular 提供了各种平台化包 (Platform- packages) 实现了不同种类的渲染器。Platform-Browser 包是我们非常熟悉的，它提供的渲染器能够写入到浏览器的 DOM。Platform-Server 提供的渲染器能够输出到服务端的 HTML 文件，这些生成的 HTML 文件之后可以被下载。

最吸引人的渲染器来自 Platform-WebWorker。这种渲染器允许在一个 web worker 的上下文环境进行渲染。在作者的《guide to the Angular source tree》一书中，作者用一个章节详细介绍了Platform-WebWorker，包括消息总线和消息代理，它们能够将来自web worker（web worker 不能访问浏览器的DOM）的渲染信息传递到到UI 主线程（UI 线程可以访问浏览器DOM）。由于Angular 提供了极好的灵活度，因此应用程序可以不用直接访问DOM 就能调用渲染器。类似的情况还有其它一些使用场景，例如共享型应用、X-Window 类型应用以及向文档中渲染内容的应用。

许多商业Web 网站都有一个聊天按钮，通过这个按钮用户可以通过网站以文本形式和公司的代表交谈。在线培训网站也会让老师和远程学生共享同一视图。许多销售网站也会提供类似的远程产品展示。如果这个Web 网站是基于一个Angular App，那么它就可以拥有和远程用户共享应用的方案（假如安全顾虑被正确处理的话）。

有许多实现浏览器窗口共享的方法，但这里鼓励使用一种新的Angular Platform 方案（姑且称之为Platform-Shared）。Platform-Shared 拥有一个混合的渲染器，这个渲染器既拥有类似Platform-Browser（本地渲染）的渲染功能，又拥有类似Platform-Webworker（但这时渲染信息传递的目的地不再是跨线程，而是跨网络）的渲染功能。Platform-Shared 可以通过配置使得远程用户可以选择只观看渲染结果或者选择发送事件（例如鼠标点击事件、键盘事件）到服务端。

X-Window 系统有一个渲染服务器的概念，它运行在人类用户面前的机器上，并提供一种显示服务以供远程应用程序在屏幕上渲染内容。目前 Angular 整个程序都运行在用户本地的 Web 浏览器上。想象一种新的 Angular Platform-DisplayServer 可以使 Web 程序在远程机器上运行（例如在云端或者更安全的企业数据中心）并且渲染内容到用户的 Web 浏览器上。这样，没有具体的应用程序代码需要在用户的 Web 浏览器上运行，只需要一个通用的 Platform-DisplayServer 实例。

基于渲染内容到文档想法的 Platform-Server，可以将内容渲染到一份 HTML 文档中，那么如果想要显示到其他文档格式的文档中，例如 PDF 或者 ODF（Open Document Format），那该怎么办呢？对于许多类型的应用，大家都希望显示器中显示的内容都能同样出现在文档中，那样更方便共享给其他人，更容易在普通的文本编辑器中编辑，也更容易打印。

Angular Workspaces

尽管并未被广泛使用，Angular 支持同一平台多个应用程序同时运行于一个浏览器上下文的理念（每个应用程序都可以操作同一份 DOM 的不同子树）。假设我们有一个名为 Angular Workspaces 的新包，它构建在多个 Angular 应用同时运行的想法之上。

对于大多数用户而言，当使用小型移动设备时只会同时使用单个应用程序；当使用更大些的移动设备时，可能就会在多个拆分窗口中使用两到三个应用程序；当使用平板电脑或者桌面电脑时，通常会同时使用许多应用程序，这些应用程序在重叠的窗口内运行。通常由这些设备的操作系统来提供某种桌面或工作区间管理器来管理各种不同的应用。

Web 浏览器是一种不同类型的工作区间管理器，也支持多个应用程序各自在一个浏览器 tab 页中运行。Angular Workspaces 将会是另外一种类型的工作区间管理器，其中的多个应用程序将会运行在一个浏览器 tab 页中（即同一个执行上下文中）。

Angular Workspaces 将会提供其他工作区间管理器提供的相同的服务，例如身份验证、区间隔离（每个 Angular App 运行在各自独立的 web worker 中来防止不同 App 之间的相互干扰）、App 启动器（如何选择和启用一个 App 的设置）、与基于云端 App Store 集成的应用发现功能（可以从中了解有哪些可用的 App）、App 在屏幕上的布局（多层窗口以及位置和尺寸设置）、session 管理（持久化保存某个工作区间连同其内运行的 App，在之后的某个时间在同个浏览器或另外一个浏览器上恢复这个工作区间）。

与 Web Assembly 的集成

许多科研、工程、金融、视听项目都有一个重要的 CPU 密集型的计算引擎（非 UI），他会与一个用户界面和一个用于远程 API 调用的消息通信库组合在一起。其中，计算引擎一般为了实现高性能而用 C 或者 C++ 语言来编写。迄今为止，它们都运行在服务器上。随着 Web Assembly 的出现，这些代码也可能会在浏览器上运行，从而打开新的架构格局。Angular 应该与 Web Assembly 紧密合作。

TypeScript 语言功能

Angular 应该加强对 TypeScript 语言功能的使用。既然 async/await 已经纳入 TypeScript 语法，async/await 也应该在 Angular 的源码中广泛使用，包括 Angular API 和 Angular 应用程序代码中。新版的 TypeScript v2.2 添加了对 mixins 的扩展支持，那么 Angular 也应该尽可能使用 mixins。Angular 应该在它的大型包（例如 Angular/Core）中使用 TypeScript 命名空间。尽管我们并不一定需要在所有包的顶部都加入命名空间（包本身实际上就是类似于其他语言中的根命名空间的存在），但是，如果你是一名 Angular 新手， Angular/Core 中罗列的各种类将会带来困扰，搜索答案的速度会很慢。许多经验尚浅的开发者都会这样自问“这么多可用的类中，我到底该用哪个类来实现某个特定的任务呢？”。

Angular 图表

Angular 对通用的 HTML 元素提供了很好的支持，但是在图表领域更大有可为。与图表相关的三大重要技术是 HTML Canvas 、 WebGL 2 和 SVG 2 。一个崭新的 Angular Graphics 包将会让那些开发图表 App 的开发者们交口称赞。

Angular 协议

Angular 目前提供了一个 HTTP 包来帮助客户端 HTTP 编程。这个包是对 XMLHttpRequest 调用的包装。尽管一个应用可以直接调用 XMLHttpRequest，但使用 Angular 的 HTTP 客户端包可以帮助实现依赖注入，同时可以支持后端替换（比如测试用的 in-memory-web-api ），请求的响应会被转换成 RxJs 事件流，并且对跨域请求伪造（XSRF Strategy）有更安全的加固措施。未来，Angular 应该同样支持其他协议，特别是HTTP（server）、HTTP/2、WebRTC 和Web Sockets。

Angular 作为一个系统编程框架

尽管 Angular 非常适合 Web UI 编程，但是如果深入了解它所有丰富的功能，就会清楚 Angular 也会是一个非常好的系统编程框架。那么，暂时就让我们忽略 Angular 强大的 UI 功能，仅仅专注于 Angular 剩下的非常有助于系统编程（特别是能够用于没有用户界面的应用程序或组件）的功能。

Angular 不局限于用户界面编程的强大功能包括层级式的依赖注入、事件发射器以及支持使用 RxJS 实现流式处理、zones 的使用、与 WTF（Web Tracing Framework）的集成、强化的反射功能、可测试性、元数据与装饰器、国际化、Angular 模块的动态加载、web worker 的消息总线和消息代理。

TypeScript（以及 ECMAScript）没有庞大的内置框架（不像其他语言生态，例如 Java 或 C#都有非常庞大的相关框架）。因此，类似 Angular 这样功能强大的框架可以不局限于仅仅用于 UI 编程。

要想让 Angular 成为 TypeScript 生态中出类拔萃的系统编程框架，需要在文档完善方面付出努力，需要 Angular Core 团队放一部分精力在一些无关 UI 的功能上，还需要一些在程序宿主方面的想象力。

Angular Host

目前，一位全栈的应用程序开发人员需要关注不同的程序宿主，比如开发 Web 客户端代码时（在浏览器上使用 Angular），Web 服务器编程时（使用 Node/Express），开发原生移动或桌面 App 时（使用 Ionic/NativeScript/Electron），以及开发非 UI／非服务器系统代码时（使用 Node）。尽管开发人员强烈希望能够尽可能地在所有的程序宿主间复用他们的技能树和代码库，但是因为各种目标宿主间的差异性而没能实现这种愿望。

正如我们已经讨论过的，Angular 提供了强大的系统编程能力，因此我们可以畅想，Angular 团队是否可以开发一款新型的程序宿主，可以使用 Angular 作为系统编程工具并对所有类型的应用都提供统一的 API。我们可以有 Angular Server Host（完全替代 Node/Express）、Angular Mobile Host（替代 Ionic/NativeScript/Electron）以及 Angular System Host（替代 Node）。所有这些宿主都可以使用谷歌的 V8 JavaScript VM，根据需要还可以使用一些开源的 HTTP & HTTP/2 框架以及少量的 C++ 代码，以此保证基于 Angular 框架的应用程序在这些宿主上展现统一的功能。

例如，目前基于 RxJS 的 Angular 事件发射器被用来传递服务端 HTTP 响应到客户端应用程序代码中。在将来的 Angular Server Host 中，相似地，可以用 Angular 事件发射器传递客户端的 HTTP 请求到服务端的应用程序代码。这就意味着，开发者在 Web 客户端的处理可观测事件流的技能可以直接用于 Web 服务端应用的开发。

另外一个例子，依赖注入用来根据一些动态配置的组件来组装一个应用程序的框架。大多数 Angular 开发者都希望在客户端和服务端使用同一种 Angular 依赖注入引擎。还有一个例子是 web worker 通信，这方面被 Angular Platform-WebWorker 非常好地实现用于客户端多线程，并且也非常有望用于服务端。

除了系统开发，Angular 还有一些其他功能可以用于服务端开发或者其它开发领域。许多 Web 应用都会涉及到服务端模板技术，从服务端数据库或其他中间件直接获取数据，使用一个类 HTML 模板来在服务端生成 HTML 代码，并将生成的 HTML 发送给 Web 浏览器。试想，如果这些服务端模板是基于已有的客户端 Angular 模板语法，那就意味着全栈开发者可以在客户端和服务端都使用 Angular 模板语法这门技术，而不用学习两种不同的模板引擎。

我们甚至可以敦促 Angular 的子项目的发展，例如 Angular Material 和 Angular CLI 。Angular CLI 不仅可以用于生成 Web 客户端项目的初始项目结构，还可以生成 Web 服务端程序和移动端程序的项目结构，甚至可以生成一些共用代码。组件设计是一种非常好的创意，而 Angular Material 就是组件设计中针对 Angular 项目的一种非常优秀的实现。非常期待 Angular Material 能够作为 Angular 服务端模板技术方案的一部分。

作者简介

Eamon O’Tuathail就职于 Clipcode ，负责为开发 Angular 项目的最前沿的客户端开发团队提供指导、培训和咨询服务。他曾在欧盟工作，在一些软件开发项目中先后担任软件工程师、技术架构师、项目经理和技术顾问，涉及云存储、工程管理系统、电商门户、协议设计、大规模多线程高并发的金融通信系统、安全服务器平台、X.509 证书颁发、航天可视化、地震成像技术等领域。