> For all the overlap in strategy, notable is the variety in engines underpinning all these runtimes. While Deno continues Node.js's tradition of using V8, we see Bun employing JavaScriptCore, WinterJS using SpiderMonkey, LLRT on QuickJS, and Cloudflare Workers on the tailor-made workerd. No longer is the backend solely a stage for Node.js and V8 – it's now fashionable to pick a runtime and engine optimised for the task.
I don't think this is completely accurate. While Cloudflare's workerd is a tailor-made runtime (equivalent level to deno/node/bun/etc.) it uses the V8 engine.
I see a few mentions of QuickJS, but they all refer to the fork of Bellard's QuickJS https://bellard.org/quickjs/, which I think deserves a mention. It seems to be still active (last release 2025-04-26, GitHub mirror at https://github.com/bellard/quickjs shows some activity).
LinguaBrowse · 4h ago
Took me over a year to finish writing this monster of an article. 4,000+ words, 200+ links, and lots of research covering countless JavaScript runtimes and engines.
Please have a read! I guarantee you'll learn something new.
kamikazeturtles · 1h ago
I always wondered if there is still an ROI for writing a well researched in depth article.
If the insight in the article is actually unique, it'll just get regurgitated by other writers and AIs a hundred times, maybe even with better visuals and diagrams and that'll be the article that gets all the clicks.
tommica · 40m ago
Maybe the ROI is something more personal than getting clicks?
jbreckmckye · 32m ago
It can be. But there is a certain existential dread, in the hours after sharing something, when you fear it might all have been toil in obscurity
chistev · 21m ago
I feel this way.
frankietaylr · 56m ago
Fascinating read. Great work on the research. Where do you think it will go from here?
n0n0n4t0r · 1h ago
I indeed did learn (a lot).
Thank you sir for this monster:)
quotemstr · 46m ago
Thanks for putting in all this work. People should get more credit for writing good survey articles like yours.
One of the regrettable quirks of our industry is the way we replicate theoretically language-neutral components separately in multiple language ecosystems and verticals. I wish we didn't a separate npm and cargo. I wish the polyglot runtimes you mention (especially Graal) would see more adoption. I wish we didn't have both Duktape and MicroPython. There's nothing language-specific about efficient garbage collection or compact bytecode or package dependency resolution.
Tokumei-no-hito · 1h ago
it's interesting that a lot of innovation happened on mobile runtimes to deal with apples JIT restriction. what was that about and why didn't android have the constraint?
of course i can look it up, but you probably have a better insight than the slop i'll find off google.
thanks for the article. these days it's rare to see something so well researched and written while still being able to tell it was authored by a human. cheers
toast0 · 1h ago
Apple has a JIT restriction because JIT introduces native code that was not present during app review, and app review is where they prohibit calling non-public APIs, at least historically.
Android doesn't have a JIT restriction. API restrictions are expected to be enforced at runtime, not through review time checks.
quotemstr · 41m ago
> Apple has a JIT restriction because JIT introduces native code that was not present during app review, and app review is where they prohibit calling non-public APIs, at least historically.
Another regrettable thing about our industry is the proliferation of locked-gate-in-an-open-field-tier security theater. Apple's PROT_EXEC restriction has zero security benefit: anything JIT-compiled code can do, interpreted code can do too.
(In the same vein, macOS Santa (used by many a tech company to police programs runnable on Apple developer endpoints) doesn't restrict script launches at all. The interpreters that Apple ships with macOS have built-in FFIs like Python ctypes that enables programs launched using these interpreters to do anything a Mach-O binary can do.)
While I respect the sweat and cleverness that went into making JS runtimes work efficiently while wearing Apple's no-PROT_EXEC hairshirt, none of this work ought to have been necessary. Imagine how much further ahead the industry would be if these big brains had focused on solving some other problem.
righthand · 6m ago
> Lastly, JavaScript continues to show its strength as a language for GUI programming, being employed in a variety of ways to develop native apps on mobile phones and Smart TVs, though with web view based apps still being the vogue on desktop.
Really? I thought over the last decade we let other languages into the browser but Javascript was so amazing that no one uses the other languages. Javascript has had all this competition on the UI layer it’s amazing it came out #1. Am I reading the implication correctly?
NeutralForest · 35m ago
Thanks for the article! Do you have a solution, if any, to maintain links green? Anytime I write something with lots of links, I'm always afraid that there's basically no way to retrieve the original page after some time.
paulddraper · 19m ago
Web archive and pray
Sytten · 2h ago
I would like to rectify that LLRT is mostly community contributed and one guy from AWS (Hi Richard!). There are many businesses using LLRT modules (I worked a lot on making it modular) and rquickjs.
I am a maintainer of both and I wrote a couple of modules myself. There is no better JS runtime for Rust IMO, it is based on quickjs-ng (a fork of quickjs initially due to quickjs inactivity but not both projects are active and have diverged) with a lot of the major Node/WinterJS APIs.
ottod · 1h ago
This article deserves to be the basis of a Wikipedia page. It is so well written and full of references. Congratulations to the author.
cat-whisperer · 1h ago
I'm curious, how do these new runtimes handle async context tracking? Do they all rely on Async Hooks or implement their own solutions?
reactordev · 1h ago
What!? No mention of bun?
hyper57 · 59m ago
But Bun is mentioned three times?
reactordev · 11m ago
They should include the link to their site then: bun.com
I used document.querySelector(“a”) and couldn’t find mention of it, upon reading it thoroughly, they do mention it. My fault.
I don't think this is completely accurate. While Cloudflare's workerd is a tailor-made runtime (equivalent level to deno/node/bun/etc.) it uses the V8 engine.
https://github.com/cloudflare/workerd/blob/main/docs/v8-upda...
Please have a read! I guarantee you'll learn something new.
If the insight in the article is actually unique, it'll just get regurgitated by other writers and AIs a hundred times, maybe even with better visuals and diagrams and that'll be the article that gets all the clicks.
One of the regrettable quirks of our industry is the way we replicate theoretically language-neutral components separately in multiple language ecosystems and verticals. I wish we didn't a separate npm and cargo. I wish the polyglot runtimes you mention (especially Graal) would see more adoption. I wish we didn't have both Duktape and MicroPython. There's nothing language-specific about efficient garbage collection or compact bytecode or package dependency resolution.
of course i can look it up, but you probably have a better insight than the slop i'll find off google.
thanks for the article. these days it's rare to see something so well researched and written while still being able to tell it was authored by a human. cheers
Android doesn't have a JIT restriction. API restrictions are expected to be enforced at runtime, not through review time checks.
Another regrettable thing about our industry is the proliferation of locked-gate-in-an-open-field-tier security theater. Apple's PROT_EXEC restriction has zero security benefit: anything JIT-compiled code can do, interpreted code can do too.
(In the same vein, macOS Santa (used by many a tech company to police programs runnable on Apple developer endpoints) doesn't restrict script launches at all. The interpreters that Apple ships with macOS have built-in FFIs like Python ctypes that enables programs launched using these interpreters to do anything a Mach-O binary can do.)
While I respect the sweat and cleverness that went into making JS runtimes work efficiently while wearing Apple's no-PROT_EXEC hairshirt, none of this work ought to have been necessary. Imagine how much further ahead the industry would be if these big brains had focused on solving some other problem.
Really? I thought over the last decade we let other languages into the browser but Javascript was so amazing that no one uses the other languages. Javascript has had all this competition on the UI layer it’s amazing it came out #1. Am I reading the implication correctly?
I am a maintainer of both and I wrote a couple of modules myself. There is no better JS runtime for Rust IMO, it is based on quickjs-ng (a fork of quickjs initially due to quickjs inactivity but not both projects are active and have diverged) with a lot of the major Node/WinterJS APIs.
I used document.querySelector(“a”) and couldn’t find mention of it, upon reading it thoroughly, they do mention it. My fault.