nekevss

The specification reached stage 4 just yesterday. That was the motive behind the blog post :)

I believe V8 / chrome bundles IANA time zones into the zoneinfo64 resource bundle. I'm not actually sure they hit the system tzdb at all.

Yep, temporal_rs is designed with native Rust use in mind, so you should be able to use temporal_rs directly wherever you'd use jiff or chrono.

That being said, the library is designed to be specification conformant and with EcmaScript implementations in mind. There are some specific API choices made specifically for those clients.

That being said, we are always looking for feedback regarding the native Rust API. So feel free to try temporal_rs out and provide whatever feedback you'd like :)

Typically time zone data is updated in IANA's time zone database. That data would need to be updated in the implementation. In this case, the browser would need to update their time zone data.

Super happy to see Temporal accepted!

Congrats to all the champions who worked super hard on this for so long! It's been fun working on temporal_rs for the last couple years :)

The library used for V8's temporal implementation is in Rust too ;)

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, the majority of the difference is from the Unicode data for Intl along with probably the timezone data for Temporal.

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 :)

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.

Thanks! It's always nice to talk and answer questions about the project!

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'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.

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".

No problem! If you have any questions, feel free to open an issue / discussion or reach out to us on Matrix / Discord.

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.

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 :)

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.

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 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 :)

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.

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.

We could do a WASM FFI target. I have thought about it lol

My only concern is that temporal_rs packages it's own time zone data, which may make the WASM package a little heavy, so I've been inclined to leave the polyfill up to fullcalendar's implementation.

Thanks! It's been great to see the library actually picked up and used by other implementations!

Hi all, I'm one of the main developers who's been working on Boa's implementation of Temporal and temporal_rs. Feel free to ask me anything :)

Mentioned elsewhere in this thread, but https://test262.fyi/# is great for keeping up to date with the current engine / interpreter support :)

if only it was as simply a reading int64 epoch values :')

https://test262.fyi/# will give you a bit better update on the progress on implementation in the various engines / interpreters :)