Node is single-threaded + async-everything which gives you simple concurrency with the async/await abstraction. It's these there things that come together to make building async apps simple. For example, I went out of my way to avoid Node before it had promises and async/await, and that seems to be the Javascript most HN users remember.

Concurrency in this situation almost becomes free at the expense of changing

    user = db.findUser(42)

to

    user = await db.findUser(42)

So when writing programs where you want more than one I/O thing to be happening at a time whether it's network requests or a bunch of concurrent workers, which is pretty much why you'd use Node, you get it trivially.

Even something like running parallel DB queries trivially inside an Express route:

    const [a, b] = Promise.all([db.findUser(42), db.somethingElse()])

Or starting one async early, waiting on another, and then ensuring that the first async thing is done later on:

    const a = runA() // returns a promise
    const b = await runB()
    return [a, await b]

And once again I think this is the a great example of a useful abstraction when writing anything with an I/O boundary:

    const results = await all(urls, url => crawler(url), { concurrency: 8 })

That code in Go would take me 40 lines and involve wait groups.

Compare that to Netty or trying to write async code in Rust where it's really easy to block the event loop because all libraries and stdlib are sync by default. So you're passing around a CPU pool to run sync code inside your async context. It's hard to look at that sort of code and understand its runtime behavior. Oops, you accidentally blocked. Oops, the pool gets saturated immediately and starts blocking. It's hard to straddle both worlds, and the code is constantly trying to "return to its sync default" so you have to be eternally vigilant. Sync isn't necessarily the default you want, either.

Of course, this comes with other expenses like needing to run one process per core and you can't do CPU-bound work in-process. But you may be used to that limitation using Ruby or Python for example.

I'm not trying to start a language war or tell you that you should drop what you're doing to use Node because it's The Best.

What I'm responding to is this idea that you couldn't possibly have a technical reason to use Node given a choice unless you're fresh out of a boot camp and know no better.

Node + Express is just fine for the same sorts of things that Sinatra is fine for. If you are more comfortable in JS than Ruby, please know that you have my full encouragement and support.

However, you are (perhaps unintentionally) twisting my words. I brought up bootcamps because I can demonstrate a strong causal association on a timeline.

The beef, such as it is, is with the 750k npm packages, the brutal moving target that is the packaging/transpiling/dependency hell/OCD bikeshedding that comes with a commitment to the JS ecosystem. And given that you used to be a Rails user, you know full well what giving up sane defaults in favour of the pursuit of pure compositional bliss looks like, but you're choosing to forget the trauma.

Meanwhile, there's an entire generation of new devs that have been told that Rails (or your favourite server side alternative) have been eclipsed by better thinking. I don't think I'm just an angry old man screaming at cars from my porch when I call bullshit.

Javascript is good for async code, still not sure why this is a great thing by default. It's nice when you want to write async code, do you always want to write async code? For most web apps I've seen you simply don't need to write them in such a way. Blocking IO will switch to a different thread in most ruby web servers anyway.