Will Temporal API be supported?

[nabetti1720]

Are there plans to support the Temporal API in the future?

https://tc39.es/proposal-temporal/docs/
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal

We're not in a rush, we're just happy to see if there's any willingness to support it as an engine.
If you are not willing to do so, feel free to close this issue as not-planned. :)

Thank you for taking the time to help us.

[saghul]

Not sure how @bnoordhuis feels, but my 2 cents: it's a huge spec. according to the Ladybird browser folks it took more code to implement that feature than the entire JS engine they have. So that makes me lean towards a "no" for the time being.

[chqrlie]

From the Mozilla help page:

Temporal has an intricate and powerful API. It exposes over 200 utility methods via several classes, so it could appear very complex.

Not necessariky complex, although dealing with time and dates is indeed intricate, but certainly large and possibly bloated. I shall look into it but I have a feeling it does not belong in the core engine, and an optional javascript implementation would be sufficient for applications that need it.

[bnoordhuis]

As another example of how sprawling Temporal is: V8 didn't roll their own implementation, they use temporal_rs which is written in another language altogether! (Rust vs. C++.)

And note how temporal_rs in turn sits on top of ICU, which is a massive dependency. The most stripped down version of ICU is still 4.5x bigger than the entirety of quickjs.

On the positive side, temporal_rs maps pretty straightforwardly to the JS Temporal API, so for anyone wanting to expose it in their runtime, it should be manageable to write bindings. We could maybe provide official bindings. Maybe.

[nabetti1720]

I'm slightly involved in the development of LLRT, a JS runtime based on quickjs-ng/rquickjs. I wanted to get a hint as to which layer LLRT should implement the Temporal API if it were to be implemented, and also to know that if quickjs-ng (hypothetically) announces that it will implement it, we can all look forward to it, so I decided to confirm their intentions as the engine.

There are several temporal-polyfill implementations, but unfortunately they all use Intl internally and therefore do not work on runtimes that do not implement Intl.

Yes, I also just found out about temporal_rs the other day, and I think using it would be the quickest way.

Thank you to all the experts for taking the time to share your valuable opinions. :)

[nekevss]

Awkward late comment on a closed issue.

I'm one of the temporal_rs maintainers. I'd agree that the API is very large. The temporal implementation in Boa will probably remain feature flagged, but turned on by default when everything is said and done, but it is technically an engine specification addition, not a runtime addition.

A couple things I had wanted to ask / mention.

Was the ICU reference ICU4C or ICU4X? I ask because we rely on the later, which is meant to be smaller and more modular than ICU4C.

Second, if you are interested but still want the ICU4X dependency removed, we MAY be able to. The ISO calendar is implemented directly in temporal_rs itself. The reason was to eventually feature flag the icu_calendar dep, but it hasn't been because there was no pressing need to yet. A potential blocker would be some of the recent resolve fields logic we are migrating more into icu_calendar rather than have it in temporal_rs. Although, that might actually make it easier. Feel free to open an issue for it though if you end up wanting it. Although, I don't think the calendar data in icu_calendar is that large an add.

Third, we have C bindings too 😄 Those are used mostly by Kiesel.

Finally, as someone who's spent a lot of time implementing the API. If you all do end up wanting to implement it, I highly recommend vendoring it out. Yes, there's the whole awkward "use my library" recommendation thing. But also this API is a really large feature to add from scratch. There's a reason we yanked it out of Boa and put it into it's own library to begin with.

[nabetti1720]

It seems we closed this issue a little too early, and once again we leave it to the quickjs-ng team to decide how to address this issue.

[Manishearth]

And note how temporal_rs in turn sits on top of ICU, which is a massive dependency. The most stripped down version of ICU is still 4.5x bigger than the entirety of quickjs.

I'm curious as to where the numbers come from here.

Note that ICU4X and ICU (ICU4C) are different. ICU4X is able to produce meaningful builds in the range of tens of kilobytes depending on the task you plan to do.

ICU4X is explicitly intended to be something that is very modular and sliceable (in ways ICU4C is not), with embedded systems as one of the goals (it's used on the "little" Cortex chip on some versions of the Pixel Watch!). Some of that is constrained by how you use it: if you care about binary size you may need to make some tweaks to the precise sets of APIs temporal_rs uses, though my guess is that won't be a problem, especially after ICU4X 2.1 when none of the calendar code will need any data loading.

And yeah, as @nekevss says, temporal_rs probably could make the ICU4X dep optional if you don't care about non-Gregorian stuff. It would involve some work, but not too much.

potential blocker would be some of the recent resolve fields logic we are migrating more into icu_calendar rather than have it in temporal_rs. Although, that might actually make it easier. Feel free to open an issue for it though if you end up wanting it. Although, I don't think the calendar data in icu_calendar is that large an add.

@nekevss FWIW my attempt at moving temporal_rs to the resolve fields logic retains the ISO-specific code in temporal_rs, since that's needed for spec compliance. The ISO calendar behaves differently from the Gregorian calendar in the spec, and ICU4X's resolve fields logic doesn't really have any special handling for that difference.

[nekevss]

FWIW my attempt at moving temporal_rs to the resolve fields logic retains the ISO-specific code in temporal_rs, since that's needed for spec compliance. The ISO calendar behaves differently from the Gregorian calendar in the spec, and ICU4X's resolve fields logic doesn't really have any special handling for that difference.

Ooooh lol I misread that earlier when I gave it an initial glance. Then yeah, it's definitely doable if someone wanted it feature flagged.

[bnoordhuis]

Was the ICU reference ICU4C or ICU4X?

The former. I didn't know you could strip down the latter so much.

If we were to use temporal_rs, it would be behind an opt-in, off-by-default flag. quickjs-ng should still default to being a single file you can drop in your own project, no futzing with dependencies.

I don't plan to work on it myself but happy to review pull requests.

[Manishearth]

That makes sense! Happy to provide advice to whoever starts this endeavor, temporal_rs and ICU4X both have official C and C++ bindings and you can mostly just wrap around that, but there are a fair number of spec nuances that came up when implementing it for V8.