Rendered at 17:31:43 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Klonoar 2 days ago [-]
> Rewrite a bundler in Rust and you haven't only made it faster. You've also shrunk the pool of JavaScript developers who can maintain it. The new tool still looks like a duck and quacks like a duck, but it's a different beast altogether. Its internals retreat behind a black box that fewer people hold the keys to. The source may still be open, but the door to contributions is closing.
Alternatively, there's a pool of JS developers who shouldn't be maintaining critical infrastructure to begin with.
It's not a black box, those codebases are usually open and the only thing holding you or anyone back is learning anything outside of a small pond of JavaScript.
Write non-browser-things in fast languages. It is not a complicated concept - even less so in an era where stuff is getting written for you.
devilsdata 2 days ago [-]
Absolutely agree. If a JS developer doesn't know Rust, Go, Zig, or something, then they probably aren't going to do a good job at maintaining critical infrastructure, even if it were written in JS.
Why are people writing "critical" infrastructure in JS anyway, it is the wrong tool for the job.
jmull 2 days ago [-]
Why are people writing critical infrastructure in [any language]?
In reality, the tools this article is referring to were written in javascript because they could be and it was the best tool for the job (according to the people who matter: the people who did the work).
If someone wants to rewrite them for speed and/or to chase the next shiny language, that's fine with me, but let's not kid ourselves that there was something wrong with using javascript in the first place.
Using the right abstractions (including the right number of abstractions) and the right data structures and algorithms is always going to trump the constants language choice can optimize.
theowaway213456 2 days ago [-]
> Using the right abstractions (including the right number of abstractions) and the right data structures and algorithms is always going to trump the constants language choice can optimize.
I was with you until this paragraph, which is straight up incorrect. Language choice absolutely matters if your goal is performance.
The most obvious counterexample is that the TypeScript team pretty much did a direct port from TS to Golang, without significantly rewriting their core algorithms or changing their data structures, and it sped up the TS compiler by 10X, which is an enormous performance improvement that would be silly to dismiss as just a "constant." This is because JS is a bad choice of language for implementing a fast compiler, primarily due to its poor support for multithreading.
conartist6 24 hours ago [-]
I still think that rewrite was ill-advised. Yes they got a 10x speedup, but now it's unclear whether the JS tooling ecosystem lives in Go or Rust or JS.
Given that we've now got a three way language schism, the story for sharing data between processes isn't really solved. Data can move nicely within Go, but not between Go and Rust or JS. Tools like ts-morph also got left behind with no replacement.
I think that in retrospect the power of the JS ecosystem was all about plugins. It's plugins that make ESLint such a powerful platform that it still can't be replaced.
From the perspective of making a efficient platform for running plugins, JS actually is the most theoretically efficient implementation language! That's why, for example, VSCode put a bunch of work into moving its core state from C++ to JS, a change which brought them big perf wins and helped them beat out Atom: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
devilsdata 20 hours ago [-]
What do you mean when you say the "story for sharing data between processes isn't really solved"? My understanding of this is mostly academic because I don't personally mix languages all that often, but aren't there many established ways of communication between languages. You have IPC, unix sockets, FFI, protobufs, and other serialising/deserialisation formats. Not to mention the classic (but probably slightly overkill) move of spinning up a local HTTP server and using REST endpoints.
conartist6 18 hours ago [-]
Yes, all those ways exist. I was more saying that if copying between structures processes using serialization is all you need, the JS ecosystem already has that.
The thing is if you need to do big expensive copies on the input or output it forces you towards a batch processing model, which is the opposite of incremental computation.
walt_grata 2 days ago [-]
When did the love of learning disappear from this field? I remember when everyone i talked to was learning something new just to better themselves?
yoyohello13 2 days ago [-]
> When did the love of learning disappear from this field?
Like 10 years ago? When you could get a 400k/yr job after a 3 month JS boot camp. The market got flooded with people who don’t care about making good stuff. Now it’s the “AI has commodified intelligence so why learn anything” crowd
dieselgate 2 days ago [-]
> When you could get a 400k/yr job after a 3 month JS boot camp.
I get the point but these numbers are hyperbole and do not happen in real life.
suplexer 2 days ago [-]
Or just write faster JS using it's lower-level language features. Nothing about whatever collection of build tools the JS ecosystem uses "requires" rust/zig/c++/go for performance. It's a closed text transform problem.
The native languages are easier to get decent performance for sure but, braking the entire ecosystem and a generation of future contributors, for what should realistically be single or low double digit percent gains is not worth it.
Klonoar 1 days ago [-]
> Or just write faster JS using it's lower-level language features.
You are simply ignoring the history of these tools and why people have begun to reach for the languages in question.
whakim 2 days ago [-]
I think there's a huge spectrum between "pokes around in source code occasionally" and "maintains critical infrastructure." Learning to read and understand the open source software that powers a lot of the toolchain is a big part of the development of a lot of engineers, and said toolchain mostly not being written in a language you're familiar with is a barrier to that (not an insurmountable barrier, but still a barrier, to be clear).
I agree with you that the juice is worth the squeeze here, but I don't think it's right to pretend that there's absolutely zero cost in terms of the learning pathway for the next generation of open source contributors and maintainers.
pjmlp 1 days ago [-]
I had to laugh about the Tiger Beetle history when hearing about it on one of my podcast feeds.
Although it is now famously one of the Zig written production deployments, the founders thought JavaScript would be a great option to write a database server, like really?!?
pan69 1 days ago [-]
> In the month of July 2020, we developed a prototype of TigerBeetle in Node as a performance sketch to measure the basic components of the design (batching, TCP protocol, cryptographic checksums everywhere, fsync journalling, in-memory business logic and hash table operations).
Compiling to WebAssembly enables every language to run in the browser. Google used Java and Amazon used Rust.
suplexer 16 hours ago [-]
1) Google Sheets use case
Long story short they are comparing the performance of server-side Java to client-side JS (Java transpiled through GWT/J2CL). So something like:
Java -> Hotspot -> native
vs
Java -> GWT/J2CL -> JS -> V8 (in Chrome) -> native
Apples to oranges.
They then used J2CL (I presume, not clear from the article) to port Java to Wasm and eventually got around 66% of the server-side Java performance. The Wasm performance story also was nowhere near straightforward - hence the immense efforts spent on optimizing WasmGC and validating the transpiler output.
The root of the problem is likely the GWT/J2CL transpiler output. There shouldn't be that much of a peformance drop off between to high-level languages if you're transpiling with speed in mind. I bet there are probably lots of expense runtime checks in the generated output, among others things.
2) Amazon Prime Video use case
Blog seems mostly fine on the surface. But my complaints are always the claims about the limits of performance one could get from a JS-based system - especially in environments where you can call out into native audio/visual libraries.
"In those experiments, code written in Rust and compiled to Wasm was 10 to 25 times as fast as JavaScript."
What does the JS versus Rust code look like? Are they using the similar libraries/graphics apis/techniques? Did they exhaust every possible low-level tool in JS (Worker Threads, SharedMemory, etc). I feel there are a also rainbow of optimization opportunities available if one controls V8 and the underlying C++ stack.
Not that their eventual Wasm architecture is bad per se, it's just layering Rust+JS -> Wasm/C++ is much more complex than simply JS -> C++ back and forth.
As a side note, it very annoying that SIMD was taken out of development for JS. Big TC39 wants wants JS to fail.
In both cases the WebAssembly result is twice as fast as the JavaScript version.
How do you account for that?
suplexer 15 hours ago [-]
In Google sheets case, because they are being processed through two separate transformation pipelines, then they compare the result from different runtime environments (i.e. server vs client). The automated translation via J2CL is surely producing very suboptimal code in JS versus Wasm. The end result doesn't matter if it's incomparable.
In Amazon's case, are they using specialized vector instructions (i.e. SIMD) in the Rust version, different graphics apis, specialized algorithms? They just said it's 10 to 25 times faster with no code. Ok...sure.
suplexer 2 days ago [-]
It's late for me. I've commented plenty on this thread but I'll revisit this particular comment tomorrow with my assessment of these two blog posts.
Just skimming the Google Sheets wasm one, looks like pure technical debt chaos so I'm already plenty suspicious.
Suffice it to say that all these pseudo-technical but actually marketing blog posts should be taken with a truckload of salt. Apples-to-oranges unless proven otherwise.
Heterodox argument: a big part of the reason JavaScript has been so successful is that interpreted languages actually can be extremely fast—competitive with, and in many cases, faster than compiled languages, with V8 arguably the fastest interpreter in existence.
See this post by Mike Pall, author of LuaJIT (which is comparable to or faster than V8 performance-wise, despite being basically a single-developer project), which explains why: https://web.archive.org/web/20180603053407/http://article.gm.... Basically, it’s much easier to add high-quality runtime-trace-aware recompilation to a JIT interpreter, which a non-trace-aware compiled language will often not be able to beat.
MiroslavPokorny 2 days ago [-]
Javascript only becomes fast because most of the CPU time is spent in native code rather than actual compiled or interpreted javascript.
The big diff between scripted and compiled languages is the former dispatches by name and the later dispatches by index. No surprises which is faster and which can be compiled in the faster native code.
jauntywundrkind 2 days ago [-]
JavaScript only becomes fast because it continually is making tradeoffs to decide what level of work to put into running any given bit of code. For a while this was three or four different targets on V8 (which I think maybe is down to just 2 now again).
Compiled vs interpretted is viewing this through the compiled language lens. I think the interesting part is that some runtimes are dynamically deciding how to run the code. The contrast versus those folks who decide and bake every single decision in ahead of time, where the only thing that happens is totally pre-scripted, is strong.
Stop Writing Dead Programs is such a lovely talk that hopefully can shake a couple of these sleepers awake, get us to see how absurd compiled code really is. And is quite fun and funnily said. https://news.ycombinator.com/item?id=33270235
skybrian 2 days ago [-]
It's mostly fast enough for most apps and that definitely helps. It's not as consistently fast as some languages that don't rely on an JIT. That matters more for tooling than your average website.
suplexer 2 days ago [-]
There's no need to even contextualize your argument, it is the reality. The whole point of spending such heroic efforts on a fast VM implementation is so that even faster peformance becomes a niche use cases.
But alas, many unskilled programmers use Javascript to make useful things - sometimes beyond their ability. Even a state-of-the-art virtual machine like V8 cannot hope to fix that class of peformance problems.
I will withhold my opinion on the "faster than compiled languages" part though. ;)
hn_submit 2 days ago [-]
JavaScript is an abomination that never should've been left alive.
And yes, I ask myself the question: "Who in his right mind would run JavaScript on the server and even write business logic in it?" Lots of idiots in this world it seems. JavaScript is the reason our text editors need 16GB of RAM to run these days and a simple weather app 1GB.
In the ol' days assembly programmers probably could've written the weather app in a couple of KB (that's a MILLION times less memory people).
suplexer 2 days ago [-]
A programmer that can write a small efficient weather app in assembly can also easily do so in JS. Especially writing it in a c-style imperative way.
Modern Javascript has many low-level facilities and a great VM. You're conflating the low, average skill of the JS community to what the language is capable of.
hn_submit 1 days ago [-]
We shouldn't be using scripting languages for anything but animating something on a web page. The idea behind NodeJS is idiotic. We shouldn't allow low-skilled programmers to write server software.
If A.I. code generators put a stop to this then it will have served its purpose IMHO.
shimman 2 days ago [-]
People say this yet still are served some of the worse performing apps from supposedly the "best" corporations in the industry.
suplexer 2 days ago [-]
Low average skill unfortunately includes them as well. I say unfortunate because, like the build tool developers, they serve an outsized audience with their poorly written apps.
But, to be fair, large tech corporation have many other roadblocks to better software quality, well before you reach testing individual skill levels. Moral decay and office politics to say the least...
hn_submit 1 days ago [-]
I can relate to some "dumbing down" of developer tools and languages. Java and C# are examples and those are fine. But JavaScript?!
Employers are absolutely fixated on gutting developers' salaries and going so far as to building their entire business on molasses by using JavaScript.
pjmlp 10 hours ago [-]
I really hate that several vendors when moving from PaaS to SaaS, have dropped their Java and .NET SDKs, and now the only thing they have is Next.js integrations.
MiroslavPokorny 2 days ago [-]
Exactly!
In todays of multi processors, its seems completely backward to adopt a runtime that is limited to a single thread.
suplexer 2 days ago [-]
JS has Web Workers in the browser and Worker Threads module in nodejs for parallelism. Most apps don't need to them to be fast, but many slow apps would be less slow if Workers were used more often.
MiroslavPokorny 2 days ago [-]
Node is a single thread per process.
While other languages leverage sharing memory amongst multiple cpus, node requires a process per CPU.
LoganDark 2 days ago [-]
From experience... It was really amazing to share TypeScript protocol definitions between the server and client. The client side would get all the autocomplete and intellisense and typed goodies, the server side used a compiler extension called typescript-is to validate the request bodies in one go, using the types as the source of truth. I loved not having to duplicate the validation logic in a separate way and manually maintain it to be consistent with the types. To this day I think that was the most natural way I've ever written a server-client pair and to this day nothing's compared, even supposedly cross-language things like protobuf. Ugh, TypeScript is so good at what it does. Sometimes I hate the lack of nominal types, but it really is up there with Rust as one of my favorite languages.
agos 20 hours ago [-]
come on, you can do better than hurl insults at fellow programmers
nzoschke 2 days ago [-]
> Rust, Go and Zig are taking over increasingly large parts of the JavaScript toolchain...
Large parts of the JavaScript application space too.
Language consistency, ergonomics, standard library and performance matters, and JS has major warts here. I bet when these languages are 30+ years old like JS is, the software landscape isn't dominated nearly as much by JS.
These days I intentionally start all projects with as little JS as possible, opting for Go and HTMX instead. Removing the layers of JS inconsistency and build tools makes my and my agents lives better.
I love JavaScript and TypeScript, but like all interpreted languages, they really do have a hard time fitting into certain environments where you can't get an enormously complicated VM or can't get by with a much slower version of the language.
You can argue that high-throughput / low-latency dev tools are one of these environments. I'm not so sure. I think a lot of JS tooling is written in slow JS and gets fast with a rewrite to another language largely because of better structure.
Some environments really are tougher though. I started using WebAssembly a lot a year ago and the story for JavaScript and Python is just pretty terrible. And for JS, the things that make it hard to run in Wasm aren't universally good things to have in the language in the first place. The extreme dynamism of JS is something that so much JS tooling tries to limit.
But I think a lot of the language is quite good, and that there are possible variants of JS that are great even. I started one I hope will fit that one day (https://zena-lang.dev) and the first use cases for me are all tooling to try to make sure it's at least good for that: self-hosted compiler, formatter, regex engine, JSON parser, etc. It's quite a bit like JS/TS, but fixes a lot of things and runs forward with features that will take JS many years to get to, if it ever does (ie, pipelines, pattern matching).
I'm hoping that WebAssembly can slowly continue to gain a place on the web so JS can give up its near monopoly there. We'll see!
agentultra 2 days ago [-]
You can wait for slow programs that use a ton of excess memory, sure.
Or, you can have fast programs that use memory efficiently.
You just can’t do it in JavaScript. You can get really performant with JavaScript with careful engineering for sure… but there’s a big wall of diminishing returns even with all of the JIT compilation and tracing garbage collection.
Nothing stopping those same JS developers from learning some Zig or Rust or whatever. It might actually be easier to learn than memorizing all of JavaScript’s implicit coercion rules.
But if that’s too much to ask then stay in JS land and make sure there are JS devs to write tools for!
suplexer 2 days ago [-]
Instead of writing utilities, libraries, guidelines, build-time transformations, etc to help (or even) force JS devs to stay on the happy path, the industry "experts", large companies, and thought leaders chose to go the exact opposite route with React and adjacent tools. The results speak for themselves...
There is nothing stopping JS devs from working with byte buffers with near-zero overhead.
agentultra 18 hours ago [-]
Yeah, you can go pretty far with JS performance. I’ve been a fan. I find it’s harder to maintain than C, Zig, C++, Rust, etc. It’s really easy to break performant JS code. No types, allocations are hard to control without extreme discipline. It’s so flexible and you have to give up a lot of that to get performance out of JS.
React is a whole beast.
It would be neat to see some JS devs killing some benchmarks.
suplexer 16 hours ago [-]
Yea, it does require great discipline but I've been surprised by the lack of tools to help with writing high performance js.
Surely there can be some middle ground were you just want some small part of your app to run faster without including another tech ecosystem (locked within a Wasm sandbox).
pjmlp 1 days ago [-]
Because it was a really bad idea to start using JavaScript outside the browser anyway.
We were doing just fine before node, and this whole rewrite JavaScript into something compiled, and more usable, is the closing of a circle that should never have happened in first place.
hexasquid 2 days ago [-]
I'm interested to know why tsc (pre-go) would give me near-instant LSP diagnostics on a large typescript project, and rust-analyzer takes ages to produce diagnostics in a small rust project.
suplexer 2 days ago [-]
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.
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!
pjmlp 11 hours ago [-]
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.
suplexer 3 hours ago [-]
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.
pjmlp 59 minutes ago [-]
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.
suplexer 9 minutes ago [-]
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 transform 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 no doubt 10-100x is normal. For quality JS no way. In those case they are usually reaching into features inaccessible to normal users, but as a compiler/transpiler guy, I could connect those gaps if shown the code.
cisc 15 hours ago [-]
But why bother when you already have the speed up? And why didn't TypeScript deliver it in the first place?
suplexer 15 hours ago [-]
I don't mean to say you should, I just wanna stress that it's important to be critical of claims others make without evidence.
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.
suplexer 15 hours ago [-]
As someone who is creating a serious programming language whose bootstrap compiler is currently in (a restricted form) of JS. I am immensely skeptical of their claim on all fronts.
cisc 11 hours ago [-]
Why are you skeptical of Anders Hejlsberg's claims about his own language? He designed TypeScript.
Are you claiming that your own, separate programming language is faster than TypeScript, just like Go is faster than TypeScript? So in fact you agree with Anders?
suplexer 2 hours ago [-]
Yes, much faster. Conversely, I don't think Anders is claiming his Typescript implementation to be particularly fast - he believed JS wasn't fast enough to solve his performance problems. Which isn't true.
The TS compiler has always been slow. There are/were several TS-in-Rust/Go compilers long before Anders announced and released the offical Go version. I've also been writing transpilers since before TS was a thing, the TS team could have made it work in JS.
But it's often easier to switch to a language that gives you that structure/performance for free. "Free" in that large companies have the budget to afford a bug-for-bug port/rewrite.
tannerr_dev 2 days ago [-]
i enjoyed learning go. not that far from js
when i first started learning programming i thought it was super important to pick one language to be really good at and that could do everything but you dont have to pick just one.
i honestly think learning it opened my mind to thinking about programming differently and is probably better in the end
dbt00 2 days ago [-]
learning more languages is good actually. I still mostly write imperative code but having spent some time learning functional languages was very good for my brain.
Kuyawa 2 days ago [-]
If you need a desktop app go with rust, zig or swift depending on your platform
If you need a web app for CRUD, avoid frameworks, typescript, tailwind, nothing, just bare-naked node/html/css/js
If you need games in the browser or stuff where every byte needs optimization go with WASM
A programmer's life has become simpler
halfcat 2 days ago [-]
> just bare-naked node/html/css/js
Why include node here?
MiroslavPokorny 2 days ago [-]
If you need to be pawned go with Node.
jan_m_savage 2 days ago [-]
i don't mean to be a snark, but honestly I can't get the point of the long essay. What's the main idea?
2 days ago [-]
prokopton 2 days ago [-]
I've worked with Vue, React, Qwik, and Svelte over the last 10 years. I have never felt the hate that HN spews out over JavaScript.
hackersnooze1 2 days ago [-]
tldr: interpreted languages are still slower than compiled languages, surprising no one
sublinear 2 days ago [-]
> Rust, Go and Zig are taking over increasingly large parts of the JavaScript toolchain...
Alternatively, there's a pool of JS developers who shouldn't be maintaining critical infrastructure to begin with.
It's not a black box, those codebases are usually open and the only thing holding you or anyone back is learning anything outside of a small pond of JavaScript.
Write non-browser-things in fast languages. It is not a complicated concept - even less so in an era where stuff is getting written for you.
Why are people writing "critical" infrastructure in JS anyway, it is the wrong tool for the job.
In reality, the tools this article is referring to were written in javascript because they could be and it was the best tool for the job (according to the people who matter: the people who did the work).
If someone wants to rewrite them for speed and/or to chase the next shiny language, that's fine with me, but let's not kid ourselves that there was something wrong with using javascript in the first place.
Using the right abstractions (including the right number of abstractions) and the right data structures and algorithms is always going to trump the constants language choice can optimize.
I was with you until this paragraph, which is straight up incorrect. Language choice absolutely matters if your goal is performance.
The most obvious counterexample is that the TypeScript team pretty much did a direct port from TS to Golang, without significantly rewriting their core algorithms or changing their data structures, and it sped up the TS compiler by 10X, which is an enormous performance improvement that would be silly to dismiss as just a "constant." This is because JS is a bad choice of language for implementing a fast compiler, primarily due to its poor support for multithreading.
Given that we've now got a three way language schism, the story for sharing data between processes isn't really solved. Data can move nicely within Go, but not between Go and Rust or JS. Tools like ts-morph also got left behind with no replacement.
I think that in retrospect the power of the JS ecosystem was all about plugins. It's plugins that make ESLint such a powerful platform that it still can't be replaced.
From the perspective of making a efficient platform for running plugins, JS actually is the most theoretically efficient implementation language! That's why, for example, VSCode put a bunch of work into moving its core state from C++ to JS, a change which brought them big perf wins and helped them beat out Atom: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
The thing is if you need to do big expensive copies on the input or output it forces you towards a batch processing model, which is the opposite of incremental computation.
Like 10 years ago? When you could get a 400k/yr job after a 3 month JS boot camp. The market got flooded with people who don’t care about making good stuff. Now it’s the “AI has commodified intelligence so why learn anything” crowd
I get the point but these numbers are hyperbole and do not happen in real life.
The native languages are easier to get decent performance for sure but, braking the entire ecosystem and a generation of future contributors, for what should realistically be single or low double digit percent gains is not worth it.
You are simply ignoring the history of these tools and why people have begun to reach for the languages in question.
I agree with you that the juice is worth the squeeze here, but I don't think it's right to pretend that there's absolutely zero cost in terms of the learning pathway for the next generation of open source contributors and maintainers.
Although it is now famously one of the Zig written production deployments, the founders thought JavaScript would be a great option to write a database server, like really?!?
https://github.com/tigerbeetle/tigerbeetle-history-archive/b...
> And I think now, I think a lot of the reason why people went into NPM was because the tooling in C was so terrible.
> Like, how do you compile a C program?
Are some interesting quotes and hint much more to lack of knowledge on server compiled languages than a "performance sketch".
Full podcast episode is here,
https://shows.acast.com/software-unscripted/episodes/tigerbe...
Speed matters. WebAssembly is taking jobs from JavaScript precisely because it's faster.
The calculation engine for Google Sheets became twice as fast with the switch to WebAssembly: https://web.dev/case-studies/google-sheets-wasmgc
The Amazon Prime Video app became twice as fast with less variability in performance when they switched to WebAssembly: https://www.amazon.science/blog/how-prime-video-updates-its-...
Compiling to WebAssembly enables every language to run in the browser. Google used Java and Amazon used Rust.
Long story short they are comparing the performance of server-side Java to client-side JS (Java transpiled through GWT/J2CL). So something like: Java -> Hotspot -> native vs Java -> GWT/J2CL -> JS -> V8 (in Chrome) -> native
Apples to oranges.
They then used J2CL (I presume, not clear from the article) to port Java to Wasm and eventually got around 66% of the server-side Java performance. The Wasm performance story also was nowhere near straightforward - hence the immense efforts spent on optimizing WasmGC and validating the transpiler output.
The root of the problem is likely the GWT/J2CL transpiler output. There shouldn't be that much of a peformance drop off between to high-level languages if you're transpiling with speed in mind. I bet there are probably lots of expense runtime checks in the generated output, among others things.
2) Amazon Prime Video use case
Blog seems mostly fine on the surface. But my complaints are always the claims about the limits of performance one could get from a JS-based system - especially in environments where you can call out into native audio/visual libraries.
"In those experiments, code written in Rust and compiled to Wasm was 10 to 25 times as fast as JavaScript."
What does the JS versus Rust code look like? Are they using the similar libraries/graphics apis/techniques? Did they exhaust every possible low-level tool in JS (Worker Threads, SharedMemory, etc). I feel there are a also rainbow of optimization opportunities available if one controls V8 and the underlying C++ stack.
Not that their eventual Wasm architecture is bad per se, it's just layering Rust+JS -> Wasm/C++ is much more complex than simply JS -> C++ back and forth.
As a side note, it very annoying that SIMD was taken out of development for JS. Big TC39 wants wants JS to fail.
https://github.com/tc39/ecmascript_simd
How do you account for that?
In Amazon's case, are they using specialized vector instructions (i.e. SIMD) in the Rust version, different graphics apis, specialized algorithms? They just said it's 10 to 25 times faster with no code. Ok...sure.
Just skimming the Google Sheets wasm one, looks like pure technical debt chaos so I'm already plenty suspicious.
Suffice it to say that all these pseudo-technical but actually marketing blog posts should be taken with a truckload of salt. Apples-to-oranges unless proven otherwise.
See this post by Mike Pall, author of LuaJIT (which is comparable to or faster than V8 performance-wise, despite being basically a single-developer project), which explains why: https://web.archive.org/web/20180603053407/http://article.gm.... Basically, it’s much easier to add high-quality runtime-trace-aware recompilation to a JIT interpreter, which a non-trace-aware compiled language will often not be able to beat.
The big diff between scripted and compiled languages is the former dispatches by name and the later dispatches by index. No surprises which is faster and which can be compiled in the faster native code.
Compiled vs interpretted is viewing this through the compiled language lens. I think the interesting part is that some runtimes are dynamically deciding how to run the code. The contrast versus those folks who decide and bake every single decision in ahead of time, where the only thing that happens is totally pre-scripted, is strong.
Stop Writing Dead Programs is such a lovely talk that hopefully can shake a couple of these sleepers awake, get us to see how absurd compiled code really is. And is quite fun and funnily said. https://news.ycombinator.com/item?id=33270235
But alas, many unskilled programmers use Javascript to make useful things - sometimes beyond their ability. Even a state-of-the-art virtual machine like V8 cannot hope to fix that class of peformance problems.
I will withhold my opinion on the "faster than compiled languages" part though. ;)
And yes, I ask myself the question: "Who in his right mind would run JavaScript on the server and even write business logic in it?" Lots of idiots in this world it seems. JavaScript is the reason our text editors need 16GB of RAM to run these days and a simple weather app 1GB.
In the ol' days assembly programmers probably could've written the weather app in a couple of KB (that's a MILLION times less memory people).
Modern Javascript has many low-level facilities and a great VM. You're conflating the low, average skill of the JS community to what the language is capable of.
If A.I. code generators put a stop to this then it will have served its purpose IMHO.
But, to be fair, large tech corporation have many other roadblocks to better software quality, well before you reach testing individual skill levels. Moral decay and office politics to say the least...
Employers are absolutely fixated on gutting developers' salaries and going so far as to building their entire business on molasses by using JavaScript.
In todays of multi processors, its seems completely backward to adopt a runtime that is limited to a single thread.
While other languages leverage sharing memory amongst multiple cpus, node requires a process per CPU.
Large parts of the JavaScript application space too.
Language consistency, ergonomics, standard library and performance matters, and JS has major warts here. I bet when these languages are 30+ years old like JS is, the software landscape isn't dominated nearly as much by JS.
These days I intentionally start all projects with as little JS as possible, opting for Go and HTMX instead. Removing the layers of JS inconsistency and build tools makes my and my agents lives better.
More thoughts on my JS-less stack here: https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...
You can argue that high-throughput / low-latency dev tools are one of these environments. I'm not so sure. I think a lot of JS tooling is written in slow JS and gets fast with a rewrite to another language largely because of better structure.
Some environments really are tougher though. I started using WebAssembly a lot a year ago and the story for JavaScript and Python is just pretty terrible. And for JS, the things that make it hard to run in Wasm aren't universally good things to have in the language in the first place. The extreme dynamism of JS is something that so much JS tooling tries to limit.
But I think a lot of the language is quite good, and that there are possible variants of JS that are great even. I started one I hope will fit that one day (https://zena-lang.dev) and the first use cases for me are all tooling to try to make sure it's at least good for that: self-hosted compiler, formatter, regex engine, JSON parser, etc. It's quite a bit like JS/TS, but fixes a lot of things and runs forward with features that will take JS many years to get to, if it ever does (ie, pipelines, pattern matching).
I'm hoping that WebAssembly can slowly continue to gain a place on the web so JS can give up its near monopoly there. We'll see!
Or, you can have fast programs that use memory efficiently.
You just can’t do it in JavaScript. You can get really performant with JavaScript with careful engineering for sure… but there’s a big wall of diminishing returns even with all of the JIT compilation and tracing garbage collection.
Nothing stopping those same JS developers from learning some Zig or Rust or whatever. It might actually be easier to learn than memorizing all of JavaScript’s implicit coercion rules.
But if that’s too much to ask then stay in JS land and make sure there are JS devs to write tools for!
Even the V8 team gave up on documentation: https://v8.dev/blog
There is nothing stopping JS devs from working with byte buffers with near-zero overhead.
React is a whole beast.
It would be neat to see some JS devs killing some benchmarks.
Surely there can be some middle ground were you just want some small part of your app to run faster without including another tech ecosystem (locked within a Wasm sandbox).
We were doing just fine before node, and this whole rewrite JavaScript into something compiled, and more usable, is the closing of a circle that should never have happened in first place.
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: 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.
https://devblogs.microsoft.com/typescript/typescript-native-...
https://www.theregister.com/devops/2026/09/18/microsoft-agen...
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.
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.
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.
Asm.js can be transform 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 no doubt 10-100x is normal. For quality JS no way. In those case they are usually reaching into features inaccessible to normal users, but as a compiler/transpiler guy, I could connect those gaps if shown the code.
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.
Are you claiming that your own, separate programming language is faster than TypeScript, just like Go is faster than TypeScript? So in fact you agree with Anders?
The TS compiler has always been slow. There are/were several TS-in-Rust/Go compilers long before Anders announced and released the offical Go version. I've also been writing transpilers since before TS was a thing, the TS team could have made it work in JS.
But it's often easier to switch to a language that gives you that structure/performance for free. "Free" in that large companies have the budget to afford a bug-for-bug port/rewrite.
when i first started learning programming i thought it was super important to pick one language to be really good at and that could do everything but you dont have to pick just one.
i honestly think learning it opened my mind to thinking about programming differently and is probably better in the end
If you need a web app for CRUD, avoid frameworks, typescript, tailwind, nothing, just bare-naked node/html/css/js
If you need games in the browser or stuff where every byte needs optimization go with WASM
A programmer's life has become simpler
Why include node here?
Found it.