[nonethewiser]

Can you comment on what you prefer about it? I find npm/js pretty smooth and the rough edges of Deno seem to kill the purported improvements at this point. That was just my gut-take several months ago and I was already steeped in the node/npm ecosystem so I'm curious about your perspective.

[tracker1]

No Byzantine build config files,. As a start. Dependencies are downloaded to a shared location outside your project on demand instead of a separate npm install step.

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.

[pachico]

For starters Deno is much, much faster in both installation and runtime.

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.

[satvikpendem]

How is it faster in runtime? Isn't it all V8 at the end?

[RussianCow]

It's not the JavaScript runtime that's faster but the built-in APIs. Supposedly (I haven't tested this myself), Deno has faster implementations of many Node.js APIs, which I have seen reflected in benchmarks for things like throughput in an HTTP server.

[jokethrowaway]

Same with bun, it looks like node is leaving some performance on the table (maybe for backward compatibility or maybe because nobody bothered to improve it)

[kibibu]

Bun doesn't use V8, so there are other performance differences there

[factormeta]

It is fair to note, that JavascriptCore outperforms V8 already. However, it is in Zig. And Deno is in Rust.

[satvikpendem]

What does that mean, though? Does Deno create an HTTP server in Rust directly?

[DanielHB]

A ton of NodeJS modules are not part of V8 at all, like "fs" or "path" because those don't really make sense in a browser context. Basically everything that is not a W3C standard is probably not implemented in V8.

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.

[OscarDC]

To add to this, a lot of those "W3C API" (most?) (to which I'll also add WHATWG API, like HTML5 - or fetch) have actually no relation to ECMAScript and thus aren't generally in v8 because they are not JavaScript.

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

[DanielHB]

NPM used to be reaaaaaallly bad due to lack of lockfiles and how it used to handle diamond dependencies Added to the propencity of JS projects to have a ton of deps...

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.