ESM规范-现在的主导

规范的实现依赖于宿主环境，比如浏览器环境实现了EcmaScript Module（后文简称ESM）规范。

Node v12之前支持CommonJS（后文简称CJS）规范，12之后同时支持CJS与ESM。

在「宿主环境」之上，是基于模块化规范实现的「工具集」，比如webpack、vite、VScode生态。

再往上，基于「工具集」提供的API，可以实现各种工程化工具。比如：

• webpack loader
• VScode plugin
• babel plugin

再往上，就是开发者自己编写的业务代码。

开发者只需要在工具集中配置好工具，就能为业务代码提供服务。比如：

• 在VScode（工具集）中配置eslint（工具），就能在开发时获得相应提示
• 在webpack（工具集）中配置babel loader（工具），就能在开发时使用ES6+语法

可见，理想状态下，在开发者视角是不需要关注底层的「模块化规范」实现的。。

有了服务端模块规范（CJS），很自然的，JS开发者们想为客户端（主要是浏览器）提供一种模块化规范。

然而CJS是为服务端设计的。

在服务端，IO操作通常能迅速完成，所以CJS规范定义的：

模块加载 --> 模块解析 --> 模块执行

这个流程是作为一个整体同步执行的。

然而在浏览器环境，「模块加载」（即数据请求）通常很耗时。

AMD（Asynchronous Module Definition 异步模块定义）规范，就是这样需求背景下的产物。

然而这些社区提出的规范终究只是为了解决一时的需求，随着历史的发展，新的模块化规范不断涌入、消亡，直到ESM规范被提出，ESM规范是ES标准的模块化规范。

现在主流框架用的都是esm规范。

ESM将模块规范分为三个阶段：

模块加载 --> 模块实例化 --> 模块执行

其中「模块加载」由宿主环境提供的loader完成（比如在浏览器环境，loader的行为由HTML规范[4]定义）。

「模块实例化」与「模块执行」由ESM规范定义执行流程。

区别于CJS规范的同步执行，ESM规范将流程拆解为3个独立阶段。

然而，此时社区已经有大量基于CJS规范产出的开源包、组件，他们无法立刻切换到ESM规范。

所以，JS生态的现状是：会处于、并将长期处于CJS规范的库与ESM规范的库共存的状态。

ESM注定是主导。