* The other being Google's Closure Compiler, which probably isn't relevant to you as it assumes that its output has to run on existing engines in browsers.

Yes, basically. And removing structural inheritance.

Maybe Cranelift might offer that out of the box? If so, it'd be a great choice. If it doesn't, or if the only lever to pull is simply a runtime "how much optimisations should we do" one then Cranelift might not be such a great choice, since we'd want to avoid bringing in big and heavy dependencies that only use a particular subset at runtime.

We owe a lot to Boa: I would like to call Jason Williams a personal acquaintance, we've discussed JS engines in general, and Boa and Nova in particular both face to face and online. Some parts of builtin methods, like float parsing, have been copied verbatim from Boa with copyright notices to Jason.

As for comparisons, the focal difference is perhaps the starting aims of each project: Boa was started by Jason (according to his Node.JS conf talk) to see if one can build a JS engine in Rust, and what building a JS engine means anyhow. They've since showed that indeed this can be done, no problem whatsoever. Because Boa walked, Nova could "run": I started working on Nova actively because I wanted to see what building a JS engine using an ECS-like architecture and data-oriented design would look like; what would it mean to get rid of the traditional structural inheritance / object-oriented design paradigm of JS engines, and what would the resulting engine look like?

So, Boa is a quest to show that a (traditional) JS engine can be built in Rust. Nova is a quest to show that Rust-like non-traditional architectures can be applied to a JS engine, and hoping that this will lead to unforeseen (or previously unappreciated) benefits.

Building an engine that benchmarks better than V8, SpiderMonkey, or JSC is a multi-year effort with a very high chance of failure. Maybe Nova's data-oriented heap design will give us a leg up on that, but it's still a massively challenging endeavour.

Building an engine with good benchmarks, an amazingly small memory footprint, and great cache-friendliness: that is the kind of engine I'm seeing in Nova. As you say, most JS apps are not bottlenecked by performance. Memory and complexity are the more likely bottlenecks; I believe I can improve the former fairly radically, and hopefully drive JS developers such as myself towards reducing the latter through opinionated engine design.

The engine is written with a fair bit of feature flags to disable more complicated or annoying JS features if the embedder so wants: it is my aim that this would go quite deep and enable building a very slim, simple, and easily self-optimising JS engine through this.

That could then perhaps truly serve as an easy and fast scripting engine for embedding use cases.

In a way I'm honestly surprised we've gotten that high, but on the other hand maybe it's not too crazy either: Kiesel engine (written in Zig) is at 75% and is pretty much the same age as Nova, and I believe has a similar sized "development team" (one person doing a lot of the work, LinusG for them and me on Nova's side, and then a smattering of other people with a bit less free time on their hands).

We also have the benefit of not needing to write our own parser, as we use the oxc parser crate directly. That has given us a huge leg up in getting up and running.

That being said, our own tests show 70.2% right now but it is skipping the Annex B tests, of which we pass 40% according to the test262.fyi website. And on test262.fyi we currently pass only 58.7%: this number is in error I believe. We've already passed 60% on test262.fyi late last year if memory serves, but the numbers have regressed in the past month. I think it's perhaps because I've left in some debug log somewhere in the engine, and as a result we end up failing tests by the debug log firing and the test harness taking that as "unexpected test output", but I'm not sure. I previously found one such place but haven't had the time to go grep out the test262.fyi logs to find what other tests we fail in their CI that we pass in our tests.

It fails to differentiate between JavaScript engines, a core language implementation, and runtimes, an engine plus the useful parts needed for writing software (os, event loop etc.).

It lists engines like boa, duktape or Hermes as if they are the same thing as Node, Deno or Bun, but at the same time doesn't even mention SpiderMonkey, V8 or JavaScriptCore, as if realizing they are not actually in the same class.

I guess the snark wouldn't work as well if a chunk of the list gets eliminated by thinking about it.