API proposed by Chrome: Declarative partial updates
theanonymousone
26 points
14 comments
May 24, 2026
Related Discussions
Found 5 related stories in 90.8ms across 8,303 title embeddings via pgvector HNSW
- Chrome looks set to ship an LLM Prompt API to the web. We oppose this API Vinnl · 23 pts · April 30, 2026 · 53% similar
- The Prompt API gslin · 59 pts · April 27, 2026 · 50% similar
- Mozilla's opposition to Chrome's Prompt API jaffathecake · 607 pts · April 30, 2026 · 50% similar
- Under the hood of MDN's new front end soheilpro · 14 pts · April 08, 2026 · 47% similar
- WebMCP is available for early preview andsoitis · 233 pts · March 01, 2026 · 47% similar
Discussion Highlights (5 comments)
nofriend
Very odd proposal. The new element syntax is perhaps the boldest choice. I wonder why they thought that was necessary. The idea of using this to defer rendering elements is also odd. So this would use a http long polling style? It really goes against several decades of progress in the web platform, where by now it's long established that you do this sort of thing with xhr. I'm amazed that they even put this in chrome, let along are saying things like "let sites use this new functionality right away even before this lands in other browsers" as if it's a sure thing.
ComputerGuru
Is this a Google-only proposal? Has Mozilla provided their thoughts on the matter?
fg137
I scanned the page but didn't get -- why? What problem does it solve? Why is a browser in the business of taking care of content update? How is this better than existing solutions?
BigJono
Wtf? I can't really tell how you'd even use this. Is it supposed to be some sort of micro-optimisation thing to do with how HTML is parsed (now you can download chunks out of order, presumably with some performance gains since it's browser native?). When I saw the title I was hoping it was going to be a very simple React-like API for constantly updating parts of the DOM with maximum performance since the browser devs are now involved. It doesn't look like that's what this is at all. And all these years later I'm still wondering why browsers aren't implementing an API like that when it's been obvious for over a decade now that real-time DOM updates are a vital browser feature that needs to be performant, and that developers vastly prefer a declarative model to a procedural one. Why after 15-16 years are we still building 100 versions of the same abstraction in user-land to turn Element.append into "refresh these elements when this data changes"?
dfabulich
Declarative partial updating "sets the stage for client-side includes." https://github.com/WICG/declarative-partial-updates The linked article suggests a potential syntax: <template for="footer" patchsrc="/partials/footer.html"> That would transclude the content of /partials/footer.html in your HTML. But the road ahead for this is still quite bumpy. Here's a good video from a year ago, talking through the obstacles. https://www.youtube.com/watch?v=t0NBcve0enY