Nova: A JavaScript and WebAssembly engine written in Rust
trynova.dev
trynova.dev
For the foreseeable future the aim will be rather on the QuickJS/DuckTape level than beating V8. But! That is only because they need to be beat before V8 can be beaten :)
I'm not rushing to build a JIT, and I don't even have exact plans for one right now but I'm not barring it out either.
If my life, capabilities, and external support enable it then I do want Nova to either supplant existing mainstream engines, or inspire them to rethink at least some of their heap data structures. But of course it is fairly unlikely I will get there; I will simply try.
I'm aiming for something like 75-85% this year; basically get iterators properly done (they're in the engine but not very complete yet), implement ECMAScript modules, and then mostly focus on correctness, builtins, and performance improvements after that. 99% would perhaps be possible by the end of next year, barring unforeseeable surprises.
* 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.
Thank you so much <3
So the project started as a "let's write a better JS engine than V8 in Rust!" kind of joke. Beyond that, I personally wanted to write in Rust, and it turns out that with sufficient abuse[1], the Rust borrow checker can be used to perform GC safety checks at compile time. This means that Nova can avoid rooting a lot of values during runtime because at compile time the borrow checker has already ensured that those values will never be used after a GC safepoint.
This is something that would not be feasible in other languages without significant custom checking infrastructure. As an example, Firefox / SpiderMonkey has a custom linter that checks that "no-GC" functions cannot accidentally call back into "GC" functions, but it is roughly a full-program analysis task and the checker is hand-written, custom code that sometimes lacks special cases for this function or that. In Nova, a "GC" function takes a move-only "GcScope" parameter by value (and all GC-able Values observe that value; when the value gets moved to a child call, all those observing Values invalidate; this is that GC safety checking), and "no-GC" functions take a copy "NoGcScope" parameter that can be created from a "GcScope" and that again observes the "GcScope". Through these, the borrow checker becomes the checker for this logic.
[1]: https://fosdem.org/2025/schedule/event/fosdem-2025-4394-abus...
And `1` is?
Still at early stages, quite incomplete, not nearly ready for real use, AFAICT.
Yes, basically. And removing structural inheritance.
So basically it just means that I have to write more interfaces and implementations for them, because I don't have base classes to fall onto. Instead, in derived type/class instances I have an optional (maybe null) "pointer" to a base type/class instance. If the derived instance never uses its base class features, then the pointer stays null and no base instance is created.
Often derived objects in JS are only used for those derived features, so I save live memory. But: the derived object type needs its own version of at least some of the base class methods, so I pay more in instruction memory (executable size).
There are strong (IMO) reasons to think it will fit, though. User code can indeed do whatever but it rarely does. Programs written in JS are no less structured and predictable than ones written in C++ or Rust or any other language: they mostly operate on groups of data running iterations, loops, and algorithms over and over again. So the instructions being interpreted are likely to form roughly ECS System-like access patterns.
Furthermore, it is more likely that data that came into the engine at one time (eg. one JSON.parse call or fetch result) will be iterated through at the same time. Thus, if the engine can ensure that data is and stays temporally colocated, then it is statistically likely that the interpreter's memory access patterns will not only come from System-like algorithms, they will access Component-array like memory.
So: JS objects (and other heap allocated data) are Entities, their data is laid out in arrays of Components (TODO laying out object properties in Component arrays, at least in some cases), and the program forms the Systems. ECS :)
I think your instincts about program structure are mostly right, but the outliers are pretty far out there.
I’m much less optimistic about how you’re framing arbitrary data access. In my experience, it’s very common for JS code (marginally less common when authored as TS) to treat JSON (or other I/O bound data) as a perpetual blob of uncertainty. Data gets partially resolved into program interfaces haphazardly, at seemingly random points downstream, often with tons of redundancy and internal contradictions.
I’m not sure how much that matters for your goals! But if I were taking on a project like this I’d be looking at that subset of non-ideal patterns frequently to reassess my assumptions.
The partial resolving and haphazardness of JSON data usage shouldn't matter too much. I don't mean to make JSON parsed objects to be some special class, per se, or for the memory layout to depend on access patterns on said data. Only, I force data that was created together to be close together in memory (this is what real production engines already do, but only if possible) and for that data to stay together (again, production engines do this but only as is reasonably possible; I force the issue). So I explicitly choose temporal coherence. Beyond that, I use interface inheritance / removal of structural inheritance to reduce memory usage. eg. Plain Arrays (used in the common way) I can push to 9 bytes or even 8 bytes if I accept that Arrays with a length larger than 2^24 are always pessimised. ECS / Struct-of-Arrays data storage then further allows me to choose to move some data onto separate cache lines.
But; it's definitely true that some programs will just ruin all reasonable access patterns and do everything willy-nilly and mixed up. I expect Nova to perform worse on those kinds of cases: as I am adding indirection to uncommon cases and splitting up data onto multiple cache lines to improve common access patterns, I do pessimise the uncommon cases further and further down the drain. I guess I just want to see what happens if I kick those uncommon cases to the curb and say "you want to be slow? feel free." :) I expect I will pay for that arrogance, and I look forward to that day <3
Arrays, Objects, ArrayBuffers, Numbers, Strings, BigInts, ... all have their data allocated onto different heap vectors. These heap vectors will eventually be SoA vectors to split objects' attributes along ECS-friendly lines; eg. Array length might be split from the elements storage pointer, Object shape pointer split from the Object property storage pointer etc. Importantly, what we already do is that an Array does not hold all Object's attributes but instead holds an optional pointer to a "backing Object". If an Array is used like an Object (eg. `array.foo = "something"`) then a backing object is created and the Array's backing Object pointer is initialised to point to that data. Because we use a SoA structure, that backing Object pointer can be stored in a sparse column, meaning that Arrays that don't have a backing Object initialised also do not initialise the memory to hold the pointer.
I'm also interested in maybe splitting Object properties so that they're stored in ECS-friendly lines (at least if eg. they're Objects parsed from an Array in JSON.parse).
Our GC is then a compacting GC on these heap vectors where it simply "drops" data from the vector and moves items down to perform compaction. This also means it gets to perform the compaction in a trivially parallel manner <3
But: the lesser but still impactful performance benefit of ECS is the usage of Struct-of-Array vectors for data storage. JavaScript can still ruin that benefit by always accessing all parts and features of an Object every time it touches one, but it is a less likely thing to happen. So, there is a benefit that JavaScript code itself can enjoy.
Finally, there is one single "true System" in a JavaScript engine's ECS: the garbage collector. The GC will run through a good part of the engine heap, and you can fairly easily write it to be a batched operation where eg. "all newly found ordinary Objects" are iterated through in memory access order, have their mark checked, and then gather up their referents if they were unmarked. Rinse and repeat to find all live/reachable objects by constantly iterating mostly sequential memory in batches. This can also be parallelised, though then the batch queue needs to become shareable across threads.
The sweep of the heap after this is then a True-True System where all items are iterated in order, unmarked ones are ignored, marked ones are copied to their post-compaction location, and any references they hold are shifted down to account for the locations of items changing post-compaction.
Good point.
If you know the data can't be accessed in parallel by the user code, that safety guarantee might allow the JIT to do it anyway.
Memory that's accessed together is stored together.
So for example, if you're calculating physics in a game, you perform all the needed physics operations on values stored contiguously in memory. Great cache locality means huge reduction in cache misses and performance benefits. If you had millions of entities and are performing each entity's set of operations (rendering, IO, AI, physics, etc) entity by entity, you might be getting a lot of cache misses.
There's an entire talk by Bob Nystrom (of crafting interpreters and game programming patterns) arguing you likely don't need to use ECS unless you have the exact problem of high cache miss rate.
Any particular reason against using Cranelift for WASM?
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.
Wondering how hard it is to embed / vendor it into other projects. In the past we relied on duktape especially because how easy it is to just copy one .c file into your project and have it integrated there. It's one of the best features of duktape that other JS engines couldn't yet beat. Do you have plans to maybe provide a collapsed version of nova that is especially easy for embedding into third party projects?
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.
As for calling methods on a Rust singleton / struct, that is not yet really supported. We do have a `Value::EmbedderObject` type that will be the place for these, but its implementation is so far entirely empty / todo!() only. The first step for those will be just a very plain and simple `Box<dyn ObjectMethods>` type of thing, but eventually I'm thinking that our EmbedderObjects would actually become backed by an ECS data storage in the engine heap. So eg. your Bar type would be registered to the engine via some call together with its fields, and those would form an ECS "archetype". Then these items would be created by another call and would then become visible to JS code as objects, with some of their fields possibly being pointers to foreign heap data etc.
But that's a little ways off.
I see you use Cargo feature for this. One thing to be aware of is Cargo's feature unification (https://doc.rust-lang.org/cargo/reference/features.html#feat...), ie. if an application embeds crate A that depends on nova_vm with all features and crate B that depends on nova_vm without any security-sensitive features like shared-array-buffer (eg. because it runs highly untrusted Javascript), then interpreters spawned by crate B will still have all features enabled.
Is there an other way crate B can tell the interpreter not to enable these features for the interpreters it spawns itself?
There is currently no other way to disable features, and at least for the foreseeable future I don't plan on adding runtime flags for these things. I'm hoping to use the feature flags for optimisations (eg. no need to check for holes, getters, prototype chain in Array indexed operations if those are turned off) and I'm a bit leery of making those kinds of optimisations if the feature flags are runtime-controllable. It sounds like a possible safety hole.
For now I'll probably have to just warn (potential) users about this.
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.
But, an apology is also in order: the 70% number on our website is more misleading than I thought it is. Our test runner skips entirely Annex B[1] _and_ Intl tests; one could perhaps view the 70% number then as "percentage of ECMA262 specification done". The 58% value reported by test262.fyi is probably the correct value (unless we have a bug with debug prints that causes spurious failures there).
[1]: I remembered that we skip Annex B tests; those are fairly few in number and we pass 40% of them anyway, so their effect isn't large. Didn't remember the other category we skip, and absolutely didn't remember that it's a major one like Intl.