HN

Comments (65)

• Menu

  simonw
  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...
• Menu

  gurgunday
  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 SiliconIt'll be interesting to see how much it will affect React Native apps as it gets more and more optimized for this use case
• Menu

  callc
  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.
• td2
  Its cool, but is there any explenation how score is calculated?
• Menu

  gunwd
  This is super cool, I didn't know JavaScriptCore consistently outperformed V8And SpiderMonkey seems... not up there compared to the other 2
• donatj
  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.
• Menu

  mikehall314
  I assume the 98% compatibility on ES6 for V8 is because they don't have tail call optimisation?
• csmantle
  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)
• Menu

  _alastair
  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.https://github.com/alastaircoote/esperanto
• anon
  undefined
• Menu

  ChocolateGod
  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?
• maelito
  That's a lot of duplicate code. Différent hardware constraints and history I guess.
• Menu

  ForHackernews
  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.https://github.com/Hans-Halverson/brimstone
• sorentwo
  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.
• anon
  undefined
• Menu

  pastage
  Now run the "Which programming language is fastest?" Benchmark on all of them.https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
• pmkary
  I never thought they are so many!