Hydration speed up

[lastonoga]

Hey, guys!

I did a work to speed up hydration step (https://github.com/sexy-framework/sexy).
And i got really good numbers (better then NuxtJS in 4.5 times and Sapper in 10 times)

And i can try to help you with it.

To make really cool FID and TTI we need to skip first hydration.

First "DOM hydration" is made by SSR, then on client side we only need to register subscribers on reactive variables and skip DOM work:

• innerHTML
• nodeValue
• setAttribute
• classList and etc

All of that we need to skip.

As i know Svelte doesn't skip it. Am i right?

[benmccann]

Yes, I agree 100% and suggested the same here: #4975. There's also #4308, which has a PR, but I think still does too much work

In any case, I think this issue should probably be closed because it's an issue in Svelte (not Sapper) and there are already existing issues tracking it

[lastonoga]

@benmccann Looks like svelte maintainers don't want to make fast hydration...

[slimboyfats]

@lastonoga Why do you think that?

[lastonoga]

@slimboyfats First, because PR was ready 5 months ago. And second, bad performance makes me to not use Svelte even if i like it.

Thats why i made my own framework with super-fast hydration. I don't want to create bikes but what else can i do? Vue/React/Angular are very slow.

[slimboyfats]

@lastonoga But the PR isn't closed so I don't find where it's denied, can you link?

[lastonoga]

@slimboyfats It's not denied. Simple performance question is under discussion for 5 months and thats a problem for framework progress. Vue will make new version in 6 months and it will be faster then Svelte for sure. And svelte will loose market. I did framework that has 10x faster hydration then Svelte, but has same features. It doesn't look like a problem to accept a PR.

[slimboyfats]

But I read in the issue that it might be breaking changes and that is a major thing to do.

[antony]

@lastonoga It's not a race to beat Vue, and Svelte doesn't have bad performance. this Issue is raised on the wrong project, and duplicates existing issues. Furthermore, we don't just shove in every performance enhancement, as, has been made evident in the last few days, most of them have huge glaring issues which would regress various features of the framework.

We will happily accept properly considered PRs which are well written, tested, and consider every aspect of the impact of the code changing including breaking existing users of the codebase.

One of the best bits about Svelte is it's simplicity, and the care taken to provide the optimal DX, instead of hammering it for performance, breaking various existing scenarios, and shifting CPU cycles to the browser, when it's already significantly faster than most other things out there.

If you can't raise issues in a neutral manner without a pressure-driven doomsday scenario because we haven't acknowledged and merged your framework into ours within 24 hours, then it might be better to not raise them at all.

[lastonoga]

@antony

I think there is a problem with misunderstanding. Let's start from the beginning.

1. I need a reactive framework with fast hydration (vanilla/jquery like)
2. I did my own to test how big are feature limitations and there is no limits
3. I don't want to make bikes and start from scratch, thats why i want to help Svelte be faster in hydration. And question is how can i help? If PR is not ready, so how i can help to make it ready?
4. What is the biggest problem with preventing re-rendering on client-side?

[antony]

@lastonoga from what I understand, the reason that we haven't made this change to hydration is that Svelte doesn't make any guarantees about what it is hydrating. Svelte will accept html from anywhere and try to hydrate it, and as far as I understand, solutions like yours require a concrete guarantee (as other frameworks) of DOM structure.

So whilst it'd work in the perfect case, it'd basically break all other cases of hydration.

[lastonoga]

@antony Got it. What about to add to svelte compiler an option like hydrationDomCheck? If flag is true then developer takes all responsibility on his own (about DOM matches guarantee). Without checking First input delay will be better.

Otherwise, svelte re-render DOM as at is now.

[antony]

@lastonoga it's a possibility, I don't know the exact ins-and-outs, but it probably could be a compiler option.

None of the existing PRs implement it as a compiler option currently, though, they're all-or-nothing.