Hydration is pure overhead

#1

Post by steve8708 » Wed, Apr 20, 2022, 6:50 PM UTC

Hydration is pure overhead
builder.io

Re: Hydration is pure overhead

#2

Post by recursivedoubts » Wed, Apr 20, 2022, 7:09 PM UTC

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.

Re: Hydration is pure overhead

#3

Post by daenney » Wed, Apr 20, 2022, 7:30 PM UTC

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.

htmx is the first thing that’s made me feel like I can build a useful front end again in years. Plain server side rendering of templates and a bit of sprinkles on top. It’s awesome and thank you!

Re: Hydration is pure overhead

#4

Post by chasd00 » Wed, Apr 20, 2022, 7:43 PM UTC

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 directly to the browser?

Is the idea to take advantage of the server's horsepower to get something on the screen fast by sending pre-rendered HTML and then wait while the browser runs the code to basically re-create the page for interactivity?

(it's been a while since i've done traditional front-end web dev)

Re: Hydration is pure overhead

#5

Post by ushakov » Wed, Apr 20, 2022, 7:46 PM UTC

No post body was provided.

Re: Hydration is pure overhead

#6

Post by legym » Wed, Apr 20, 2022, 7:48 PM UTC

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/data-fetching-with-react...

Nextjs Blog on Server Components https://vercel.com/blog/everything-about-react-server-compon...

Nextjs Documentation on Server Components (Alpha) https://nextjs.org/docs/advanced-features/react-18/server-co...

We can try it out today on a platform that supports a node environment. This is from nextjs docs. I have a few thoughts on Svelte, but just wanted to point this out!"

With Server Components, there's zero client-side JavaScript needed, making page rendering faster.

Re: Hydration is pure overhead

#7

Post by yboris » Wed, Apr 20, 2022, 7:51 PM UTC

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

Re: Hydration is pure overhead

#8

Post by chrischen » Wed, Apr 20, 2022, 7:51 PM UTC

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.

Re: Hydration is pure overhead

#9

Post by programmarchy » Wed, Apr 20, 2022, 7:53 PM UTC

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 make their decision to act, there's no extra delay to produce the next state. However, with a "just in time" event binding, now the user has to wait (slightly) longer after they've already made their decision, which seems worse.

Re: Hydration is pure overhead

#10

Post by chrischen » Wed, Apr 20, 2022, 7:54 PM UTC

ushakov wrote: post #5

Quoted post unavailable.

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 that having a static build tool that generates HTML will also allow you to write more HTML and more complex HTML, as you can abstract away reusable components. So there are benefits even if you are serving non-interactive HTML pages. Just cache the React build output.