Partial Hydration

Background & Motivation

Partial hydration is a key differentiator between classical MPAs/Astro and tools like vite-plugin-ssr/Next/Nuxt. Partial hydration is key to achieving high lighthouse scores and improve performance in general.

Most projects that require SSR have prioritized SEO and instant loading of content for their users, whatever the network or device conditions are, instead of doing it all client-side, so it only makes sense that tools that allow SSR also allow partial hydration.

Astro will soon have SSR (it’s on their roadmap) and they will compete a lot on mind share.

For more context, read RyanCarniato’s tweets, he is talking about it a lot, he is the author of SolidJS and working on the Marko team at eBay: https://twitter.com/RyanCarniato/status/1442715830471389194?s=20

Proposed Solution

I think the islands approach to partial hydration is the future, as in:

• No hydration by default
• Hydrate only the parts the developer specifies

This approach has been highly popularized by Astro. Their API is also very straightforward. Here is another attempt to use Vue, Vite with partial hydration, inspired by Astro: https://github.com/ElMassimo/iles

Next steps

I think we should first discuss:

• Does this falls into the scope of vite-plugin-ssr?
• If so, detailed design on how this should be integrated

Let me know what you think!

[brillout]

Next.js’s fundamental problem is that it’s not a collaborative project. It’s the old school way of having one big company developing everything, whereas Vite is a platform that fosters an ecosystem of passionate developers such as ourselves.

If the Vite ecosystem collaborates, we will outperform Next.js in both features and performance. And many will join us: senior developers profoundly despise lock-ins and Vercel/Next.js is full of lock-ins. Eventually, it’s gonna be Next.js VS a lot of passionate devS.

It was always clear to me that vite-plugin-ssr will and cannot be the end game; there needs to be a wrapper on top of vite-plugin-ssr that offers a zero-config DX, something more like SvelteKit.

I always designed vite-plugin-ssr so that a framework can be built on top of it: a vite-plugin-ssr app essentially consitutes of two parts:

• A render() hook that transforms the routed page to HTML. Any tech can be used here: any view framework (React/Vue/…) and any HTML supplying method (e.g. HTML streaming).
• The entire browser-side code (renderer/_default.page.client.js). Since this file is the entire browser-side code, any hydration strategy can be used including partial hydration.

This means that Astro / Solid Start / îles can be built on top of vite-plugin-ssr.

This will save us from re-inventing a ton of subtle things, two recent examples: routing precendence and CSP support. The really neat (and powerful) thing here is that we can polish all these things and everyone benefits.

Thoughts?

Btw. Vike is going to be a full-stack (Frontend + Backend + Database + Deploy) boilerplate generator (little prototype: create-vike). Would be lovely to include Solid Start / Astro / îles to the boilerplates generated by Vike.

Also CC’ing @patak-js @aleclarson @antfu @yyx990803 since this is very much about the Vite ecosystem at large. In the end, it’s going to be Vite VS Next.js.

[ElMassimo]

Would love to collaborate on this! I’m wrapping up a new release for îles, and have a roadmap that will take a few weeks before I start thinking about supporting SSR, but it’s certainly possible with the current architecture.

In particular, packages such as @islands/hydration could be reused.