5 ms·
"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++."
by gidis_ 3y ago
"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).
- esailija 3y agoJITting 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.
- sentimentscan 3y agoThere 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
- afavour 3y agoYeah 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.
- coldtea 3y agoThe 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.
- afavour 3y agoLet 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.
- skydhash 3y ago> 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.
- WeAddValue 3y agoOr just use htmx.org
- deleted 3y ago[deleted]
- WeAddValue 3y agoThis! 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.
- emilecantin 3y agoYes, 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/javascript-vs-cpp 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.
- yakubin 3y agoThose 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.
- emilecantin 3y agoYes, 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.
- yakubin 3y agoThat 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.
- ymolodtsov 3y agoSeems 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.
- RHSeeger 3y agoCompiled 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.