by bcherny on 6/20/24, 11:40 AM with 218 comments
by bastawhiz on 6/20/24, 1:36 PM
I had been using adminjs at work. Their new major version was ESM-only, and it was easier to _write a new admin panel from scratch_ than it was to refactor our entire codebase to be ESM just so we could upgrade one library. I expect that's the situation at hundreds of thousands of other companies.
Like for all the belly aching that happened over async functions (and the whole function color rant), synchronous and asynchronous functions work together just fine through plain old promises. You can easily use async functions alongside functions that use old fashioned callbacks. ESM vs CJS is a file coloring (versus function coloring) problem, but there's no interoperability. There's no escape hatch when you just need one file to use another file but their colors are incompatible.
by knallfrosch on 6/20/24, 1:08 PM
All of that is something that I consider to be platform-level. It's insane that millions of feature-writing devs are expected to know all these arcana.
Then again, it might be fixed™ soon Ⓡ
https://joyeecheung.github.io/blog/2024/03/18/require-esm-in...
by jakubmazanec on 6/20/24, 3:42 PM
[1] https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3...
[2] https://nodejs.org/api/packages.html#packages_dual_package_h...
by jeswin on 6/20/24, 1:37 PM
But I do believe they got the syntax wrong - should have been "from fs import { readFile }" so that auto-complete works. Python got that right, but that's the only thing Python got right ;)
by gbuk2013 on 6/20/24, 1:35 PM
Parent article mentions static analysis and synchronous loading on startup but that has never been an issue for me despite building some large and complex Node apps over the years.
I’ve looked into this in the past but all I could find are strong opinions without solid technical reasoning.
by can3p on 6/20/24, 1:29 PM
The proposal to disable node.js style imports will just split ecosystem and make a large part of industry stick to ancient version / make a fork. Is that really worth the gain? Just check how long it took some bigger projects to migrate from python2 to python3
by apitman on 6/20/24, 7:08 PM
1. I'm developing a library that depends on d3js
2. I want the library to be usable without any build tools. Just clone my repo and host the files from a static server. Or just import directly from jsdelivr
3. I also want people to be able to use NPM to install my library if they so choose
The problem is if I vendor d3js, then developers who consume my library via NPM might end up with 2 copies of d3js in their app, if their app also uses d3 directly. But if I don't vendor it, then my ESM-only users have to use an import map to resolve the bare specifier in the browser, which is kind of ugly and confusing.
More details: https://stackoverflow.com/q/78645299/943814
by righthand on 6/20/24, 1:47 PM
It hasn’t changed because it’s not a real problem. This is like forcing main as the default branch in git.
by Aeolun on 6/20/24, 1:03 PM
The extensions were always silly to me. Who changes only a few files to esmodules? You either change your whole project or not at all.
by catapart on 6/20/24, 1:17 PM
by TheRealPomax on 6/20/24, 4:42 PM
by h1fra on 6/20/24, 5:12 PM
by ramesh31 on 6/20/24, 1:03 PM
This will never, ever happen. Too much of the foundational ecosystem relies on it.
by PaulHoule on 6/20/24, 6:36 PM
I’ve worked on a few big React projects but haven’t really looked much into how the build works, I found out upgrading one thing forced me to upgrade other things and I wound up making a lot of changes by hand to the build scripts and figured I’d probably screw something up. Dependencies changing from CommonJS to ESM was probably the most common problem that can frequently solved by version bumps (at risks of adopting changes you don’t want)
At some point I decided to try the alternate path of switching to Vite for a build system since I’ve had good luck working with it for some VR side projects.
It’s funny how you can code on front-end Javascript and not need to learn about CommonJS until something like this hits.
by lenerdenator on 6/20/24, 1:47 PM
by fwlr on 6/20/24, 2:06 PM
Another angle that might be effective: take the most popular aspect of commonjs - `require(‘extensionless-string’)` - and tie it to the least popular aspect, .cjs extensions.
by o11c on 6/20/24, 4:29 PM
It's quite meaningful for dependencies to be fetched asynchronously, but sometimes you really need something to be executed in the order it's written.
by preya2k on 6/20/24, 2:33 PM
by ulrischa on 6/20/24, 2:47 PM
by 999900000999 on 6/20/24, 6:10 PM
It will never happen because it would require coordination and money, but instead of having millions upon millions of different NPM packages, many of which are downright harmful, we should have a careful selection of maybe the top 20,000 or so.
And then maybe call the next generation of node something else, maybe ProJS.
by pictur on 6/20/24, 4:53 PM
by meego on 6/20/24, 5:34 PM
by montroser on 6/20/24, 2:21 PM
And for what? In Node specifically, it's not as if esm actually solves any real problem! In the greater ecosystem, sure it has some benefits, but Node doesn't even have to choose. Just support both at once, like bun and build systems have for a while, and let's move on from this nonsense.
by byt3h3ad on 6/22/24, 4:00 AM
by plopz on 6/20/24, 4:16 PM
by zazaulola on 6/20/24, 10:19 PM
Why do you dislike `require()` so much?
Just imagine a person who doesn't write modules in Node.JS, but he would like his small scripts to be placed in one JS-file - without any additional directories and `package.json`. His script, for example, updates data for a desktop widget, is easily bypassed by standard nodejs modules and he has hundreds of such scripts in his folder. Why does he need all this `import` overhead?
by pcloadletter_ on 6/20/24, 1:35 PM
by tobyhinloopen on 6/20/24, 8:59 PM
by replete on 6/20/24, 3:03 PM
by mirekrusin on 6/20/24, 1:16 PM
by rezokun on 6/20/24, 1:10 PM