JavaScript 的未来：它还少些什么？每日前端夜话0x28

每日前端夜话0x28

每日前端夜话，陪你聊前端。

每天晚上18:00准时推送。

正文共：9219 字 1 图

预计阅读时间： 15 分钟

翻译：疯狂的技术宅

原文：http://2ality.com/2019/01/future-js.html

近年来，JavaScript 的功能得到了大幅度的增加，本文探讨了其仍然缺失的东西。

说明：

我只列出了我所发现的最重要的功能缺失。当然还有很多其它有用的功能，但同时也会增加太多的风险。

我的选择是主观的。

本文中提及的几乎所有内容都在 TC39 的技术雷达上。 也就是说，它还可以作为未来可能的 JavaScript 的预览。

有关前两个问题的更多想法，请参阅本文第8节：语言设计部分。

1. 值

1.1 按值比较对象

目前，JavaScript 只能对原始值（value）进行比较，例如字符串的值（通过查看其内容）：

相反，对象则通过身份ID（identity）进行比较（对象仅严格等于自身）：

如果有一种能够创建按值进行比较对象的方法，那将是很不错的：

另一种可能性是引入一种新的类（确切的细节还有待确定）：

旁注：这种类似装饰器的将类标记为值类型的的语法基于草案提案。

1.2 将对象放入数据结构中

如果对象通过身份ID进行比较，将它们放入 ECMAScript 数据结构（如Maps）中并没有太大意义：

可以通过自定义值类型修复此问题。 或者通过自定义 Set 元素和 Map keys 的管理。 例如：

通过哈希表映射：需要一个操作来检查值是否相等，另一个操作用于创建哈希码。 如果使用哈希码，则对象应该是不可变的。 否则破坏数据结构就太容易了。

通过排序树映射：需要一个比较值的操作用来管理它存储的值。

1.3 大整数

JavaScript 的数字总是64位的（双精度），它能为整数提供53位二进制宽度。这意味着如果超过53位，就不好使了：

对于某些场景，这是一个相当大的限制。现在有[BigInts提案]（http://2ality.com/2017/03/es-integer.html），这是真正的整数，其精度可以随着需要而增长：

BigInts还支持casting，它为你提供固定位数的值：

1.4 小数计算

JavaScript 的数字是基于 IEEE 754 标准的64位浮点数（双精度数）。鉴于它们的表示形式是基于二进制的，在处理小数部分时可能会出现舍入误差：

这在科学计算和金融技术（金融科技）中尤其成问题。基于十进制运算的提案目前处于阶段0。它们可能最终被这样使用（注意十进制数的后缀 ）：

1.5 对值进行分类

目前，在 JavaScript 中对值进行分类非常麻烦：

首先，你必须决定是否使用 或 。

其次， 有一个众所周知的的怪癖，就是把 归类为“对象”。我还认为函数被归类为 同样是奇怪的。

第三，不适用于来自其他realm（框架等）的对象。

也许可能通过库来解决这个问题（如果我有时间，就会实现一个概念性的验证）。

2. 函数式编程

2.1 更多表达式

不幸的是C风格的语言在表达式和语句之间做出了区分：

特别是在函数式语言中，一切都是表达式。 Do-expressions 允许你在所有表达式上下文中使用语句：

下面的代码是一个更加现实的例子。如果没有 do-expression，你需要一个立即调用的箭头函数来隐藏范围内的变量 ：

使用 do-expression，你可以更优雅地编写这段代码：

2.2 匹配：解构 switch

JavaScript 使直接使用对象变得容易。但是根据对象的结构，没有内置的切换 case 分支的方法。看起来是这样的（来自提案的例子）：

正如你所看到的那样，新的 语句在某些方面类似于 ，不过它使用解构来挑选分支。当人们使用嵌套数据结构（例如在编译器中）时，这种功能非常有用。 模式匹配提案【https://github.com/tc39/proposal-pattern-matching】目前处于第1阶段。

2.3 管道操作

管道操作目前有两个竞争提案 。在本文，我们研究其中的智能管道（另一个提议被称为F# Pipelines）。

管道操作的基本思想如下。请考虑代码中的嵌套函数调用。

但是，这种表示方法通常不能体现我们对计算步骤的看法。在直觉上，我们将它们描述为：

从值 开始。

然后把 作用在 上。

然后将 作用于结果。

然后将 应用于结果。

最后将结果赋值给 。

管道运算符能让我们更好地表达这种直觉：

换句话说，以下两个表达式是等价的。

另外，管道运算符支持部分应用程序（类似函数的 方法）：以下两个表达式是等价的。

使用管道运算符一个最大的好处是，你可以像使用方法一样使用函数——而无需更改任何原型：

最后，让我们看一个长一点的例子（取自提案并稍作编辑）：

3 并发

一直以来 JavaScript 对并发性的支持很有限。并发进程的事实标准是 Worker API，可以在 web browsers 和 Node.js （在 v11.7 及更高版本中没有标记）中找到。

在Node.js中的使用方法它如下所示：

唉，相对来说 Workers 是重量级的 —— 每个都有自己的 realm（全局变量等）。我想在未来看到一个更加轻量级的构造。

4. 标准库

JavaScript 仍然明显落后于其他语言的一个领域是它的标准库。当然保持最小化是有意义的，因为外部库更容易进化和适应。但是有一些核心功能也是有必要的。

4.1 用模块替代命名空间对象

JavaScript 标准库是在其语言具有模块之前创建的。因此函数被放在命名空间对象中，例如，，和：

如果将这个功能放在模块中会更好。它必须通过特殊的URL访问，例如使用伪协议 ：

好处是：

JavaScript 将变得更加模块化（这可以加快启动时间并减少内存消耗）。

调用导入的函数比调用存储在对象中的函数更快。

4.2 可迭代工具 (sync 与 async)

迭代 的好处包括按需计算和支持许多数据源。但是目前 JavaScript 只提供了很少的工具来处理 iterables。例如，如果要 过滤、映射或消除重复，则必须将其转换为数组：

如果 JavaScript 具有可迭代的工具函数，你可以直接过滤迭代：

以下是迭代工具函数的一些示例：

笔记：

有关迭代器的工具函数示例，请参阅 Python 的 itertools （https://docs.python.org/3/library/itertools.html）。

对于 JavaScript，迭代的每个工具函数应该有两个版本：一个用于同步迭代，一个用于异步迭代。

4.3 不可变数据

很高兴能看到对数据的非破坏性转换有更多的支持。两个相关的库是：

Immer 相对轻量，适用于普通对象和数组。

Immutable.js 更强大，更重量级，并附带自己的数据结构。

4.4 更好地支持日期和时间

JavaScript 对日期和时间的内置支持有许多奇怪的地方。这就是为什么目前建议用库来完成除了最基本任务之外的其它所有工作。

值得庆幸的是 是一个更好的时间 API：

5. 可能不需要的功能

5.1 optional chaining 的优缺点

一个相对流行的提议功能是 optional chaining。以下两个表达式是等效的。

此功能对于属性链特别方便：

但是，仍然存在缺点：

深层嵌套的结构更难管理。

由于在访问数据时过于宽容，隐藏了以后可能会出现的问题，更难以调试。

optional chaining 的替代方法是在单个位置提取一次信息：

你可以编写一个提取数据的辅助函数。

或者你可以编写一个函数，使其输入是深层嵌套数据，但是输出更简单、标准化的数据。

无论采用哪种方法，都可以执行检查并在出现问题时尽早抛出异常。

进一步阅读：

“Overly defensive programming” by Carl Vitullo 【https://medium.com/@vcarl/overly-defensive-programming-e7a1b3d234c2】

Thread on Twitter by Cory House 【https://twitter.com/housecor/status/1088419498846244864】

5.2 我们需要运算符重载吗？

目前正在为运算符重载进行早期工作，但是 infix 函数可能就足够了（目前还没有提案）：

infix 函数的好处是：

你可以创建 JavaScript 以外的运算符。

与普通函数相比，嵌套表达式的可读性仍然很好。

下面是嵌套表达式的例子：

有趣的是，管道操作符还有助于提高可读性：

6. 各种小东西

以下是我偶尔会遗漏的一些东西，但我认为不如前面提到的那些重要：

链式异常：使你能够捕获错误，能够包含其他信息并再次抛出。

可组合的正则表达式：

正则表达式的转义文本（对于很重要）：

支持负索引的 ：

匹配和解构的模式（KatMarchán 的提案）：

检查对象的深度相等性（有可能：可选地使用谓词进行参数化，以支持自定义数据结构）：

枚举：向 JavaScript 添加枚举的一个好处是可以缩小与 TypeScript 的差距。目前有两份提案草案（尚未处于正式阶段）。 一个是Rick Waldron，另一个是Ron Buckton。在两个提案中，最简单的语法如下所示：

Tagged collection literals （由KatMayán提议 - 并撤回）：允许你创建 Map 和 Set，如下所示：

7. FAQ：未来的JavaScript

7.1 JavaScript 会不会支持静态类型？

不会很快！当前开发时的静态类型（通过 TypeScript 或 Flow）和运行时的纯 JavaScript 之间的分离效果很好。所以没有什么合理的理由改变它。

7.2 为什么我们不能通过删除怪异和过时的功能来清理 JavaScript？

Web 的一个关键要求是：永远不要破坏向后兼容性：

缺点是语言会有许多遗留功能。

但好处大于缺点：大型代码库仍然是同质的，迁移到新版本很简单，引擎仍然较小（不需要支持多个版本）等等

通过引入当前功能的更好版本，仍然可以修复一些错误。

有关此主题的更多信息，请参阅“针对不耐烦的程序员的 JavaScript ”。

8. 关于语言设计的思考

作为一名语言设计师，无论你做什么，都会使一些人开心，而另一些人会伤心。因此，设计未来 JavaScript 功能的主要挑战不是让每个人都满意，而是让语言尽可能保持一致。

但是对于“一致”的含义，也存在分歧。因此，我们可以做到的最好的事情就是建立一致的“风格”，由一小群人（最多三人）构思和执行。不过这并不排除他们接受许多其他人的建议和帮助，但他们应该设定一个基调。

引用 Fred Brooks:

稍微回顾一下，尽管许多优秀实用的软件系统都是由委员会设计的，并且是作为一些项目的一部分而构建的，但是从本质上说，那些拥有大量激情粉丝的软件就是一个或几个设计思想的产品，——致伟大的设计师。

这些核心设计师的一个重要职责是对功能说“不”，以防止 JavaScript 变得太大。

他们还需要一个强大的支持系统，因为语言设计者往往会遭到严重的滥用（因为人们关心并且不喜欢听到“不”）。 最近的一个例子是 Guido van Rossum 辞去了首席 Python 语言设计师的工作，因为他受到了虐待。

8.1 其他想法

这些想法可能也有助于设计和见证 JavaScript：

创建描述 JavaScript 未来前景的路线图。这样的路线图可以用讲故事的方式并将许多单独的部分连接成一个连贯的整体。我所知的最后一个这样的路线图是 Brendan Eich 的“和谐的梦想”。

记录设计理念。现在，ECMAScript 规范只记录了怎样做，而没有为什么。举个例子：可枚举性的目的是什么？

规范的解释者。半正式的规范部分几乎已经可执行。如果能够像编程语言一样对待和运行它们会很棒。 （你可能需要一个约定来区分规范代码和非规范辅助函数。）

鸣谢：感谢Daniel Ehrenberg对本博文的反馈！

求分享

如果你觉得这篇文章对你有帮助，请点击右下角的 “好看” 并分享给小伙伴们

下面夹杂一些私货：也许你和高薪之间只差这一张图

2019年京程一灯课程体系上新，这是我们第一次将全部课程列表对外开放。

愿你有个好前程，愿你月薪30K。我们是认真的 ！

唠一唠怎样才能拿高薪