Node.js actually had no parallelism at the start, other than the ability to manually spawn new processes. Worker threads were only added in 2018 with v10.5.0, and only stabilized in 2019 with v12.

What Node.js had from the start was concurrency via asynchronous IO. And before Node.js was around to be JavaScript's async IO framework, there was a robust async IO framework for Python called Twisted. Node.js was influenced by Twisted[0], and this is particularly evident in the design of its Promise abstraction (which you had to use directly when it was first released, because JavaScript didn't add the async/await keywords until years later).

[0] https://nodejs.org/en/about

I was referring to the async io from the start, not worker threads. Other langs had their own frameworks for this, including Twisted for Python, but it really makes a difference having that stuff built-in and default.

Async IO is concurrency, not parallelism. And Node.JS is simply a framework for JavaScript, like Twisted is a framework for Python. If you compare a framework to a language, then of course the framework has more stuff built in; but that's hardly a fair comparison.

NodeJS is a separate runtime. It's not really the same language either since import syntax differs from web JS and the standard libs are different. Or in practical terms, you can't copy a lot of browser JS code and expect it to work in NodeJS as-is.

But that's beside the point. Performant web backends are way easier to deal with in NodeJS than in Python. I'm not comparing to Twisted because, even though it looks good, every Python backend I've ever seen was either plain Python or Django, which was also a mess compared to Express.

The amount of breakage in the Node land when doing major package upgrades far exceeds anything seen in Python. And it happens more often, too, because the stdlib is so thin you need way more packages to do anything interesting.

Not saying that Python is great, but Node is even worse.

Yeah, generally I feel like the indentation sensitivity was the right idea (the alternative evidently being worse compiler error messages, bugs like the `goto fail` vulnerability, and greater verbosity) but it causes real difficulties with the REPL, as well as with shell one-liners.

Jupyter fixes the REPL problem, and it's a major advance in REPLs in a number of other ways, but it has real problems of its own.

I agree async is a mess, but for web backends what is wrong with multi-process?

I do not think JS got it right. Node did, by doing async, but the reason for that was that JS did not do threads! It was making a virtue of a deficiency.

I love whitespace for scope.

JS didn't do threads for a reason, though. It's not that the people working on JS had never heard of threads. Java, which JS was named after, was pervasively multithreaded from the beginning. The Microsoft IE folks lived and breathed threads. Opera even had multithreaded JS in 02000 before they took it out.

JS didn't do threads because threads are an error-prone way to write concurrent software. Crockford was a huge influence on its development in the early 02000s, and he had been at Electric Communities; he was part of the capabilities cabal, centered around Mark S. Miller, who literally wrote his dissertation on why you shouldn't use threads and how to structure async code comprehensibly. Promises came from his work, by way of Twisted. Unfortunately, a lot of that work didn't get into JS until well after Node had defined a lot of its APIs.

But this wasn't "making a virtue of a deficiency". JS was intentionally exploring a different approach to structuring concurrent software. You might argue that that approach didn't pay off, but it wasn't some kind of an accident.

I would say that it would be better to offer both options, depending on what you are doing. Not so much for JS's original role in the browser, but threads can be the right approach for a lot of backend tasks.

TCL, which promoted the same approach for the same reasons long before Node, eventually added threading.

That's an excellent point about Tcl; I'm sure it was a strong influence on Brendan's design for JS, though maybe not as strong as Perl, Java, and Scheme.

We clearly need some way to take advantage of manycore, but I'm still not convinced that threading with implicitly shared mutable state is the right default. It isn't even what the hardware implements! Every core has its own cache! It's a better fit to the hardware than a single giant single-threaded event loop is, and I think that accounts for its curent dominance, but there are a lot of other possibilities out there, like transactional memory, explicit asynchronous message-passing interfaces, or (similarly) lots of tiny single-threaded event loops like Erlang (or, maybe, like Web Workers).

Web backends tend to have lots of concurrent connections doing IO-bound things. Processes or OS threads have too much overhead for this; they're more for when you want CPU parallelism with some communication between threads. Thread pools are still only a compromise. So JS with event loops made a lot of sense.

Greenthreading like in Golang is even better cause you get the advantages of OS threads, but that requires a runtime, which is why Rust didn't do that. And I guess it's hard to implement, cause Java didn't have it until very recently.

> Web backends tend to have lots of concurrent connections doing IO-bound things. Processes or OS threads have too much overhead for this

Depends what you are doing, how you are doing it, and how careful you need to be with resources.

The article is about the fact that it is often OK even when done in a particularly inefficient way.

Well yeah it still works with enough hardware, but what I said is why it's usually inefficient.

Java had green threads since the beginning. That's where the term "green threads" came from and why there's a yield() method.

An early Java version had greenthreads, but they were soon removed in like the year 2000. That's pretty much the reason all our Java code at work uses some kind of cooperative multitasking with that painful promises syntax (foo().then(...))