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

51–60 of 84 posts

Re: Hydration is pure overhead

#51

Post by ratorx »

ushakov wrote: post #39
chrischen wrote: post #10

Earlier quoted context omitted.

You don’t need dependencies like webpack, react, or even any javascript at all to show static pages… and it would be a poor use of them just to write static html. But if you want interactive elements like image editors, rich text edition, fancy tables, then you start needing smarter and smarter build tools to bundle it all together and support the maintenance of interactive complex web applications. I'd also argue th…

why do i need React for any of this? most template engines have partials and some have macros (Jinja2) React-based static site generators are so slow that they’re unusable for any website that has more than a couple pages

The developer experience is better. I personally like type safe templates, and just the JSX bits of React are one of the most mature type safe templating frameworks with very good editor support.

Re: Hydration is pure overhead

#52

Post by chrischen »

ushakov wrote: post #39
chrischen wrote: post #10

Earlier quoted context omitted.

You don’t need dependencies like webpack, react, or even any javascript at all to show static pages… and it would be a poor use of them just to write static html. But if you want interactive elements like image editors, rich text edition, fancy tables, then you start needing smarter and smarter build tools to bundle it all together and support the maintenance of interactive complex web applications. I'd also argue th…

why do i need React for any of this? most template engines have partials and some have macros (Jinja2) React-based static site generators are so slow that they’re unusable for any website that has more than a couple pages

I don't use React-based static site generators, but I'd imagine if they become slow it's because it's generating a large code-base, but unless you provide some benchmarks showing compilation of React vs some other templating system I can't really take your argument against it for this use case.

Re: Hydration is pure overhead

#53

Post by fleddr »

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.

That's a terrible mindset no matter how much you hate Angular.

Re: Hydration is pure overhead

#54

Post by chrischen »

tylerhou wrote: post #28
chrischen wrote: post #26

Earlier quoted context omitted.

Well, servers often come with more but slower cores.

But servers have a much higher power budget compared to phones or most laptops. That's supposedly the target user base for SSR + hydration.

I don't think the purpose of SSR + hydration is to simply move the wait time from first render to server response, or that servers can somehow render faster. To fully yield the benefits you'd have to enable caching, so that the server spits out something without rendering and the client side can simply hydrate.

Caching is not something individual distributed clients can do, which is why the server is the only way able to reasonably take on this role. You can also easily configure nginx to serve just-in-time caching.

Re: Hydration is pure overhead

#55

Post by codercatdev »

simulate-me wrote: post #34
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…

One reason I like SSR is that you need some form of SSR for public-facing websites anyway. Website previews (like in iMessage, Twitter, etc.) rely on Open Graph tags in the HTML, and these services expect the OG tags to be available without executing any JavaScript. Since you already need this step, you can make loading pages much faster if you inline any data you might have fetched from the client at view time.

Just one side note here you could also just use SSG, and never need to hit a server unless you rebuild the page in some fashion

Re: Hydration is pure overhead

#56

Post by ushakov »

chrischen wrote: post #52
ushakov wrote: post #39

Earlier quoted context omitted.

why do i need React for any of this? most template engines have partials and some have macros (Jinja2) React-based static site generators are so slow that they’re unusable for any website that has more than a couple pages

I don't use React-based static site generators, but I'd imagine if they become slow it's because it's generating a large code-base, but unless you provide some benchmarks showing compilation of React vs some other templating system I can't really take your argument against it for this use case.

don’t take my word for it

https://css-tricks.com/comparing-static-site-generator-build...

Next.js and Gatsby are the slowest

Re: Hydration is pure overhead

#57

Post by redbar0n »

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…

It is correct, except I think the browser generates the DOM from the HTML, and the JS just attaches event handlers to it.

The reason for the double work is that the context here is SSR/SSG:

«The re-execution of code on the client that the server already executed as part of SSR/SSG is what makes hydration pure overhead: that is, a duplication of work by the client that the server already did.»

In client-side rendering (CSR), there isn’t double work in rendering the HTML, since the client only does it.

Yes, the idea is to send pre-rendered HTML (by using SSR/SSG). The client doesn’t need to re-create the page/HTML, simply hydrate it (attach event handlers). But it is duplicate work and turns out to be a bit expensive to always do it on the initial load.

Hope that helps to clarify.

Re: Hydration is pure overhead

#58

Post by ryansolid »

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…

Yeah RSCs are another approach I'd say that are playing with these sort of approaches. Other notables include:

Marko: https://www.markojs.com Astro: https://astro.build

Re: Hydration is pure overhead

#59

Post by recursivedoubts »

eyelidlessness wrote: post #31
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.

Is this condescension really necessary? I don’t think it helps the discussion generally, but particularly from authors of libraries in a similar space with a different approach. Lots of others in the space, many whose work would likely get a similar reaction, are quite welcoming to competing approaches and even speak highly of them. That said, I think you might want to consider looking more closely at how Qwik works.…

that's fair, I was being too sardonic

i've spent a bit of time today looking into qwik and I appreciate what they are trying to do

not my bag, but i'm obviously a contrarian in the web world

Re: Hydration is pure overhead

#60

Post by eyelidlessness »

recursivedoubts wrote: post #59
eyelidlessness wrote: post #31

Earlier quoted context omitted.

Is this condescension really necessary? I don’t think it helps the discussion generally, but particularly from authors of libraries in a similar space with a different approach. Lots of others in the space, many whose work would likely get a similar reaction, are quite welcoming to competing approaches and even speak highly of them. That said, I think you might want to consider looking more closely at how Qwik works.…

that's fair, I was being too sardonic i've spent a bit of time today looking into qwik and I appreciate what they are trying to do not my bag, but i'm obviously a contrarian in the web world

Hey, thank you for this response though! It’s much more what I like/hope to see in the ecosystem. Also I’m an old curmudgeon so I relate, and sometimes need a nudge to turn the contrarian knob down to friendly :)
Post reply on HN