量化指標是與非：挽救被量化指標扼殺的技術團隊
作者 | 劉新翠整理 | 徐杰承本文整理自快狗打車技術總監劉新翠在WOT2023大會上的主題分享，更多精彩內容及現場PPT，請關注51CTO技術棧公眾號，發消息【WOT2023PPT】即可直接領取
所周知，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模塊轉換為CommonJSconst moduleA = require('./moduleA');如果你在構建的代碼中看到 require調用，你就是在發出 CommonJS，而import和export的存在表示你是ES模塊的未來的一部分。
在吸引了開發者注意的新工具中，bun 是亮點。bun 的主要亮點在于，它已經解決了CommonJS 和 ES 模塊之間的互操作性問題。但是，這個修復并不完全符合規范——他們只是為了讓它工作而修補了CommonJS和ES模塊之間的問題。
由于支持這些不同的模塊系統，JavaScript工具鏈可能非常復雜。
采用ES模塊，你正在簡化Web開發。所有的Node.js長期支持版本現在都使用ES模塊，這標志著一個明確的海變。
盡可能使用ES模塊。現在是時候結束這種分裂，擁抱未來了。現代JavaScript，統一的JavaScript。
如果你一直在使用或考慮使用 CommonJS，可能是時候仔細看看你的代碼了。未來是一個有ES模塊的地方，我們每個人都有責任使 JavaScript 的景觀變得更加簡單和有趣。
本文鏈接：http://www.www897cc.com/showinfo-26-17641-0.htmlJavaScript的大分水嶺:CommonJS vs ES模塊
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號