Chrome proposes new APIs: Declarative partial updates
Posted by imbev@reddit | programming | View on Reddit | 105 comments
Posted by imbev@reddit | programming | View on Reddit | 105 comments
jimmytoan@reddit
The 'Chrome ships it, then calls it a standard' pattern has been running since the early Chrome days. Flexbox, native ES modules, service workers, web components - Chrome shipping them effectively made them standards before W3C formally ratified anything. The uncomfortable truth is Chrome's market share means 'Chrome ships' IS de facto standardization regardless of the formal process. The RFC/standards path exists to prevent exactly this but the speed gap between a browser shipping a polyfillable feature and the formal process finishing is now measured in years.
programming-ModTeam@reddit
No content written mostly by an LLM. If you don't want to write it, we don't want to read it.
Goodie__@reddit
Honestly this seems reasonable on first read.
Im still not a fan of Google unilaterally deciding what web standards should be. The RFC process exists for a reason.
niutech@reddit
You don't need another standard with another syntax. It has long been possible in every web browser without JS by using my Pure HTML Out-Of-Order Streaming (PHOOOS) technique based on Declarative Shadow DOM. Try the demo.
Goodie__@reddit
Opens demo
Looks inside
Script JS tags
Not sure what I expected
niutech@reddit
Man, read the comment in that
<script>! This is just an optional tiny Declarative Shadow DOM polyfill for older browsers, it is no longer required in modern browsers! Disable JS in your dev tools and reload the demo.mr_birkenblatt@reddit
How are they doing that here? They have a polyfill so people can use it right away.
Going through the RFC process first would take years before you can even test your idea out in the wild. Better to have an experimental feature and once it finds adoption you can propose it as standard
Goodie__@reddit
Google have used experimental features being in the wild to shoot down any proposed criticisms of a standard in the past. See: WebHID.
You are right at the RFC process take a long time, arguably too long. A single browser unilaterally deciding what the standard is isnt exactly great either.
What's your ssuggestion?
JimDabell@reddit
Fun fact: If Google proposes a feature and literally nobody else in the world agrees to it, as long as Google keeps it in Chrome for two years, MDN will remove the “experimental” marker:
OrphisFlo@reddit
MDN is not a standard body. What is written there is not binding for other vendors nor does it say that they recognize by default any non "experimental" APi.
Schmittfried@reddit
It’s basically the voice of one of three relevant rendering engines. If they recognize another Browser‘s features, it’s recognized by 2/3 of the rendering engines.
OrphisFlo@reddit
It's the same for any browser, if one has implemented anything and a second one implements it, 2/3 will have it.
But Mozilla doesn't get preferential treatment, when they implement anything, it's not gospel for the others. Because then, why wouldn't Chromium's feature be that also?
Also, MDN is always lagging behind the actual specs, it's paraphrasing the real spec. While it's convenient, it's probably more important to be able to follow the spec link at the bottom and understand them, or a lot of nuance and important details may be lost. The web specs are not too bad to read, it's nothing like the C++ standard!
Schmittfried@reddit
Yes, but the statement was that Mozilla recognizes features as standard once they’ve been supported by a different engine for long enough. The fact that they do this implicitly makes those features a de facto standard automatically, because now it’s 2/3 of the relevant rendering engines that recognize it. So your counterpoint about them not being a standard body doesn’t really matter. It’s not about preferential treatment. It’s sufficient that any one of the 3 rendering engines states that they automatically recognize a feature of the other two if it’s around for long enough to always form a majority. It just happens to be Mozilla.
RecognitionOwn4214@reddit
It kinda is an authorative source for developers
OrphisFlo@reddit
It's irrelevant if the topic is proper standardization of APIs. It's a view on some established standard, but it's not necessarily up to date nor authoritative.
Something more relevant would be WPT to check for implementation status in browsers. Web developers are not the target audience, but it's at least closer to reality.
Sigmatics@reddit
It's not just Google
sbrocket@reddit
What kind of criticisms are you're referring to here? "This shouldn't exist" type criticism or "this needs to change because X" type criticism? If you're talking the former...if developers have already picked up your experimental features, isn't that an indication that there is demand for it and it isn't being simply pushed on everyone?
Goodie__@reddit
IIRC when it comes to WebHID, Mozilla have raised various privacy concerns, which is why they haven't implemented it yet, and AFAIK dont have any intention to.
"This exists, and is good, and people use it, but if i were a advertising company it sure would be handy to have ANOTHER way to fingerprint users"
sbrocket@reddit
Does Mozilla propose any solutions at all for the concerns they raise or is this just another case of them opting for "we're not even going to give our users a choice"?
Yes advertisers slurp up any and all fingerprint signals. I don't like it, but I don't think dragging your feet forever on useful APIs is really the right answer to that. Users just go elsewhere and then are even worse off.
aLokilike@reddit
Never thought Illaoi would end up bootlicking for unwanted user tracking.
sbrocket@reddit
No idea what that reference means. People here seem to be more religious than technical if the impulse is to jump to insults upon encountering something you disagree with rather than even attempt to explain your differing point of view. Weird.
aLokilike@reddit
"You cannot refuse all change, THE WORLD IS CHANGE, so you must accept this change" is insanely dogmatic and not something you can argue with. Illaoi is a video game character, she does nothing but smash faces and talk obsessively about how change is good.
OrphisFlo@reddit
Do you really think that Google is using WebHID for tracking?
Most of the usage is going to be on services where you need to be authenticated and should have no strong expectation of privacy. When WebHID is used on Google Meet to control hardware mute buttons on headsets in a call where users are already sending their audio and video, do you think that anyone cares about gathering "another bit"?
Those APIs are usually not exposing anything without a permission prompt anyway, so it's not like they can be used by anyone for tracking. And knowing the extension is present just means that you are Chrome, which you could already gather with a million other checks.
Goodie__@reddit
I mean they weren't given much of a chance to feedback on WebHID.
I believe this commenter from "Back in the day" says it better than I can. https://github.com/mozilla/standards-positions/issues/459#issuecomment-886271967
valarauca14@reddit
Arguably, always has. You can almost chart the history of which webbrowser was "defining" the standard by reading user agent strings
We're lucky the OSS conspiracy against Micro$lop kept IE out of there. Everyone jumped on XHR too quickly despite microsoft being prosecuted for literally having a monopoly on the internet.
quentech@reddit
Your in a programming sub and don't know the difference between a browser, an operating system, and the internet?
valarauca14@reddit
Their monopoly investigation & prosecution was on the grounds of Internet Explorer monopolizing the internet browser market. cite
quentech@reddit
Again - a browser and the internet are not the same thing.
From your own damn link:
franklindstallone@reddit
It's pretending to be open and using a market position to force what you want. That's the problem.
If it gains traction then there can't really be any debate about it because it will be expected to be supported.
The fact one of the biggest companies can push it the web in the way that benefits them is a key reason it will be nearly impossible for anyone other than equally large companies to develop a new browser engine and why everyone just uses Chromium, further adding to their power to do what they want.
It's not that different to what Microsoft tried with IE other than they don't have an existing monopoly on operating systems to use against them.
Schmittfried@reddit
Google search alone is grounds to split the Chrome department. The road operator shouldn’t control the quasi-monopolistic navigation system.
mtutty@reddit
If you can't clearly enumerate the tradeoffs involved in YOLO'ing a new web proposed web standard, you prob shouldn't be advocating for having it.
efvie@reddit
Is the polyfill equally performant and convenient?
If not, this coerces other vendors to implement the feature ASAP.
edgmnt_net@reddit
No, but in a way this ultimately seems like a performance-enhancing feature. If the layout engine can now perform updates smarter and faster in Chrome, maybe there isn't much you can do but use a slow polyfill or reduce the rate of updates on other browsers. Not sure any (ad-hoc/open-coded) alternative can do better.
nemec@reddit
I don't think many people believe the 10000 ft view of the feature is not a positive for browsers. The problem is that no other browser vendor had input into the feature because Google bypassed the standards process. Right now, vendors' options are
Presumably, the polyfills make websites slower than vanilla JS because they can implement API compatibility as middleware but can't actually take advantage of the speed benefits Chrome has - meaning any website owner adopting the feature simultaneously makes Chrome faster and all other browsers slower.
This incentivizes vendors to adopt Google's vision and once there's broad browser support such that a critical mass of website devs rely on the feature, it's much more difficult to make breaking changes to the spec meaning, for the most part, whatever Google ships becomes the feature.
I do think Chrome's devs are trying to make the web a better place here, but they're taking a distinctly IE6 route to get to it.
chucker23n@reddit
Intentionally or not, one of the biggest browser engines implementing a feature while the actual spec isn’t even a working draft standard.
Meanwhile, they encourage web devs to already build on it, which in turn has in the past resulted in devs arguing Gecko and WebKit are “behind”.
There is a standards process. It’s bureaucratic and slow, but that’s ultimately a good thing.
Chii@reddit
That's what makes a defacto standard. By creating an easy path to adoption even if there's no standard, the popularity and ubiquity of chrome can generate a forced standard in due time by simply making it defacto.
This is how google can take control of the web using their numbers, rather than by getting other parties on board.
Chisignal@reddit
If you’re google and you make an “experimental” feature that finds adoption in the wild, it’s no longer an experiment. Even if they deployed it just on their sites, they’re just too big for this not to give a huge advantage to themselves on their platforms over other browsers - but once it gets adopted it’s pretty much over, W3C has to come in and clean up the mess by codifying it, lest we repeat the browser incompatibility wars of yore - and thus Google pushes a feature through single handedly.
OrphisFlo@reddit
RFCs are documents from the IETF and I doubt this is the avenue they will prefer to use to standardize this. Most new APIs nowadays are going to be done under the W3C umbrella and it seems that they have established a WICG group, confirming that.
This is a normal step in the process of standardization, it's possible to have a focused group producing an experimental document (and possibly some shim implementation) and have it later reviewed and adopted by another well established Working Group formally.
Working Groups are quite busy nowadays, so the WICG structure is great to quickly iterate with less formalities on something new and experimental for the initial design stages.
yopla@reddit
On the other hand The RFC process gave us XHTML and a bunch of stuff no one cared about and the spinoff of two differents standard group writing specs for HTML. 😆
ISDuffy@reddit
Firefox have talked about it as well in a video. They is positive feedback from the other browser on this.
spcbeck@reddit
A billion times better than anything Meta has done for standards, frankly.
Lachee@reddit
I hate google just comes up with new standards and now it's up to everyone to catch up. It's IE all over again
imbev@reddit (OP)
This is inspired by prior HATEOS work such as from https://htmx.org/, is being standardized (https://github.com/WICG/declarative-partial-updates), and has polyfills to support all browsers today (https://github.com/GoogleChromeLabs/template-for-polyfill, https://github.com/GoogleChromeLabs/html-setters-polyfill)
niutech@reddit
We don't need another standard. Declarative partial updates have been possible in every web browser without JS by using my Pure HTML Out-Of-Order Streaming (PHOOOS) technique based on Declarative Shadow DOM since 2024. Try the demo.
JimDabell@reddit
Just because it appears on GitHub WICG it doesn’t mean it’s being standardised. It needs the other rendering engines to agree to it. So far, rendering engines have agreed to the first half of functionality described by the article, but not the second. So saying that “this is being standardised” is premature. Half of it is; Google would like the other half to be standardised, but nobody else has agreed to it yet.
Google do not unilaterally decide what is a standard; it requires buy-in from at least one other rendering engine.
OrphisFlo@reddit
It is in the pipeline for standardization. Having an incubator community group is perfect to get feedback and make quick changes to their eventual specification quickly. They can work on it and prepare whatever documents are needed so that it is adopted later by a proper established WG at the W3C, or at least gets enough feedback to reshape it until every vendor is happy with it.
Timing wise, it is also happening months before the TPAC conference where all W3C working groups and some community groups are meeting. They will have feedback from all vendors and domain experts. I don't know what else you think happens for standardizing anything, but this is very normal way to deliver new APIs in an experimental shape.
ISDuffy@reddit
Firefox have also talked about these, this isn't a case like the prompt API, this feature been discussed cross browser.
https://bsky.app/profile/webdevs.firefox.com/post/3meyc55xgrt2f
SanityInAnarchy@reddit
It's fashionable to hate on the Chrome/Blink monopoly, and for good reasons, but...
This is the opposite of what IE was like, for almost everything.
The problem with IE wasn't so much that it was adding new standards -- that happened, that's where we got XHR, but it was pretty rare. The much more common problem was they mangled what standards they did implement, and never bothered to implement most new standards that every other browser was doing fine with.
Supporting IE6 meant giving up a ton of features, or trying to hack them together with a ton of extra work with polyfills, or giving up and rebuilding half the site in Flash. It meant going back ten years in web dev. It's probably why the Web does so much transpilation now, even now that modern browsers have a decent version of JS, because we all got in the habit of transpiling to support es5 or older just so things would work in IE.
The modern equivalent of that is Safari. Especially mobile Safari, since no other engines are allowed on iOS. (Every iOS browser is only allowed to be a reskin of Safari, you can't have a real Firefox on iOS.) Google will come up with a new standard, but Mozilla will implement it, everyone will update, and every browser on the planet except Mobile Safari will support it.
sbrocket@reddit
The crucible is whether web developers actually use it, not whether Google proposes it. And if developers opt into using said experimental feature, isn't that an indication that there is demand for it and it isn't being simply pushed on everyone?
It sounds way pushier to try and deny developers features that they opted into using or want to opt into using because of personal philosophical objections, if that's the kind of criticism we're talking. See: Firefox and WebSerial (which has *finally* shifted), WebBluetooth, etc.
mr_birkenblatt@reddit
It comes with a polyfill. And what's better for proposing a feature than coming up with an implementation so people can see what you're talking about?
sohang-3112@reddit
This looks quite interesting, reduces need for libraries like HTMX (though it's still needed for a cross-browser experience).
Another interesting new Chrome api allows us to use normal html elements inside a
<canvas>element when required!! https://developer.chrome.com/blog/html-in-canvas-origin-trialForgetTheRuralJuror@reddit
Wow I can't wait to do something terrible with that
OutrageousTomato572@reddit
You meant to say terrific, right? RIGHT?
hyrumwhite@reddit
in the follow up section:
Yes please!
astonished_lasagna@reddit
So they bring native APIs for HTMX?
OutrageousTomato572@reddit
Is web dev ecosystem going to finally mature this time?
AndrewNeo@reddit
we're so back
kn4rf@reddit
At what point do we stop stuffing more stuff into the web spec and just let there be some stuff that is handled by frameworks like React/Vue/Svelte. Not everything is needed to be a browser feature, sometimes less is more.
Efficient-Chair6250@reddit
Wtf, that's not even XML anymore?!
jhartikainen@reddit
I remember in the mid 2000s or so when the XHTML "fad" was at its greatest there were actually sites built with clientside XML and XSLT to transform it into HTML. It was an interesting technique.
Seems like that would allow this (and more) so it makes me wonder if those technologies have been completely forgotten, or if they're somehow unsuitable.
LoveThatCardboard@reddit
This was actually super handy for me circa ~2006.
The original incarnation of WoW armory, which is Blizzard's site that lets you see stats on any character in the game, served a very clean XML document with character gear and stats and then turned it into a web page with a linked XSLT.
Made it super easy to create an IRC bot that would pull down people's characters and keep an automatic log of who got what got what gear from raid.
jhartikainen@reddit
Ooh yeah that was exactly the website I was thinking of :) Forgot what it was called but that jogged my memory
piesou@reddit
XSLT is still used, it's a great tool to deal with XML, but with regards to the web, it's not used directly anymore. However loads of frameworks use similar constructs (angular, svelte, Vue), like using tags for ifs or for loops
rsclient@reddit
From my experience: XSLT is the concept of a good idea, wrapped up in the most unforgiving, unintuitive tooling whose primary error message is silently not working.
Which means that when updating XSLT, you have to add things slowly so there's only ever one bug to fix at a time :-)
kniy@reddit
It's a processing instruction: https://en.wikipedia.org/wiki/Processing_Instruction
The fun bit about XML is that it's so complex a standard, everyone uses a different subset!
rsclient@reddit
The XML people loved XML so much that there's a bunch of it that isn't the "classic" XML with that get closed. Instead there's bonkers things with <? random crap> that requires a different mini-parser.
evincarofautumn@reddit
Yeah, just SGML style, not XML
Lachee@reddit
Sounds like yaml
vladexa@reddit
or markdown
nemec@reddit
or SGML
_ConsciousLibrary_@reddit
Markdown is more different implementations bolting on their own additional features than the standard spec being bloated with different implementations using their own subset.
Or in short. Superset vs subset.
Efficient-Chair6250@reddit
God fuck this chungus life 😭
ForgetTheRuralJuror@reddit
Efficient-Chair6250@reddit
Yeah, but at least exists. And I unclosed elements are only supported as a best-effort attempt to render anything
evincarofautumn@reddit
Unclosed elements were inherited from SGML, before the quirks got to them
In SGML they’re user-defined and opt-in, so you have to both declare the tag as optional in the schema and enable omitted tags in the document, and you can only omit an opening or closing tag where it’s actually unambiguous
SGML is huge and complicated as a whole, but it has a lot of nice parts, like
<em/null end tags/for inline markup and<short-tags>…for omitting the ending tag name from block elementsYoghurtFlan@reddit
Bastardised PHP. We're coming full circle.
nemec@reddit
Fun fact, this syntax apparently predates PHP by almost a decade
https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub152.pdf (see pg 30)
RecognitionOwn4214@reddit
Xhtml was a failed experiment - and html isn't xml ...
moh_kohn@reddit
I like the declarative templates. I hate the example. I am so so tired of loading spinners for stuff that should be loaded with the page. It's an embarrassment that the profession considers the current situation of nested spinners, spinners in panels and so on to be acceptable.
Nice API though.
okandship@reddit
the idea looks useful, but the process matters almost as much as the api. experimental browser features need a real path for other engines to shape them before usage becomes the argument.
programming-ModTeam@reddit
No content written mostly by an LLM. If you don't want to write it, we don't want to read it.
3131961357@reddit
Back in my day, we called them frames
ManySugar5156@reddit
Kinda like htmx but built into the browser, so that’s neat, but also i hate the “Google decides” vibe again.
rsclient@reddit
May I rant a bit? The paper says this:
This is completely the wrong end of the stick, and for two reasons.
Firstly, the reason the web is slow is entirely a problem with ads being slow. Make ads faster, and the web is faster. My personal favorite way to fix this would be to add a tax on all web ads, with a (much) high tax for ads requiring intrusive information.
Secondly, web performance is engineered with requirements set from above, not something that just naturally happens. A web designer will get a specs for the performance for certain network types, hopefully with P90 or P99 requirements. Either that, or the old website is deemed "fast enough" and new code just has to match the performance.
In all cases, the web designed is tasked with working on their code until it's fast enough, and then they stop. This means that any API to "make the web faster" really means "the web will be exactly as fast, only now you can put in more ads".
And third of my two rants: the slowest part of the web is now the slow AI responses, the slow-to-click-on popups for cookies, and the hides-the-page begging pages to subscribe and allow alerts. Nothing the Google paper helps with any of these.
TheRealAfinda@reddit
So from looking at the semo source, on the server side this looks like a lot like SSE to me since content is being written to the response body stream 'as it's available'.
From the Demo i can't really fathom how this could be applied right away without refactoring how responses are handled as a whole. Maybe i'm missing something?
hyrumwhite@reddit
A streaming html response could load up a table shell, which would be rendered immediately, then with the stream still open, hit the db and write a target template with rows from the db.
For the user, they see the page with the table shell, and loading state, and then the table is populated, all with the browser loading chrome.
Previously the only way to achieve this would be either hanging the stream at the table while the rows are loaded, or a document call for the shell and then a subsequent JS call for the data
TheRealAfinda@reddit
Yeah, this i get. Now looking at the Demo you'd have to do some serious refactoring for the Backend to have this available over multiple Projects.
Either some sort of Middleware approach or an entire Framework that understands these concepts as well.
It's nice the Browser knows how to parse and handle this but the Server needs to know how to Serve this aswell.
RegisteredJustToSay@reddit
If I was designing a standard for making XSS easier this is how it would look. I get the purpose and usefulness but I'm sure we just got some new attack primitives too.
Lucidendinq@reddit
Back when I didn’t know much about JavaScript and saw dynamic text appearing on a page, I thought it worked like this—DOM getting manipulated as the document loaded.
Very interesting. Hoping this develops into a standard and more browsers add support for it.
sojuz151@reddit
A really clear explanation and a demo that shows why would we even need this. Anything that can be used to replace Javascript is a win for me
aatd86@reddit
I am finishing writing a framework and it can't replace things as-is. It addresses only one part of a whole partial rendering feature that we implemented. There are also some questions that are left without answers. I will submit a report.
bzbub2@reddit
you can see analogies to other systems here https://github.com/WICG/declarative-partial-updates
MyraFragrans@reddit
I like it, I imagine it will improve time-to-first-byte for pages with server-processed data. The proposed syntax looks straight-forward, too, and easily implemented server-side. Can't wait to play around with this!
wvenable@reddit
Google just straight up adds processing instructions to HTML. I think the comments here are downplaying the significance of this. It's a whole new other layer to the document processing with a new type of syntax.
I'm not sure I'm a fan of a whole new markup just for this. Especially when it ends up with something like <?start> and <?end> which are both terribly named and an ugly type of construct in an HTML document.
mfitzp@reddit
Yeah, the naming really is dreadful. It mentions that ‘<?’ Is a standard XML syntax for “processing instructions”, but then goes ahead and uses the most generic vague name for the “instruction”. It’s like if the paragraph tag had been called
Even_Scheme_3080@reddit
so Chrome is basically proposing we do less JavaScript to update the DOM — and somehow this is controversial
mccoyn@reddit
Yes, and you can even use this today thanks to a JavaScript library!
Superb_Garlic@reddit
"so Chrome is basically doing a little bit of monopoly — and somehow this is controversial"
Yes actually.
iamapizza@reddit
It's one of the few times I've read through a proposal and was happy to see it isn't another js hack. The examples were straightforward and easy to understand.
I'm even seeing client side includes in the future considerations section. It might finally be happening... dare I hope that will happen within my lifetime.
tom-smykowski-dev@reddit
We have already frameworks that handle it. It makes no sense to change HTML definition only so that Google can scrape web cheaper to reproduce on their platform
HalfSarcastic@reddit
For Google it does.
Clearly they propose the change for the sake of reducing JS usage on the websites as it will help to parse the content without spending too much resources on JS interpretation.
tom-smykowski-dev@reddit
yes. It could have been useful when Google was a search engine and drove ppl to websites for exchange for being able to put ads next to search results. Now when Google steals content and visitors there's no reason for anyone to accommodate to Google frivolous ideas
Dminik@reddit
I wonder if is good enough to replace the streamed script tag many frontend frameworks use. I'm a bit doubtful as they usually send request data (or serialized RSC trees in react) rather than HTML fragments.
The new set of HTML updates also miss some form of updateHTML to do diffed changes (elements, attributes/properties, text) without replacing state (like cursor position).
These new APIs don't hurt, but I also don't see them being used very often.
CondiMesmer@reddit
Sounds like React components in HTML form. I mean that in a good way, so this sounds cool. I'm down for more proposed changes that aren't anti-competitive, anti-consumer, or surveillance like this.
lactranandev@reddit
Just because it works (on frameworks) doesn't mean we can't make it better. And Google just prove that.