JavaScript的大分水岭:CommonJS vs ES模块
所周知，JavaScript社区喜欢进行热烈的辩论。四年来，我们如何组织代码的问题上一直存在一个分歧——这是一个基本但令人意外地有争议的问题，继续将开发者分开。
这种分歧围绕着 CommonJS 和 ES 模块，这是两个用于划分 JavaScript代码的主要系统。
理解这个分歧
当JavaScript最初被发明时，它的主要角色是作为Web浏览器的脚本语言。但是，随着Node.js的出现，似乎展现出了一系列的可能性。
现在，它不仅仅是一个浏览器的语言。它可以为服务器和其他应用程序提供动力。
在那种情境下，浏览器中的所有东西都在全局作用域中，你不必过多地考虑模块。但是构建一个复杂的服务器应用程序并不那么简单。你不能把所有的代码都打包在一个文件中——那将是一个噩梦。
出现的解决方案？一个叫做CommonJS的模块系统。
const moduleA = require('./moduleA');
CommonJS 使用一个叫做 require 的函数，允许你从其他文件中提取 JavaScript并访问从它们导出的函数。
然而，JavaScript 很快用ES6——适应了这些想法，以满足Web应用程序的需求。他们引入了import和export。
import moduleA from './moduleA';
现在，你可能会纳闷，为什么JavaScript没有坚持已经在使用的require调用呢？
require 的问题在于它是同步的，并假设所有文件都已经准备好。但是，在浏览器上下文中，你可能需要等待外部资源时，require的同步性质会让系统崩溃。
因此，分裂开始了。
兼容性难题
大多数开发者转向ES模块，因为它们不仅是新颖的，而且很有趣。但一个相当大的群体仍然坚持使用CommonJS。这种分裂导致了兼容性问题。
如果你在ES模块内部运行，你可以没有问题地导入CommonJS。但是，使用CommonJS导入ES模块是不行的——除非你采用一个模拟导入的异步函数解决方法。
const moduleA = await import('./moduleA');打包器的作用
像babel或TypeScript这样的打包器或转译器为这个复杂问题增加了另一层，你写的内容取决于你发出的内容。你可以用ES模块写，但发出 CommonJS。
// Babel或TypeScript编译器将ES模块转换为CommonJS
const moduleA = require('./moduleA');
如果你在构建的代码中看到 require调用，你就是在发出 CommonJS，而import和export的存在表示你是ES模块的未来的一部分。
未来属于ES模块
在吸引了开发者注意的新工具中，bun 是亮点。bun 的主要亮点在于，它已经解决了CommonJS 和 ES 模块之间的互操作性问题。但是，这个修复并不完全符合规范——他们只是为了让它工作而修补了CommonJS和ES模块之间的问题。
由于支持这些不同的模块系统，JavaScript工具链可能非常复杂。
采用ES模块，你正在简化Web开发。所有的Node.js长期支持版本现在都使用ES模块，这标志着一个明确的海变。
尽可能使用ES模块。现在是时候结束这种分裂，拥抱未来了。现代JavaScript，统一的JavaScript。
如果你一直在使用或考虑使用 CommonJS，可能是时候仔细看看你的代码了。未来是一个有ES模块的地方，我们每个人都有责任使 JavaScript 的景观变得更加简单和有趣。
来源： 大迁世界
本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！
