Hydration is pure overhead

https://www.builder.io/blog/hydration-is-pure-overhead

by steve8708 • 4 years ago

79 67 4 years ago

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.

daenney• 4 years ago

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!

hunterb1235• 4 years ago

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.

lf-non• 4 years ago

Not that irrelevant.

Traditional SSR involved a separation between templates which contain presentation logic, and controllers for mediating business logic, persistence etc.

If your backend & frontend are in same language, or you use template engines with implementations in mutliple language like handlebars/pug/soy etc. you could easily render the same templates using JS and your client side can have as much ui state, interactivity etc. as you want.

If we adopt incremental enhancement then the fetching of templates can be delayed - we primarily need the controllers which handle dom events to make the server-rendered ui interactive. This is easily achievable through libraries like stimulus where controllers can add complex interactivity to server rendered templates and re-render them if needed through templates which are fetched on demand. We can even preserve form element states by using libraries like morphdom for swapping content.

However, what really breaks down all of the above is the concept of components as popularized by React etc. When we start writing react-style components then our rendering logic and associated behavior are tightly coupled and we need to pull in all the rendering logic for enhancing the server rendered content. React devs like to preach that traditional separation of concerns is not useful in practice and it is better to have rendering code colocated with behavior - but solutions like this just demonstrate that this separation did actually have some merit albeit at the cost of some indirection.

What solutions like Qwik are attempting to do is enabling folks to keep writing component oriented code but now we need a fancy compiler tooling that deeply integrates with the stack. The approach does have its merits but it is just one path to address the problem.

layer8• 4 years ago

For apps that need to work offline

I wonder if it’s a suitable approach at all for those, because when they’re offline they won’t be able to lazy-load the JS code they’re still missing.

ushakov4• 4 years ago

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

hunterb1235• 4 years ago

there’s no other explanation

Faster initial load times for PWAs?

No conspiracy theory or capitalism rant needed.

eyelidlessness4• 4 years ago

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. It produces markup metadata that’s not dissimilar to what I see in htmx. I don’t know if it’s a direct inspiration, but that similarity seems particularly odd to dismiss so bluntly.

The major philosophical difference between the two is the authoring experience: Qwik annotates the HTML with a compiler, in htmx it appears the expectation is you write the annotations directly. Qwik’s server side templates just happen to be authored as JSX components. Both are completely valid! Probably more a matter of preference than anything.

Personally, I prefer the Qwik approach. But I welcome yours as well and encourage people who would prefer it to choose it. Both are significantly better, in many cases, for users than the current outcomes from many other frameworks which appeal to the devs Qwik is targeting. Isn’t that also welcome given the state of web dev today?

recursivedoubts2• 4 years ago

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

cultofmetatron2• 4 years ago

don't forget LiveView!

mikl• 4 years ago

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

chasd002• 4 years ago

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)

chrischen3• 4 years ago

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.

bacro• 4 years ago

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.

MonaroVXR• 4 years ago

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.

I'm thinking about that Hacker News article, which had a laptop in the datacenter, because it was much faster on it.

grayrest3• 4 years ago

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.

wonnage3• 4 years ago

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 chunks of the UI rather than just URLs.

brundolf• 4 years ago

You get to at least see the content much faster, it's just not interactive for a bit. The benefit is clearest when rendering pages at build time and then serving the HTML over a CDN

But even then, it's definitely still a problem vs sites that don't have to be hydrated. Some people see this approach as a best-of-both-worlds, but in reality it's still a compromise that has costs

tshaddox• 4 years ago

If that is correct then why is the javascript run on the server to begin with and not just sent directly to the browser?

Just the same ordinary reasons to generate HTML on the server: it allows you to support HTTP caching (in a CDN or even browser caching), it (potentially) lets the browser start rendering content much sooner, and it will be viewable by user agents (bots, scrapers, search engines, etc., but also humans) that don't run JavaScript.

chasd002• 4 years ago

that makes sense, so if you're using http caching appropriately the server side "render" or running of the javascript happens on the first visit and then infrequently thereafter.

wonnage3• 4 years ago

When the javascript arrives it is run again on the browser to re-generate the DOM with event handlers attached.

Not the DOM, but the virtual DOM. Instead of inserting elements (which is expensive), it can just walk the existing server-rendered DOM and attach listeners.

simulate-me2• 4 years ago

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.

codercatdev• 4 years ago

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

lhorie2• 4 years ago

Generally speaking, if you approach qwik.js from a 10,000 mile view like you'd normally approach other frameworks, you're going to miss the trees for the forest. One of the axioms where this framework is coming from is the idea of providing React-like developer experience, so yes, there's going to be templates expressed in JS.

Where it gets technical has to do with how the JS gets delivered to the browser. It starts with a small bootstrapping that sets up event delegation, sort of like `document.documentElement.addEventListener('click', becomeAwareOfClicks)`. This happens literally on the first chunk of HTML being streamed in, meaning that the framework is now already aware of clicks happening anywhere in the app, even before HTML <body> is available in JS.

Eventually some HTML will stream in with an attribute that indicates how a click event on an element should be handled. The framework can then quickly determine whether it needs to "hydrate" that event handler: a) if the event was captured by `becomeAwareOfClicks` and b) the intersection observer deems that element is visible and available to DOM manipulation, then c) it can download the relevant handler, meaning it triggers business logic at latest as soon as the intersection observer downloads the handler.

Note that at this point, no other JS has downloaded yet. Eventually it does download it, like every other framework, but the key point is that it can respond to events with actual business logic before the rest of the JS comes down the pipe.

redbar0n• 4 years ago

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.

eyelidlessness4• 4 years ago

What you’ve described is a complete and accurate description of the “hydration” approach which the article (also correctly) describes as pure overhead. The approach proposed in the article/implemented in Qwik dispenses with re-running the JS which already ran on the server and just carries on with the state it produced.

The SSR/hydration approach:

- Benefits SEO

- Usually benefits initial content on the screen

- Has a bunch of performance penalties after that as JS is loaded, parsed, and (usually blocking) recreates the data structure representing its initial state

Qwik’s approach (at least conceptually) skips that third point for everything until an interaction needs to respond to some state change based on an interaction, and does that with only the information needed for that event.

In a tweet thread, I described my mental model of this as effectively developing like I’m building an app where all the server/client UI code is shared, but the UX is like I wrote plain HTML with some jQuery or whatever to make a few elements interactive. What Qwik does is determine which parts of the server code need to be the compiled jQueryish code, but only calls it when needed.

An equivalent React codebase would re-render the entire page (well mount point) even if most of it will have no meaningful effect.

legym• 4 years ago

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.

ushakov4• 4 years ago

React Server Components

really?

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

grayrest3• 4 years ago

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.

yboris• 4 years ago

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

wwweston2• 4 years ago

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.

fleddr• 4 years ago

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

hu3• 4 years ago

Experience is invaluable.

He probably knows much more than those who didn't create a major front-end tool.

eyelidlessness4• 4 years ago

I was surprised when I saw his name attached to this project too. But goodness, having followed it for some time, are you ever wrong. If anything Qwik has reminded me professionally that people really can learn from their experiences and surprise you. Angular was in fact terrible. Qwik is not Angular or like it in any way.

mst2• 4 years ago

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.

culi• 4 years ago

Whatever actual criticisms you have of Angular, do you really think there's anyone around who would be even more painfully aware of those criticisms than him?

hatenberg• 4 years ago

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

programmarchy• 4 years ago

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.

zanellato19• 4 years ago

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.

deckard1• 4 years ago

it's all to appease the Google black box. UX always takes a back seat to SEO. Because if there are no users, then no one to irritate with bad UX in the first place. If it weren't for SEO we would have all dropped SSR+hydration long ago. Absolutely no one likes unifying URLs and content and all that shit on two sides of a single app.

mst2• 4 years ago

The goal here, as I understand it, is to make sites that can be built using fully interactive tooling whose main purpose is to be read, so fast initial readability is paramount and the alternative to JIT interactivity would be a page transition so the network problem doesn't actually make anything worse.

It may not be the best possible set of trade-offs for any particular application but it seems like a set of trade-offs worth exploring.

lhorie2• 4 years ago

Haven't dug too deep, but my understanding is that this doesn't bind event handlers just in time, but instead sets up event delegation from a tiny blocking bootstrapping script, to attach a top-level event handler that catches all events as soon as the first chunk of HTML streams in.

In addition, it sets up an intersection observer. Then depending on when an event happens, it might require downloading that one event handler piecemeal if the event occurred early enough during page load, or if the event is late enough, the action happens instantaneously because the intersection observer already downloaded the handler in anticipation that the user would interact with the element, it being visible and all.

The trade-off is that the download of every other JS thing effectively gets deferred due to fragmentation of how JS gets loaded in the page, but the cleverness of the trade-off is that in typical scenarios, most of that deferred code is not going to be activated by the user in the first place (or at least not in quick succession so as to overload network).

wonnage3• 4 years ago

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.

steve87083• 4 years ago

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

CreepGin• 4 years ago

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 it?

BenjiWiebe• 4 years ago

Tip: If you have a mouse with a scroll wheel, clicking with the scroll wheel (middle clicking) opens links in a new tab too.

steve87083• 4 years ago

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

steve87083• 4 years ago

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

scotty792• 4 years ago

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.

Hydration is pure overhead

Related Stories