Hacker News Reader

Comment by actionfromafar | Hacker News Reader

But Javascript the language is intrinsically linked to Javascript the runtime. Not sure what you are going for here. I'm not at all the surprised that tuned Javascript can be as performant as pre-compiled Javascript.

To explain further, I'm also not surprised that hand tuned assembler can get the same performance as compiled C.

View on HN

> I'm not at all the surprised that tuned Javascript can be as performant as pre-compiled Javascript.

Well you must be smarter than I am (which is not saying much).

For my grug brain, an untyped memory-managed interpreted language will be at a significant disadvantage against a typed compiled language whatever the use case. It's a testament to the Chrome dev team's hard work.

It is also possible that the WASM VM has not benefited from as much love as the JS VM.

I have also a bit of a grug [0] brain, but this old brain has become accustomed to the idea that JIT and other optimisation passes can cram out such an insane amount of inference that it will find the fastest code possible. Effectively finding the hand-tuned equivalent. I first got this hunch looking at the JVM. Couldn't hand code JVM instructions which run faster than Java code. But both the hand coded "JVM assembly" and the generated assembly benefited from JIT passes.

What remains then, is compiling to native. This is where C shines and Javascript doesn't. Because of it's data model, Javascript just can't take advantage of what you could do in plain C.

0: This rambling "explanation" is exhibit A

I think parents point is more about that there is nothing making JavaScript (the language nor the runtime) intrinsically slow, but rather the DOM that makes it so the perception of JavaScript is that the language/runtime is slow.

When people bitch about that JS is so bloated and slow, it's usually because of things interacting with the DOM and everything related to it, or just slow network connections. But then people take out their frustrations on the language instead.

I'm not sure if the DOM is that slow actually, compared to raw code that can output at any time manipulating the DOM only has produce an update within the next frame for an external observer to perceive it as as fast as possible basically.

Often the problem is probably that people are making too many DOM nodes (no virtualization), talking to the DOM inefficiently via a slow framework (React) and talking to the framework inefficiently (bad code).

> but rather the DOM that makes it so the perception of JavaScript is that the language/runtime is slow.

Not sure what you mean by this. Every time I run something like document.getElementById(), it is very fast.

Is this supposed to be a joke? If not, that's not how you measure performance. Try doing it a million times a second and use actual performance metrics instead of your eyes (which can't tell the difference between 1 nanosecond and 100 milliseconds, so completely useless for determining whether something is slow/fast). Even then just getting the element is clearly not the DOM operations that people are referring to when they say that the DOM is slow.

I think this is a good point - pure JavaScript code is indeed exceptionally fast. DOM calls do have relatively high overhead, and if the change kicks off CSS recalculation or layout, then that can be even more costly. However that's not representative of the performance of the JavaScript language itself.

Most of my bitching that JavaScript is slow comes from node, which is quite far removed from the DOM. Fast and slow are relative terms, of course, but JavaScript's language features necessitate that it will always be slower than most static, compiled languages. Regardless of runtime. What blows me away is how unsafe the language is on top of being slow, and yet it's basically eaten the world

You're clearly doing something wrong if you seriously think Node is slow. V8 is extremely fast.

Reply on news.ycombinator.com