Node came out way before any of these features were invented, and the ES committee knowingly broke compatibility when designing for the browser. Modules are supported since v14 but you have to opt in.
ES modules were not only issue with node. There are bunch like no Promises in std library(they are adding that though) standard library is very minimal, so not easy to make a web app without a npm package.
Simple: Not all node packages work in the browser. It'd be great if I could just say "ok this package will work for the browser, period." Also, with a module format that the browser can use (ie ECMAscript 6)
Unfortunately like almost all Node libraries, it isn't very mature or well-maintained. I stopped using it because it was too rigid and missing vital features.
I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. Backwards compatibility is a serious concern.
It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.
I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.
Agree that node/npm are the dumpster fire of JS, but ESM is still going through growing pains too. I have switched off of Node over to Deno. It natively supports ES modules. But most of the time I try to consume an ESM the code was designed to only load in a browser. It gets especially complicated if the ES module is using something like WASM - using FFMPEG via an ESM using WASM is the current use case I'm working on.
Also, Node 12 supported ESM somewhat fine, you just had to use the --experimental-modules flag for Node. If you still have to support Node 12 in 2023 for some odd reason, you probably shouldn't have a problem enabling an experimental flag to support more modern libraries.
Node 10 was truly the last LTS that had zero ESM support, and that support ended 2 and a half years ago.
Node implemented native ES modules behind a feature flag, but it is just awful. They introduced a new file type ".mjs" that gets special handling and has a bunch of arbitrary rules that determines how they can interact with normal node modules. I though I had been following this discussion, but this slipped under my radar for months. For some reason they felt the need to cater to some bizarre dynamic async importing edge cases that no one actually needs.
There are better solutions and NPM developers have implemented one to prove that it just works. It's OK to raise an exception at runtime when a developer tries to do something ridiculous.
Node ESM support REALLY sucks. Node import maps suck (and are poorly documented). Node doesn't support TypeScript out of the box. Node dependency management has always sucked. I've used three different package managers, and I'm sure more will pop up in the future.
I've always loved Node.js. But the unfortunate reality is it sucks to build new projects in it in 2022.
There was no big change on the ESM side. They are still experimental and require the `.mjs` extension. The only change around modules that I am aware of is the update of the V8 engine. It adds support for `import.meta`.
There are still ongoing discussions around Node's ESM support, you can follow the modules repo [0].
ESM interop is inarguable. But these days Node has a test runner and compatibility with browsers (it implements fetch)… I guess I feel like Node is likely to catch up with most of this stuff over the lifetime of any long running project.
Npm is the main thing I dislike about Node though. I hope compatibility is a feature meant for easing transitions, not something the general user base should be embracing.
reply