关于 JavaScript 未来的猜想-CSDN博客

本文链接：https://blog.csdn.net/2401_84150046/article/details/138954675

更多细节参考ts39-proposal-temporal docs。

Private Methods (stage 3)

private-methods 提案为 JavaScript Class 引入了私有的属性、方法以及getter/setter，不同于 TypeScript 中使用 private 语法，这一提案使用#语法来标识私有成员，在阮老师的ES6标准入门中也提到了这一提案。

所以这个提案已经过了多少年了…

参考阮老师给的例子：

class IncreasingCounter {

#count = 0;

get value() {

console.log(‘Getting the current value!’);

return this.#count;

}

increment() {

this.#count++;

}

类似的，还有一个同样处于 stage3 的提案proposal-class-fields引入了static关键字。

对 TypeScript 使用者来说可能没什么感觉，因为在 JavaScript 中写 Class 越来越少了。但是这一提案成功被引入后，可能会使得TS到JS的编译产物变化，即直接使用JS自身的static、#语法。比如现在这么一段TS代码：

class A {

static x1 = 8;

}

编译结果是：

“use strict”;

class A {}

A.x1 = 8;

而在static被引入后，则可能会直接使用static语法。

同样的，现在的编译结果其实并不能确保“私有”，即编译后的 JS 代码仍然能非法的获取私有成员，因为从语言层面并没有相关能力提供。

Top-level await (stage4)

proposal-top-level-await这个提案感觉就没有啥展开描述的必要了，很多人应该已经用上了。简单地说，就是你的 await 语法不再和 async 强绑定了，你可以直接在应用的最顶层使用 await 语法而不再需要套一个 async 函数，NodeJS也从 14.8 开始支持了这一提案。

Import Assertions (stage 3)

proposal-import-assertions 这一提案为导入语句新增了用于标识模块类型的断言语句，语法如下：

import json from “./foo.json” assert { type: “json” };

import(“foo.json”, { assert: { type: “json” } });

注意，对 JSON 模块的导入最开始属于这一提案的一部分，后续被独立出来作为一个单独的提案：proposal-json-modules。

这一提案最初起源于为了在 JavaScript 中更便捷的导入 JSON 模块，后续出于安全性考虑加上了 import assertions 来作为导入不可执行模块的必须条件。

这一提案同样解决了模块类型与其 MIME 类型不符的情况，并且，和现在如火如荼的基于 ESM 的 Bundleless 工具结合应该会有奇妙的化学反应，期待 Vite3.0 能安排上这个提案。

Error Cause (stage 3)

proposal-error-cause这一提案目前由淘系技术部的昭朗同学在推进，其目的主要是为了便捷的传递导致错误的原因，如果不使用这个模块，想要清晰的跨越多个调用栈传递错误上下文信息，通常要这么做：

async function getSolution() {

const rawResource = await fetch(‘//domain/resource-a’)

.catch(err => {

// 想想要怎么抛出一个携带有效信息的错误？

// 直接抛出个异常？

// 1. throw new Error('Download raw resource failed: ’ + err.message);

// 实例化一个error再指定属性？

// 2. const wrapErr = new Error(‘Download raw resource failed’);

// wrapErr.cause = err;

// throw wrapErr;

// 创建Error的子类？

// 3. class CustomError extends Error {

// constructor(msg, cause) {

// super(msg);

// this.cause = cause;

// }

// throw new CustomError(‘Download raw resource failed’, err);

})

const jobResult = doComputationalHeavyJob(rawResource);

await fetch(‘//domain/upload’, { method: ‘POST’, body: jobResult });

}

await doJob(); // => TypeError: Failed to fetch

看起来好像都不太直观？而按照这一提案的语法：

async function doJob() {

const rawResource = await fetch(‘//domain/resource-a’)

.catch(err => {

throw new Error(‘Download raw resource failed’, { cause: err });

});

const jobResult = doComputationalHeavyJob(rawResource);

await fetch(‘//domain/upload’, { method: ‘POST’, body: jobResult })

.catch(err => {

throw new Error(‘Upload job result failed’, { cause: err });

});

}

Decorators (stage 2)

proposal-decorators这一提案…，或许是我们最熟悉的老朋友了。但是此装饰器非彼装饰器，历时五年来装饰器提案已经走到了第三版，仍然卡在 stage 2。

来看看它现在的实现是这样的，是不是感觉有点诡异？

decorator

这里引用笔者早前的一篇文章来简单讲述下装饰器的历史：

首先我们需要知道，JS 与 TS 中的装饰器不是一回事，JS 中的装饰器目前依然停留在 stage 2 阶段，并且目前版本的草案与 TS 中的实现差异相当之大（TS 是基于第一版，JS 目前已经第三版了），所以二者最终的装饰器实现必然有非常大的差异。

其次，装饰器不是 TS 所提供的特性（如类型、接口），而是 TS 实现的 ECMAScript 提案（就像类的私有成员一样）。TS 实际上只会对 stage-3 以上的语言提供支持，比如 TS3.7.5 引入了可选链（Optional chaining）与空值合并（Nullish-Coalescing）。而当 TS 引入装饰器时（大约在 15 年左右），JS 中的装饰器依然处于 stage-1 阶段。其原因是 TS 团队与 Angular 团队 PY 成功了，Ng 团队不再维护 AtScript，而 TS 引入了注解语法（Annotation）及相关特性。

但是并不需要担心，即使装饰器永远到达不了 stage-3/4 阶段，它也不会消失的。有相当多的框架都是装饰器的重度用户，如Angular、NestJS、MidwayJS等。对于装饰器的实现与编译结果会始终保留，就像JSX一样。如果你对它的历史与发展方向有兴趣，可以读一读是否应该在 production 里使用 typescript 的 decorator？（贺师俊贺老的回答）

和类的私有成员、静态成员提案一样，目前使用最广泛的还是 TS 中的装饰器，但是二者的语义完全不同，因此原生装饰器的提案不太可能会影响 TypeScript 到 JavaScript 的编译结果。

Iterator Helpers （stage 2）

proposal-iterator-helpers提案为ES中的Iterator使用与消费引入了一批新的接口，虽然实际上，如 Lodash 与 Itertools（思路来自于Python3中的 itertools）这样的工具库已经提供了绝大部分能力，如 filter、filterMap 等。其他语言如 Rust、C# 中也内置了非常强大的Iterator Helpers，见Prior Art。

示例：

function* naturals() {

let i = 0;

while (true) {

yield i;

i += 1;

}

const evens = naturals()

.filter((n) => n % 2 === 0);

for (const even of evens) {

console.log(even, ‘is an even number’);

}

虽然目前很少会直接和 Generator、Iterator 打交道了，但这些毕竟是语言底部的东西，了解其基本使用与运行机制还是有好处的。

throw Expressions (stage 2)

proposal-throw-expressions这一提案主要提供了 const x = throw new Error() 这一语法，但这并不是 throw 语法的替代品，更像是 **面向表达式(Expression-Oriented) ** 能力的补齐。

function getEncoder(encoding) {

const encoder = encoding === “utf8” ? new UTF8Encoder()

encoding === “utf16le” ? new UTF16Encoder(false)

encoding === “utf16be” ? new UTF16Encoder(true)

throw new Error(“Unsupported encoding”);

}

Upsert(Map.prototype.emplace) (stage 2)

proposal-upsert这一提案为 Map 引入了 emplace 方法，在当前 Map 上的key已存在时，执行更新操作，否则执行创建操作。确实是很甜的语法糖，感觉底层框架、工具库用 Map 多一些。

Observable (stage 1)

proposal-observable这一提案，其实懂的同学看到 Observable 这个词已经懂这个提案是干啥的了，它引入了 RxJS 中的Observable、Observer（同样是next/error/complete/start）、Subscriber(next/error/complete)等概念，当然还有 Operators（但目前只是部分），同样支持高阶Observable，以及在被订阅时才会开始推送数据（Lazy-Data-Emitting）。

function listen(element, eventName) {

return new Observable(observer => {

// Create an event handler which sends data to the sink

let handler = event => observer.next(event);

// Attach the event handler

element.addEventListener(eventName, handler, true);

// Return a cleanup function which will cancel the event stream

return () => {

// Detach the event handler from the element

element.removeEventListener(eventName, handler, true);

};

});

}

估计是因为还在 stage1 的关系，目前支持的操作符只有of、from这种最基础的，但按照这个趋势下去RxJS中的大部分操作符都会被吸收过来。个人感觉需要非常久的时间才能看到未来结果，因为 RxJS 拥有的海量操作符可不是说着玩的，如果全都要吸收过来可能会吃力不讨好的。同时，RxJS的学习成本还是有的，我不认为大家会因为它被吸收到JS语言原生就会纷纷开始学习相关概念。

Do Expression (stage 1)

proposal-do-expressions这个提案和 throw Expressions 一样，都是面向表达式（Expression-Oriented）的语法，函数式编程的重要特性之一。

看看示例代码：

let x = do {

let tmp = f();

tmp * tmp + 1

};

let y = do {

if (foo()) { f() }

else if (bar()) { g() }

else { h() }

};

对于像笔者一样没接触过函数式编程的同学，这种语法可能确实很新奇有趣，但提案中还存在着一些注意点：

在do {}中不能仅有声明语句，或者是缺少 else 的if，以及循环。
空白的do {}语句效果等同于void 0。
await/yield标识继承自上下文

对于异步版本的do expression，存在一个尚未进入的提案proposal-async-do-expressions，旨在允许使用async do {}的语法，如：

// at the top level of a script

async do {

await readFile(‘in.txt’);

let query = await ask(‘???’);

// etc

}

Pipeline Operator (stage 1)

目前star最多的提案，似乎没有之一？

proposal-pipeline-operator提案引入了新的操作符|>，目前对于具体实现细节存在两个不同的竞争提案。这一语法糖的主要目的是大大提升函数调用的可读性，如 doubleNumber(number) 会变为 number |> doubleNumber 的形式，对于链式的连续函数调用更是有奇效，如：

function doubleSay (str) {

return str + ", " + str;

}

function capitalize (str) {

return str[0].toUpperCase() + str.substring(1);

}

function exclaim (str) {

return str + ‘!’;

}

在管道操作符下，变为如下形式：

let result = exclaim(capitalize(doubleSay(“hello”)));

result //=> “Hello, hello!”