Remove rendering code for static component with hydration

[PaulBGD]

If you can trust that the server rendered a component correctly, then I think there's a decent bundle size optimization by removing the creation code for static components.

For example in one of my codebases I put several SVGs as components that are completely static and don't use any data properties to update them. So with server rendering, in theory we can completely remove the creation code for these SVGs.

Another similar smaller optimization could be used for smaller pieces of a component, such as if we know a element doesn't change (like a title or something) then we can remove that piece of the element creation.

Obviously these types of optimizations aren't simple, but they're probably the biggest change for making smaller bundles.

[Rich-Harris]

Agree. This would be an excellent feature. What do we think a good API for that looks like? Idea to get us started:

const { code, map } = svelte.compile(source, {
  hydratable: true,
  repair: false // defaults to true? could *maybe* default to false in v2?
});

Would we want to use checksums of subtrees to verify that the DOM was in the expected state? e.g. this gets SSR'd...

<div data-svelte-checksum='123xyz'>
  <!-- children... -->
</div>

...and this code gets generated (maybe only in dev mode)?

if (node.dataset.svelteChecksum !== '123xyz') {
  throw new Error('Server-rendered HTML differs from expectations');
}

[PaulBGD]

I like the checksum idea, that's an easy way to synchronize state between the client and the server.

I'm not sure about the error throwing. Ideally it makes sense that in a production environment, the client should check the server's work and not just assume it's good.

[PaulBGD]

Convinced my company to use Svelte for a new project and this would be a nice to have. If you like that syntax, I can write up a PR.

[collinanderson]

Hi All,

I just tried out svelte for the first time and was surprised by the amount of unnecessary create/mount/destroy code that is not used with hydration. Also, there's a bunch of unnecessary code to "claim" elements that never get updated or destroyed.

So I just wanted to mention that having some sort of "hydrate-only" or "partial hydration" option would be nice, though might require some tree-shaking to figure out whether elements get create/mount/destroy'd or not.

Is this this a similar issue to what Rich Harris mentioned in the Jamstack Conf 2021 "Transitional Apps" talk?

If you have a server-rendered page and you're hydrating it with an interactive client-side app then you will end up serving data and component code that isn't strictly necessary. This is probably the least compelling part of the modern web story right now, but it's a very active area of research and development.

The React team is working on server components, which is sort of like HTML over the wire except vastly more sophisticated. Marko is doing something called partial hydration, which means skipping the code and data for non-interactive subtrees. Qwik is aggressively lazy-loading everything, so you don't load code until you need it for a specific interaction. Astro is tackling this problem with so-called "islands architecture", which is less granular than Marko but gets you most of the way there. Svelte, the framework I help maintain, uses a compiler to make the cost of the framework as low as possible, and though we don't yet do any kind of partial hydration you can easily turn off hydration at the page level.

Thanks,
Collin