I don't know if that's totally fair to Chrome. The specification was undergoing a lot of changes at the time, and V8 decided to wait for the specification to stabilize; meanwhile, Anba kept working on the implementation for FireFox. Additionally, the version of Temporal that Deno exposed last year was the heavily out of date to the most recent specification and had a large portion of the specification that was not even implemented.
For the engine, the answer is yes, Intl and Temporal are feature flagged due to the dependencies. What I suspect they’re comparing above is the CLIs, which is completely different than the engine. I’d have to double check for the CLI. If I recall correctly, we include all features in the CLI by default.
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 :)
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`.
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.
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".
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.
reply