6 ms·
> Rehydration is a really big deal. Sounds dorky but it dramatically speeds up load times and such by serving flat HTML and injecting JS afterward, like the old
by eyelidlessness 4y ago
> Rehydration is a really big deal. Sounds dorky but it dramatically speeds up load times and such by serving flat HTML and injecting JS afterward, like the old days, except you can write code like it's not the old days.
Hydration is actually a compromise, and not a great one for UX. It’s in fact been said to be “pure overhead”, which I think is an overstatement but only slightly.
What you’re describing in the abstract is spot on though. Serializing server state to HTML and sprinkling in interactivity to pick up where it left off is exactly where we should be headed.
And yes it is like the old days, and yes all of HN will rapidly say so. The big difference now is the convergence of code written for both server and client, and compilers which help strip down and optimize what happens in the client.
Hydration in the current sense is re-running most of what the server already did, to recreate the runtime state it already had. That may be perceptively faster in terms of metrics like first paint, but it’s a huge barrier for time to interactive. All the more so when most content is static and has to load twice—fast first as HTML, then slower and redundantly as JS.
The best way to solve this is to not serve or hydrate anything at all unless you need to. The “islands” approach is a very good, but coarse, way to solve this: isolate components which are actually interactive, treat the rest as static. A more granular approach—termed resumability by Qwik and as I understand it the forthcoming version of Marko—works by treating the server-generated HTML as the initial state. The code executed from there is much more isolated than a full component.
- LeanderK 4y agoif the code is the same on the server, one could serialise the state and transfer it with the html, right?
- ash 4y agoYou still have transfer the JS.
- alrlroipsp 4y agoITT, it was finally proven that JS is not code.
- solardev 4y agoI don't think anyone believes JS is a great language. It's just what we're stuck with. How I wish something, anything better could've taken over. .NET was beautiful to work in. Maybe the native apps for iOS or Android are cleaner (I dunno, never tried). But browsers are what the world use, and they only speak HTML and Javascript (sadly). So we're stuck unless something else manages to create a sea change in how the world uses the internet.
- eyelidlessness 4y agoRight, but not all of it. The way Qwik serializes it is (this is from memory and probably overly simplistic, but conceptually approximate): - Primitives already present from the server render are serialized directly into the HTML, and the compiled code reads those values from the DOM - Everything else is split into fine grain chunks, assigned a special identifier (Qwik uses URLs) which is serialized to the HTML to fetch (which can be eager or on-demand) and activate interactivity as needed My understanding is that currently Qwik serializes more than necessary—i.e. can be optimized further to eliminate non-interactive chunks from consideration—but that they’re focused on reducing JS cost first.
- axlee 4y agoThat's how it works.
- lbriner 4y agoThe way I read it, you might have lots of javascript to compute and render your e.g. counter control but you can keep that on the server side, only return the (much smaller) piece of HTML code and ONLY the JS needed to make the control interactive. I don't know whether this means that it doesn't work as SPA any more since if you want to keep the best of both, you will end up creating more4 complexity, a new framework to learn and probably get marginal improvements at best.
- redbar0n 4y agothat’s how it works, but you also need to attach event handlers and set up the state for the framework on the client-side (for subsequent interactions).
- LeanderK 4y agoI meant the state for the framework, as I understood it the same framework was used on the serverside.
- mayank 4y ago> The big difference now is the convergence of code written for both server and client, and compilers which help strip down and optimize what happens in the client. I understand the spirit of your comment, but this was/is also true of Google Web Toolkit (GWT).
- eyelidlessness 4y agoI’m going to have to take that on faith, their site doesn’t appear to ship the JS necessary to open the nav menu. But clicking through a few links confirmed what I recall: the major difference (apart from language) is the component/templating approach. Not that one is inherently better than the other (though I do personally prefer JSX), but bringing this concept to a dev environment which thus far mostly lacks it is a good thing for users. And with more flexibility in variety, there’s better odds users will get that experience.
- DylanSp 4y ago> A more granular approach—termed resumability by Qwik and as I understand it the forthcoming version of Marko—works by treating the server-generated HTML as the initial state. The code executed from there is much more isolated than a full component. Is that sort of what Phoenix LiveView does? Return a fully server-rendered page on initial load, then set up a "template" on the client side that can receive any values that change server-side over a websocket and patch them into the DOM?
- eyelidlessness 4y agoThis sounds conceptually similar, albeit maybe more similar to React Server Components? I’m really not familiar enough with Phoenix to get that specific though. Even in the JS ecosystem there’s a lot of nuance between seemingly similar approaches (hence why even commonly referenced concepts like hydration can be confused for what they actually do).
- DylanSp 4y agoI think what Fresh is doing now is more similar to Server Components, shipping full components to the client. With LiveView, once it's set up on the client, the updates it sends over the wire are much smaller. https://fly.io/blog/how-we-got-to-liveview/ https://fly.io/blog/how-we-got-to-liveview/ shows some examples of the idea.
- eyelidlessness 4y agoYeah this looks much more similar to Qwik. It even looks like they have a similar view serialization approach.
- redbar0n 4y ago> Hydration in the current sense is re-running most of what the server already did, to recreate the runtime state it already had. It’s interesting that the problems with hydration is in some sense caused by the insistence on one-way data binding (deriving the view from the state). I imagine that with two-way data binding then you’d just need to attach event handlers and then the state would be derived from the view on the next interaction. Maybe.
- nine_k 4y agoIt's really easy to make the states diverge this way. That's why the one-way binding is popular. OTOH if there were a way to produce a two-way implementation from a one-way description, that could be great for performance. But this is already more CS than engineering.
- redbar0n 4y agoHow do the states diverge? I think you can have a two-way binding with a controlled update procedure, akin to one-way data-binding. I’ve read some people claim to do it by producing a kind of one-way directionality under-the-hood (?) from two-way bindings. The goal being that views can update state (and other views). I think it was here I read it: «‘2-way’ shouldn't be a problem if a component reports user events (perhaps transformed/mapped) to the domain model without changing it's own core state (disregarding throttling etc.) and only changes its core state in response to events from the domain model.« — peerreynders @ https://dev.to/peerreynders/comment/1objn https://dev.to/peerreynders/comment/1objn
- eyelidlessness 4y agoI’m not sure that gets you much. You still have to know which parts of the code are implicated in executing those event handlers, which very likely close over other state and call into other logic. To an extent you can get that with static analysis (as Qwik does, with one-way binding), but highly dynamic code is tricky no matter what.
- melony 4y agoFor all the improvements pioneered by Marko, why is eBay still so slow (compared to equivalent ecommerce sites in Next.js and similar)?
- eyelidlessness 4y agoI’m not sure why you’re asking me, but I just did a quick “how slow does eBay feel” on my really spotty mobile connection and it didn’t feel slow at all. Faster than HN, which is usually my fast baseline that responds even when I’m not coaxing my network settings.
- pier25 4y agoMy guess, the bottleneck is in the data layer. Honestly it's unfair to compare a small e-commerce site made with Next to one of the biggest websites on the internet. If Ebay was made with Next it would probably be much slower. React is the slowest at SSR of the modern frameworks. Amazon considered using it but it was too slow for them so they keep using Java + sprinkled JS.
- pier25 4y ago> Serializing server state to HTML and sprinkling in interactivity to pick up where it left off is exactly where we should be headed. Ironically we were already doing that 15 years ago years with PHP/ASP/Java/Rails + jQuery.
- eyelidlessness 4y agoThis is neither ironic nor correct. But I will say I’ve described my mental model of Qwik as effectively that UX, but the compiler writes the jQuery for you.