JavaScript Hydration Is a Workaround, Not a Answer – The New Stack
In net growth, Hydration is a way so as to add interactivity to server-rendered HTML. It’s a way by which client-side JavaScript converts a static HTML net web page right into a dynamic net web page by attaching occasion handlers to the HTML parts.
Nevertheless, attaching occasion handlers to the Doc Object Mannequin (DOM) just isn’t probably the most difficult or costly a part of hydration.
On this article, I’ll clarify why I imagine hydration is overhead. It’s not the answer; it’s a hack that consumes reminiscence and slows down startup, particularly on cellular. For the sake of this text, let’s outline overhead as work that may be averted and nonetheless results in the identical finish consequence.
Digging Deeper into Hydration
Miško Hevery
Miško Hevery is the chief technology officer at Builder.io. As CTO, Miško oversees the technology division that powers the Builder.io applications and software. Before joining Builder.io, he created open source platforms for Google, including Angular and AngularJS, and was co-creator of Karma. While at Google, he brought a testing culture there with his blog. Before focusing on making the web better, he believes testing is the key to success.
The laborious a part of hydration is realizing what occasion handlers we want and the place they must be hooked up.
- WHAT: The occasion handler is a closure that accommodates the habits of the occasion. It’s what ought to occur if a person triggers this occasion.
- WHERE: The situation of the DOM aspect the place the WHAT must be hooked up (consists of the occasion sort)
The added complication is that WHAT is a closure that closes over APP_STATE and FW_STATE:
- APP_STATE: the state of the applying. APP_STATE is what most individuals consider because the state. With out APP_STATE, your software has nothing dynamic to indicate the person.
- FW_STATE: the interior state of the framework. With out FW_STATE, the framework doesn’t know which DOM nodes to replace or when the framework ought to replace them. Examples are component-tree and references to render features.
So how can we recuperate WHAT and WHERE? By downloading and executing the rendered elements in HTML. That is the costly half.
In different phrases, hydration is a hack to recuperate the APP_STATE and FW_STATE by eagerly executing the app code within the browser and includes:
- Downloading element code.
- Executing element code.
- Recovering the WHAT (APP_STATE and FW_STATE) and WHERE to get occasion handler closure.
- Attaching WHAT (the occasion handler closure) to WHERE (a DOM aspect).
Let’s name the primary three steps the Restoration section.
Restoration is when the framework is attempting to rebuild the applying. The rebuild is pricey as a result of it requires downloading and executing the applying code.
Restoration is straight proportional to the complexity of the web page being hydrated and might simply take 10 seconds on a cellular system. Since Restoration is the costly half, most functions have a suboptimal startup efficiency, particularly on cellular.
Restoration can be overhead: It rebuilds info that the server already gathered as a part of server-side rendering (SSR) or static website technology (SSG). As a substitute of sending the knowledge to the consumer, the knowledge was discarded. In consequence, the consumer should carry out costly Restoration to rebuild what the server already had. If solely the server had serialized the knowledge and despatched it to the consumer together with HTML, the Restoration may have been averted. The serialized info would save the consumer from eagerly downloading and executing all the elements within the HTML.
In different phrases, the re-execution of code on the consumer that the server already executed as a part of SSR/SSG is what makes hydration pure overhead.
Resumability: A No-Overhead Various to Hydration
To take away overhead, the framework should not solely keep away from Restoration, but in addition step 4 from above: attaching the WHAT to WHERE.
To keep away from this value, you want three issues:
- All the required info serialized as a part of the HTML, together with WHAT, WHERE, APP_STATE, and FW_STATE.
- A world occasion handler that depends on occasion effervescent to intercept all occasions in order that we’re not compelled to eagerly register all occasions individually on particular DOM parts.
- A manufacturing unit perform that may lazily recuperate the occasion handler (the WHAT).
The above setup is resumable as a result of it may possibly resume the execution the place the server left off with out redoing any work that the server already did. By creating the WHAT lazily as a response to a person occasion, we will keep away from doing all of the pointless work that occurs in hydration. All this implies no overhead.
Reminiscence Utilization
The DOM parts retain the occasion handlers for the lifetime of the aspect. Hydration eagerly creates all the listeners, so it wants reminiscence to be allotted on startup.
Alternatively, resumable frameworks don’t create the occasion handlers till after the occasion is triggered. Due to this fact, they are going to devour much less reminiscence than hydration. Moreover, the occasion handler is launched after its execution, returning the reminiscence.
In a means, releasing the reminiscence is the alternative of hydration. It’s as if the framework lazily hydrates a particular WHAT, executes it after which dehydrates it. There’s not a lot of a distinction between the primary and nth execution of the handler.
The Efficiency Distinction
To place this concept into observe, we constructed Qwik, a framework that’s designed round “resumability” and achieves a speedy startup. To point out you the impression of resumability, we constructed a to-do app demo that runs on Cloudflare edge. This web page is prepared for interplay in about 50 ms.
We additionally used the resumable technique (and Qwik) to redo our web site, builder.io. Utilizing Qwik (and our different resolution, Partytown), we had been in a position to cut down 99% of the JavaScript in our site and get a PageSpeed score of 100/100. (You’ll be able to nonetheless go to the old page using hydration to check and expertise the efficiency distinction for your self.)
Conclusion
Put merely, hydration is overhead as a result of it duplicates work. The server builds up the WHERE and WHAT (APP_STATE and FW_STATE), however the info is discarded as an alternative of being serialized for the consumer. The consumer then receives HTML that doesn’t have adequate info to rebuild the applying. The lack of awareness forces the consumer to eagerly obtain the applying and execute it to recuperate the WHERE and WHAT.
Another strategy is resumability. Resumability focuses on transferring all the info (the WHERE and WHAT) from the server to the consumer. Solely a person interplay forces the consumer to obtain code to deal with that particular interplay. The consumer just isn’t duplicating any work from the server; subsequently, there is no such thing as a overhead.
Function picture via Pixabay.