Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

API proposed by Chrome: Declarative partial updates

developer.chrome.com

Post reply on HN
Print view View original

11–20 of 48 posts

Re: API proposed by Chrome: Declarative partial updates

#11

Post by kkarpkkarp »

dfabulich wrote: post #7
nofriend wrote: post #3

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…

The new element syntax is needed to signify DOM ranges that may cross the boundaries of HTML element trees. Some text to replace . Jake Archibald at Mozilla has a good video about this. https://www.youtube.com/shorts/yARSOcqOWvY

I am puzzled then: so what would happen if the template will replace this island form your example with markup without closing ``?

Re: API proposed by Chrome: Declarative partial updates

#12

Post by dfabulich »

ComputerGuru wrote: post #4

Is this a Google-only proposal? Has Mozilla provided their thoughts on the matter?

When you have questions like this, the best places to check are the "standards positions" Github repositories for Mozilla and WebKit.

https://github.com/mozilla/standards-positions/issues/1369

Mozilla hasn't officially weighed in, but one decision maker (hsivonen) did vote in favor of it.

Apple WebKit is officially in favor of it, as of just a few days ago.

https://github.com/WebKit/standards-positions/issues/628

Re: API proposed by Chrome: Declarative partial updates

#13

Post by trueno »

fg137 wrote: post #6

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?

From what I read, think HTMX. HTML streams top to bottom so this proposal means out of order streaming of html things. So handles a lot of delivery/rendering stuff that's frontloaded with react/js/etc. It doesn't touch state management though.

Don't use chrome anymore but, I dunno if all browsers came to the table and unified behind something like this I'd be all about it. Most of the web stacks seem like some weird polished turd solution where we started frontloading more and more onto javascript, so I am amusingly not against this proposal. Feel like it could be a step into a better direction for web technologies, which feel like a very odd/lost ship in the world of software.

Re: API proposed by Chrome: Declarative partial updates

#14

Post by dfabulich »

kkarpkkarp wrote: post #11
dfabulich wrote: post #7

Earlier quoted context omitted.

The new element syntax is needed to signify DOM ranges that may cross the boundaries of HTML element trees. Some text to replace . Jake Archibald at Mozilla has a good video about this. https://www.youtube.com/shorts/yARSOcqOWvY

I am puzzled then: so what would happen if the template will replace this island form your example with markup without closing ` `?

  

    Some replaced text
Which, by the HTML standard, will automatically close the `` as the `

` closes.

Re: API proposed by Chrome: Declarative partial updates

#15

Post by 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:
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

Re: API proposed by Chrome: Declarative partial updates

#16

Post by [deleted] »

kkarpkkarp wrote: post #8
nofriend wrote: post #3

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…

> The new element syntax is perhaps the boldest choice Probably to not break anything in older browsers which hasn't adopted it yet: new tag will be simply ignored, that's my thinking > 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" It is behind the flag, like every other new proposal they made.…

[deleted]

Re: API proposed by Chrome: Declarative partial updates

#17

Post by JimDabell »

dfabulich wrote: post #12
ComputerGuru wrote: post #4

Is this a Google-only proposal? Has Mozilla provided their thoughts on the matter?

When you have questions like this, the best places to check are the "standards positions" Github repositories for Mozilla and WebKit. https://github.com/mozilla/standards-positions/issues/1369 Mozilla hasn't officially weighed in, but one decision maker (hsivonen) did vote in favor of it. Apple WebKit is officially in favor of it, as of just a few days ago. https://github.com/WebKit/standards-positions/issues/628

As far as I can see out-of-order streaming is only half the described functionality – there is also HTML streaming & revamped DOM parsing which does not have the positive signals that out-of-order streaming does:

https://github.com/mozilla/standards-positions/issues/1370

https://github.com/WebKit/standards-positions/issues/629

Re: API proposed by Chrome: Declarative partial updates

#18

Post by khana »

BigJono wrote: post #9

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…

[dead]

Re: API proposed by Chrome: Declarative partial updates

#19

Post by [deleted] »

kkarpkkarp wrote: post #8
nofriend wrote: post #3

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…

> The new element syntax is perhaps the boldest choice Probably to not break anything in older browsers which hasn't adopted it yet: new tag will be simply ignored, that's my thinking > 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" It is behind the flag, like every other new proposal they made.…

[deleted]

Re: API proposed by Chrome: Declarative partial updates

#20

Post by lenkite »

fg137 wrote: post #6

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?

> How is this better than existing solutions?

For one - will not need to write JS or bundle a JS library to do this if it has native platform support.

Post reply on HN