It stings a little, as a long time Svelte developer that still feels a sense of loss after Svelte 5’s departure from Svelte 3/4’s simplicity — a departure pioneered by Dominic.
> We've explored the reactivity landscape. While early DOM templating proposals didn't include updating, userland systems have thoroughly explored the landscape by now, and discovered good mental models and better and worse implementation approaches. I think we can now zero-in on a system that combines the best features from the different approaches.
AFAIK Ryan Carniato/Solid JS is still exploring what’s possible with signals. I don’t think userland exploration of this space has entirely finished, and further innovation may be possible.
There is a lot of interesting research outside of the webdev bubble in the incremental computation problem space, and self-adjusting computations (signals) aren't even that interesting.
> If the Records and Tuples proposal were progressing, JSX could maybe create Records with boxes, but that proposal has been stalled, especially on the record identity and box parts that would make it suitable for a JSX semantics.
> There are in-flight proposals for very low-level DOM update primitives, like DOM Parts, which target framework implementations, but I think higher-level APIs like full declarative templating can take even more load off, help prove out and complete the lower-level API proposals, and be really impactful for developers and users.
Chrome implemented a prototype, then the spec changed and they removed it, then they implemented the new version. I should have been clearer and said Chrome Canary and Firefox Nightly. Not sure when it will reach stable but probably some point this year, they’ve been working on it for ages and Safari is onboard.
There is still innovation happening in frameworks. I do wonder if it is too early to start adding things like this to the browser. Web components landed way too early and now we’re stuck with them.
I think it makes sense for companies to start with decode though. That hits pretty much 100% of users--everyone watches video.
But only a small fraction of users actually create content and need accelerated encode. And Apple especially I think is unlikely to use AV1 for their video recording, given their investment in other formats for that use-case.
> And Apple especially I think is unlikely to use AV1 for their video recording, given their investment in other formats for that use-case.
I concur. The raison d'être for AV1 is (lack of) patent license royalties. These apply to user devices as well as services. Think Google: Android as well as YouTube cost fortunes in AVC/HEVC licenses, so here AV1 makes sense.
On the other hand, Apple sells expensive hardware and has no problem ponying those licenses. Soon after adopting HEVC they doubled down with Dolby Vision which technically adds very little on top of standard HDR features already available in HEVC and AVC but present serious interop problems for device come with shiny Dolby stickers.
Plus unless you are streaming or producing a ton of video most users can afford to wait a bit for software encoding (which is often better quality as well). So encoding is far less important than decoding.
As far as I can tell, Apple has always only supported decoding for non-MPEG codecs.
And their encoders (at least on macOS in the past) usually don’t yield results comparable to software or dedicated quality-optimized encoding ASICs, so if I wanted high quality at low bitrates I’d have to reencode offline anyway.
It would be nice to have it available for video conferencing or game streaming, though.
