譯者注：親測(cè)在IE7+到edge，oppo手機(jī)自帶的瀏覽器都能夠降級(jí)而執(zhí)行fallback.js。不過加載fallback的同時(shí)，也會(huì)把index.mjs一并加載，而支持module的瀏覽器則不會(huì)加載fallback。

IE系列均會(huì)執(zhí)行fallback.js

加載fallback的同時(shí)，也會(huì)把index.mjs一并加載

而支持module的瀏覽器則只會(huì)加載模塊

有沒想過另外一個(gè)好處：既然瀏覽器能夠識(shí)別module，那它必然也能夠支持ES67的其他特性，如箭頭函數(shù)、async-await。你不需要為這些特性進(jìn)行babel編譯，現(xiàn)代瀏覽器跑著更小和最大部分未編譯的模塊化代碼，而不兼容的則使用nomodule的降級(jí)代碼。

上面介紹了模塊腳本和傳統(tǒng)腳本在語言層面的異同，除此之外，在瀏覽器加載過程中也有所不同。

模塊腳本及其依賴是通過CORS來獲取的，也就是說模塊腳本一旦跨域就需要加上適當(dāng)?shù)姆祷仡^，比如 Access-Control-Allow-Origin:*。而眾所周知，傳統(tǒng)腳本則不需要（譯者注：還記得傳說中的JSONP嗎）。

加了async屬性會(huì)使得腳本在下載過程中不阻塞DOM渲染，而下載完成后立即執(zhí)行，兩個(gè)async腳本之間的執(zhí)行時(shí)序不確定，執(zhí)行時(shí)機(jī)也不確定，有可能在domContentLoaded之前或者之后。但這一屬性對(duì)傳統(tǒng)的內(nèi)聯(lián)腳本是無效的，而對(duì)模塊的內(nèi)聯(lián)腳本卻是有效的。

你可能會(huì)對(duì)前面的 .mjs后綴感到好奇，但是在互聯(lián)網(wǎng)的世界里，文件后綴并不重要，只要服務(wù)器下發(fā)的MIME類型( Content-Type:text/javascript)正確就可以。瀏覽器是通過script標(biāo)簽上的type屬性來識(shí)別模塊腳本的，而不是后綴名。

所以無論使用 .js還是 .mjs都是可以的。但是我們還是建議使用 .mjs，原因有兩個(gè)：

在開發(fā)的時(shí)候，可以不需要看代碼，通過后綴名非常直觀地看出哪些是模塊腳本。

nodejs中，ES6的模塊化特性仍在實(shí)驗(yàn)性階段，而該特性只支持 .mjs后綴的腳本。

在import一個(gè)模塊時(shí)，后面的相對(duì)或絕對(duì)路徑字符串稱為module specifier或import specifier，也就是模塊資源路徑。

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

瀏覽器對(duì)于模塊資源路徑做了一些限制。不支持類似下面這種只有模塊名或部分文件名的資源路徑（稱之為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，或者以 /, ./, ../開頭的相對(duì)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";

傳統(tǒng)腳本的加載和解析會(huì)阻塞html的解析，可以通過添加 defer屬性解決（讓腳本加載和html解析并行）

但這里想告訴你的是，模塊腳本默認(rèn)具備defer的并行功能，因此無需畫蛇添足加上defer屬性。還有不僅僅只有主模塊與html解析并行，其他子模塊也一樣。

我們之前僅僅用到了靜態(tài)的 import，它需要在首屏就把全部模塊資源都下載下來。但有時(shí)候按需加載或異步加載會(huì)更為合理，這有助于提高首次加載時(shí)間，而 import()可以用來解決這個(gè)問題。

不像靜態(tài) import只能用在 "一樣，動(dòng)態(tài) import()也可以用在普通的script。具體可以看下我們關(guān)于動(dòng)態(tài)import的文章。

NOTE: Webapck自己實(shí)現(xiàn)了一套 import()方案，可以動(dòng)態(tài)將import()進(jìn)去的模塊抽離出來，生成多帶帶的文件。

另一個(gè)和JS modules相關(guān)的新特性是 import.meta，它能提供關(guān)于當(dāng)前模塊的meta信息。準(zhǔn)確的meta信息并不是ECMAScript規(guī)范指定的部分，它取決于宿主環(huán)境。在瀏覽器拿到的meta信息和在nodejs里面拿到的是有區(qū)別的。

下面的例子中，圖片的相對(duì)路徑默認(rèn)是基于HTML所在位置來解析的，但通過 import.meta.url可以實(shí)現(xiàn)基于當(dāng)前模塊來解析。

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);

通過模塊腳本，開發(fā)時(shí)我們可以無需再用webpack、Rollup、Parcel等打包工具就可以享受原生的模塊化福利，在以下場(chǎng)景建議可以直接使用原生的模塊腳本：

開發(fā)環(huán)境下

不超過100個(gè)模塊且相對(duì)較淺的依賴層級(jí)關(guān)系（小于5）的小型web應(yīng)用

然而，我們?cè)谛阅芷款i分析中發(fā)現(xiàn)，加載一個(gè)模塊化庫(kù)（大約300個(gè)模塊），經(jīng)過打包的性能數(shù)據(jù)要比未經(jīng)過打包直接使用原生模塊腳本的好。

其中一個(gè)原因是 import/ export語法是可以靜態(tài)分析的，因此打包工具在打包過程中就可以進(jìn)行靜態(tài)分析并移除冗余未使用的模塊。從這可以看出，靜態(tài)的 import/ export不僅僅只是語法特性，還具備關(guān)鍵的工具屬性（可靜態(tài)分析）！

我們的總體建議是繼續(xù)使用打包工具進(jìn)行上線前的模塊打包處理。畢竟從某種程度上，打包可以幫助你盡可能減少代碼體積，用戶不必要加載無用的腳本，更有利于頁(yè)面性能。

開發(fā)者工具的代碼覆蓋率檢查能幫助你檢測(cè)源碼中是否存在無用代碼。我們同時(shí)也建議通過代碼分割對(duì)模塊進(jìn)行合理拆分，以及延遲加載非首屏關(guān)鍵路徑的腳本。

打包與使用模塊腳本的權(quán)衡取舍

通常在web開發(fā)領(lǐng)域，所有方案都有利弊，需要權(quán)衡取舍。與加載一個(gè)未經(jīng)過代碼拆分的打包腳本相比，使用模塊腳本也許會(huì)降低首次加載性能（cold cache），但是可以提升用戶再次加載（warm cache）的速度。比如對(duì)于總大小200KB的代碼，在修改一個(gè)細(xì)顆粒化的模塊之后，那么用戶只需要更新有變更的代碼，這總比重新加載所有代碼（打包腳本）要強(qiáng)。

如果相對(duì)于首次訪問體驗(yàn)來說，你更關(guān)注用戶再次訪問體驗(yàn)，并且你的應(yīng)用不超過數(shù)百個(gè)細(xì)顆粒化模塊的話，你不妨嘗試下使用模塊腳本，通過性能數(shù)據(jù)對(duì)比之后再做出最后的選擇。

瀏覽器工程師們正努力提升模塊腳本的性能，我們希望模塊腳本以后能夠適用于更多的應(yīng)用場(chǎng)景。

盡可能讓你的代碼以細(xì)顆粒化的模塊進(jìn)行組織。當(dāng)在開發(fā)時(shí)，每個(gè)模塊最好不要輸出過多的內(nèi)容。

下面的 ./util.mjs模塊，輸出了 drop pluck和 zip三個(gè)函數(shù)。

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

如果你的代碼僅僅只需要 pluck，你也許會(huì)這樣引入：

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

在這種情況下，如果沒有構(gòu)建打包編譯，瀏覽器會(huì)還是會(huì)下載、解析和編譯整個(gè) ./util.js模塊，即使只僅僅需要其中一個(gè)export。

如果 pluck不與 drop和 zip有引用或依賴關(guān)系的話，最好還是將它獨(dú)立成一個(gè)模塊 ./pluck.mjs。以達(dá)到無需加載其他無用函數(shù)的目的。

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

這不僅能夠讓你的源碼簡(jiǎn)潔，還能夠減少對(duì)打包工具（移除冗余代碼）的依賴。如果在你的應(yīng)用中其中一個(gè)模塊從未被 import過，那么瀏覽器就不會(huì)去下載。而那些真正有用的模塊則會(huì)被瀏覽器緩存起來。

此外，使用細(xì)顆粒化的模塊也有助于對(duì)接未來的瀏覽器原生打包功能。

通過 你可以進(jìn)一步優(yōu)化模塊加載。瀏覽器會(huì)預(yù)加載甚至預(yù)解析和編譯這些模塊及其依賴。

這對(duì)于有復(fù)雜依賴關(guān)系模塊的應(yīng)用尤為重要。沒有 rel="modulepreload"，瀏覽器需要發(fā)出多個(gè)HTTP請(qǐng)求來計(jì)算出整個(gè)依賴關(guān)系。而如果你把所有依賴模塊通過 rel="modulepreload"提前告訴瀏覽器，那么瀏覽器則無需再漸進(jìn)式地去計(jì)算。

HTTP/2支持多路復(fù)用，多個(gè)請(qǐng)求及響應(yīng)信息可以同時(shí)進(jìn)行傳輸，這有助于提高模塊樹的加載效率。

Chrome團(tuán)隊(duì)還預(yù)研了服務(wù)器推送——另一個(gè)HTTP/2特性，是否能夠作為部署高度模塊化應(yīng)用的一個(gè)可行方案。但結(jié)局令人失望，HTTP/2的服務(wù)器推送比想象中要難以應(yīng)用，并且web服務(wù)器及瀏覽器的對(duì)其實(shí)現(xiàn)目前并沒有針對(duì)高度模塊化web應(yīng)用進(jìn)行優(yōu)化。另一方面，服務(wù)器很難只推送未被緩存的資源。如果通過告知服務(wù)器完整的用戶緩存狀態(tài)來解決這個(gè)問題的話，又存在隱私泄露風(fēng)險(xiǎn)。

無論如何，采用HTTP/2協(xié)議吧！只要記住目前HTTP/2的服務(wù)器推送目前還不能作為一個(gè)好的解決方案。

JS modules正在緩慢地被接納使用。我們的使用統(tǒng)計(jì)顯示只有0.08%（不包括動(dòng)態(tài) import()或者worklets）的頁(yè)面目前使用了 。

Chrome團(tuán)隊(duì)正在通過不同的方式，致力于提高基于JS modules的開發(fā)體驗(yàn)。下面列舉其中的幾種。

我們提交了一版對(duì)于目前模塊解析算法的優(yōu)化。新算法目前已經(jīng)被同時(shí)列入了HTML規(guī)范和ECMASciprt規(guī)范，并且已在Chrome 63版本中實(shí)現(xiàn)。希望這項(xiàng)優(yōu)化能夠在更多的瀏覽器中落地。

新算法更快更高效，舊算法在計(jì)算依賴圖譜（dependency graph）大小的時(shí)間復(fù)雜度為O(n2)，在Chrome中的實(shí)現(xiàn)也是一樣。而新算法則提升至O(n)。

此外，新算法在報(bào)解析錯(cuò)誤時(shí)更加準(zhǔn)確。如果一個(gè)依賴圖譜中有多個(gè)錯(cuò)誤，那么基于舊算法，每次執(zhí)行都會(huì)報(bào)不同的解析錯(cuò)誤。這給開發(fā)調(diào)試帶來不必要的困難。新算法則保證每次執(zhí)行都會(huì)報(bào)相同的解析錯(cuò)誤。

Chrome實(shí)現(xiàn)了worklets，允許web開發(fā)者自定義那些在瀏覽器底層的硬編碼邏輯。目前開發(fā)者可以將一個(gè)JS模塊引入到渲染管道（rendering pipeline）或者音頻處理管道。

Chrome65版本支持了 PaintWorklet，也稱為CSS繪制API（the CSS Paint API），用于控制如何繪制一個(gè)DOM元素。

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

Chrome66版本支持了 AudioWorklet，允許開發(fā)者注入自定義的音頻處理代碼。同時(shí)這個(gè)版本開始了 AnimationWorklet的公測(cè)，開發(fā)者可以創(chuàng)造視差滾動(dòng)效果(scroll-linked)以及其他高性能程序動(dòng)畫（procedural animations）。

最后， LayoutWorklet，又稱為CSS布局API（the CSS Layout API）已在Chrome67版本中實(shí)現(xiàn)。

我們正在對(duì)Chrome中的web workers支持傳入模塊腳本。你可以通過輸入 chrome://flags/#enable-experimental-web-platform-features開啟這個(gè)特性。

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中，我們經(jīng)常會(huì)通過它們的包名引入模塊，比如：

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

根據(jù)現(xiàn)行的HTML規(guī)范，類似上述的包名寫法（bare import specifiers）會(huì)拋出異常。我們提交的“包名映射表”提案將會(huì)支持上述寫法（包括在生產(chǎn)環(huán)境）。該映射表（JSON格式）將幫助瀏覽器將包名轉(zhuǎn)換為完整資源路徑（full URLs）。

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

Chrome loading團(tuán)隊(duì)正在探索一種原生的web打包格式（下稱為web packaging），作為一種新模式來分發(fā)web應(yīng)用。web packaging的主要特性如下：

Signed HTTP Exchanges：可以讓瀏覽器信任某個(gè)HTTP請(qǐng)求對(duì)（request/response）確實(shí)是來自于所聲明的源服務(wù)器。

Bundled HTTP Exchanges：是多個(gè)請(qǐng)求對(duì)的集合，不要求當(dāng)中的每個(gè)請(qǐng)求都進(jìn)行簽名（signed），只要攜帶某些元數(shù)據(jù)（metadata）用于描述如何將請(qǐng)求束作為一個(gè)整體來解析。

兩者結(jié)合起來，這種web打包格式就能夠?qū)⒍鄠€(gè)同源資源安全地整合到一個(gè)HTTP GET相應(yīng)中。

市面上的打包工具如webpack、Rollup、Parcel，都會(huì)將多個(gè)模塊最終打包成一個(gè)或少數(shù)幾個(gè)bundle，這會(huì)導(dǎo)致源碼中進(jìn)行的模塊拆分在上線后就喪失了它的意義。那么通過原生打包，瀏覽器可以將bundle反解成原樣。

簡(jiǎn)單來說，你可以把一個(gè)HTTP請(qǐng)求對(duì)包（Bundled HTTP Exchange）理解為一個(gè)資源文件包，它可以通過目錄表（manifest）隨意訪問，并且里面的資源能夠被高效地緩存以及根據(jù)相對(duì)優(yōu)先級(jí)的高低來標(biāo)記。有了這個(gè)機(jī)制，原生模塊能夠提升開發(fā)調(diào)試的體驗(yàn)。當(dāng)你在Chrome開發(fā)者工具查看資源時(shí)，瀏覽器會(huì)精準(zhǔn)定位到原生的模塊代碼中，而不需要復(fù)雜的source-map。

Chrome已經(jīng)實(shí)現(xiàn)了一部分提案（SignedExchanges），但是打包格式（bundling format）以及在高度模塊化app中的應(yīng)用仍在探索階段。

移植新的功能和API到瀏覽器中無可避免會(huì)帶來持續(xù)性的維護(hù)成本以及運(yùn)行成本。每一個(gè)新特性都會(huì)污染瀏覽器的命名空間，增加啟動(dòng)開銷，并且也增大引入bug的可能性。Layered APIs的目的是以一種更具擴(kuò)展性的方式通過瀏覽器來實(shí)現(xiàn)或移植一些高級(jí)API。而模塊腳本是實(shí)現(xiàn)Layered APIs的一項(xiàng)關(guān)鍵技術(shù)。

由于模塊是顯式引入的，所以通過模塊來引入layered APIs可實(shí)現(xiàn)按需使用（不會(huì)默認(rèn)內(nèi)置）。

模塊的加載源可自定義，因此layered APIs實(shí)現(xiàn)了一套自動(dòng)加載polyfill（當(dāng)不支持時(shí)）的機(jī)制。

模塊腳本和layered APIs如何協(xié)同運(yùn)作，具體細(xì)節(jié)仍在制定中，但目前的協(xié)議如下：

這個(gè)模塊腳本引入了 virtual-scrollerAPI，如果瀏覽器支持則會(huì)直接讀取內(nèi)置layered APIs集合（std:virtual-scroller），反之則網(wǎng)絡(luò)加載對(duì)應(yīng)的polyfill。

譯者：對(duì)于Layered APIs更多的中文介紹 https://zhuanlan.zhihu.com/p/...

此文已由騰訊云+社區(qū)在各渠道發(fā)布

獲取更多新鮮技術(shù)干貨，可以關(guān)注我們騰訊云技術(shù)社區(qū)-云加社區(qū)官方號(hào)及知乎機(jī)構(gòu)號(hào)