To all reasonable software developers out there, please don't listen to the prevailing groupthink. Javascript (the language) has many semantic problems but speed (from the VM) is one of it's best features! Like, you have to be writing some questionable code in very questionable styles/dialects to have a 10x (or more!) slowdown vs native.
Obviously - using native non-portable language/compiler features - you can reach some worthwhile speedup for certain workloads. But I have yet to see any of these "we rewrote our build system to Rust" type blog posts utilize any them.
It's always the apples-to-oranges marketing style drivel. Just because the some assertion comes from a very (very!) large company or well-known community member doesn't mean it is true.
In all my years of lurking this site, this port mortem is one of the few articles on this topic I trust:
<a href="https://zaplib.com/docs/blog_post_mortem.html" rel="nofollow">https://zaplib.com/docs/blog_post_mortem.html
This argument can also be applied to the separate, startup time performance axis. Though there are more tradeoffs there.
I bet if you took the AI-generated Rust codebase and another 120k to reverse it right back to Typescript you'd get keep most of that same speed up!
Hardly given the limitation of V8 powering a dynamic language, it doesn't even match Java and .NET JIT compilers, as they have the benefit of actually using the type system for performance optimisations.
What makes node projects bearable, is that occasionally I have an excuse to write C++ Addons, or to fix something in one of those npm packages that is more native code than JS.
Java/.NET by default have an edge due to being less dynamic than JS and having a more mature VM. Both of these qualities are not static properties, as in:
1) You can programming JS in a style that is stricter than standard JS and even Java/C#
2) You can run JS on other virtual machines, including Hotspot VM (transpile to Java Bytecode)/GraalVM.
This stricter style js (asm.js) was the precursor to Webassembly; it still exists. You can also be very meticulous to craft monomorphic code through your project to get great performance.
Almost no one does this, cause it's harder, yet people still claim to know the limits of JS performance.
The AI Rust -> Typescript will provide the default structure V8 needs to run fast.
Yes you can, and the dynamic nature means it will still be slower than strongly typed languages.
Asm.js was a political decision from Mozzilla that never accepted PNaCL, and was never as fast as Chrome's solution, hence why we have WebAssembly nowadays.
I rather have AI Rust -> Machine Code / WebAssembly.
The point of an asm.js style is so that you can eliminate almost all of the dynamic variance so that ahead-of-time compilation is possible.
Asm.js can be transformed into whatever PNaCL takes to get even faster - there is no limit. Especially if someone were to say, write new enchancements to asm.js to restrict it even further.
It will be hell write that in pure JS of course, but that's beyond the point. You can use all manner of (unnatural) signals/semantics to indicate, for example, in-depth type information about a language construct.
It is hard when dynamic language users do very dynamic things. My whole point is, you have to be doing some very, very dynamic things to get into the 10x plus range in most cases.
For the Python, Ruby, Perl family of purely interpreted languages no doubt 10-100x is normal. For quality, lower-level JS no way. In those cases, they are usually reaching into features inaccessible to a JS runtime. It could also be due to a VM performance bug/limitation. As a compiler/transpiler guy, I could connect those gaps if shown the code - in variety of "creative" ways. ;)
Porting to native disrupts the previous ecosystem. It's amazing when users of your software can modify it to fit their needs, in the same language.
Adding another barrier in the name of performance is justified only if your project actually hits hard limits. It's annoying when I hear these claims of JS is slow, then look at the code in questions (if it's public).
The code always has immediate problems. In some sense, maybe it is better to just switch languages then to challenge these assumptions.
suplexer · · focus · HN ↗
Obviously - using native non-portable language/compiler features - you can reach some worthwhile speedup for certain workloads. But I have yet to see any of these "we rewrote our build system to Rust" type blog posts utilize any them.
It's always the apples-to-oranges marketing style drivel. Just because the some assertion comes from a very (very!) large company or well-known community member doesn't mean it is true.
In all my years of lurking this site, this port mortem is one of the few articles on this topic I trust: <a href="https://zaplib.com/docs/blog_post_mortem.html" rel="nofollow">https://zaplib.com/docs/blog_post_mortem.html
This argument can also be applied to the separate, startup time performance axis. Though there are more tradeoffs there.
cisc · · focus · HN ↗
<a href="https://devblogs.microsoft.com/typescript/typescript-native-port/" rel="nofollow">https://devblogs.microsoft.com/typescript/typescript-native-...
pjmlp · · focus · HN ↗
<a href="https://www.theregister.com/devops/2026/09/18/microsoft-agentically-ports-copilot-runtime-to-rust-for-120k/5297549" rel="nofollow">https://www.theregister.com/devops/2026/09/18/microsoft-agen...
suplexer · · focus · HN ↗
cisc · · focus · HN ↗
suplexer · · focus · HN ↗
Anyone can claim anything is true!
"But why bother when you already have the speed up? And why didn't TypeScript deliver it in the first place?"
That's a question for them.
pjmlp · · focus · HN ↗
What makes node projects bearable, is that occasionally I have an excuse to write C++ Addons, or to fix something in one of those npm packages that is more native code than JS.
suplexer · · focus · HN ↗
This stricter style js (asm.js) was the precursor to Webassembly; it still exists. You can also be very meticulous to craft monomorphic code through your project to get great performance.
Almost no one does this, cause it's harder, yet people still claim to know the limits of JS performance.
The AI Rust -> Typescript will provide the default structure V8 needs to run fast.
pjmlp · · focus · HN ↗
Asm.js was a political decision from Mozzilla that never accepted PNaCL, and was never as fast as Chrome's solution, hence why we have WebAssembly nowadays.
I rather have AI Rust -> Machine Code / WebAssembly.
suplexer · · focus · HN ↗
Asm.js can be transformed into whatever PNaCL takes to get even faster - there is no limit. Especially if someone were to say, write new enchancements to asm.js to restrict it even further.
It will be hell write that in pure JS of course, but that's beyond the point. You can use all manner of (unnatural) signals/semantics to indicate, for example, in-depth type information about a language construct.
It is hard when dynamic language users do very dynamic things. My whole point is, you have to be doing some very, very dynamic things to get into the 10x plus range in most cases.
For the Python, Ruby, Perl family of purely interpreted languages no doubt 10-100x is normal. For quality, lower-level JS no way. In those cases, they are usually reaching into features inaccessible to a JS runtime. It could also be due to a VM performance bug/limitation. As a compiler/transpiler guy, I could connect those gaps if shown the code - in variety of "creative" ways. ;)
cisc · · focus · HN ↗
Why bother? It's better just to use a different language in the first place and get the performance for free.
Your argument is consistently "if only JavaScript was different then it would be faster".
That's wonderful but it isn't different. JavaScript is JavaScript. If you want performance you're better off with another language.
suplexer · · focus · HN ↗
Adding another barrier in the name of performance is justified only if your project actually hits hard limits. It's annoying when I hear these claims of JS is slow, then look at the code in questions (if it's public).
The code always has immediate problems. In some sense, maybe it is better to just switch languages then to challenge these assumptions.
cisc · · focus · HN ↗
But it doesn't fit their needs. It's too slow.