Partial Hydration via the use:action directive 👀

Unsure if this should go here or in an RFC. I’ll start here, but write a proper RFC if the scope is too big for a regular issue.

With the somewhat recent feature of disabling JS completely on pages it would be nice to selectively add sprinkles of JS around the page for some progressive enhancement.

Describe the solution you’d like Svelte’s action directive could work very well for this as. I briefly mentioned the idea to @pngwn and he mentioned that the life cycle hooks/methods wouldn’t be usable (as we don’t know when something is updated or destroyed. I think for a first version this would be fine - we would simply ignore the update and destroy functions. I don’t this would be a big loss since you would lose the context of the page if you navigate away from it anyway, I think (or can you disabled JS but have the router still be enabled?).

Describe alternatives you’ve considered An alternative way of doing this would be how Elder.js does it - a preprocessor that looks through your pages and finds any that are marked with some prop (sveltekit:partial?) and bundles that separately, injects that in some intersectionObserver solution. This would allow the usage of full components.

How important is this feature to you? I can live without it, but partial hydration is 👌 and would give us a nice and easy way to enhance our static pages with whimsy and excitement! 👏

[SteveALee]

I’m pleased to see a growing interest in partial Hydration for Progressively Enhanced SSG content. AstroJS and petite-vue are the newest ‘frameworks’ exploring this. The term ‘island architecture’ seem to be growing in usage for this; ie there’s no top-level app component

I recently explored using 11ty and AlpineJS in an interactive music Journal.

I’d personally love a svelte PH solution for a project targetting users in parts of Africa where connectivity is poor and older devices are used.

[benmccann]

The TodoMVC and Vue articles are both extremely misleading and inaccurate because they ignore code splitting. E.g. the TodoMVC article says when you have an application five times the size of TodoMVC then you’ll start to get worse performance with Svelte. But SvelteKit loads only the JS necessary for a page - not the entire application’s JS. So really you would need a single page that is larger than five applications. I’ve never seen a real application get anywhere even close to that. Those articles were both written by people promoting other frameworks and, while I respect the authors, they lead to such wildly inaccurate and biased conclusions

I do agree partial hydration would be a nice enhancement and it’s something we’ll add one day, but having it will probably add about one point to your Google Page Speed Score (it’d be hard for it to do better since most apps are already scoring around 99-100). Meanwhile, nearly every virtual DOM application I’ve seen scores in the 60s or 70s. If you added partial hydration to these apps most of them would be nowhere close to performing as well as a SvelteKit app, so it really is important to look at the whole picture

Svelte absolutely does send unnecessary JS over the wire today. But in practice, it still sends far less unnecessary code than almost everything else out there including most island architectures. We would like to improve hydration, but we also want to take our time to do it right because this is a feature that will probably be implemented at least partially in Svelte core and won’t be easy to change once it’s been released. We’ll likely consider it post SvelteKit 1.0 as focus shifts back to Svelte core. And if you’re already on SvelteKit you will one day get those improvements for very little additional work