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

Hydration is pure overhead

builder.io

Post reply on HN
Print view View original

71–80 of 84 posts

Re: Hydration is pure overhead

#71

Post by steve8708 »

CreepGin wrote: post #46

While we are on the topic of browser event handlers and "embracing how browser actually work", I can't help but mention that the builder.io website's top navbar cannot handle ctrl + clicking (for opening links in a new tab). It's actually quite subtle. Sometimes it works, sometimes it doesn't, depending on which page you are on, what you've already clicked, etc. All part of the fun of frontend web development, ain't…

Oops, thanks for catching. I implemented the client side routing there from scratch with partytown and must have forgot a check to make sure the ctrl/cmd/shift keys aren’t down when canceling the event for a client side routes. Will get that fixed this week

Re: Hydration is pure overhead

#72

Post by steve8708 »

wonnage wrote: post #40

This article complains that downloading stuff is slow and then goes on to propose a solution where you have to wait for stuff to download before firing a scroll handler.

Totally fair. The intended argument is that downloading (and parsing and executing) an entire page just for one button click to load is slow.

But if you can hydrate granularity, and prefetch smartly (based on visibility, analytics, etc) things speed up a lot.

If done right, there is no delay on interaction, and a lot less time and resources required to load a page, increasing lighthouse scores and TI specifically

Thats what we’ve seen in the field too, the FAQs in the article link to some real world examples. Tho I can’t say our prefetching is as smart yet in practice as we want, so sometimes there is a delay on very first interaction. There is a straightforward way to improve this tho that we are working on

Re: Hydration is pure overhead

#73

Post by scotty79 »

mst wrote: post #65
wwweston wrote: post #38

Earlier quoted context omitted.

> is the creator of Angular. Welp, that's reason enough for me to ignore him entirely. Especially on the topic of "overhead." Angular was an inexcusable atrocity.

The original Angular was, for its time, absolutely fantastic. The state of the art has absolutely moved on but provided you were willing to understand its model (just like these days you need to understand React's model) it provided a power to performance ratio that nothing else in its class was capable of at the time.

No. It was not. It was jumbled mess of ad-hoc solutions. Many of the concepts that were core stuff of angular are completely forgotten now. It discovered nothing of value. I worked in a project that used it for almost a year. And none of what I learned about AngularJS was useful since then. Except from general notion of "avoid angular" and "treat frameworks that cram stuff into html with suspicion".

Re: Hydration is pure overhead

#74

Post by scotty79 »

It seems like just trading pre-loading for lag on first interaction and trading bundling stuff int as few requests as possible for many smaller requests with their respective headers.

I mean it's fine to have choice about this trade-offs but you can do it right now just by splitting your application into parts and hydrating only the part the user interacts with. Which gives you additional flexibility of automatically hydrating the part the user is most likely to use and hydrating others in the background in the periods of user inactivity.

Also this article focuses very much on event handlers, but main part of hydration is creation of dynamic structures that allow the application to re-render dynamically and efficiently, sometimes swapping out large parts of page contents that are not delivered with initial pre-rendered HTML.

If you really wanted to improve the situation one could work on introducing partial hydration on demand into React and work on ways to serialize most of internal structures of React apps like virtual dom, so they can be passed along with the pre-rendered HTML to make the remaining requests lighter.

Creating new framework is way less impactful.

Re: Hydration is pure overhead

#75

Post by hatenberg »

wwweston wrote: post #38
yboris wrote: post #7

For reference, Miško Hevery, the author of this post, is the creator of Angular . At the end of the article, there's his solution: https://qwik.builder.io/guide/overview > Qwik is a new kind of web framework that can deliver instant loading web applications at any size or complexity. Your sites and apps can boot with less than 1kb of JS

> is the creator of Angular. Welp, that's reason enough for me to ignore him entirely. Especially on the topic of "overhead." Angular was an inexcusable atrocity.

Most developers would scoff at their own code written a decade ago, because we learn constantly, it's what makes this profession great.

So unless you're one of those people who just are consistently great, maybe the secret identity of Fabrice Bellard, you may want to consider this before making immature statements like this.

Besides, inexcusable atrocities being picked up by large parts of the industry (hi javascript), are pretty common and one could bet that they afford much more learning and real world value than perfect academic solutions never used by anyone

Re: Hydration is pure overhead

#76

Post by ponyous »

wonnage wrote: post #45
grayrest wrote: post #20

Earlier quoted context omitted.

This post is part of a broader effort among emerging js frameworks to send less code down to the browser. It's not just bandwidth. The time to parse, compile, and execute the JS can take as long on a phone as the download itself For a decent fraction of applications a large chunk of the code that's written is to generate non-interactive parts of the app (data fetching, wrappers, component markup, CSS) and the actual…

You could avoid shipping down the JSX templates but only by promising to never render a comment on the client. That's basically the approach taken by this React Server Components proposal: https://github.com/josephsavona/rfcs/blob/server-components/... Rails has experimented with this sort of thing in the past; it requires some deep integration with the HTTP server so that clients can request updates to specific chun…

Oh my, this is what we did ~15years ago with PHP and jQuery, I was hoping no more. We really did a full circle.

Re: Hydration is pure overhead

#77

Post by xigoi »

matthoiland wrote: post #21
ushakov wrote: post #5

Quoted post unavailable.

I've been brainwashed by consumers – they demand and expect a certain experience on the modern web. Also, you can run Next.js on a Raspberry Pi and free Cloudflare DNS+SSL. :shrug:

I'd really like to know what kind of customer demands that a website should be 15 MB in size and use thousands of packages.

Re: Hydration is pure overhead

#78

Post by mikl »

cultofmetatron wrote: post #35
recursivedoubts wrote: post #2

Sometimes you just have to laugh. We've been doing SSR all along, folks: server side templates. Yeah, HTML was pretty hamstrung as a hypermedia, which made for mediocre UX, but that's been fixed by libraries like unpoly, hotwire, or, my own, htmx.

don't forget LiveView!

LiveView is easily the best implementation of this concept, shame Elixir is not more popular than it is.

Re: Hydration is pure overhead

#79

Post by tored »

ponyous wrote: post #76
wonnage wrote: post #45

Earlier quoted context omitted.

You could avoid shipping down the JSX templates but only by promising to never render a comment on the client. That's basically the approach taken by this React Server Components proposal: https://github.com/josephsavona/rfcs/blob/server-components/... Rails has experimented with this sort of thing in the past; it requires some deep integration with the HTTP server so that clients can request updates to specific chun…

Oh my, this is what we did ~15years ago with PHP and jQuery, I was hoping no more. We really did a full circle.

Full circle because it is better, you avoid the unnecessary moving of state, however it is of course zero benefit of using react at this point.

Re: Hydration is pure overhead

#80

Post by steve8708 »

steve8708 wrote: post #71
CreepGin wrote: post #46

While we are on the topic of browser event handlers and "embracing how browser actually work", I can't help but mention that the builder.io website's top navbar cannot handle ctrl + clicking (for opening links in a new tab). It's actually quite subtle. Sometimes it works, sometimes it doesn't, depending on which page you are on, what you've already clicked, etc. All part of the fun of frontend web development, ain't…

Oops, thanks for catching. I implemented the client side routing there from scratch with partytown and must have forgot a check to make sure the ctrl/cmd/shift keys aren’t down when canceling the event for a client side routes. Will get that fixed this week

confirmed - I foolishly did not include this check, PR sent for the fix, thanks again for mentioning!
Post reply on HN