I've only dipped my toes in the water with Deno, but it solves a few pain points I've felt with Node. Direct deps via url vs npm as middleman, a standard library (thank goodness!), and single binary distribution. Types are great too, but these other things would be enough for me.

> a standard library (thank goodness!)

Then what are all these modules, if not a standard library? https://nodejs.org/api

libuv bindings ?

Honestly a standard library was needed since a decade but... I would have preferred a coordinated effort between browsers and node/deno. At this point even if just the browsers and deno get two different stdlib we risk _a_lot_ of useless fragmentation and headaches.

_If_ the browsers do get a std lib akin to what we've built for deno, I would be comfortable archiving the deno_std repo and pointing people to use the browser one. We're not yet 100% compatible with browsers in the stdlib, but being compatible as much as possible is one of our goals, specifically to address the browser/server-side divide and generally make it simpler and more enjoyable to program in JavaScript

The built-in Typescript support is amazing, but the selling feature for me was the ability to generate static binaries. Shipping is much easier when your built process can produce a single output!

You've been able to do that with Nexe for Node.js apps since basically forever.

Yes but because it's not natively supported there's common issues like https://github.com/nexe/nexe/issues/639.

A NodeJS Docker container is a few lines. I agree Deno's single binary is a nice feature but it's not very interesting for everyone.

Docker is very nice to deploy on docker-dedicated servers, but on legacy app or personal workstations binaries are more flexible

A docker container works for services - but CLI tools are more easily shipped as binaries.

It certainly isn't that interesting for everyone, but for a subset of users it's great!

> a standard library (thank goodness!)

What's a "standard" for you? Whatever definition, I think it implies there are > 1 implementations of it.

Node.js is based on CommonJS APIs, an initiative lead and implemented by earlier server-side JavaScript (SSJS) runtimes at the time such as v8cgi/TeaJs, Helma, etc. until Node.js dominated SSJS around 2011. Remember, SSJS is as old as the hills, starting 1996/7 with Netscape's LifeWire, and arguably has seen even longer use than Java as a mainstream server-side language.

Also not a "standard" in the above sense is TypeScript.

As to "standard library", the core packages on npmjs plus package.json are the standard library of Node.js on top of core Node.js APIs, and were developed in that spirit.

Using the word 'standard' was probably a mistake in my parent comment, I just parroted the terminology from the docs.

Really what I mean by 'standard' in this context is a batteries-included experience for most day-to-day programming problems.

I can appreciate the minimalist view where every project selects a core set of libraries for the given challenge. On the other hand, a core set of libraries that are good enough for most things just reduces decision fatigue, and makes it easier to just code.