引言

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

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

理解這個分歧

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

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

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

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

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

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

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

import moduleA from './moduleA';

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

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

因此，分裂開始了。

兼容性難題

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

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

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

打包器的作用

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

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

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

未來屬于ES模塊

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

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

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

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

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

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

最新評論