"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 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.
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.
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.
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
Hey man, keep your head up. I understand how difficult it can be running a business especially in a foreign country. A good way to keep your cashflow positive is to get contracts and outsource them. You can email me if you need a hand as I am also a software engineer, I could be of help.
