Congrats to the Boa team! It's great to see an independent open source project thrive and become more widely useful. This is huge impact.
On the integration with Kiesel and Chrome, I'm pleased to see that engines/browsers can share the cost of developing new language features.
Temporal is massive! Almost as big as the delta of introducing ES6. There are 4,000+ tests. The functionality does not need to be engine-specific, so it makes sense to leverage reuse.
I believe this is the first introduction of Rust into V8 itself. Which seems like a happy side-effect that hopefully makes it easier to share more Rust libraries in future. This helps keep browser development sustainable.
I attempted to implement the Temporal spec myself and it really isn't fun. After the tc39 meeting in May, I also switched to `temporal_rs` for `yavashark`. My own implementation ways everything else than optimal, I didn't support the RFC9557 timeformat.
In theory you could even use temporal_rs to provide an perfect polyfil with wasm.
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.
Diplomat has a wasm backend so it would even be really easy to produce a WASM ffi target with idiomatic JS and TS bindings.
Also, Diplomat supports traits and callbacks so you could actually make the timezone impl pluggable. Though we don't currently have JS support for that.
This is a big milestone to getting Temporal shipped in Chrome (unflagged), which will have huge positive on JS developers around the world. Thank you all for your hard work to get this built and over the finish line.
Congrats to the Boa team! It's great to see an independent open source project thrive and become more widely useful. This is huge impact.
On the integration with Kiesel and Chrome, I'm pleased to see that engines/browsers can share the cost of developing new language features. Temporal is massive! Almost as big as the delta of introducing ES6. There are 4,000+ tests. The functionality does not need to be engine-specific, so it makes sense to leverage reuse.
I believe this is the first introduction of Rust into V8 itself. Which seems like a happy side-effect that hopefully makes it easier to share more Rust libraries in future. This helps keep browser development sustainable.
I attempted to implement the Temporal spec myself and it really isn't fun. After the tc39 meeting in May, I also switched to `temporal_rs` for `yavashark`. My own implementation ways everything else than optimal, I didn't support the RFC9557 timeformat. In theory you could even use temporal_rs to provide an perfect polyfil with wasm.
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.
Diplomat has a wasm backend so it would even be really easy to produce a WASM ffi target with idiomatic JS and TS bindings.
Also, Diplomat supports traits and callbacks so you could actually make the timezone impl pluggable. Though we don't currently have JS support for that.
But also tz info isn't that big I think...
Thanks! It's been great to see the library actually picked up and used by other implementations!
This is a big milestone to getting Temporal shipped in Chrome (unflagged), which will have huge positive on JS developers around the world. Thank you all for your hard work to get this built and over the finish line.