That said, today Boa has a whole team of maintainers who I’m sure will answer some questions here.
Yes the name does invoke the sense it’s a Python project but I liked it and stuck with it, I saw a Boa snake at a zoo once and knew I wanted to name my next project after it, I was also inspired by Mozilla at the time who named their projects after animals.
Speaking of Mozilla, Boa’s existence came to be because at the time I was working on Servo and wanted to include an all-rust JS engine, one didn’t really exist so I set about making one as a learning exercise, after around 2 years more joined me on that journey and today Boa is around 8 years old. It is not browser grade (although at 94.12% it is more compliant than some browser engines) but that doesn’t matter, plenty of Rust projects have found good use for it as they find it easy to embed and use, so we’re happy.
Another recent thing which we’re very proud is seeing our implementation of Temporal be used in V8 and other engines, so we’re also helping the wider ecosystem and raising all ships! (More here: https://boajs.dev/blog/2025/09/24/temporal-release)
We do hope to improve performance over the next year or so, hopefully that answers some of the Qs here.
Do you see catching up on performance with v8-jitless as a goal or is conformance the primary goal right now? Any plans on doing a JIT? I was always impressed by the idea of Truffle where you implement the language semantics once and you get both interpreter and JIT safely out of it which is a huge source of vulnerabilities in traditional JIT systems
Hi, I'm another one of the maintainers on the project.
In general, we are shifting more to performance now than conformance. We currently sit at around 94% conformance, so there's not really that much more to go conformance-wise. The remaining conformance gains are a couple of the newer specification features and Intl related features. Our current conformance can be found at https://boajs.dev/conformance.
Regarding performance, we are already making some gains, with hopefully more to come. The best example of this was probably the updates to script-bench-rs with our most recent release (which can be found at this commit https://github.com/khvzak/script-bench-rs/commit/d9635de77d2...). We still obviously have more to improve on, but we have already made some pretty steady progress from where we were.
EDIT: I forgot to answer your question about v8-jitless. Obviously in the future it would be nice to be able to be more competitive with v8-jitless, but at least for me, I'd just like to focus on improving the Boa overall.
Long answer: first, `fetch` is a runtime feature, and Boa is first and foremost an engine. So `boa_engine` -- the core project crate -- does not support `fetch` out of the box.
That being said, we do have a `boa_runtime` crate. This crate is not currently a full runtime, but it is a collection of runtime features that have been implemented and can be registered onto the context. `fetch` is one of the features that has an implementation completed in `boa_runtime`, and it does use reqwest if I'm remembering correctly. If you're interested to see some example code of registering features, you can look at our CLI code as an example :)
The past year has been huge for conformance for us, not only we caught up with the top engines but we surpassed them when working on Temporal and having all tests pass for that.
We hope to wind down some of the conformance priority now and focus on performance, we need to work on a new GC, refactor some parts of the engine, and improve various areas.
The idea of a JIT has been raised and we’re not against it, but it’s not on our plans right now (because of the above), that being said there is an open discussion.
You might want to look at the way the BEAM guys implemented their JIT in a slightly simplified and less performant (but obviously in way that is easier to reason about and extend and build upon) should you go down this road! Interesting project, I will take a look.
Right now, we use a forked and modified version of the `gc`. We definitely need to update it. Admittedly, I've been hoping to work on it but got a little distracted with temporal ...
I don't think I've actually heard of rsgc before. It's definitely interesting to see playXE put it together. I know that they'd been working on starlight at one point, so it'd be interesting to see takeaways from it.
To get to your question on the existing GCs, so far the answer is we don't truly know. We really need to do some GC experiments and test different options in Boa with JavaScript. There are not really that many GC crates out there of which I'm aware. There rust-gc's `gc` crate, dumpster, and `arena-gc` (tack on rsgc). But of those, the `gc` crate truly has the best API that we've used in Boa, but the performance is not ideal amongst other optimizations. It would be nice to preserve that API while improving the performance as well. But that remains to be seen.
I have no experience with them. In any case, it would be advisable to make the GC implementation swappable so that the language is gc-implementation-agnostic.
Hi! I am one of the maintainer of rquickjs and llrt.
Are you looking to build node-like modules anytime soon? I think we could easily port most of the modules I wrote for llrt to your engine.
If we could get rid of the C code in our app, that would make me very happy.
I'm not aware of any plans to build node-like modules, but I think we have the basic support to potentially build them out ... but I could be overlooking or missing something. I'm not personally familiar with them. But defining and using a macro should hopefully be fairly straightforward in Rust with the macros from our latest release (https://boajs.dev/blog/2025/10/22/boa-release-21#boa_module). If we're missing something, feel free to let us know.
Any runtime functionality that has been implemented is available in `boa_runtime`. I've mentioned this elsewhere in the thread, but this crate is not a runtime itself (yet). Currently, it's a collection of runtime features like `console` and `fetch`.
We're looking into the next release potentially being a v1.0, so maybe that option is a bit more possible after that release. But at the same time, I think Servo spends a decent amount of time maintaining the `mozjs` crate, so who knows.
I can't speak exactly for the other maintainers, but for me, I mostly enjoy working on Boa and Boa related things (I've spent the better part of the last year and a half on the temporal implementation). I think it would be cool to have a highly performant and conformant Rust JavaScript engine. So that's my goal :)
Servo would be difficult, becuase it uses the SpiderMonkey to manage it's entire DOM implementation (not just JS objects). Blitz would be much easier I think, but it would need to some work to allow JS objects to keep DOM objects alive.
Congrats in general! The Temporal in rust release happening in Chrome & others is so cool! So exiting to see such a core piece of work being done & then shared widely among browsers. Speaks well to Rust, the trust folks have in it, and the ability to use Rust from a variety of projects.
There's also a very lovely talk
Cross-Engine Contributions at Scale: How newcomers accelerated Temporal and Upsert in SpiderMonkey, V8, and Boa that goes deep in depth in how technically Temporal was used across engines.
https://www.youtube.com/watch?v=WieD_9BswAE
Thanks! Temporal_rs has been a really fun project to work on, and it's been great to see that it's useful for other engines!
Hopefully, there will be more chances in the future for projects like temporal_rs. Beyond just temporal_rs, I think the Temporal integration in V8 and Kiesel was a good proof of concept for Rust based libraries over FFI using Diplomat.
Nice to see another contender in this space. If OP is here, can you comment on runtime sandboxing and interop support? Can I selectively disable (or intercept) certain features like network support?
Just to note, Boa is an JavaScript engine / interpreter. We're not a runtime, but we do already have some runtime features implemented in the `boa_runtime` crate, but I don't believe that includes any sandboxing as of right now. It's not even a full fledged runtime ... yet (there's been some discussion about expanding it to a full fledged runtime if anyone has a general interest to work on it). For now, `boa_runtime` is just a collection of features for users to potentially use and if they'd like to implement more, then they are totally welcome to.
I am not meant to be harsh, but note that it fails on a small number of test cases, on v0.21 that is ~900 out of ~50k. Strictly speaking it cannot be described as standard-comforming unless there is some reason behind every failed test. A better way to strive on standard conformance, like QuickJS takes, is to pin down the ecma262 revision and make it 100% compliant.
That may be fair. The better wording may even be specification compliant, but none of the Boa maintainers made this post (we found out about it after the fact).
We, the maintainers, could probably sit down some day and try to triage the failures into a documented txt file, but the overhead on that might make it hard to maintain for an open source project. Plus a large amount of the failures are just new specification features that nobody has implemented yet.
I really appreciate the clear and detailed project description, the only concern is the title on HN. Failing on tests is fine, especially when it demands huge efforts to triage and reiterate on the project structure for them.
There's typically a pretty big difference between an interpreter meant to be embeddable and one that's not. Trying to embed V8 and keep up with V8 API changes would be a huge amount of work. I could see myself using something like this instead of Lua for some projects where V8 would be too much.
My first thought was that this could be interesting for yt-dlp?
Likely similar to something like https://github.com/mlua-rs/mlua - but wanting to execute javascript (instead of lua, and no static libs?) in the context of native rust.
This mad man had the courage to present BOA a rust project at JS Conf. The project had it's spotlight taken by Bun and Deno. I also think the project was progressing pretty slowly from what people were expecting.
Well the first two are runtimes built on top of JavaScriptCore and V8, respectively. So we're definitely in a different space.
QuickJS/QuickJS-NG might be a better comparison, but I think they are limited in specification conformance or at least selective in specification conformance in favor of remaining in a single file and fast. For instance, I'm not entirely sure whether they will be supporting Temporal once it goes Stage 4 because of the size of the feature, and I don't think they support Intl. But I also can't speak for QuickJS.
With projects like this competing against well known massive competitors (eg. the browser JS engines), not seeing their main competitors in a benchmark is a massive red flag to me: https://boajs.dev/benchmarks
Not seeing V8, SpiderMonkey JavaScriptCore is very strange...
Personally, I'm more impressed with https://github.com/Hans-Halverson/brimstone - it is faster, nearly just as full featured (almost full ES2025) and last but not least, a single person project.
Yeah! I found out about Brimstone just the other day! Its definitely interesting! One optimization that they have that Boa needs to implement is ropes for our string type :)
Well, it is, because V8 is definitely an embeddable JS engine. For many people they might want to make a choice between V8 and Boa and for them the performance numbers are important information!
People who need an extremely high performance JavaScript engine, where the extra performance is worth using an engine that's hard to embed, has an unstable API, and an absolutely massive unwieldy Google-style C++ code base with all the pain that entails, plus a JIT and all the limitations that entails, JITed V8 is the right choice.
People who just want to run JavaScript code where performance isn't such a big concern would prefer something like Boa (or the other engines listed on the comparison benchmark page).
Both have their uses, and their use case is almost entirely non-overlapping. You wouldn't choose Boa for a competitive web browser engine or as the runtime for your back-end server software. You would consider it for a plug-in system, or maybe a game's scripting system.
I'm not saying that there would be no value in having benchmarks which compare the JITless, easily embeddable JS interpreters against JITed, hard-to-embed browser-quality JS engines like V8 and SpiderMonkey. I'm just saying that those engines aren't really Boa's competitors, certainly not its "main competitors"; it's a different kind of thing that serves a different need.
It isn't, v8 will have anywhere between 2-1000x performance depending on the exact code it's jitting. Boa absolutely destroys v8 here though:
use boa_engine::{Context, Source, JsResult};
fn main() -> JsResult<()> {
let js_code = r#"
let two = 1 + 1;
let definitely_not_four = two + "2";
definitely_not_four
"#;
// Instantiate the execution context
let mut context = Context::default();
// Parse the source code
let result = context.eval(Source::from_bytes(js_code))?;
println!("{}", result.display());
Ok(())
}
Huh, I just noticed thanks to this that the comment needs to be updated in the example lol it should probably say "Parse and evaluate the source code".
Is it though? V8 and spider monkey both have jits so performance numbers of the form “wow V8 is vastly faster than any of these other ones!” (similarly for sm). Does that really have any value?
Hi all, wow was not expecting this to be trending right now.
I’m the creator of Boa, you can catch my talk about it at JS Conf EU 2019 https://www.youtube.com/watch?v=_uD2pijcSi4
That said, today Boa has a whole team of maintainers who I’m sure will answer some questions here.
Yes the name does invoke the sense it’s a Python project but I liked it and stuck with it, I saw a Boa snake at a zoo once and knew I wanted to name my next project after it, I was also inspired by Mozilla at the time who named their projects after animals.
Speaking of Mozilla, Boa’s existence came to be because at the time I was working on Servo and wanted to include an all-rust JS engine, one didn’t really exist so I set about making one as a learning exercise, after around 2 years more joined me on that journey and today Boa is around 8 years old. It is not browser grade (although at 94.12% it is more compliant than some browser engines) but that doesn’t matter, plenty of Rust projects have found good use for it as they find it easy to embed and use, so we’re happy.
One recent example is Biome who use it for their plugin infrastructure. https://github.com/biomejs/biome/pull/7300
Another recent thing which we’re very proud is seeing our implementation of Temporal be used in V8 and other engines, so we’re also helping the wider ecosystem and raising all ships! (More here: https://boajs.dev/blog/2025/09/24/temporal-release)
We do hope to improve performance over the next year or so, hopefully that answers some of the Qs here.
> I saw a Boa snake at a zoo once and knew I wanted to name my next project after it
Top tier reasoning, literally makes me want to use it
Do you see catching up on performance with v8-jitless as a goal or is conformance the primary goal right now? Any plans on doing a JIT? I was always impressed by the idea of Truffle where you implement the language semantics once and you get both interpreter and JIT safely out of it which is a huge source of vulnerabilities in traditional JIT systems
Hi, I'm another one of the maintainers on the project.
In general, we are shifting more to performance now than conformance. We currently sit at around 94% conformance, so there's not really that much more to go conformance-wise. The remaining conformance gains are a couple of the newer specification features and Intl related features. Our current conformance can be found at https://boajs.dev/conformance.
Regarding performance, we are already making some gains, with hopefully more to come. The best example of this was probably the updates to script-bench-rs with our most recent release (which can be found at this commit https://github.com/khvzak/script-bench-rs/commit/d9635de77d2...). We still obviously have more to improve on, but we have already made some pretty steady progress from where we were.
EDIT: I forgot to answer your question about v8-jitless. Obviously in the future it would be nice to be able to be more competitive with v8-jitless, but at least for me, I'd just like to focus on improving the Boa overall.
Does Boa support `fetch`? And if so, is it built on Reqwest or Wreq [1]?
I immediately have use for this if y'all have async fetch support. I can use JavaScript as an extension language for our app.
I love how supremely easy it looks to embed in normal Rust apps without a complicated build script. That, to me, is a killer feature.
Really awesome work on this!
[1] Wreq is starting to get popular for its ability to bypass Cloudflare and look like a normal browser
So this is a bit loaded. Short answer: it can.
Long answer: first, `fetch` is a runtime feature, and Boa is first and foremost an engine. So `boa_engine` -- the core project crate -- does not support `fetch` out of the box.
That being said, we do have a `boa_runtime` crate. This crate is not currently a full runtime, but it is a collection of runtime features that have been implemented and can be registered onto the context. `fetch` is one of the features that has an implementation completed in `boa_runtime`, and it does use reqwest if I'm remembering correctly. If you're interested to see some example code of registering features, you can look at our CLI code as an example :)
This sounds really well architected and extensible. I've gotta check this out.
Thank you!
No problem! If you have any questions, feel free to open an issue / discussion or reach out to us on Matrix / Discord.
The past year has been huge for conformance for us, not only we caught up with the top engines but we surpassed them when working on Temporal and having all tests pass for that.
We hope to wind down some of the conformance priority now and focus on performance, we need to work on a new GC, refactor some parts of the engine, and improve various areas.
The idea of a JIT has been raised and we’re not against it, but it’s not on our plans right now (because of the above), that being said there is an open discussion.
You might want to look at the way the BEAM guys implemented their JIT in a slightly simplified and less performant (but obviously in way that is easier to reason about and extend and build upon) should you go down this road! Interesting project, I will take a look.
Are existing GCs for Rust (e.g. rsgc) not suitable?
Right now, we use a forked and modified version of the `gc`. We definitely need to update it. Admittedly, I've been hoping to work on it but got a little distracted with temporal ...
I don't think I've actually heard of rsgc before. It's definitely interesting to see playXE put it together. I know that they'd been working on starlight at one point, so it'd be interesting to see takeaways from it.
To get to your question on the existing GCs, so far the answer is we don't truly know. We really need to do some GC experiments and test different options in Boa with JavaScript. There are not really that many GC crates out there of which I'm aware. There rust-gc's `gc` crate, dumpster, and `arena-gc` (tack on rsgc). But of those, the `gc` crate truly has the best API that we've used in Boa, but the performance is not ideal amongst other optimizations. It would be nice to preserve that API while improving the performance as well. But that remains to be seen.
Here are some gc crates:
https://docs.rs/rsgc/latest/rsgc/
https://docs.rs/ristretto_gc/latest/ristretto_gc/
https://docs.rs/dumpster/latest/dumpster/
https://docs.rs/shredder/latest/shredder/
I have no experience with them. In any case, it would be advisable to make the GC implementation swappable so that the language is gc-implementation-agnostic.
The hope of the experiments is to hopefully find an API that can be used and allow for the GCs to be more swappable. At least that's my personal hope.
We really have to dig into the experimentation and rewrite before knowing for certain.
Hi! I am one of the maintainer of rquickjs and llrt. Are you looking to build node-like modules anytime soon? I think we could easily port most of the modules I wrote for llrt to your engine. If we could get rid of the C code in our app, that would make me very happy.
Hi!
I'm not aware of any plans to build node-like modules, but I think we have the basic support to potentially build them out ... but I could be overlooking or missing something. I'm not personally familiar with them. But defining and using a macro should hopefully be fairly straightforward in Rust with the macros from our latest release (https://boajs.dev/blog/2025/10/22/boa-release-21#boa_module). If we're missing something, feel free to let us know.
Any runtime functionality that has been implemented is available in `boa_runtime`. I've mentioned this elsewhere in the thread, but this crate is not a runtime itself (yet). Currently, it's a collection of runtime features like `console` and `fetch`.
Is it still boa's goals to be used with Servo? Servo is currently tightly coupled with spidermonkey, which makes this ain’t easy.
I think it would be cool to see Servo use us.
Someone on our last release thread on Reddit (https://www.reddit.com/r/rust/comments/1odnore/boa_0210_rele...) mentioned adding Boa to Blitz, which I think would be interesting to see as well.
We're looking into the next release potentially being a v1.0, so maybe that option is a bit more possible after that release. But at the same time, I think Servo spends a decent amount of time maintaining the `mozjs` crate, so who knows.
I can't speak exactly for the other maintainers, but for me, I mostly enjoy working on Boa and Boa related things (I've spent the better part of the last year and a half on the temporal implementation). I think it would be cool to have a highly performant and conformant Rust JavaScript engine. So that's my goal :)
Servo would be difficult, becuase it uses the SpiderMonkey to manage it's entire DOM implementation (not just JS objects). Blitz would be much easier I think, but it would need to some work to allow JS objects to keep DOM objects alive.
> plenty of Rust projects have found good use for it as they find it easy to embed and use, so we’re happy.
I could easily see something similar to MongoDB being birthed out of Boa. MongoDB uses v8 for querying.
Huh! TIL. I'll have to look into that, I'm curious how it works. Although, now that I think about it, that does make sense.
Congrats in general! The Temporal in rust release happening in Chrome & others is so cool! So exiting to see such a core piece of work being done & then shared widely among browsers. Speaks well to Rust, the trust folks have in it, and the ability to use Rust from a variety of projects.
I also really enjoyed your earlier deep dive blog posts on implementation of Temporal, https://boajs.dev/blog/2025/06/15/temporal-impl-1
There's also a very lovely talk Cross-Engine Contributions at Scale: How newcomers accelerated Temporal and Upsert in SpiderMonkey, V8, and Boa that goes deep in depth in how technically Temporal was used across engines. https://www.youtube.com/watch?v=WieD_9BswAE
Thanks! Temporal_rs has been a really fun project to work on, and it's been great to see that it's useful for other engines!
Hopefully, there will be more chances in the future for projects like temporal_rs. Beyond just temporal_rs, I think the Temporal integration in V8 and Kiesel was a good proof of concept for Rust based libraries over FFI using Diplomat.
Found it:
https://github.com/boa-dev/boa/blob/6200e4b5eec1284b87e902c5...
The Boa constructor
edit: I'm here all week btw
How endearing is it seeing multiple maintainers hop in the comments to happily answer questions?
Seems like a nice team and project.
Thanks! It's always nice to talk and answer questions about the project!
Nice to see another contender in this space. If OP is here, can you comment on runtime sandboxing and interop support? Can I selectively disable (or intercept) certain features like network support?
We do have some interop support available in our `boa_runtime` crate (https://docs.rs/boa_runtime/latest/boa_runtime/) and the engine itself.
Just to note, Boa is an JavaScript engine / interpreter. We're not a runtime, but we do already have some runtime features implemented in the `boa_runtime` crate, but I don't believe that includes any sandboxing as of right now. It's not even a full fledged runtime ... yet (there's been some discussion about expanding it to a full fledged runtime if anyone has a general interest to work on it). For now, `boa_runtime` is just a collection of features for users to potentially use and if they'd like to implement more, then they are totally welcome to.
I am not meant to be harsh, but note that it fails on a small number of test cases, on v0.21 that is ~900 out of ~50k. Strictly speaking it cannot be described as standard-comforming unless there is some reason behind every failed test. A better way to strive on standard conformance, like QuickJS takes, is to pin down the ecma262 revision and make it 100% compliant.
That may be fair. The better wording may even be specification compliant, but none of the Boa maintainers made this post (we found out about it after the fact).
We, the maintainers, could probably sit down some day and try to triage the failures into a documented txt file, but the overhead on that might make it hard to maintain for an open source project. Plus a large amount of the failures are just new specification features that nobody has implemented yet.
I really appreciate the clear and detailed project description, the only concern is the title on HN. Failing on tests is fine, especially when it demands huge efforts to triage and reiterate on the project structure for them.
I don't think there's literally any conforming implementations of modern ECMAScript by that definition.
If you mean "latest" ECMAScript then that is true. Even latest gcc or clang does not support all features from C++23: https://en.cppreference.com/w/cpp/compiler_support.html.
This project is pretty cool, but reading through the pages my biggest takeaway was how fast libjs is. Amazing work over on Ladybird.
I wonder what they're doing that's so different than Boa.
What's the use case?
There's typically a pretty big difference between an interpreter meant to be embeddable and one that's not. Trying to embed V8 and keep up with V8 API changes would be a huge amount of work. I could see myself using something like this instead of Lua for some projects where V8 would be too much.
My first thought was that this could be interesting for yt-dlp?
Likely similar to something like https://github.com/mlua-rs/mlua - but wanting to execute javascript (instead of lua, and no static libs?) in the context of native rust.
The alternative might be https://github.com/denoland/rusty_v8 but without needing C++ V8.
(this is the first I'm hearing of Boa)
Correct me if I'm wrong, mlua is a set of bindings to interact with the Lua C API via FFI, not necessarily a Rust implementation.
It (mlua) would be more similar to rusty_v8.
indeed, not pure rust / requires vendored lib, but i thought it might help explain the potential use case
This mad man had the courage to present BOA a rust project at JS Conf. The project had it's spotlight taken by Bun and Deno. I also think the project was progressing pretty slowly from what people were expecting.
Bun and Deno are in totally different spaces to Boa IMO. Looks like Boa is comparable to QuickJS in the small embedded engine space.
Well the first two are runtimes built on top of JavaScriptCore and V8, respectively. So we're definitely in a different space.
QuickJS/QuickJS-NG might be a better comparison, but I think they are limited in specification conformance or at least selective in specification conformance in favor of remaining in a single file and fast. For instance, I'm not entirely sure whether they will be supporting Temporal once it goes Stage 4 because of the size of the feature, and I don't think they support Intl. But I also can't speak for QuickJS.
Doesn't matter, they were more exciting and relevant for Devs.
Seems pretty relevant- are JS Conf folks notoriously anti-rust or something?
It was a notoriously rust heavy talk, I genuinely loved it.
JavaScript scripting by users inside frameworks / applications built in other languages. Similar to https://github.com/dop251/goja for Go or https://github.com/sebastienros/jint for .NET
There is a Rust based browser project ongoing that can use this (if its not already).
Awesome!
I'm always on the lookout for embeddable JS engines.
How hard would it be to make Boa deterministic?
Like, with seeded randomness, etc.
Feels like a better name for an embeddable Python engine written in Rust.
Lua is the best for embedding.
With projects like this competing against well known massive competitors (eg. the browser JS engines), not seeing their main competitors in a benchmark is a massive red flag to me: https://boajs.dev/benchmarks
Not seeing V8, SpiderMonkey JavaScriptCore is very strange...
This is offering a JS scripting layer in an otherwise Rust project. Performance is nice, but probably not a requirement.
> Not seeing V8, SpiderMonkey JavaScriptCore is very strange...
They do compare with JIT-less V8 and SpiderMonkey there, just JSC is missing.
I recently did my own benchmarking with a lot more engines, including other Rust engines: https://ivankra.github.io/javascript-zoo/?v8=true
Personally, I'm more impressed with https://github.com/Hans-Halverson/brimstone - it is faster, nearly just as full featured (almost full ES2025) and last but not least, a single person project.
Yeah! I found out about Brimstone just the other day! Its definitely interesting! One optimization that they have that Boa needs to implement is ropes for our string type :)
It's an embedded engine for scripting a bigger application. Its main "competitor" would be QuickJS.
Though they aren't really competing on anything as far as I can tell, so maybe calling it a "similar project" is more fitting.
It's not competing with V8, SpiderMonkey and JavaScriptCore.
Well, it is, because V8 is definitely an embeddable JS engine. For many people they might want to make a choice between V8 and Boa and for them the performance numbers are important information!
People who need an extremely high performance JavaScript engine, where the extra performance is worth using an engine that's hard to embed, has an unstable API, and an absolutely massive unwieldy Google-style C++ code base with all the pain that entails, plus a JIT and all the limitations that entails, JITed V8 is the right choice.
People who just want to run JavaScript code where performance isn't such a big concern would prefer something like Boa (or the other engines listed on the comparison benchmark page).
Both have their uses, and their use case is almost entirely non-overlapping. You wouldn't choose Boa for a competitive web browser engine or as the runtime for your back-end server software. You would consider it for a plug-in system, or maybe a game's scripting system.
What about people who want performance somewhere in the middle? There is clearly value in knowing the performance difference.
I'm not saying that there would be no value in having benchmarks which compare the JITless, easily embeddable JS interpreters against JITed, hard-to-embed browser-quality JS engines like V8 and SpiderMonkey. I'm just saying that those engines aren't really Boa's competitors, certainly not its "main competitors"; it's a different kind of thing that serves a different need.
It isn't, v8 will have anywhere between 2-1000x performance depending on the exact code it's jitting. Boa absolutely destroys v8 here though:
Huh, I just noticed thanks to this that the comment needs to be updated in the example lol it should probably say "Parse and evaluate the source code".
Oh my god, that's so easy to embed.
I have to check this out.
This is awesome. You literally just sold me on it.
> anywhere between 2-1000x performance depending on the exact code it's jitting
That is useful information! Benchmarks can show you this useful information.
Is it though? V8 and spider monkey both have jits so performance numbers of the form “wow V8 is vastly faster than any of these other ones!” (similarly for sm). Does that really have any value?
Both SpiderMonkey jitless (sm-jitless) and v8 jitless are on the benchmarks page, if you click the checkboxes you will see them in the graphs.
V8-jitless is in the benchmarks and even then still blows it away, as does quickjs.