llcooliovice

Chrome are prototyping a declarative client-side include mechanism.

<template src="/partial.html" for=""></template>

Together with the declarative API, it will also include a way to import HTML in JavaScript:

import fragment from "/partial.html" with { type: "fragment" }

HTML primitives for updating parts of a document without a full page refresh

Interop is such a good idea, I’m surprised more developers don’t participate.

From Dominic Gannaway, the creator of Inferno, who worked on React at Meta and on Svelte 5 at Vercel. Feels like a hybrid of React and Svelte 3/4.

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

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

That proposal hasn’t just stalled, it’s been withdrawn. https://github.com/tc39/proposal-record-tuple/issues/394

It has been replaced by https://github.com/tc39/proposal-composites

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

There is an alternative suggestion to DOM parts which might be a better bet: https://github.com/whatwg/dom/issues/736

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's no fundamental templating knowledge that's portable between stacks, and native DOM creation APIs like innerHTML are unsafe by default.

setHTML() is already implemented in Chrome/Edge and Firefox so this point is a bit outdated - there is a safe alternative to innerHTML.

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.

A better non-modal dialog using the popover API.

Now supported by the Apple M3 chips.

With the modernisation of Microsoft Outlook, if will finally be possible to code an email in a semi-modern way.