Hacker News Reader

Comment by ex3ndr | Hacker News Reader

Javascript is plagued with idea that it is slow while it is not. Many devs now have PTSR after arguing day after day that javascript is a good thing and not slow.

Performance is a very important thing in js world for a peace of mind of devs.

View on HN

> Javascript is plagued with idea that it is slow while it is not.

I benchmarked a hello world in .net and node/express, and the .net version was multiple orders of magnitude faster than the node/express version. That's a starting point, and as you add more logic, that gap only grows in my experience. Javascript may be fast _enough_ for many cases, and in a tight JIT loop it may be faster again, but by any measure, js is not quick.

No realistic, decently written, js application would be "orders of magnitude" faster if rewritten in .net.

And until we have a feature parity moderately complex web app written in multiple languages to compare, we'll never know. In the meantime, all we have to go on is basic benchmarks, and I've not ever seen a _single_ benchmark that puts any js, framework or otherwise in the same ballpark as java, .net or go. When I do, I'll happily change my tune, but until then I'll have to stick with what all the numbers I've ever seen say - js is significantly slower.

One example is the techempower benchmarks Fortune section[0]. It's a fairly basic app, but it tests a full stack web app in multiple languages, and it's pretty clear that js is fimrly in the middle of the pack, far behind the compiled options. If you have any sources to the contrary, I'd love to see them.

[0] https://www.techempower.com/benchmarks/#section=data-r21&tes...

JavaScript ranks higher than C# in your benchmark.

See my other response here https://news.ycombinator.com/item?id=33224873

Maybe not .net, but I've worked on 3D graphics in the browser and can say with confidance that rewriting your app in C or C++ could see orders of magnitude perf increase over JS.

There is often a speedup, but maybe not by orders of magnitude. I've usually seen 2x-3x or so.

Comparing a pure js implemention to code using opengl or webgl, I imagine several orders of magnitude difference is likely.

But a decent js implemention of 3D graphics-something would use one of the available tools for such applications. Making the difference considerably smaller.

Or is you experience different?

I've worked with a couple of the 'decent JS implementation of 3D graphics' libraries and, although they're not all like this, the ones I used were not built by people with experience doing low-level performance work. As such, they made some poor architectural decisions that prevented users of the libraries from doing some very basic optimizations that would have increased perf significantly.

The three major blockers I remember were:

1. Render contexts are created on the main thread and the user of the library gets no control over this. This means all driver overhead and library function calls block the main thread, which matters a lot when trying to hit 8ms/frame.

2. Loading textures asynchronously (in another thread, not Javascript async/await) was straight up impossible due to poor architecture. This means app startup was 500ms instead of 5ms. Maybe not a big deal to you, but our use case necessitated quick (a few frames at worst) startup.

3. The renderer used a scene graph, which was hilariously slow to traverse for large numbers of objects. Impossible to optimize by anyone as far as I can tell. Scene graphs just don't work well in JS.

I’m sorry, but I simply don’t buy that. You either measured something unrelated (e.g. framework), or it was a faulty benchmark for some other reason.

I'm afraid it was a while back so I don't have it to hand, but what I do have is the techempower benchmarks [0] which show about a 10x difference between asp.net or go, and all of the js options. I'm not going to claim they're perfect, and would be happy if you could provide some info that supports your argument?

[0] https://www.techempower.com/benchmarks/#section=data-r21

JavaScript is ranked 5th on the ranking you linked to.

4 ranks before .Net.

I was hesitant as to how much I should go into this because you get into the semantics of the benchmark but this [0] thread goes into why - that particular implementation doesn't behave the same way as the other implementations, it uses a different db driver that doesn't synchronise, which won't be allowed in the next version of the benchmarks. Techempower publish regular snapshots of their benchmarks at [1], and if you look at any of the snapshots that aren't the last published set where the discrepancy was fixed you'll see that all of the js implementations lag far far behind.

[0] https://github.com/TechEmpower/FrameworkBenchmarks/issues/72...

[1] https://tfb-status.techempower.com/

Are you sure about your conclusion though? Apart from just-js missing in action in last 3 runs, here it's just fine

https://www.techempower.com/benchmarks/#section=test&runid=e...

they upgraded postgres recently and it uses a different default authentication mechanism which broke just-js. they seem to have stopped doing runs right now so just-js should re-appear when they start again.

i'm sorry but this is not true. postgres pipelining is not allowed in the benchmarks any more, and even when it was, just-js was completely compliant with the rules and it was other C++, PHP, Rust and C# frameworks that were non compliant.

the postgres driver was rewritten in JS because i spent so long benchmarking using the pg C driver and couldn't get the performance i needed from it. if you actually read the github thread you can see i even did a lot of work to verify the various frameworks were compliant with the requirements.

in round 21, postgres pipelining was disallowed for all frameworks and just-js/JavaScript is in first place. \o/

https://www.techempower.com/benchmarks/#section=data-r21&hw=...

Just-js is not really a Javascript: https://github.com/just-js/just. .Net in that list much closer to what everyone assumes.Net is.

Looks like Javascript to me

https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...

https://just.billywhizz.io/blog/

it is! people who love bashing JavaScript always come up with this line that just-js "is not JavaScript". ¯\_(ツ)_/¯

Oh, come on! I am in fact a front end developer. And when I saw the result first time a few years ago, I was surprised and wanted to use this “just JS”, but the reality was quite far from what I was expecting. It might look like JS, but if you check the source code of the app for the benchmark, you’ll realise that it looks more like C or C++.

More details in this thread: https://github.com/just-js/just/issues/5

And yet the top js entry is above all c# and go entries. It takes the top overall on the composite score.

Not that it is representative of actual use cases. Can't use just-js in production as it's hyper optimized for this benchmark rather than a work horse. But it does provide a better view of what is possible if the work is put in.

Isn’t that just basically a js wrapper over a very optimized c++ lib though?

Might call node.js the same thing. Deno has a rust shell and bun is zig.

Just-js had spent a lot of resources optimizing the input and output gateways to the V8 engine and it obviously pays off nicely. It does serve requests with the JS.

Is the boundary in the same place? Not familiar enough with the others to say exactly. But does it really matter?

like bun or node or deno (Rust as well as C++).

in techempower, the vast vast majority of code running in the just-js entry is JavaScript. all the core libraries for networking and interacting with the OS are js wrappers around C++/v8. the http server, though incomplete and not production rady, is written in javascript, with http parsing handed off to picohttpparser. the postgres wire protocol is completely written in javascript. in fact, one of the advantages JS and other JIT languages have is you can optimize away a lot of unnecessary logic at run time when you need to. e.g. https://github.com/just-js/libs/blob/main/pg/pg.js#L241

the whole point of doing this was to prove that JS can be as fast as any other language for most real world web serving scenarios.

if i had more time to work on it, i am sure i could improve the fortunes score where it would be at or very close to the top of that ranking too.

You’re not wrong but I do think it’s important to remember the context: people don’t tend to write math-heavy code in classic JS (there’s a side discussion about WASM now) so relatively few apps bottleneck on CPU - it’s wild when you see people going on about how they need to switch frameworks based on some microbenchmark of request decoding when 99% of their request processing time is some kind of database. I’ve seen more Node apps blow up on RAM usage than CPU because someone thought async would magically make their app faster without asking how much temporary state they were using.

Where I think there’s more of a problem is cultural: similarly to Java, there’s a subset of programmers seemingly dedicated to layering abstractions faster than the JIT developers can optimize them.

"Relatively few apps bottleneck on CPU" is a very 2010 opinion. With fast intranet (100Gbps+) and SSD, running business logic can become the bottleneck in many cases.

Unfortunately, I don't have readily available data to back up my claim neither.

I’m not saying it can’t happen, just that it’s pretty rare. SSDs are not infinite capacity and 100G networking isn’t common even in data centers - and more to the point, what really matters is latency: how many cycles can your CPU exercise in the time it takes for a round-trip network request is usually orders of magnitude greater than your business logic.

Again, not saying it never happens but I’ve rarely seen the kind of microbenchmark this story is about end up correlating with real application performance. I have seen developers get all fired up in some religious war and endanger their entire project trying to see benefits which never materialized, though, a common feature there was this focus on toy benchmarks rather than measuring the whole system or what they could do at the app level if they weren’t supporting some niche framework.

>> Where I think there’s more of a problem is cultural: [...] there’s a subset of programmers seemingly dedicated to layering abstractions faster than the JIT developers can optimize them.

This sounds extremely accurate to me

Express is a slowest solution on the market. Fastify can handle as much as 60k (!) requests per second per core(!): https://www.fastify.io/benchmarks/

For example, go can handle about the same amounts (be advised that this tests are for 4 cores, so results have to be divided): https://github.com/smallnest/go-web-framework-benchmark

I agree performance is important, but it’s optimistic for any dev to assume that this particular layer is the place where things will be slow. Introduce a single file or other 3rdparty IO dependent method on your HTTP response and poof

To be fair it did used to be quite slow. But that was like 10 years ago. General awareness hasn't caught up to the huge engineering efforts it seems.

It's been 14 years since the v8 engine was released. Node.js has been out longer than 10 years.

Ikr. You can regularly read some random dev tell the world "interpreted" Java is "too slow" for them.

Javascript isn't Java. Javascript follows ECMAScript, which also isn't Java. And ECMAScript isn't a language.

I don't know if they were making a JS joke but I have legitimately had newer programmers tell me that Java is an interpreted language because it compiles to a bytecode language which is interpreted by the JVM. Inversely I've had people argue that JS and Python are compiled languages because their interpreters convert statements into bytecode before executing them. When someone starts trying to argue those points I find its best to just give them a thumbs up and leave the conversation.

Describing Javascript can be confusing. C++ compiles -> C compiles -> assembly language compiles -> 1-for-1 to machine code. But Javascript be like "Javascript is the programming language interacts with your browser" or "Javascript conforms to the ECMAScript specification that describes how the language should act but is implemented according to the browser vendor's interpretation of said specification, and is further compiled according the browser." And that only covers browsers' Javascript.

And I'm not even sure if the above is 100% accurate.

Reply on news.ycombinator.com