Comment by gidis_ | Hacker News Reader

Comment by gidis_ | Hacker News Reader

Parent Full thread

"and JavaScrip is an interpreted language, not a compiled one, so by default, it will be orders of magnitude slower than an app written in Swift, Rust, or C++."

This statement is misleading and false.

The distinction between "interpreted" and "compiled" isn't as clear-cut as it once was, especially in the context of modern languages and runtimes. However, when it comes to JavaScript, here's the general understanding:

-Interpreted: JavaScript is traditionally known as an interpreted language. This means that it is typically executed line by line, on-the-fly, without a preliminary compilation step to machine code. When web browsers first supported JavaScript, they essentially had interpreters that read and executed JavaScript code directly.

- Just-In-Time Compilation (JIT): Modern JavaScript engines like V8 (used in Chrome and Node.js), SpiderMonkey (used in Firefox), and Chakra (used in older versions of Microsoft Edge) use Just-In-Time (JIT) compilation to execute JavaScript code. With JIT, the JavaScript code is compiled into machine code just before it is executed, rather than being interpreted line by line. This approach can greatly improve performance because the machine code can be optimized for the current machine and can be executed much faster than interpreted code. So, in this sense, JavaScript is compiled at runtime. - Ahead-of-Time Compilation (AOT): There are also tools and technologies that allow you to compile JavaScript (or languages that transpile to JavaScript) "ahead of time" into machine code or other languages. Examples include the asm.js subset of JavaScript and WebAssembly (although WebAssembly isn't strictly JavaScript, it's a target for languages including C/C++ and Rust, among others).

Yes, Javascript is used in browsers and has a few different competing runtimes, and as such, there are a lot of resources invested in making it faster than the other runtimes.

As a result, except in only very trivial cases, Javascript is only slower than C++ by about a factor of 2-4. This is a much smaller difference than the "orders of magnitude" mentioned above.

The following list of benchmarks illustrates this point: https://programming-language-benchmarks.vercel.app/javascrip...

The only exception is "hello world", which is about one order of magnitude slower in JS, but that's probably explained by the runtime startup / teardown.

Those are microbenchmarks, and as such are misleading when it comes to evaluating JIT-ed languages. They also don’t involve ever touching the DOM, which is a major source of slowdowns in real-world JS apps.

Yes, but any UI stuff in C++ is also going to be a major source of slowdowns.

And C++ compiled to WASM will have the same slowdowns if it needs to touch the DOM.

That actually makes me want to create a set of UI benchmarks comparing performance standard UI operations in C++ with Qt vs JS with DOM. I think I’ll look into it over the weekend.

JITting alone will just make code slower. Even with many optimizations V8 eventually changed the "unoptimizing JIT" to an interpreter and now only JITs hot functions.

Yeah this really bugs me because it leads people down the path of WASM craziness when the language is rarely the problem.

Most web apps are slow because the DOM is slow.

The DOM is plenty fast.

Most web apps use it for what it wasn't meant to do, in an inefficient matter, with useless rerenders and overhead.

Let me clarify: the DOM is fast _at what it does_. But in order to truly serve things like web apps rather than documents it needs to have primitives like list virtualization. It doesn't, so people end up using needlessly complex JavaScript frameworks that drag down performance.

> But in order to truly serve things like web apps rather than documents it needs to have primitives like list virtualization.

Why not create a UI system, like X Window over the web (I know X can be done over the network) specifically for web apps? Solve the issue at the root and leave the DOM to documents.

Or just use htmx.org

This! Call it once with a string containing 457 elements and the DOM is blazing fast. Call it 457 times to create an element and the DOM is slow.

Seems like a technicality to me, although I'd be happy to update the statement in the post. It's still not compiled in advance and while the technologies you described (asm.js, WebAssemly) exists most web apps discussed don't use them at all.

Compiled JIT can be pretty similar to AOT, if the application runs for any real period of time. Generally, a JIT will try to compile any given block of code only once; so it winds up working towards the same state as something AOT.

That being said, there is a caveat that the code _can_ change for something compiled JIT, and there are inefficiencies related to that.

There are benchmarks/cases were JS is faster then C++ Yes obliviously C++ is faster then JS, but complexity/time of programmer may cause you to write slower code then v8/JIT. I can't sadly find a link for that benchmark

Reply on news.ycombinator.com