Server side JavaScript? That’ll never catch.
I love these examples of historical calls made too early...
I love these examples of historical calls made too early...
The usual example I trot out is when I was writing a client-side pivot table creator in the mid-2000s, as far as I can remember, with just 100 items the js version took 20-30 seconds. I then tried it using XML/XSLT instead[1] and it was instant.
I haven't checked recently, but even a few years ago javascript is extremely slow with large datasets, I was mucking around with Mandelbrot generators and js compared to C# was like a bicycle vs a jet engine, they weren't even vaguely in the same league performance-wise. Just had a quick look at some js based versions looks like it's got a bit faster, but still slow.
[1] Awesome performance, super hard for others to understand the code. XSLT was great in some ways, but the learning curve was high.
https://blogs.unity3d.com/2014/10/07/benchmarking-unity-perf...
Granted, this benchmark is for generated Javascript, not "idiomatic Javascript" (if there is such a thing). Of course you can write arbitrarily slow Javascript as well. There's a lot of stuff that can throw a wrench into the JIT.
That said, there's a lot going on there. Javascript can not use SIMD or multiple threads. Some tests are heavier on C#, which is converted to C++ in the Javascript version and thus becomes "faster than native C#".
The point is not give an exact number on how fast Javascript is compared to any other language, there's wide variance across usage and implementations. The point is to show that Javascript to rival C# performance is feasible.
Node is an unlikely event. It hit the sweet spot precisely when async started being needed, there was a runtime environment that made it viable (v8, thanks to massive investment by Google on Chrome), and a language that made it kind of natural.
Node as a server/backend language: I would say the say the ecosystem and usage are at least as large as Go/Ruby. This is hard to gauge. But I assume/expect a factor of 2 or more. If you look for web specific libraries it is unlikely you'd find something for either Go/Ruby but not for Node. Python is harder to compare because it is used much more broadly.
For me the biggest use-cases for Node are: server-side/static rendering (get all the power/expression of frontend libraries on your http/build server), web-socket ease of use and the fact that there are tons of programmers who are at least familiar with the language.
And even though it is steadily declining, the most popular web-backend language is still PHP by a long shot. And this won't change until the other languages get managed hosting that is as cheap and simple and similarly ubiquitous.
Server side javascript didn't catch on the first time around because you couldn't create threads. Because in the early 2000's, all technical interviews asked about Java style multi-threading. At some companies, the first round of technical interviews was a very, very detailed discussion about the Java threading model. If you didn't pass, you didn't get to round two. So everybody wanted to use threads.
But I used a few servers that allowed for JS scripting way before Node.
I guess, most of them were proprietary, so it never caught on until Node.
Just an example of (sort of) non-proprietary, non-browser JS.