8 ms·
JavaScript engines zoo – Compare every JavaScript engine
- td2 9mo agoIts cool, but is there any explenation how score is calculated?
- gunwd 9mo agoThis is super cool, I didn't know JavaScriptCore consistently outperformed V8 And SpiderMonkey seems... not up there compared to the other 2
- DarkFuture 9mo agoDisappointing for Firefox for such lower performance. I just ran the JetStream2 benchmark and got: - Firefox: 159 score - Chromium: 235 score That's on latest Fedora Linux and Ryzen 3600 CPU.
- p_ing 9mo agoM2 Air w/ 24GB RAM macOS 26.2: - Firefox: 253.584 - Safari: 377.470 - Chrome: 408.332 - Edge: 412.005
- quantum_bit 9mo agoMy results similar with M4 Pro (12 cores, 16 cores GPU), 24 GB RAM macOS 26.2 (the same benchmarks, I guess, https://browserbench.org/JetStream2.0/ https://browserbench.org/JetStream2.0/): Firefox: 298.136 Safari: 425.762 Just the last test in this test suite: > 3d-cube-SP > 3D cube rotation benchmark by Simon Speich. The original can be found on Simon's web page. Tests arrays and floating-point math in relatively short-running code. gives the following results: Firefox: 305.197 200 First 338.983 Worst 419.309 Average Safari: 818.449 238.095 First 176.471 Worst 1957.237 Average which shows that in this particular test, Safari is 2.5 times faster.
- tralarpa 9mo agoSimilar results here. I'm curious to know what the problem of Firefox is. For example, the 3d-raytrace-SP benchmark is nearly three times faster on Edge than on Firefox on my i7 laptop. The code of that benchmark is very simple and mostly consists of basic math operations and array accesses. Maybe the canvas operations are particularly slow on Firefox? This seems to be an example that developers should take a look at.
- 360MustangScope 9mo agoThe developers are busy ramming AI into it by management. This is probably never going to get looked into.
- nicoburns 9mo ago> Maybe the canvas operations are particularly slow on Firefox That seems likely. WebRender (Firefox's GPU accellerated rendering backend) doesn't do vector rasterization. So Firefox rasterizes vectors using the CPU-only version of Skia and then uploads them to the GPU as textures. Apparently the upload process is often the bottleneck. In contrast, Chrome uses (GPU-accelerated) Skia for everything. And Skia can render vector graphics directly into GPU memory (at least part of the rasterization pipeline is GPU accelerated). I would expect this to be quite a bit faster under load. It's a known problem, but I hear that almost all of the Gecko graphics team's capacity beyond general maintenance is going towards implementing WebGPU. --- SpiderMonkey is also now just quite a bit slower than V8 which may contribute.
- forgotpwd16 9mo agoInteresting how V8 to JSC ~2x LOC but ~2/3 the binary size.
- esprehn 9mo agoThe size difference is so large it makes me wonder if one is being compiled with ICU and the other without.
- tracker1 9mo agoComments and formatting can account for that difference in LOC though... not always directly comparable. Haven't looked, but variances with different assembly bits can make a big difference too.
- aurareturn 9mo agoThat’s the promise of Bun - that it is faster because it uses JavascriptCore.
- gurgunday 9mo agoBun is faster because it implements pretty much everything natively and just exposes them in JS, not because it uses JSCore I believe long term, V8 will become the undisputed champ again as Google has a lot more incentive than Apple to make the fastest engine, but this is just a wild guess of mine, and I'm biased being a Node.js Collaborator I've been hearing for a while that JSCore has a more elegant internal architecture than V8, and seeing the V8 team make big architectural changes as we speak seems to support it [1], but like I said, hopefully they will pay off long term [1] — https://v8.dev/blog/leaving-the-sea-of-nodes https://v8.dev/blog/leaving-the-sea-of-nodes — https://v8.dev/blog/maglev https://v8.dev/blog/maglev
- lionkor 9mo ago> Google has a lot more incentive than Apple to make the fastest engine What are those incentives? I see no incentive for Google to make something fast.
- charcircuit 9mo agoFaster page load times increases engagement with the web. More engagement on the web leads to more engagement with Google's ads.
- lionkor 9mo agoI don't agree. Page load times do not matter when everything is so locked down that most people don't even know there's an alternative.
- aurareturn 9mo agoBut this was always true. True for last 40 years. What’s changed in 2026 that will motivate Google to overtake JSCore?
- ForHackernews 9mo agoIs this right? Brimstone has a single contributor, 74k LoC (vs 1.3M for V8) and it's 97% compatible with ES6? That's a staggering accomplishment. https://github.com/Hans-Halverson/brimstone https://github.com/Hans-Halverson/brimstone
- deleted 9mo ago[deleted]
- pmkary 9mo agoWow!
- maelito 9mo agoThat's a lot of duplicate code. Différent hardware constraints and history I guess.
- mikehall314 9mo agoI assume the 98% compatibility on ES6 for V8 is because they don't have tail call optimisation?
- ivankra 9mo agoPretty much. ES6+ scores are from running compat-table's test suite (https://compat-table.github.io/compat-table/es6/ https://compat-table.github.io/compat-table/es6/), along with their weighting. If you click on an engine's name to go to a page about it, there's a report at the bottom with failing tests.
- senfiaj 9mo agoMaybe because with tail call optimization you wouldn't have a proper stack trace?
- mikehall314 9mo agoSupposedly, although the team at Apple were able to implement it. I think they had some oddly named technology like Chicken which created a shadow stack trace? Half remembered.
- senfiaj 9mo agoYes, It's called ShadowChicken, and it has negative implications for debuggability. To make debugging tolerable, JavaScriptCore added an (intentionally silly) mechanism called ShadowChicken: a shadow stack used by Web Inspector that can show a finite number of tail-deleted frames (they mention 128). It's has some tradeoff. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Execution_model#:~:text=In%20reality%2C%20discarding,the%20debuggability%20issue https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... . https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-in-webkit/ https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-... V8 team decided that it's not worth it, since proper stack traces (such as Error.stack) are essential for some libraries, such as Sentry (!). Removing some stack trace info can break some code. Also imagine you have missing info from the error stack trace in production code running on NodeJS, that's not good. If you need TCO, you can compile that code in WASM. V8 does TCO in WASM.
- deleted 9mo ago[deleted]
- gurgunday 9mo agoYou can see when JIT is disabled, the upcoming Static Hermes (Hermes V1) engine from Meta, built specifically for React Native, outperforms both V8 and JSCore on Apple Silicon It'll be interesting to see how much it will affect React Native apps as it gets more and more optimized for this use case
- no_wizard 9mo agoReact Native continues to be one of the best technology bets I’ve ever made. At one point I really thought that Flutter would outclass it but typical Google project stuff has really put a damper on it from all I can see. It’s not better than native apps, but as far as cross platform GuIs go it’s still very very good
- wiseowise 9mo ago> Flutter would outclass it but typical Google project stuff has really put a damper on it from all I can see. Flutter is amazing, but they really shot themselves in the foot with Dart (and I say that as someone who doesn't mind Dart).
- port11 9mo agoFlutter and KMM are actually very good and better to use than the debacle that React Native can be. But they’re worlds behind in community support, and React Native became the ‘kitchen sink’ that works for most needs. As a React Native developer for, what, 6 years, I don’t have much positivity left to offer. Bug reports to the core team that went nowhere, the Android crash on remote images without dimensions, all the work offloaded to Expo, etc. Google couldn’t really done better, maybe Flutter should’ve become independent after the initial release.
- no_wizard 9mo agoThe problem Flutter has is highly highly dependent on Google, from funding to development. That it is also the only real use case for Dart also doesn’t help matters. While I agree the technology is very good and in some cases superior it doesn’t have a path to stable funding, seemingly. Google laid off a big chunk of Dart and Flutter teams last year, and there is no Expo to pickup the slack. While Meta could do the same for React Native, Expo has always been there to pick up the slack and it receives bigger community support from the community too. For example Shopify has a few great well maintained RN libs
- pmkary 9mo agoI never thought they are so many!
- sorentwo 9mo agoBefore looking at the zoo I figured there would be a dozen or so engines compared. Seeing the actual comparison is astounding! The amount of work just to aggregate and compare is admirable, let alone the effort behind the engines themselves.
- deleted 9mo ago[deleted]
- donatj 9mo agoI am pleased to see how complete this table really is. I recently migrated a tool from Otto to Modernrc's QuickJS transpile of QuickJS to pure Go. Both are represented.
- ChocolateGod 9mo agoIs there any benchmarks between engines that record memory usage? How many of these engines are chasing benchmarks at the cost of increased memory usage?
- ivankra 9mo agoI captured max RSS size while running benchmarks as a rough approximation, but it's not exposed anywhere. If you go to the repo, you can run `./bench/compare -f rss_mb -lT bench/amd64/*.json` to see a table in the terminal. No big surprises there, Java engines (Rhino, Nashorn, GraalJS) are most memory-hungry.
- _alastair 9mo agoIt’s fascinating to see so many implementations targeting the same thing, along with the crazy variation in runtime size. I’d love to see memory usage comparisons too but I suppose you’d need to establish what you’re actually measuring first. A few years ago I started work on a kind of abstraction layer that would let you plug Rust code into multiple different engines. Got as far as a proof of concept for JavascriptCore and QuickJS (at the time I had iOS and Android in mind as targets). I still think there’s some value in the idea, to avoid making too heavy a bet on one single JS engine. https://github.com/alastaircoote/esperanto https://github.com/alastaircoote/esperanto
- ivankra 9mo agoI actually captured max RSS size while running benchmarks as a rough approximation, but it's not exposed anywhere. If you go to the repo, you can run `./bench/compare -f rss_mb -lT bench/amd64/*.json` to see a table in the terminal. No big surprises there, Java engines (Rhino, Nashorn, GraalJS) are most memory-hungry.
- bflesch 9mo agothanks for your work!
- csmantle 9mo agoWhat surprises me is that under the "Show variants" checkbox, SpiderMonkey 24 from 2013 outperforms 147alpha by ~2000 pts -- almost 10% --, while having 1/4 LOC, 1/3 binary size and almost 1:1 on other metrics. (SM 24 targets ES5, however)
- simonw 9mo agoAll these JavaScript engines and it's still remarkably hard to find a robust solution for executing JavaScript from untrusted sources inside my own server-side applications. Every time I look I find repos that look promising at first but are either unmaintained or have a team or just one or two maintainers running them as a side project. I want my sandbox to be backed by a large, well funded security team working for a product with real money on the line if there are any holes! (Playing with Cloudflare workerd this morning, which seems like it should cover my organizational requirements at least.) Update: Classic, even Cloudflare workerd has "WARNING: workerd is not a hardened sandbox" in the README! https://github.com/cloudflare/workerd?tab=readme-ov-file#warning-workerd-is-not-a-hardened-sandbox https://github.com/cloudflare/workerd?tab=readme-ov-file#war...
- pastage 9mo agoOne process per sandbox will get you far, if all you want is to execute something. I would go as far as say it is pretty easy.
- simonw 9mo agoI want to execute untrusted code. This makes it very difficult indeed.
- mike_hearn 9mo agoWhat's wrong with V8? You could also look at GraalJS. It's shipped as part of the Oracle Database, there's a security team, patching process etc. It's used in production by Amazon amongst others. It's got flexible sandbox features too. https://www.graalvm.org/latest/reference-manual/embed-languages/#access-privilege-configuration https://www.graalvm.org/latest/reference-manual/embed-langua... The way it's written is good for security as well: https://medium.com/graalvm/writing-truly-memory-safe-jit-compilers-f79ad44558dd https://medium.com/graalvm/writing-truly-memory-safe-jit-com... Disclosure: I sit next to the GraalVM team.
- 9mo ago
- pastage 9mo agoNow run the "Which programming language is fastest?" Benchmark on all of them. https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- ivankra 9mo agoYou can use this docker image with all the pre-built binaries as a starting point: https://hub.docker.com/r/ivankra/javascript-zoo https://hub.docker.com/r/ivankra/javascript-zoo Just keep benchmark code limited to standard ECMAScript, don't expect any browser or Node APIs besides console.log() or print().
- callc 9mo agoI got a question for everyone: as a web user, have you been affected by performance limitations of a particular JS engine? Have you switched browsers b/c of JS speed? My n=1 as a long time Firefox user is that performance is a non-issue (for the sites I frequent). I’m much more likely to switch browsers because of annoying bugs, like crashes due to FF installed as a snap. It honestly is pretty surprising, given that JS runtime runs website code single-threaded.
- mock-possum 9mo agoNo, speed / performance of JavaScript has never, in my entire history of web use, been a driving factor in picking a browser - there may be one-offs here and there where I’m annoyed I have to switch to a different browser for a few minutes due to feature support or extension availability - but I can’t remember thinking “boy I wish JavaScript didn’t run so slow”
- creatonez 9mo agoWhen Chrome first came out in 2008, it was noticeably faster than any competitors. Users with only moderate tech knowledge were switching in droves because it was faster. Part of this was that it had a process-per-tab model properly making use of multi core CPUs for the first time, but much of it was because V8 was fast. The gap is not so big these days. JavaScriptCore, Spidermonkey, and V8 are all competent.
- bschmidt25003 9mo ago[dead]
- bschmidt25011 9mo ago[dead]
- vivzkestrel 9mo agogenuine question, let us say you took the source code of every single engine you see here and feed it to all the 10000 llms and ask them to analyze the code, optimize every function the best way they see fit, make architectural changes as and when they see appropriate, what do you think will be the result from cutting edge models?
- utf_8x 9mo agoConsidering the relatively limited context window even on the latest models, the output would likely be incoherent mess. Sure, you could make the LLM go through the code in easily digestible chunks (file by file) but to get any groundbreaking optimization, it would need to have the context of the entire project to properly understand the architecture. (IMO that is, I'm not an expert)