"Async all the things" concurrency doesn't matter.
Javascript is not going to be faster than Go or Rust, which are increasingly taking over as web backends. (I'm writing stuff in Rust's Iron framework lately.) Or Java, for that matter.
I can serve more requests from these languages than "concurrent" Javascript.
I don't doubt that you can.
But in a lot of situations, as long as the slow stuff like db queries and api calls don't block, it's good enough.
And that's easier to accomplish in JS.
What does it mean that it "comes with the language"? In what way is Javascript the language any more asynch than Python, PHP, or Ruby? The browser and Node environment are not JS the language. They are the environments JS predominantly runs in, and they provide async events, which could be done with any language running in similar environments.
This has only been the case for a few years, since the ECMAScript Xs, which is why I think you're being downvoted. To be fair, it's a relatively new feature in Python too.
To me, it's the event-driven problems JS tries to solve that seems to overlap with typical server functionality. That has been true since the beginning.
What, that you clicked a button and JS did something back in 95 when Netscape introduced it? The same could be said for Visual Basic for any language that had callback code attached to a button click. You do realize that Python, Perl, etc could be written to handle GUI code back then as well.
JS has been focused on event handling types of problems while python and perl were used for many other types of problems. You can build a GUI with R, but it wasn't made for it.
Javascript is not going to be faster than Go or Rust, which are increasingly taking over as web backends. (I'm writing stuff in Rust's Iron framework lately.) Or Java, for that matter.
I can serve more requests from these languages than "concurrent" Javascript.