I agree on the point of first-party, as I already wrote.
I suspect there would be a lot of edge case footguns in trying to write something like patch() that tries to crawl the content as a diff and make only the minimal changes. Things like events being bound incorrectly to elements, what to do when the structures of the old and new don't match in some breaking way, etc.
Not saying it can't be done but I suspect it's more complexity than we think of typically when using a term like patch. Some of those items (such as transitions) can be pretty straightforward to deal with already.
> Also, there's the matter of performance. Diffing and patching as a single method call implemented natively should be a lot faster than using a bunch of JS code.
Performance and the DOM (especially as typically deployed in an SPA / the "modern" web) don't really go together already, so I'm not convinced that's a particularly compelling argument. Making it first-party on its own is already that compelling argument IMO.
I suspect there would be a lot of edge case footguns in trying to write something like patch() that tries to crawl the content as a diff and make only the minimal changes. Things like events being bound incorrectly to elements, what to do when the structures of the old and new don't match in some breaking way, etc.
Not saying it can't be done but I suspect it's more complexity than we think of typically when using a term like patch. Some of those items (such as transitions) can be pretty straightforward to deal with already.
> Also, there's the matter of performance. Diffing and patching as a single method call implemented natively should be a lot faster than using a bunch of JS code.
Performance and the DOM (especially as typically deployed in an SPA / the "modern" web) don't really go together already, so I'm not convinced that's a particularly compelling argument. Making it first-party on its own is already that compelling argument IMO.