Hacker News Reader

Comment by capableweb | Hacker News Reader

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.

View on HN

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.

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.

> 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'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).

Reply on news.ycombinator.com