I was forced to start coding again in JS some weeks ago and I wanted to try Deno. I must say it's been a very smooth and fast experience so far. Very well done!
I am not sure if I'll have the chance to exploit other features it has (besides the built-in dotenv support).
Not so many years ago, even installing npm wasn't straight forward.
Like, for example, I recently found out that there are 3 separate ReadbleStream objects in NodeJS, one from "stream" (older one used in Request), one from "stream/web" (W3C standard, used by global.fetch()) and another one I forgot where it comes from. It doesn't help that two of them have the same name and you run into errors like "ReadableStream is not of type ReadableStream".
I assume the one from "stream/web" directly calls into V8 APIs because since it is a standard it would be implemented in V8 (it is used in the browser's window.fetch() after all). While the one from "stream" is built and maintained by NodeJS Foundation.
It is not really reasonable to expect the NodeJS Foundation to have enough resources to optimise all this modules to the max. And the W3C doesn't seem interested in building standards for server-side only things.
Those API could be thought as from the "environment" in which JavaScript run. For example we often call web-only APIs "DOM API": `fetch`, `xmlHttpRequest` and so on.
Node.js also has its own environment. For example both `setTimeout` and `setInterval`, though present in both web and node.js, are implemented differently by browsers and node.js (it's just that node.js decided to go with roughly the same API - see below for code examples for both).
Taking requests as examples there are both declared in blink, the rendering engine and not v8 again because they aren't JS:
- fetch (https://source.chromium.org/chromium/chromium/src/+/main:thi...)
- XMLHttpRequest (https://source.chromium.org/chromium/chromium/src/+/main:thi...)
For the fun of looking even more at some code of reputable projects: for setTimeout / setInterval, I would guess they are declared here in blink: https://source.chromium.org/chromium/chromium/src/+/main:thi...
And maybe here for Node.js: https://github.com/nodejs/node/blob/8a41d9b636be86350cd32847...
To note that "filesystem" API also exist in web world: https://fs.spec.whatwg.org
Again, this API is completely different than in Node.JS
TypeScript and esm/cjs usage without crazy syntax (writing modules, consuming cjs at least).
Lintinng and formatting in the box.
Can do shell scripts without package.json and nom install, just a shebang line at the top.
These are some of the things I like better.
It has mostly been sorted out by all package managers. The node_modules debacle is still a hotly contested topic, it creates a lot of problems, but it also solves a lot of them compared to alternative approaches.
Then you have install performance which is mostly fine by now in all package managers, but if you really have problems with it you can use pnpm or yarn2.
As the python ecosystem grows and dependency trees move away from "django only" you can see they having the same types of problems that JS used to have.
Anyway you're certainly not alone in your opinion, but I think that a lot of the bad reputation with Node and NPM comes from the amount of "change management" you need to do to "limit" the vast amount of freedom the tools give you into something that will be workable for your team. Once you get there, however, I've found it to be a much to work with than things like Nuget and dotnet, requirements.txt and python, Cargo and Rust and a lot of others. I do have a personal preference for yarn, but I guess that's mostly for nostalgic reasons. I also very much appreciate that things like PiPy are going down what is similar to the NPM route.