You 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
This is super cool, I didn't know JavaScriptCore consistently outperformed V8
And SpiderMonkey seems... not up there compared to the other 2
I assume the 98% compatibility on ES6 for V8 is because they don't have tail call optimisation?
I 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.
I 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.
Is there any benchmarks between engines that record memory usage?
How many of these engines are chasing benchmarks at the cost of increased memory usage?
It’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.
What 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)
That's a lot of duplicate code. Différent hardware constraints and history I guess.
Is 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.
genuine 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?
Before 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.
Its cool, but is there any explenation how score is calculated?
I never thought they are so many!
Now run the "Which programming language is fastest?" Benchmark on all of them.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[dead]
[dead]
All 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#war...