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.
It's true the down-levelled code that uses WeakMaps is slower. The decision to downlevel is in the hands of the user and is controlled by the tsconfig "target" option.
The only environment that needs downlevelled #private fields is IE11.
Which value are you setting for target? I tried es2021, and it still doesn't give me native #. I cannot use esnext, because other stuff doesn't compile anymore.
This is interesting. The things you list as problems are the same set of things we tried to solve:
- automatic compilation that is fast
- sourcemaps work
- decoupling of packages to help compatibility
- automatic tsconfig management
I wonder if you would have a different conclusion with these things taken care of.
I agree that TypeScript makes it easier to have functions with complex parameters - because they are now documented and more understandable. So yes, this demands more discipline on the API designer to keep APIs simple.
For our purposes, the primary problem with enums is not the runtime overhead. The runtime code for TS enums is a little verbose but it's not huge. The semantics are a little wacky as described in Axel Rauschmeyer's article: https://2ality.com/2020/01/typescript-enums.html
The primary problem is the potential conflict with future ECMAScript. Multiple TypeScript team members have talked about how this feature is now regretted. The article features Orta's famous meme-slide communicating why runtime features (specifically calling enum) should not really be in the TypeScript language. Anders talked about it three weeks ago during the Q&A session at TSConf: https://www.youtube.com/watch?v=vBJF0cJ_3G0
enum is highly unlikely to be removed from TypeScript because of the strong commitment to backwards compatibility. But that doesn't mean we should encourage proliferation. Especially when many use-cases can be served more simply by string unions.
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.