2 ms·
The disappointing part is that all their choices are the correct ones. I want a fresh start for the server side JS ecosystem that’s all ESM code, no NPM, etc et
by afavour 3y ago
The disappointing part is that all their choices are the correct ones. I want a fresh start for the server side JS ecosystem that’s all ESM code, no NPM, etc etc. But you’re right, the momentum simply isn’t ever going to be there to make people switch to such a world.
I comfort myself with the knowledge that unlike Deno and Bun, Node isn’t propped up by VC funding. I can’t justify investing in either because I don’t know that they’re going to be around in the long term.
- spartanatreyu 3y agoThere's a snag in making the correct choices of course. What are correct choices now, turn into incorrect choices tomorrow. Node/Npm is filled with incorrect choices right now that they're keeping around to keep backwards compatibility, and there's no way they're going to do a quick break à la Python 2 -> 3, instead we have a slow transition leaving us with: - CommonJS instead of ESM - No permission system - Callback based APIs (Which have luckily been getting replaced with promise based APIs) - No built-in node-version manager (e.g. nvm) - etc... But as the language evolves, we gain new capabilities that the runtime will take a really long time to adapt to. Looking ahead, these feature will likely change what we want in a runtime's APIs. - Promise cancellation - Better stream APIs - Explicit Resource Management (the `using` keyword, like D's `scope(exit)` and Go's `defer`) - Records and Tuples (to make certain data immutable) - etc...