[HN Gopher] Boa: A standard-conforming embeddable JavaScript eng...
___________________________________________________________________
Boa: A standard-conforming embeddable JavaScript engine written in
Rust
Author : maxloh
Score : 126 points
Date : 2025-11-06 06:15 UTC (9 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| sebastianconcpt wrote:
| What's the use case?
| jasonjmcghee wrote:
| 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)
| written-beyond wrote:
| 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.
| jasonjmcghee wrote:
| Seems pretty relevant- are JS Conf folks notoriously anti-
| rust or something?
| written-beyond wrote:
| It was a notoriously rust heavy talk, I genuinely loved
| it.
| afavour wrote:
| Bun and Deno are in totally different spaces to Boa IMO.
| Looks like Boa is comparable to QuickJS in the small
| embedded engine space.
| nekevss wrote:
| 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.
| written-beyond wrote:
| Doesn't matter, they were more exciting and relevant for
| Devs.
| mort96 wrote:
| 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?
| jddj wrote:
| 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
| Timothycquinn wrote:
| There is a Rust based browser project ongoing that can use this
| (if its not already).
| speps wrote:
| 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...
| mort96 wrote:
| It's not competing with V8, SpiderMonkey and JavaScriptCore.
| IshKebab wrote:
| 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!
| mort96 wrote:
| 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.
| IshKebab wrote:
| What about people who want performance somewhere in the
| middle? There is clearly value in knowing the performance
| difference.
| le-mark wrote:
| 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?
| baq wrote:
| 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(())
| }
| echelon wrote:
| 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.
| IshKebab wrote:
| > anywhere between 2-1000x performance depending on the
| exact code it's jitting
|
| That is useful information! Benchmarks can _show_ you
| this useful information.
| nekevss wrote:
| 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".
| 0cf8612b2e1e wrote:
| This is offering a JS scripting layer in an otherwise Rust
| project. Performance is nice, but probably not a requirement.
| gr4vityWall wrote:
| 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.
| vlovich123 wrote:
| V8-jitless is in the benchmarks and even then still blows it
| away, as does quickjs.
| jitl wrote:
| 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.
| ivankra wrote:
| > 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.
| delduca wrote:
| Lua is the best for embedding.
| ComputerGuru wrote:
| 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?
| nekevss wrote:
| 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.
| ModernMech wrote:
| Feels like a better name for an embeddable Python engine written
| in Rust.
| k__ wrote:
| 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.
| jayflux wrote:
| 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.
| vlovich123 wrote:
| 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
| nekevss wrote:
| 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.
| echelon wrote:
| 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
| nekevss wrote:
| 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 :)
| echelon wrote:
| This sounds really well architected and extensible. I've
| gotta check this out.
|
| Thank you!
| nekevss wrote:
| No problem! If you have any questions, feel free to open
| an issue / discussion or reach out to us on Matrix /
| Discord.
| jayflux wrote:
| 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.
| amelius wrote:
| Are existing GCs for Rust (e.g. rsgc) not suitable?
| nekevss wrote:
| 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.
| Ganipote wrote:
| Is it still boa's goals to be used with Servo? Servo is
| currently tightly coupled with spidermonkey, which makes this
| ain't easy.
| nekevss wrote:
| I think it would be cool to see Servo use us.
|
| Someone on our last release thread on Reddit (https://www.red
| dit.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 :)
| jauntywundrkind wrote:
| 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
| nekevss wrote:
| 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.
| qbane wrote:
| 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.
| nekevss wrote:
| 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.
___________________________________________________________________
(page generated 2025-11-15 23:00 UTC)