Imagine how orange juice is transported: the water is removed to reduce the quantity, and water is added back - "rehydrated" - at the destination.
But I think there is a fundamental problem with this idea that I think needs to be solved before we can scale our applications for the next generation of frontend architecture.
I have just come across a tool that makes me think we're much closer to finding a suitable answer to this significant issue.
const root = document.getElementById("root");
But this creates a few issues:
- Bundle sizes grow larger and larger dependent on the requirements of the application, meaning that the JS pages take longer dependent on the bundle size (and therefore the complexity of the project),
There have been three main ideas around how to solve this up until now:
Solution 1: Static all the way ...
The first answer to this problem is static-site generation: use JS to compile in the pipeline, and serve only static HTML to the browser. Certain static-site generators (like Hugo, Jekyll, Eleventy etc), excel at this.
The advantage of this approach is that HTML is still the fastest and best way to serve up content.
Solution 2: Rehydrate all the things
But ... and this is a big but! ... it's expensive.
Solution 3: Splitting traffic
I've been trying to figure out how we negate these problems, because until we do, we face an impasse which prevents us from scaling our applications as we want — and from reaching broader audiences.
(Remember, the next billion web users come from countries where conditions are a lot less ... guaranteed).
There's a variation on this one which I've been thinking about on and off for a while: using an edge handler (such as those Cloudflare or Cloudfront provide, short running standalone functions) to split traffic (or transform websites even before they get to the viewer) based on some sort of browser preference setting. With this idea, we could route people based on one of these three settings:
- device has low battery
- device has a poor network connection
So no, splitting traffic isn't a good option. It may be fine to do that on small blogs like this one, but it's not a viable option for sites when some complex functionality is required .. or even some simple functionality: my HTML-only site doesn't have animations or a search tool.
What we need is something in-between these options. Something that can build HTML statically (or on the server), and partially rehydrate elements on the client where that is needed.
This isn't a new idea. The core React team were hoping that concurrent mode would allow you to do this. However, building up a DOM tree is pretty difficult to achieve asynchronously.
This idea of partial rehydration, or "Islands architecture" by Jason Miller (creator of, among other things, Preact), is something I had really hoped we'd get to at some point.
And now it seems we are here. The below talk at Svelte Summit 2021 blew my mind:
Astro is the first tool I've come across that has this ambition: to facilitate importing and selectively hydrating components in your page as you require them.
This has the potential to solve all of these problems:
- No more "uncanny valley" of pages being visible but not being interactive
- No large bundles being loaded upfront
- We could even give the user control over whether they want to load certain components
Astro is in early alpha, and seemingly in stealth mode too! I'm so eager to get building with this tool now, but it seems I'm going to have to wait a while before the team are ready to open it to a public beta offering.
This could be a really powerful tool, and fundamentally improve the way we build for the web. How exciting would that be!