It's 2024; #JavaScript #libraries should be shipping #ESModules *only*
I'd like to spend some more time with #WebComponents, #ServiceWorkers, #WebSockets, #OffscreenCanvas, #WebWorkers, #WebGPU, #SVG, and the #GamePad #API.
I've been noodling for a long time about how you could build a game using #ESModules, and #CustomElements to allow players to author their own components to extend the game.
I guess I'm just more interested in how the game works mechanically than how it looks.
Is it wrong if I'm kind of enjoying the drama about #ljharb?
Burn tc39 down! Make the web anew!
The only standard is death comes to everything!
> enough libraries use ES Modules that for many projects you need to either use ES Modules, or figure out how to interoperate ES Modules with your CommonJS code. At the same time, enough code still uses CommonJS that you often need to figure out how to include that legacy code in your otherwise-ES Module project.
https://borischerny.com/javascript,/typescript/2024/06/19/ES-Modules-Are-A-Mess.html
> Babel has stayed on CJS until now because that allows deferring loading modules until they’re needed for performance: While that’s possible with ESM, it has much worse ergonomics.
https://thenewstack.io/how-javascript-is-finally-improving-the-module-experience/
Here’s a niche gotcha with the clipboard API’s `navigator.clipboard.writeText()` method that’s unique to Safari:
If you access a function from a module within your gesture handler (e.g., click handler), you will get a permission error.
The (sadly hacky and not as robust) workaround is to set a global variable from your module instead.
Full gist:
> Support for require()ing ESM graphs is now exposed by default in Node.js 22