It used to be super slow. Like, you cannot imagine how slow it was.

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.

In principle, Javascript on modern JIT can approach roughly 40-80% of the performance of C++, more or less across the board, not just in some toy benchmark. This benchmark is from 2014:

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 seems an optimistic reading of those graphs. As far as I can tell. a lot of them are 20-30% the speed of native, not 40-60%.

For the Firefox graph, none of them are below 35%, only three are below 40%. The average is well above 60%.

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.

Having done it NES-style, I'm kind of glad that server-side JS didn't catch.

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.

is there consensus on whether Node did or did not "catch"? like, sure, it was a launch language of AWS Lambda and Netflix uses it heavily. but every backend person I know uses Go or Python or Ruby, anything other than JS. pretty much only fullstack JS people consistently pick nodejs as first choice - but that's just my POV. I'd love some more definitive numbers.

Node as a tool definitely did catch on: automated testing, package management, REPL integration, bundling etc.

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.

It's absolutely catching on with younger developers who don't want to bother using multiple languages. Anecdotally, like 100% of developers in their 20s at my company push hard for JS.

Its components are part of every developer's toolbox (a lot of really essential command line tools use to be installed with npm). I don't see many backends powered by it, but I'm mostly a Python developer and that certainly biases my samples.

Paypal, Linkedin, Netflix, Uber

>> Server side JavaScript? That’ll never catch.

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.

I did my own "JavaScript Server Pages" using Rhino (JS for Java), which does compilation of JS to java bytecode. It worked great for me. I did two sites using it, then changed job.

Haha

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.

At my first job out of college in 2008 we wrote JS for a desktop app on top of Mozilla's xulrunner platform. At the time I hadn't heard of using JS outside the browser and Node was still a few years off. It was a great experience but Xulrunner got killed by Mozilla and the company had to rewrite in C#.

Just an example of (sort of) non-proprietary, non-browser JS.

But node js is alive now.

He was being sarcastic :)

Whooooosh

Read past sentence 1...