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

11–20 of 84 posts

Re: Hydration is pure overhead

#11

Post by hunterb123 »

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.

This is for enhancing CSR initial load times. For apps that need to work offline, have a lot of UI state, have sister native apps, etc.

Yes we've had SSR, noone is disputing that, nor is it relevant. These are separate solutions for separate problems.

I agree some people reach for the wrong tools sometimes, but that's a universal problem.

Re: Hydration is pure overhead

#12

Post by ushakov »

legym wrote: post #6

The company I work for is making a big deal about client-side hydration. We use nextjs for our sites. My director was asking about Svelte. "Something i wanted to mention is both the React team and nextjs team are aware of this and are working on a solution to address needing to load Javascript on the client. Its called React Server Components React Server Components Documentation https://reactjs.org/blog/2020/12/21/d…

> React Server Components

really?

c’mon could we please ask the React folks to stop making simple things hard?

Re: Hydration is pure overhead

#14

Post by grayrest »

legym wrote: post #6

The company I work for is making a big deal about client-side hydration. We use nextjs for our sites. My director was asking about Svelte. "Something i wanted to mention is both the React team and nextjs team are aware of this and are working on a solution to address needing to load Javascript on the client. Its called React Server Components React Server Components Documentation https://reactjs.org/blog/2020/12/21/d…

If you're into this sort of thing you should look into Marko. They're kind of obsessed about page load perf with the justification that it's good for e-commerce. They've also been into streaming, partial hydration, out of order rendering, etc for years as part of that general effort.

Re: Hydration is pure overhead

#15

Post by zanellato19 »

programmarchy wrote: post #9

If I'm understanding correctly, this is binding event handlers "just in time" instead of when a component initializes. Isn't that just a tradeoff between working the CPU at load time vs. working the CPU on user interaction? This doesn't seem like a great tradeoff to me. Sure, maybe you save time during component initialization, but while that is happening the user is digesting the information anyway. Then once they m…

Yeah... This screams of people who never had bad networks. If you are going to add interactivity as a JIT thing, what happens when the user has a shitty connection? You give the impression that the page loaded to the user, but it didn't really load. This is just increasing by a lot the amount of connections the user will have to make. Its _more_ overhead with a bunch of http calls.

Re: Hydration is pure overhead

#16

Post by ushakov »

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.

the reason we need all this is so that Netlify and Vercel can make money

there’s no other explanation

it’s a capitalist game and if you want to stay sane, you shouldn’t play it

Re: Hydration is pure overhead

#17

Post by bacro »

chrischen wrote: post #8
chasd00 wrote: post #4

This is confusing to me. From the article it sounds like the javascript is run on the server producing markup. That markup is sent to the browser for rendering then the javascript is requested by the browser. When the javascript arrives it is run again on the browser to re-generate the DOM with event handlers attached. If that is correct then why is the javascript run on the server to begin with and not just sent dir…

I think most importantly the server can cache requests (cache the generated HTML). This is especially important for public, mostly static pages that one might want to do SEO optimizations for anyways. Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser.

>Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser.

Isn't this the other way around? I mean a server is supposed to be fast enough to handle a lot of requests.

Re: Hydration is pure overhead

#18

Post by hunterb123 »

ushakov wrote: post #16
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.

the reason we need all this is so that Netlify and Vercel can make money there’s no other explanation it’s a capitalist game and if you want to stay sane, you shouldn’t play it

> there’s no other explanation

Faster initial load times for PWAs?

No conspiracy theory or capitalism rant needed.

Re: Hydration is pure overhead

#19

Post by hunterb123 »

bacro wrote: post #17
chrischen wrote: post #8

Earlier quoted context omitted.

I think most importantly the server can cache requests (cache the generated HTML). This is especially important for public, mostly static pages that one might want to do SEO optimizations for anyways. Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser.

>Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser. Isn't this the other way around? I mean a server is supposed to be fast enough to handle a lot of requests.

An individual server is more powerful than one client, but your client computing power multiplies by your user base.

Same reason DDoS attacks are generally more powerful than DoS attacks.

Power in numbers.

Re: Hydration is pure overhead

#20

Post by grayrest »

chasd00 wrote: post #4

This is confusing to me. From the article it sounds like the javascript is run on the server producing markup. That markup is sent to the browser for rendering then the javascript is requested by the browser. When the javascript arrives it is run again on the browser to re-generate the DOM with event handlers attached. If that is correct then why is the javascript run on the server to begin with and not just sent dir…

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 code for event handling is relatively small. Hacker News, for example, is a pretty common framework demo since it's simple to write. You need a bit of JS on the comments page for the vote buttons and the comment collapse but if you write HN in a natural way in most component oriented frameworks the bundle coming down is considerably larger and includes all the code for rendering the comments (for example) even though the comments never change and most hydration approaches will put the comments in both the markup and embed a JSON/JS chunk in the page so hydration and the client side render can happen with consistent data. This doubles the size of the page with the overhead of the data half running through some subset of the JS code machinery.

In the case of Qwik, the idea is to do a server side render and then lazy load everything on the client as it's needed. At least that's my understanding, I haven't used the framework beyond a toy project. There are other approaches but to use the HN example, you'd never download the comment collapsing code if you didn't click a collapse button.

Post reply on HN