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

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

加載fallback的同時，也會把index.mjs一并加載

而支持module的瀏覽器則只會加載模塊

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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ā)時我們可以無需再用webpack、Rollup、Parcel等打包工具就可以享受原生的模塊化福利，在以下場景建議可以直接使用原生的模塊腳本：

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

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

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

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

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

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

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

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

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

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

盡可能讓你的代碼以細顆?；哪K進行組織。當在開發(fā)時，每個模塊最好不要輸出過多的內(nèi)容。

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

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

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

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

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

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

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

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

此外，使用細顆?；哪K也有助于對接未來的瀏覽器原生打包功能。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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