[pachico]

I'm not a big fan of JavaScript but I admit I stayed away from it because I dislike nodejs and npm terribly.

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!

[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

[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.

[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.

[Quothling]

We use Typescript for virtually everything at my place of work. Not so much because it's a great language for the a lot of the backend, and we do use some c++ for bottlenecks, but because it's so much more productive to use a single language when you're a small team. Not only can everyone help each other, we can also share resources between the front and the back end, and we've several in-house libraries to help us with things like ODATA querying and API's since there aren't really any public packages that are in anyway useful for that. I guess we probably should've gone with something other than ODATA, but since we use a lot of Microsoft graph APIs which despite their names are ODATA, it made sense at the time. We don't have trouble with Node or NPM, and when we onboard new people, the tend to step right into our setup and like it. Granted, we've done some pretty extensive and very opinionated skeleton projects that you have to use if you want to pass the first steps in our deployment pipeline. This took a little bit of effort, and it's still a team effort to keep our governance up to something we all agree on, but with those in place, I've found it's genuinely a nice way to work. An example of how strict we are is how you can't have your functions approved without return types and you certainly can't change any of the linting or Typescript configs. Similarly you can't import 3rd party NPM packages which aren't vetted first, and we have no auto-update on 3rd party packages with out a two week grace period and four sets of human eyes. I'm not going to pretend that a all of these choices are in anyway universal, but it's what we've come together and decided works for us.

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.

[mattferderer]

Curious to hear your opinion on ODATA after using it on your projects. Pros, cons, anything.