引言

所周知，JavaScript社區(qū)喜歡進行熱烈的辯論。四年來，我們?nèi)绾谓M織代碼的問題上一直存在一個分歧——這是一個基本但令人意外地有爭議的問題，繼續(xù)將開發(fā)者分開。

這種分歧圍繞著 CommonJS 和 ES 模塊，這是兩個用于劃分 JavaScript代碼的主要系統(tǒng)。

理解這個分歧

當JavaScript最初被發(fā)明時，它的主要角色是作為Web瀏覽器的腳本語言。但是，隨著Node.js的出現(xiàn)，似乎展現(xiàn)出了一系列的可能性。

現(xiàn)在，它不僅僅是一個瀏覽器的語言。它可以為服務(wù)器和其他應(yīng)用程序提供動力。

在那種情境下，瀏覽器中的所有東西都在全局作用域中，你不必過多地考慮模塊。但是構(gòu)建一個復(fù)雜的服務(wù)器應(yīng)用程序并不那么簡單。你不能把所有的代碼都打包在一個文件中——那將是一個噩夢。

出現(xiàn)的解決方案？一個叫做CommonJS的模塊系統(tǒng)。

const moduleA = require('./moduleA');

CommonJS 使用一個叫做 require 的函數(shù)，允許你從其他文件中提取 JavaScript并訪問從它們導(dǎo)出的函數(shù)。

然而，JavaScript 很快用ES6——適應(yīng)了這些想法，以滿足Web應(yīng)用程序的需求。他們引入了import和export。

import moduleA from './moduleA';

現(xiàn)在，你可能會納悶，為什么JavaScript沒有堅持已經(jīng)在使用的require調(diào)用呢？

require 的問題在于它是同步的，并假設(shè)所有文件都已經(jīng)準備好。但是，在瀏覽器上下文中，你可能需要等待外部資源時，require的同步性質(zhì)會讓系統(tǒng)崩潰。

因此，分裂開始了。

兼容性難題

大多數(shù)開發(fā)者轉(zhuǎn)向ES模塊，因為它們不僅是新穎的，而且很有趣。但一個相當大的群體仍然堅持使用CommonJS。這種分裂導(dǎo)致了兼容性問題。

如果你在ES模塊內(nèi)部運行，你可以沒有問題地導(dǎo)入CommonJS。但是，使用CommonJS導(dǎo)入ES模塊是不行的——除非你采用一個模擬導(dǎo)入的異步函數(shù)解決方法。

const moduleA = await import('./moduleA');

打包器的作用

像Babel或TypeScript這樣的打包器或轉(zhuǎn)譯器為這個復(fù)雜問題增加了另一層，你寫的內(nèi)容取決于你發(fā)出的內(nèi)容。你可以用ES模塊寫，但發(fā)出 CommonJS。

// Babel或TypeScript編譯器將ES模塊轉(zhuǎn)換為CommonJS
const moduleA = require('./moduleA');

如果你在構(gòu)建的代碼中看到 require調(diào)用，你就是在發(fā)出 CommonJS，而import和export的存在表示你是ES模塊的未來的一部分。

未來屬于ES模塊

在吸引了開發(fā)者注意的新工具中，bun 是亮點。bun 的主要亮點在于，它已經(jīng)解決了CommonJS 和 ES 模塊之間的互操作性問題。但是，這個修復(fù)并不完全符合規(guī)范——他們只是為了讓它工作而修補了CommonJS和ES模塊之間的問題。

由于支持這些不同的模塊系統(tǒng)，JavaScript工具鏈可能非常復(fù)雜。

采用ES模塊，你正在簡化Web開發(fā)。所有的Node.js長期支持版本現(xiàn)在都使用ES模塊，這標志著一個明確的海變。

盡可能使用ES模塊?，F(xiàn)在是時候結(jié)束這種分裂，擁抱未來了?，F(xiàn)代JavaScript，統(tǒng)一的JavaScript。

如果你一直在使用或考慮使用 CommonJS，可能是時候仔細看看你的代碼了。未來是一個有ES模塊的地方，我們每個人都有責(zé)任使 JavaScript 的景觀變得更加簡單和有趣。

以上就是JavaScript分水嶺CommonJS 對比ES模塊分析的詳細內(nèi)容，更多關(guān)于JavaScript CommonJS 對比ES的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論