3

What are the main differences between Resumability , Hydration and Reconcillation ?

We know Resumability is future of web app, Is it possible to make most of the current meta framework (Nextjs,Remix, Sveltekit, Solidstart, etc.. ) resumable ?

Harsh Mangalam
  • 1,116
  • 1
  • 10
  • 19
  • I wish. I want Seveltekit so use resumability instead of hydration. It would make it my complexly favorite framework – Royer Adames Jul 19 '23 at 20:14

1 Answers1

8

SSR means server side rendering. It is desired for search engine optimization and faster load time. However, a server written in JavaScript does not have the same API as the browser. So, there is no way to fully render an application. Even if it is possible, it would not make sense since runtime environments are tailored for different use cases. For example, there is no click events on the server side, etc. So, SSR returns partially rendered application + client side code.

When client side code executes, it will hydrate the application, meaning it will take the partially rendered app returned from the server, calculate the new state and bind the events etc. Client side application does less work than its client only version but still some tasks are repeated. Resumable frameworks like Qwik tries to address this shortcoming.

In simple terms, resumability means recovering application's state without re-fetching resources. It is an emerging pattern for writing isomorphic applications.

In Resumabilty, there is no top-down hydration, at least in Qwik's implementation. Client side logic is either infused into the server returned code or fetched piece by piece when they are needed. Qwik serializes the application's state and framework state into HTML returned from the server. Events are bound to the UI upon user's interaction, when user clicks on a button.

Edit: There are three basic approaches to when to resume a server rendered application:

  1. On page load: This is almost identical to hydration.
  2. On idle: Application is resumed when browser becomes idle.
  3. Upon user interaction: This is what Quick uses.

Problems with resumability concentrate around the UI lag that is introduced due to network latency because code is fetched and executed upon user interaction, which becomes more visible on low end devices and slow networks.

Reconciliation means reconciling two states, in other words diffing and patching previously rendered states of an application. React uses virtual DOM and re-renders everything when the state changes. However for a large application, this is costly. So, rather than re-calculating whole DOM tree, it keeps the unchanged parts and re-renders only the changed branches. In the context of server side rendering, reconciliation means reconciling server side rendered state of an application with its client side rendering logic.

We know Resumability is future of web app.

This is a bold statement. In computer science everything is a tradeoff.

Is it possible to make most of the current meta framework resumable ?

I don't think so. Maybe some of them but definitely not all because resumability is hard to retrofit and may require complete re-write. Not all applications needs SSR or use search engine optimization.

snnsnn
  • 10,486
  • 4
  • 39
  • 44
  • I would like to see a more in depth look at the trade off of resumability because on paper it is really the solution we look for in production websites. Thank you for your comment of resumability being the the future has a bold statement. For most production websites it does solve a big issue with scalability – Royer Adames Jul 19 '23 at 20:18
  • @RoyerAdames Resumability is overly hyped and I believe it does not deserve the publicity it receives. The UI lags when the network is slow and the application is unnecessarily complex and bloated. Future lies in component level server side rendering because the end product tends to be small, secure and efficient. – snnsnn Jul 19 '23 at 21:21
  • Thank you for responding. The you can take off Resumability from your respond and I will still agree with you. A good example of this is https://www.universalorlando.com/web/en/us. Is very slow. Making JS cost be a constant can be a solution for it. There is a lot of JS we load before we can us the page in the example I shared. Can you share some examples of why Resumability is all hype? How can I test it myself? Something that I do like about it is that the framework handles the implementation of it while I can keep my current workflow. Now we just need Angular, Svelte, and others to update. – Royer Adames Aug 12 '23 at 00:50