JavaScript 前景展望：值得期待的那些新功能

超实用的类型机制加现代工具，让网站和 Web 应用更跟得上潮流和形势。而从种种细节当中，我们也得以一窥 JavaScript 未来的发展方向。

如果单从每年公布的 ECMAScript 标准流程来看，JavaScript 的功能设计似乎并没有什么特别重大的变化倾向。TC39 联合主席兼 Bloomberg JavaScript 基础设施与工具团队负责人 Rob Palmer 一直强调要“铺平道路”，也就是逐步把小小的工具或框架功能融入语言之内，用“语法糖”的形式完成改进。换言之，先把现有功能做好、做完善，这样的升级明显更加无痛。

“我们见证了工具、框架和模式的迭代，随着时间推移，我们会在标准层面找寻融合的交接点，并努力把道路铺平，借此降低应用程序技术栈的复杂度。这样 Node 模块目录才能持续瘦身，越来越多的功能开始由语言本体直接提供。”

Vercel 公司的 TC39 代表 Justin Ridgewell 在采访中表示，考虑到 2017 年引入了原生异步等重大发展，这类增量化功能正在不断增加。“多年以来，JavaScript 引入了诸多具有新功能的新 API。我们的新功能吸纳思路也正在于此——在添加小变更的同时，尽量扩大新功能的广度。”

“我们并不会每年发布重大的功能变更：有时候是每两年一次，有时候是每三年一次。我们只会在必要时引入，确保其切实推动语言的发展。”

一部分重要的新功能（例如 Temporal）在发布之初就基本做好了应用准备；也有其他产品正处于开发中，预计会在未来几年内陆续推出。本文为大家挑选了一些最有趣的内容，同时也征求了 JavaScript 标准制定团队的意见，由他们对语言发展状况做出解释，包括 JavaScript 在下一步标准化中将要解决的问题。

类型机制不会把 JavaScript 变成 TypeScript 

TypeScript 的诞生，纯粹是为了提高 JavaScript 开发者的工作效率，绝对不是要彻底取代 JS 的江湖地位。当然，TypeScript 也成为 JS 未来发展完善的灵感来源。目前，大家在编写代码时需要在 TypeScript 中声明类型——但在代码运行时，这部分又会被移除掉。

之后的发展自然也要解决这个问题。第一阶段的类型注释提案希望在 JavaScript 代码中引入类型信息，更重要的是保证 JS 引擎能够将其正确理解为注释，这样就能保证 TypeScript 和 JavaScript 相互一致和对齐，同时明确它们其实运行在不同的层上。

Palmer 指出，开发人员可以对类型使用一等语法，包括 TypeScript 以及带有长 JSDoc 注释块的 Flow 语法，同时保证自己的代码仍然能跟 JavaScript 引擎和 JavaScript 工具链相兼容——这就避免了在代码运行前消除类型给构建过程带来的复杂性。

Palmer 解释道，“这种仅在开发期间存在，但在运行时会被完全移除的静态类型具有巨大的价值。”而且其中一部分价值可谓相当直观，“开发者可以进行类型检查，知晓自己什么时候犯了错误，同时取消对不存在属性的引用——这很棒。而且除此之外，类型信息还能大大改善开发人员的工作感受，例如重构事物的能力、在 IDE 中自动一次性重命名变量和属性，还有实现代码导航等。”

Ecma（TC39 的母机构）副总裁兼 Bloomberg JS 开发者体验软件工程师 Daniel Ehrenberg 建议，“如果大家在开发中需要用到大量并非出于自己之手的代码，那么理解它的类型构造肯定会有所帮助。”

尽管静态类型在 JavaScript 社区中一直存在争议，但考虑到长期有社区成员希望引入这项功能（静态机制连续三年在 JavaScript 现状调查中被评为最迫切需要的功能），标准流程已经基本证明这种方法能够为 JS 语言锦上添花、同时又不会影响其吸引新手开发者的简单特性。

用更智能的消息格式简化本地化过程

这里给大家科普一下，对网站和 Web 应用程序的本地化绝不止是替换掉用户界面中的消息字符那么简单。毕竟文本内容不只包含单词，还涉及数字、序数词（第一、第二等）、日期、得数和其他各种不同的语言结构，所以单纯替换单词得到的结果可能根本就不像人话。

目前已经有一些库能帮助解决这个问题，例如 FormatJS 等。但与 Java 和 C 等其他语言相比，JS 开发者和翻译人员的工作量还是要更大一些。毕竟人家 Java 和 C 都拥有支持国际 Unicode 组件（例如 ICU4J 和 ICU4）的内置字符串翻译和格式化功能。

开源咨询公司 Igalia 的 Romulo Cintra 在采访中指出，“复数部分真的很难处理。所有语法概念、词形变化和性别/阴阳性数字，以及不同的占位符在各语种之间总有种种差别。处理这种复杂性既依赖于库，也需要大量数据的支持。”

实际上，浏览器已经在使用这些组件推动软件本地化，不少 API 也能调整日期/时间格式和相对时间格式。那么，为什么不为 Web 引入类似的选项，并给 JavaScript 开发人员提供包含专业语言知识的内置选项呢？毕竟，软件已经是最适合面向全世界的产品了。

TC39 提出的 Intl MessageFormat 是另一项一阶提案，他们与 Unicode 联盟的消息格式工作组合作，希望引入包含国际化和本地化逻辑的模板化字符串，将在 JavaScript 中以内置引擎的形式用不同语言正确填写模板字段。

但在 Web 中引入国际化 API 其实是项影响深远的调整，甚至会引发对拥有 20 年历史的 ICU 消息格式 API 的重大更新。Cintra 好奇的是，“原本的 API 只支持字符串、非常僵化，完全没有模块化特性——所以，为什么不从根本上解决问题，直接上马 Unicode 新标准呢？”而这正是 MessageFormat 2.0（简称 MF 2.0）的意义所在，它在设计上就是为软件和 Web 的国际化而生、支持 Intl MessageFormat，Cintra 甚至认为它就是帮助 Web 吸引又一个十亿用户的关键。

“它将突破固有循环，在本地化和个性化层面让 Web 的可访问性来到新的层次。”

Cintra 认为，“对我来说，作为一名非英语母语者，Web 的发展方向就是让更多人能够随意访问。这一点非常重要，也只有达成这个目标，我们才有机会让所有努力开发的软件内容变得更易于访问。绝对值得期待！”

目前，大部分本地化主要依靠在运行阶段解析的自定义消息格式及专有规范来实现。Mozilla 公司靠的就是自家 Fluent 工具来翻译所有界面。Igalia 的 Ujjwal Sharma 告诉我们，Bloomberg 也有自己的内部工具。“每个人都在尝试通过不同的定制化工具解决同一个问题。”虽然 Intl MessageFormat 肯定能为已经涉足国际化工作的组织建立起通用标准，同时也继承开放协作的各种固有优势，但 Sharma 更希望它能为那些还没有固定网站翻译流程的小型组织提供助力。

除了简单翻译文本字符串之外，MF 2.0 还将包含元数据和注释，可用于标记从文字证据（包括正式和非正式）到语音合成提示的全部内容，这样就能更好地支持 Siri、Alexa 等智能扬声器和屏幕阅读工具。新标准还有望消除瓶颈，“语音和界面的许多创新都发生在客户端”，但数据量不足往往成为制约本地化工作的关键。Sharma 认为，“有了 Intl MessageFormat，我们可以在客户端落地更多愿景。”

本地化是个价值数百万美元的行业，因此必须要在兼容性和必要改进之间寻求平衡。Sharma 指出，“最好能提供一个易于使用且足够直观的 API，同时保证仍能跟传统工作方式对接起来——这明显是个极具挑战的任务。但我认为，只要能把这个问题解决好，就能彻底改变人们对于网站的看法。”

一种用于语言翻译的语言

Igalia 负责 ICU 实现的 Tim Chevalier 解释道，MF 2.0 规范定义了一种简单的编程语言，拥有名称绑定（’let’声明）和模式匹配（选择器）。他建议大家将其视为“一种用于编写可翻译消息的特定领域语言”，能够充分运用关于现有编译器和解释器的知识积累。

“希望开发人员在用上 MF 2.0 之后，体验不再像过去那样要编写一大堆神秘的字符串，而更像是在自己选定的通用语言（例如 JavaScript）中使用另一种专用语言进行编程。”他还把这种改进，比喻成从数据库硬编码查询客串到 SQL 的功能飞跃。

“曾几何时，根本就没有可靠的方法能编写程序来操纵对字符串的查询，以便生成给定查询的变体，因为人们不知道要怎么向 C++、Java 和 JavaScript 等通用语言当中嵌入查询语言。现代语言工具已经提供更丰富的查询构造方法，不再仅仅依赖于编写字符串并将其作为参数传递给函数。”MF 2.0 就承诺为开发人员提供类似的使用体验。

而且 MF 2.0 还具备可扩展性：开发人员将获得一个接口，可以用 JavaScript（或者其他语言）创建自己的新抽象以实现格式化函数。该规范还能降低高级翻译工具的编写难度，借这些工具提供更友好的用户界面，让翻译人员在不必学习硬核编程知识的前提下轻松处理文本消息。

MF 2.0 的 ICU 工作仍处于早期阶段，目前仅提供技术预览版。最早的成果是 ICU4J，但目前正被移植向 ICU4C，即大部分 JavaScript 引擎使用的语言。TC39 提案依赖于 MF 2.0，而“一旦实现了 MF 2.0 的稳定版本，TC39 那边的工作就能顺利推进。”Cintra 还推测，稳定版将允许在浏览器上实现该 API，让更多开发者感受到它的实际效果。

如果大家想亲自试试看，FormatJS 已经为初始 IntlMessageFormat 提案提供早期支持：

https://formatjs.io/docs/intl-messageformat/

正在开发一个实验性的 polyfill：

https://github.com/messageformat/messageformat/tree/main/packages/mf2-messageformat

由于该 polyfill 基于已经得到广泛应用的 React 及其他应用国际化工具，因此将为开发人员提供所需的全新语法体验。

里程碑可期，但仍在很多工作要做

Palmer 表示，JavaScript 将继续缓慢发展。“有些人觉得不妨让变革的脚步快一些，以便我们能够获取反馈、发现重要问题并进行迭代；但我们 TC39 的行事风格往往更偏保守。”

如果事实证明一旦发现设计有误且需要修正（比如 Web 组件的实现），那从 Web 平台中移除内容的成本其实非常之高。相比之下，Polyfill 和基于工具的功能实现（标准候选版）既能实现更快的反馈周期、保护 Web 兼容性，又无需让开发人员苦等正式流程走完所有流程。

“我真心认为，JavaScript 保守的开发风格是很有意义的。”

Ehrenberg 表示，“我们有很多实现方案，也有很多需要考量的用途。其他平台可以充当更具实验性的环境，而我们还是选择成为更保守的实现环境。”

按照这种模式，他提到 JavaScript 本身现在包含大量以往开发者只能通过外部工具获取的功能（包括迭代器助手等则是受到其他语言的启发）。

Ehrenberg 解释道，“在处理类字段，包括私有字段和装饰器，还有像 hashbang 语法这样的小问题时，肯定希望我们能早点拿出类型注释和新的功能模块。它们其实就是在继承人们已经在工具中获得的功能，我们想把它们纳入语言本体。CSS 的情况也差不多，同样是把很多通过工具实现的功能引入到核心语言当中，例如嵌套（经典示例）和作用域，还有层和变量等。”

此外，标准化还为开发人员的设置提供非常明确的默认值，有助于最大限度减少项目创建过程中涉及的配置操作，这同样给 JavaScript 的发展带来了新灵感。展望未来，Ehrenberg 还提出另一个值得关注的方向：响应式用户界面的核心组件，例如 signals 和 cells，有可能会成为 JS 语言的一部分。毕竟当今开发人员在前端框架上经常会用到。

这就是他常说的，JavaScript 要走“增量式共享的发现道路”。通过实验为核心功能找到新的基准，再把成果内置到语言当中。他还坚持强调，JavaScript 仍有巨大的发展空间。

“我觉得启发和灵感还有很多，我们远远没有把这些全部转化成现实。”

原文链接：

https://thenewstack.io/whats-next-for-javascript-new-features-to-look-forward-to/

相关阅读：

全网最全 ECMAScript 攻略

“TypeScript 不值得！... 反向迁移到 JavaScript 引争议

JavaScript 作用域深度剖析：动态作用域

TypeScript 与 JavaScript：你应该知道的区别