[HN Gopher] The many JavaScript runtimes of the last decade
___________________________________________________________________
The many JavaScript runtimes of the last decade
Author : LinguaBrowse
Score : 128 points
Date : 2025-07-27 14:28 UTC (8 hours ago)
(HTM) web link (buttondown.com)
(TXT) w3m dump (buttondown.com)
| LinguaBrowse wrote:
| 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.
| n0n0n4t0r wrote:
| I indeed did learn (a lot). Thank you sir for this monster:)
| kamikazeturtles wrote:
| 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 wrote:
| Maybe the ROI is something more personal than getting clicks?
| jbreckmckye wrote:
| 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 wrote:
| I feel this way.
| LinguaBrowse wrote:
| I had some faith this time as I saw a good handful of
| readers opening the email just moments after I'd posted
| the newsletter out!
|
| And while I figured Hacker News would be a coin flip, for
| other sites that show link previews, I was optimistic
| that the cartoons would encourage a click, too. In a time
| where many writers are using soulless AI-generated poster
| images, just putting in a token effort to do something
| original goes a long way.
| LinguaBrowse wrote:
| Author here - the return on investment will be modest, no
| doubt. I started the newsletter in order to share any
| thoughts on various topics without having to please a social
| media algorithm to get seen. Winning a few new readers for my
| efforts is all I'm really looking!
|
| As for the article getting regurgitated, I am not too
| worried. It is simply an awfully long, awfully dense article
| for any LLM to synthesise more than a handful of bullet
| points out of, so I think any derivative product is going to
| make for a far less engrossing read. Indeed, if you try
| asking ChatGPT about runtimes right now, you'll get a
| pathetically shallow and mainstream analysis.
|
| There may well be clickbait articles spawned from this, but
| I'm optimistic that people will find the source and be able
| to tell in an instance that it's the Real McCoy.
| Tokumei-no-hito wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| LinguaBrowse wrote:
| I totally agree that the lack of JIT has been a huge
| waste of human resources. NativeScript and React Native
| have had to move so many mountains to make viable
| software despite it.
| LinguaBrowse wrote:
| The other reploies seem to have answered it! I've never
| understood why iOS allows JIT inside WKWebView yet not inside
| bare JavaScriptCore. Maybe because WKWebView runs in its own
| separate process while a JavaScriptCore instance would run
| in-process? As for Android, guess Google are just a little
| more gung-ho?
|
| > 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
|
| Really appreciated, thanks! I do despaire that the ease of
| generating content with AI disincentivises (and discourages)
| authors from expending real effort, but there's a satisfying
| inflection point at which you can be sure you've written
| something that an LLM couldn't possibly have come up with.
| frankietaylr wrote:
| Fascinating read. Great work on the research. Where do you
| think it will go from here?
| LinguaBrowse wrote:
| As for JavaScript runtimes, having seen Lynx (and some of the
| internal work NativeScript is doing), I'd like to see more
| engine-agnostic runtimes rather than coupling each runtime to
| one engine.
|
| As for writing, I'd like to stick to more manageable topics
| in future so that I can write as a hobby rather than as
| daunting work. My previous "Frontend predictions for 2024"
| (https://buttondown.com/whatever_jamie/archive/frontend-
| predi...) was similarly thorough and took an exhausting rush
| to write up. But simpler articles like "Staying productive
| with chronic pain"
| (https://buttondown.com/whatever_jamie/archive/staying-
| produc...) were all possible to finish in a weekend.
|
| There's probably a good story in Node-API, but I think I'd
| rather take on a research-light topic for a break first!
| quotemstr wrote:
| 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.
| LinguaBrowse wrote:
| Thank you very much!
|
| I totally agree on reinventing the wheel. I think our biggest
| tool towards that will be Node-API, which is the one low-
| level building block that JavaScript runtimes seem to agree
| on (and heck, I'm sure non-JavaScript engines could implement
| a decent chunk of Node-API). The Hermes team are currently
| interested in it (https://github.com/facebook/hermes/pull/137
| 7#issuecomment-29...) for implementing heavy chunks of the
| ECMAScript spec like Intl and Temporal as plug-in features.
|
| It's interesting that you bring up tooling like npm and
| Cargo, I've never thought of sharing those. Although I'm no
| great shakes at Rust, I really, really liked how Cargo did
| things (e.g. optional dependencies and rigid library
| structure) and it'd be incredible to have that for the
| JavaScript ecosystem.
|
| Also do keep hearing nothing but great things about Graal, I
| think it's being slept on.
| revskill wrote:
| Just because he spent 1 year ???
| nabwodahs wrote:
| I'm relatively new to the JS/TS space and I'm building a mobile
| app that needs to run on both platforms. Also building a back
| end for it using Deno.
|
| I thought this article was highly informative and useful. Great
| job, and thanks!
| leptons wrote:
| Did you consider things like JScript.NET? jsc.exe still comes
| with every Windows installation, and JScript still runs on IIS
| server (I have built a few things with it).
|
| And what about things like Adobe Photoshop, After Effects,
| Premiere, and Illustrator which can run Javascript using either
| Extendscript in older versions or V8 in modern versions.
|
| https://developer.adobe.com/xd/uxp/uxp/versions/
|
| https://developer.adobe.com/photoshop/uxp/2022/ps_reference/
| LinguaBrowse wrote:
| > Did you consider things like JScript.NET? jsc.exe still
| comes with every Windows installation, and JScript still runs
| on IIS server (I have built a few things with it).
|
| I've not heard of any of these, wow - very cool that it's
| still bundled with Windows. I suspect that most things
| related to JScript wouldn't fit the scope of "the last
| decade", though? I tended to focus on creation date when
| deciding what should be in scope.
|
| > And what about things like Adobe Photoshop, After Effects,
| Premiere, and Illustrator which can run Javascript using
| either Extendscript in older versions or V8 in modern
| versions.
|
| Hmm, these may well qualify, you're right. Maybe I can add
| them to the addendum. I'd want to do a bit of research to
| understand their timeline and genealogy before including
| them, though. Wrists beginning to hurt for today now, though!
|
| I do recall now that Adobe PDFs can run JavaScript. That
| would've been worth a mention for sure.
| Sytten wrote:
| 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.
| LinguaBrowse wrote:
| Oh right, thanks for the insight. Wondering how to rephrase it.
| Did AWS at least create it, or fund it?
|
| rquickjs looks like a good one to include in the article. I've
| just edited it into the polyglot engines section (I think I've
| got a mix of engines and runtimes in there at this point
| anyway).
| cat-whisperer wrote:
| I'm curious, how do these new runtimes handle async context
| tracking? Do they all rely on Async Hooks or implement their own
| solutions?
| LinguaBrowse wrote:
| I'm not familiar with the term "context tracking", and
| management of the event loop is a bit lower level than I
| normally go, but I do know several runtimes use libuv
| (https://libuv.org) to handle asynchronous I/O, the same as
| Node.js (which it was created for).
|
| I'm sure there will be JavaScript runtimes out there using some
| of Rust's asynchronous schedulers like tokio
| (https://docs.rs/tokio/latest/tokio/), too, but I wouldn't be
| surprised if a large number of them just do things bespoke.
| reactordev wrote:
| What!? No mention of bun?
| hyper57 wrote:
| But Bun is mentioned three times?
| reactordev wrote:
| 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.
| jonluca wrote:
| You ran javascript before doing a cmd+f? I guess you are
| the target audience for this article
| reactordev wrote:
| You assume it was me that opened the page on a desktop or
| something with a primitive keyboard. I asked my agent to
| summarize and provide me the list of links to see if it
| was there. The list did not list bun. The code it
| executed through my phantomjs mcp server was simply:
| document.querySelector(a);
| xnacly wrote:
| Well i guess thats what you get for using mcp instead of
| just opening the article and reading it
| ottod wrote:
| This article deserves to be the basis of a Wikipedia page. It is
| so well written and full of references. Congratulations to the
| author.
| NeutralForest wrote:
| 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 wrote:
| Web archive and pray
| NeutralForest wrote:
| fair
| LinguaBrowse wrote:
| Thank you! It did cross my mind. I've archived a couple of the
| hard-won links in there that I had a feeling at great risk of
| rotting. But thankfully a lot of the links are to GitHub pages,
| so I'm not _so_ worried about those.
|
| Unfortunately, I think the article's readability would suffer
| if every single link were followed by an [archive] tag.
| Wikipedia have a better setup for providing both an archive
| link and a live link, which unfortunately the newsletter format
| doesn't really lend itself to.
|
| I think copying the links as-is into the Wayback Machine will
| generally do in a pinch - just a bit of a pain to find the
| right month to roll back to.
| weiliddat wrote:
| 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 wrote:
| I had it in my head that quickjs-ng
| (https://github.com/quickjs-ng/quickjs) is now blessed as the
| official fork, with Bellard even making some contributions to
| it, but maybe I've got it wrong. Here's the latest
| (https://github.com/quickjs-
| ng/quickjs/discussions/258#discus...) clarifying the two forks,
| anyway.
| williamcotton wrote:
| Speaking of QuickJS, how does it compare to embedded Lua? In
| performance, memory overhead, C API, startup time?
| LinguaBrowse wrote:
| No idea! The only benchmarks I'm aware of for QuickJS are
| against other JavaScript engines
| (https://bellard.org/quickjs/bench.html).
|
| That said, one thing I've heard a lot from NativeScript TSC
| members building on top of QuickJS is that QuickJS has
| staggeringly low overhead for calling C functions. In fact, I
| was shown benchmarks in which it calls native functions
| faster than JS functions (perhaps it's easier to optimise
| because JS functions have complications like closure capture
| to worry about). I imagine this has conceptual overlap with
| how V8's Fast API works.
| laurencerowe wrote:
| > 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.
|
| https://github.com/cloudflare/workerd/blob/main/docs/v8-upda...
| vlovich123 wrote:
| That is correct. It uses v8
| LinguaBrowse wrote:
| Dang, I misunderstood that, thanks! Fixed.
| LinguaBrowse wrote:
| My mistake, thank you for the correction! I've updated the
| article to avoid any future readers walking away with the wrong
| information.
| righthand wrote:
| > 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?
| LinguaBrowse wrote:
| > I thought over the last decade we let other languages into
| the browser
|
| Not so much! Rhino was an effort to rewrite Netscape Navigator
| in Java, and I expect that if that rewrite had taken off, Java
| might've gained a foothold (though indeed, there were Java
| applets for a time).
|
| There were also Flash apps, and of course there are some
| significant games based on WebAssembly and low-level graphics
| APIs.
|
| But ultimately JavaScript works well for GUI because it is so
| dynamic, allowing you to be less rigid in how you architect
| things. And by being a scripting language, it's super quick to
| iterate on.
| righthand wrote:
| I was being sarcastic in my post. I find bragging about
| Javascript as a flourishing UI language omitting quite a bit
| about why.
| willquack wrote:
| I had a good time being involved with a couple JavaScript
| runtimes which didn't make this list, most notably PythonMonkey
| [1] which embeds SpiderMonkey into Python and uses Python's event
| loop for its async stuff. Another interesting one was DCP which
| is sort of a pseudo js runtime that runs ontop of other js
| runtimes (including a custom sandboxed server-side runtime we
| made [3], but also any web browser), to provide cloud function
| like compute for js and wasm based workloads.
|
| Unrelated to the article, and already well known, is Pyodide
| which is a Python runtime in JS/WASM. I shoved Pyodide into DCP
| so people could run Python workloads in web browsers [4]. Crazy
| stuff...
|
| 1. https://pythonmonkey.io/ 2.
| https://distributive.network/workers 3.
| https://gitlab.com/Distributed-Compute-Protocol/dcp-native 4.
| https://willpringle.ca/blog/dcp/pyodide-worktime/
| LinguaBrowse wrote:
| My analysis on the polyglot runtimes was relatively shallow and
| I did anticipate I might disappoint, sorry! Thanks for the
| additions!
|
| I did begin a section on WASM runtimes, so Pyodide would've
| been of interest, but I could see the scope was likely to grow
| too much if I got into WASM so I held back.
| michaelsbradley wrote:
| No mention of Ejacs!?
|
| https://github.com/emacsattic/ejacs
| LinguaBrowse wrote:
| At 17 years old, I think it's comfortably outside of the scope
| of the article I was focusing on (the last decade), but thanks
| for bringing it to my attention!
|
| > Ejacs is based heavily on work by Brendan Eich (SpiderMonkey,
| Narcissus) and Norris Boyd (Mozilla Rhino).
|
| I did mention all of these, at least!
| ksherlock wrote:
| Missing^1: JScript from MicroSoft (circa 1996). Not only was it
| in Internet Explorer, it could also be used server side (ASP) and
| for scripting (WSH).
|
| Then there was JScript.NET (circa 2000)...
|
| 1. Not last decade but some of it's contemporaries are mentioned.
| LinguaBrowse wrote:
| I deliberately scoped it to the last decade because I felt it
| would be very hard to dig up information from around 1996 -
| would be better for me to leave that period to folks who were
| active developers around that time and lived through it all.
|
| But I did make sure to give Chakra a few mentions!
| rorylaitila wrote:
| GraalVM/GraalJS is one I am most impressed with. It 'just works'
| and I've been able to integrate it into my java web applications
| easily. I mostly use JS in java to run handlebars.js and test JS
| code library that we use both on the server and the client.
| LinguaBrowse wrote:
| I've heard nothing but high praise for GraalJS, yeah. I wonder
| whether it'd make any sense inside mobile apps - not due to any
| feature in mind, but simply out of interest because that's more
| the area I'm using JavaScript. The first-class interop with
| Java would be great for Android, though I wonder how cheap its
| interop with iOS (C-family languages) would be.
| asn0 wrote:
| Missed Nombas ScriptEase, a 90's-era commercial runtime most
| famous for allowing JavaScript to operate the James Webb
| Telescope. http://brent-noorda.com/nombas/us/index.htm
| LinguaBrowse wrote:
| Very cool, though when I was qualifying the scope for "the last
| decade", I was doing it by creation date rather than usage
| date, so I think I get a pass on this one!
| dfee wrote:
| This article provides good insight on the boom, but leaves out
| any insight on the inevitable bust - not on JS per se, but the
| distinct runtimes.
|
| Deno and Bun seem to be two highly competitive runtimes, each VC
| backed and positioned against each other, but the fairly tale of
| multiple winners seems unlikely in a world that favors power
| laws.
|
| So then, how do others see these ecosystems surviving over the
| next decade? What are the canaries? And, how interoperable will
| our code be?
| nosefurhairdo wrote:
| WinterCG is trying to help standardize web APIs to address
| these concerns. So one strategy when writing server-side js is
| to stick to standard APIs as much as possible.
|
| If you do want to leverage runtime-specific code you can
| isolate that code in separate modules, so if you ever do need
| to migrate off a particular runtime it's easier to
| identify/replace that code.
|
| Ultimately it's all JavaScript, and since most of these
| runtimes are open source even if they're abandoned we might see
| community forks. Though even if your chosen runtime is
| completely without support, I don't see a migration off being
| an extremely urgent or difficult task for most projects.
___________________________________________________________________
(page generated 2025-07-27 23:00 UTC)