Partial hydration

[kevmodrome]

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! 👏

[pngwn]

or can you disabled JS but have the router still be enabled?

You can indeed do this. So we would at least need to do some cleanup. A router navigation event would probably be a good moment to clean up existing actions in the context of a static page.

I think this is an obvious request and one we are bound to get sooner or later. Very few people will want zero javascript but many would like just the tiniest amount.

The problem is that kit would have to parse the component to support something along these lines, a territory that firmly belongs to svelte.

I almost feel like this would make more sense as a 'mode' of the svelte compiler.

Obviously, the real solution to this is to support partial hydration. I don't know if this feature request would be a reasonable half measure or if efforts are better invested in exploring partial hydration in its entirety.

[benmccann]

Partial hydration is basically solving a performance issue by helping users get smaller bundles and faster code execution. There's several open issues around improving Svelte performance. I think it'd be interesting to see how far we can get without partial hydration as I expect we can get pretty phenomenal performance without having to decide on API changes which would take more effort to agree on.

Probably the most impactful would be to improve Svelte's hydration implementation to be more performant (sveltejs/svelte#4308). There was an optimization added in Svelte 3.38.0 that was reverted in Svelte 3.38.2 due to a bug. I'd hope that there's a path to getting that optimization checked back in without the bug present since the original approach was agreed upon and there's been a unit test added for the bug. I just commented there suggesting a potential solution. The optimization moved the Google Page Speed score for my site from 92 to 99, so I think at least for some cases that would be a very meaningful improvement that wouldn't require any API changes.

Finally, while it's not related to hydration at all, there are a couple open performance-related PRs and Rich's SSR PR improves SSR performance by 2-3x and is pretty close to being able to be checked in.

[pngwn]

I'm all for the performance improvements in Svelte but if my content is mostly static Svelte will never come close to some selective enhancement with JS, regardless of how good the hydration performance gets because in those case it is doing unnecessary work.

I think since the static and router less options exist in svelte kit, this is a request we will get more and more. A blog, for example, is probably mostly static but users might want a pop out menu. And they might want to write that code in svelte, which is understandable. No performance improvement in svelte is going to make treating all of that static content as some thing to be hydrated even in cases where Svelte optimises the code by setting inner html, having static html as strings in JS when it is unnecessary is a bad idea.

I'm not saying this proposal is the correct way of doing it, but I don't think avoiding some kind of selective hydration is really a solution either.

[nickreese]

Just as a note for the use:action directive. This was the bug I hit with regards to implementing it on Elder.js. sveltejs/language-tools#339

This could be solved if it was an official svelte directive though.

[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.

[Madd0g]

The term 'island architecture' seem to be growing in usage for this

nice, I like that term.

I have server rendered pages right now with a single very simple interactive component. Would love to be able to load only that specific tiny interactive JS in the client, instead of the entire page + metadata.

[theurgi]

I'm not saying this proposal is the correct way of doing it, but I don't think avoiding some kind of selective hydration is really a solution either.

Watching the developments in this space, it's pretty obvious that partial hydration/islands architecture is going to set the new standard in terms of performance.

Where as Astro starts with this as a foundation and is working their way up to a more comprehensive framework by developing dynamic component SSR, React is taking a retrofit approach with Server Components.

Shipping the least amount of JS possible to the client seems like a forgone conclusion. Which ever framework (whether existing or new) can best marry this with the declarative component architecture that's come to dominate developer's mental model, will win in the long run IMO—I hope it's obvious in what sense I mean "win".

Of all the frameworks I've worked with, I find Svelte to be the most intuitive and enjoyable, but I wouldn't hesitate to migrate to another framework for the not insignificant performance gains afforded by this. I'd say it's almost obligatory for competitive e-commerce sites to prioritize this over developer experience.

I'm curious if there are any priority updates, especially now that Svelte has backing from Vercel:

[theurgi]

I suppose that answers my main question in regards to where Svelte is currently at, but...

Now put in one built with the island architecture - I bet it won't beat SvelteKit.

Well, most recently, I read this: SvelteKit vs. Astro

I fully agree with consulting actual metrics over buzzwords and in this particular case the performance gain of Astro is probably negligible for most applications. Based on this alone, I'd even prefer SvelteKit because Astro currently has some limitations where it's hard to determine whether or not they'd present a costly or even impassible challenge deeper into the development cycle.

But if I need to commit to a framework for a large scale application (and I do) and performance is a top priority, and to migrate frameworks down to road is not really an option—this remains a relevant question for me especially considering the way Svelte apps scale horizontally (you know, the whole inflection point thing: JavaScript Framework TodoMVC Size Comparison).

My assumption is that selective hydration would buy Svelte a significant amount of headroom with, if not completely solve, its horizontal scaling issue.

I was hoping that, now that Rich rubs shoulders with all the Vercel engineers who live on the bleeding edge of React, they would convince him of this magic. I wan't to choose Svelte, but all things considered I may have to take my chances with React/Preact.😔

[amardeep]

I was also hoping that svelte would support partial hydration.

I think now I would watch either Marko or Qwik

Sveltekit might be really fast, but when I am developing something which has lots of content, and little interactivity, I prefer a framework which will just send the html as is without also sending the code to render it and the data again in the js. I understand it is a subjective opinion, but I think the web would be a better place without all the unnecessary javascript being sent with everything.

[SteveALee]

@amardeep I'm with you totally as the best approach. I recently used 11ty and alpine for such an approach (https://musicpracticetools.net/)

The advantage about being explicit is it keeps Progressive Enhancement in mind.

However, last time I looked at the code Svelte generated (probably back when v3.0 launched) it generates the minimum dynamic content through javascript and deploys a minimal 'framework' runtime payload.

In other words, Svelte is very close to an implicit automatic island architecture. I assume Sveltekit builds on this; it does let you specify completely staic on a per route basis.

I may be wrong though.

[khromov]

@SteveALee

However, last time I looked at the code Svelte generated (probably back when v3.0 launched) it generates the minimum dynamic content through javascript and deploys a minimal 'framework' runtime payload.

I was also curious about whether Svelte compiler could optimize static components but unfortunately it seems that the entire DOM is still present in the JavaScript bundle.

I spun up a new SvelteKit site with the following index component:

<h1>Welcome to SvelteKit</h1>
<p>Visit <a href="https://kit.svelte.dev">kit.svelte.dev</a> to read the documentation!</p>

I then built it via @sveltejs/adapter-node and ran the resulting build.

An index.svelte-xxx.js chunk was served that contained this:

import {S as K, i as y, s as V, e as v, t as c, k as W, c as u, a as _, h, d as l, m as b, b as j, g as k, J as o, K as x} from "../chunks/vendor-f0095a1c.js";
function q(E) {
    let e, d, r, a, m, s, f, p;
    return {
        c() {
            e = v("h1"),
            d = c("Welcome to SvelteKit"),
            r = W(),
            a = v("p"),
            m = c("Visit "),
            s = v("a"),
            f = c("kit.svelte.dev"),
            p = c(" to read the documentation!"),
            this.h()
        },
        l(t) {
            e = u(t, "H1", {});
            var i = _(e);
            d = h(i, "Welcome to SvelteKit"),
            i.forEach(l),
            r = b(t),
            a = u(t, "P", {});
            var n = _(a);
            m = h(n, "Visit "),
            s = u(n, "A", {
                href: !0
            });
            var S = _(s);
            f = h(S, "kit.svelte.dev"),
            S.forEach(l),
            p = h(n, " to read the documentation!"),
            n.forEach(l),
            this.h()
        },
        h() {
            j(s, "href", "https://kit.svelte.dev")
        },

So unfortunately, Svelte can't currently optimize away even simple cases like this where there is no interactivity - everything gets sent twice over the wire, first as HTML and then as JS.

[dummdidumm]

So unfortunately, Svelte can't currently optimize away even simple cases like this where there is no interactivity - everything gets sent twice over the wire, first as HTML and then as JS.

Not true. If you set both hydrate and router to false, no JavaScript will be created for that page. See the docs for more info.

[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 non-Svelte 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

[deklanw]

@benmccann

Meanwhile, nearly every virtual DOM application I've seen scores in the 60s or 70s.

All of the popular frameworks use VDOMs. Inexperienced devs gravitate to them and bloat their code with npm-based-development. It's not hard to find performant VDOM apps. For example, despite using one of the more bloated VDOM libraries (React), this Remix demo is far above 60s and 70s.

Now put in one built with the island architecture - I bet it won't beat SvelteKit.

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.

I've been investigating frameworks for making a blog. Making a blog with small interactive elements changes this performance calculus.

As a quick and dirty benchmark I made a long blogpost with a single interactive Counter component with Sveltekit + MDSveX, Astro, and Iles. (Slinkity would also be nice to test, but I didn't). These sites aren't purely identical but it should be good enough. Lmk if I made any mistakes.

Result: they all get 100 in performance with Lighthouse. Great! Let's look closer. For the Counter component, Iles loads the Vue runtime and Astro loads the Preact runtime. Let's see how much JS is sent by each of these. For reference, in all these cases the HTML file is approx 70KB uncompressed, 10KB gzipped.

Framework	uncompressed JS (KB)	gzipped JS (KB)
Sveltekit+MDSveX	268KB	54KB
Astro	12KB	6KB
Iles	53KB	22KB

Sveltekit+MDSveX is sending 22x more JS than Astro. With gzip it's fortunately only 9x as much. That Sveltekit+MDSveX is on par here is impressive. The work done on optimizing the SSR has paid off, apparently sveltejs/svelte#6204, sveltejs/svelte#6395 But, well-optimized waste is still waste. I think this is what @pngwn was expressing above. Note, this only gets worse the longer the blogpost. I would like to test this further with longer posts, but because of long-outstanding bugs pngwn/MDsveX#358 sveltejs/svelte#4694 Svelte doesn't afford blogposts any longer.

How realistic is the benchmark? Well, IME most dev blog posts are a few paragraphs long. So, maybe this won't be a problem for most users. What about people who do write long posts?

Let's see

Article	Word count	# DOM elements	uncompressed HTML (KB)	gzipped HTML (KB)
Benchmark	7893	899	70	10
Gwern article	69.3k	17.5k	1300	321
SSC article (removed comments*)	33k	3.3k	331	97
SSC article (comments in-tact)	135k	15.5k	1600	340

*I remove the eagerly-loaded comments. They comprise most of the page, so removing them simulates 'just blogpost'.

Should these authors just "code split" their longer blog posts? Maybe. If that Gwern article were ported over to Sveltekit+MDSveX I estimate the JS to hydrate would be around 2MB-4MB, uncompressed. In that case, how much would performance degrade as a result of downloading, parsing, and executing all of that JS versus downloading, parsing, and painting all of that HTML? I'm not sure. How would it fare versus Iles and Astro? If it weren't for the aforementioned bugs I would try to estimate that.

Since these performance issues only come up at very long post length, and I would like to use clientside routing with animated transitions, I'll probably move forward with Sveltekit+MDSveX. But, just wanted to lay out my findings here. I agree with the assessment that partial hydration can be considered a future "nice to have", but it's not because Svelte is blowing out the competition already.