开始在web中使用JS Modules

译者注：亲测在IE7+到edge，oppo手机自带的浏览器都能够降级而执行fallback.js。不过加载fallback的同时，也会把index.mjs一并加载，而支持module的浏览器则不会加载fallback。

IE系列均会执行fallback.js

加载fallback的同时，也会把index.mjs一并加载

而支持module的浏览器则只会加载模块

有没想过另外一个好处：既然浏览器能够识别module，那它必然也能够支持ES67的其他特性，如箭头函数、async-await。你不需要为这些特性进行babel编译，现代浏览器跑着更小和最大部分未编译的模块化代码，而不兼容的则使用nomodule的降级代码。

上面介绍了模块脚本和传统脚本在语言层面的异同，除此之外，在浏览器加载过程中也有所不同。

模块脚本及其依赖是通过CORS来获取的，也就是说模块脚本一旦跨域就需要加上适当的返回头，比如 Access-Control-Allow-Origin:*。而众所周知，传统脚本则不需要（译者注：还记得传说中的JSONP吗）。

加了async属性会使得脚本在下载过程中不阻塞DOM渲染，而下载完成后立即执行，两个async脚本之间的执行时序不确定，执行时机也不确定，有可能在domContentLoaded之前或者之后。但这一属性对传统的内联脚本是无效的，而对模块的内联脚本却是有效的。

你可能会对前面的 .mjs后缀感到好奇，但是在互联网的世界里，文件后缀并不重要，只要服务器下发的MIME类型( Content-Type:text/javascript)正确就可以。浏览器是通过script标签上的type属性来识别模块脚本的，而不是后缀名。

所以无论使用 .js还是 .mjs都是可以的。但是我们还是建议使用 .mjs，原因有两个：

在开发的时候，可以不需要看代码，通过后缀名非常直观地看出哪些是模块脚本。

nodejs中，ES6的模块化特性仍在实验性阶段，而该特性只支持 .mjs后缀的脚本。

在import一个模块时，后面的相对或绝对路径字符串称为module specifier或import specifier，也就是模块资源路径。

import {shout} from "./lib.mjs";//                  ^^^^^^^^^^^

浏览器对于模块资源路径做了一些限制。不支持类似下面这种只有模块名或部分文件名的资源路径（称之为bare module specifiers）。这样的限制是为了以后浏览器在支持自定义模块加载器之后，加载器能够自行决定bare module specifiers的解析方式。

// Not supported (yet):import {shout} from "jquery";import {shout} from "lib.mjs";import {shout} from "modules/lib.mjs";

目前，模块资源路径必须是完整的URL，或者以 /, ./, ../开头的相对URL

// Supported:import {shout} from "./lib.mjs";import {shout} from "../lib.mjs";import {shout} from "/modules/lib.mjs";import {shout} from "https://simple.example/modules/lib.mjs";

传统脚本的加载和解析会阻塞html的解析，可以通过添加 defer属性解决（让脚本加载和html解析并行）

但这里想告诉你的是，模块脚本默认具备defer的并行功能，因此无需画蛇添足加上defer属性。还有不仅仅只有主模块与html解析并行，其他子模块也一样。

我们之前仅仅用到了静态的 import，它需要在首屏就把全部模块资源都下载下来。但有时候按需加载或异步加载会更为合理，这有助于提高首次加载时间，而 import()可以用来解决这个问题。

不像静态 import只能用在 "一样，动态 import()也可以用在普通的script。具体可以看下我们关于动态import的文章。

NOTE: Webapck自己实现了一套 import()方案，可以动态将import()进去的模块抽离出来，生成多带带的文件。

另一个和JS modules相关的新特性是 import.meta，它能提供关于当前模块的meta信息。准确的meta信息并不是ECMAScript规范指定的部分，它取决于宿主环境。在浏览器拿到的meta信息和在nodejs里面拿到的是有区别的。

下面的例子中，图片的相对路径默认是基于HTML所在位置来解析的，但通过 import.meta.url可以实现基于当前模块来解析。

function loadThumbnail(relativePath) {  const url = new URL(relativePath, import.meta.url);  const image = new Image();  image.src = url;  return image;}const thumbnail = loadThumbnail("../img/thumbnail.png");container.append(thumbnail);

通过模块脚本，开发时我们可以无需再用webpack、Rollup、Parcel等打包工具就可以享受原生的模块化福利，在以下场景建议可以直接使用原生的模块脚本：

开发环境下

不超过100个模块且相对较浅的依赖层级关系（小于5）的小型web应用

然而，我们在性能瓶颈分析中发现，加载一个模块化库（大约300个模块），经过打包的性能数据要比未经过打包直接使用原生模块脚本的好。

其中一个原因是 import/ export语法是可以静态分析的，因此打包工具在打包过程中就可以进行静态分析并移除冗余未使用的模块。从这可以看出，静态的 import/ export不仅仅只是语法特性，还具备关键的工具属性（可静态分析）！

我们的总体建议是继续使用打包工具进行上线前的模块打包处理。毕竟从某种程度上，打包可以帮助你尽可能减少代码体积，用户不必要加载无用的脚本，更有利于页面性能。

开发者工具的代码覆盖率检查能帮助你检测源码中是否存在无用代码。我们同时也建议通过代码分割对模块进行合理拆分，以及延迟加载非首屏关键路径的脚本。

打包与使用模块脚本的权衡取舍

通常在web开发领域，所有方案都有利弊，需要权衡取舍。与加载一个未经过代码拆分的打包脚本相比，使用模块脚本也许会降低首次加载性能（cold cache），但是可以提升用户再次加载（warm cache）的速度。比如对于总大小200KB的代码，在修改一个细颗粒化的模块之后，那么用户只需要更新有变更的代码，这总比重新加载所有代码（打包脚本）要强。

如果相对于首次访问体验来说，你更关注用户再次访问体验，并且你的应用不超过数百个细颗粒化模块的话，你不妨尝试下使用模块脚本，通过性能数据对比之后再做出最后的选择。

浏览器工程师们正努力提升模块脚本的性能，我们希望模块脚本以后能够适用于更多的应用场景。

尽可能让你的代码以细颗粒化的模块进行组织。当在开发时，每个模块最好不要输出过多的内容。

下面的 ./util.mjs模块，输出了 drop pluck和 zip三个函数。

export function drop() { /* … */ }export function pluck() { /* … */ }export function zip() { /* … */ }

如果你的代码仅仅只需要 pluck，你也许会这样引入：

import { pluck } from "./util.mjs";

在这种情况下，如果没有构建打包编译，浏览器会还是会下载、解析和编译整个 ./util.js模块，即使只仅仅需要其中一个export。

如果 pluck不与 drop和 zip有引用或依赖关系的话，最好还是将它独立成一个模块 ./pluck.mjs。以达到无需加载其他无用函数的目的。

export function pluck() { /* … */ }

这不仅能够让你的源码简洁，还能够减少对打包工具（移除冗余代码）的依赖。如果在你的应用中其中一个模块从未被 import过，那么浏览器就不会去下载。而那些真正有用的模块则会被浏览器缓存起来。

此外，使用细颗粒化的模块也有助于对接未来的浏览器原生打包功能。

通过 你可以进一步优化模块加载。浏览器会预加载甚至预解析和编译这些模块及其依赖。

这对于有复杂依赖关系模块的应用尤为重要。没有 rel="modulepreload"，浏览器需要发出多个HTTP请求来计算出整个依赖关系。而如果你把所有依赖模块通过 rel="modulepreload"提前告诉浏览器，那么浏览器则无需再渐进式地去计算。

HTTP/2支持多路复用，多个请求及响应信息可以同时进行传输，这有助于提高模块树的加载效率。

Chrome团队还预研了服务器推送——另一个HTTP/2特性，是否能够作为部署高度模块化应用的一个可行方案。但结局令人失望，HTTP/2的服务器推送比想象中要难以应用，并且web服务器及浏览器的对其实现目前并没有针对高度模块化web应用进行优化。另一方面，服务器很难只推送未被缓存的资源。如果通过告知服务器完整的用户缓存状态来解决这个问题的话，又存在隐私泄露风险。

无论如何，采用HTTP/2协议吧！只要记住目前HTTP/2的服务器推送目前还不能作为一个好的解决方案。

JS modules正在缓慢地被接纳使用。我们的使用统计显示只有0.08%（不包括动态 import()或者worklets）的页面目前使用了 。

Chrome团队正在通过不同的方式，致力于提高基于JS modules的开发体验。下面列举其中的几种。

我们提交了一版对于目前模块解析算法的优化。新算法目前已经被同时列入了HTML规范和ECMASciprt规范，并且已在Chrome 63版本中实现。希望这项优化能够在更多的浏览器中落地。

新算法更快更高效，旧算法在计算依赖图谱（dependency graph）大小的时间复杂度为O(n²)，在Chrome中的实现也是一样。而新算法则提升至O(n)。

此外，新算法在报解析错误时更加准确。如果一个依赖图谱中有多个错误，那么基于旧算法，每次执行都会报不同的解析错误。这给开发调试带来不必要的困难。新算法则保证每次执行都会报相同的解析错误。

Chrome实现了worklets，允许web开发者自定义那些在浏览器底层的硬编码逻辑。目前开发者可以将一个JS模块引入到渲染管道（rendering pipeline）或者音频处理管道。

Chrome65版本支持了 PaintWorklet，也称为CSS绘制API（the CSS Paint API），用于控制如何绘制一个DOM元素。

const result = await css.paintWorklet.addModule("paint-worklet.mjs");

Chrome66版本支持了 AudioWorklet，允许开发者注入自定义的音频处理代码。同时这个版本开始了 AnimationWorklet的公测，开发者可以创造视差滚动效果(scroll-linked)以及其他高性能程序动画（procedural animations）。

最后， LayoutWorklet，又称为CSS布局API（the CSS Layout API）已在Chrome67版本中实现。

我们正在对Chrome中的web workers支持传入模块脚本。你可以通过输入 chrome://flags/#enable-experimental-web-platform-features开启这个特性。

const worker = new Worker("worker.mjs", { type: "module" });

在shared workers和service workers传入模块脚本也即将支持。

const worker = new SharedWorker("worker.mjs", { type: "module" });const registration = await navigator.serviceWorker.register("worker.mjs", { type: "module" });

在nodejs/npm中，我们经常会通过它们的包名引入模块，比如：

import moment from "moment";import { pluck } from "lodash-es";

根据现行的HTML规范，类似上述的包名写法（bare import specifiers）会抛出异常。我们提交的“包名映射表”提案将会支持上述写法（包括在生产环境）。该映射表（JSON格式）将帮助浏览器将包名转换为完整资源路径（full URLs）。

包名映射表目前仍处于提案阶段（proposal stage）。

Chrome loading团队正在探索一种原生的web打包格式（下称为web packaging），作为一种新模式来分发web应用。web packaging的主要特性如下：

Signed HTTP Exchanges：可以让浏览器信任某个HTTP请求对（request/response）确实是来自于所声明的源服务器。

Bundled HTTP Exchanges：是多个请求对的集合，不要求当中的每个请求都进行签名（signed），只要携带某些元数据（metadata）用于描述如何将请求束作为一个整体来解析。

两者结合起来，这种web打包格式就能够将多个同源资源安全地整合到一个HTTP GET相应中。

市面上的打包工具如webpack、Rollup、Parcel，都会将多个模块最终打包成一个或少数几个bundle，这会导致源码中进行的模块拆分在上线后就丧失了它的意义。那么通过原生打包，浏览器可以将bundle反解成原样。

简单来说，你可以把一个HTTP请求对包（Bundled HTTP Exchange）理解为一个资源文件包，它可以通过目录表（manifest）随意访问，并且里面的资源能够被高效地缓存以及根据相对优先级的高低来标记。有了这个机制，原生模块能够提升开发调试的体验。当你在Chrome开发者工具查看资源时，浏览器会精准定位到原生的模块代码中，而不需要复杂的source-map。

Chrome已经实现了一部分提案（SignedExchanges），但是打包格式（bundling format）以及在高度模块化app中的应用仍在探索阶段。

移植新的功能和API到浏览器中无可避免会带来持续性的维护成本以及运行成本。每一个新特性都会污染浏览器的命名空间，增加启动开销，并且也增大引入bug的可能性。Layered APIs的目的是以一种更具扩展性的方式通过浏览器来实现或移植一些高级API。而模块脚本是实现Layered APIs的一项关键技术。

由于模块是显式引入的，所以通过模块来引入layered APIs可实现按需使用（不会默认内置）。

模块的加载源可自定义，因此layered APIs实现了一套自动加载polyfill（当不支持时）的机制。

模块脚本和layered APIs如何协同运作，具体细节仍在制定中，但目前的协议如下：

这个模块脚本引入了 virtual-scrollerAPI，如果浏览器支持则会直接读取内置layered APIs集合（std:virtual-scroller），反之则网络加载对应的polyfill。

译者：对于Layered APIs更多的中文介绍 https://zhuanlan.zhihu.com/p/...

此文已由腾讯云+社区在各渠道发布

获取更多新鲜技术干货，可以关注我们腾讯云技术社区-云加社区官方号及知乎机构号