IMO, it's the best thing to happen to Node. It (kinda) unifies browser and server syntax, and across competing server-side JS frameworks (Node, Deno, Bun). CommonJS was clearly a NodeJS thing.
We embraced ESM a couple of years back. It was a bit harder earlier on; for example our test frameworks didn't support mocking ESM code well enough. But now there's hardly anything to complain about. There's no going back really - we wouldn't want to.
>IMO, it's the best thing to happen to Node. It (kinda) unifies browser and server syntax, and across competing server-side JS frameworks (Node, Deno, Bun). CommonJS was clearly a NodeJS thing.
what the fuck was the point of unifying this particular thing at such a great PITA cost, when obviously none of node APIs work in the browser?
should things like Buffer be removed too? the browser only has Uint8Array, after all.
ES modules work natively in browsers, which are the slow-moving ships of the ecosystem. Changing course for them is completely unrealistic.
There’s a billion browser clients out there. That ensures that whatever API they ship, an increasing amount of code will be written directly against it. Everybody else just needs to adapt or be seen as incompatible with the baseline of JavaScript.
Show me a real product on the web that does not compile or bundle and uses native modules for code delivery. It's a dead technology that only fragments the ecosystem and makes life harder.
The web is not just for "real products". It's also a platform with tens of millions of hobbyists and dabblers writing HTML and JavaScript.
I promise you they will use any feature that's documented on MDN as being available in all browsers. And ES modules do make life easier for someone who's just writing HTML and JS and doesn't know anything about build tools.
IMO, it's the wrong attitude that we should focus on the professional ecosystem and forget about this use case. Probably most people writing front-end code got their start by creating a HTML file in Notepad (or equivalent) and loading it via file:// into the browser.
Well, that's what I'm talking about. These web standards are not for real use, but for idealists who do not develop real products. And because of their idealistic desires, we ended up with a fragmented ecosystem and made the life of developers more difficult. Good job.
By 'real product' you mean yet another generic 'web app' that does the same as other hundred generic 'web apps' but its marketing team says differently?
It's a great development experience today: no waiting for bundlers, easy inner dev loop, let the Browser do all the loading just like Web 1.0 and JS development was maybe supposed to feel.
It will become more common in products. There are going to be startups that see that great development experience and long for some returns towards "just FTP it to the web server as-is" CI/CD processes. There are going to be more product owners everywhere (startups, Enterprise) that think that HTTP/2+ adoption (or even HTTP/1.1 properly configured) is acceptable in the real world and that they are done with most of the needs for bundling.
Ah, no bundlers, no minification, no types, a dream! So, real product example pls? And how you templating your html? Not JSX, obviously, so, string literals?
Personally, I'm doing no bundlers (of my own code) and no minification in my development loop, but still using types with tsc --watch. Typescript is faster the closer it gets to just "type stripping" (where the target and module formats are both something like `es${currentYear - 2}`, especially in the default emit pattern where the JS files just get output side-by-side the TS files they input). TSX to JS transformation, with Typescript (as the only tool in that chain [0]), isn't much extra work to slow it down. (TSX is a pretty easy transformation from its syntax to simple function calls. The hard part of TSX is getting types right.)
[0] So no Babel, only Typescript. You probably don't need Babel in 2024.
ES modules mean you don't need to bundle your code; you just include your index.js in HTML, and all 30,000 JS files of your project come to the user's browser without trouble or delay (let's wish them luck, lol). Since you're bundling, it doesn't matter which module type you use; CJS has worked with code splitting perfectly for over 10 years. However, it's a pain every time you try to import a CJS library in your ESM or vice versa. The truth is, you can't just drop all legacy CJS packages in most real-world projects.
> “all 30,000 JS files of your project come to the user's browser without trouble or delay (let's wish them luck, lol)”
If only there was something in the HTTP protocol to make it more efficient to load multiple requests from the same server. Alas that must be a pipe dream, and every little image and script is loaded separately.
