Replace hydrate and router options with csr

[Rich-Harris]

Describe the problem

At present, there are four 'page options' — prerender, hydrate, router and ssr. As of #6197, these can be set in +layout[.server].js files as well as +page[.server].js files, which allows us to get rid of the corresponding config options.

router is an anomaly, however. It's the only option that has a meaning after the initial render — if you navigate to a page with router = false, it will disable the client-side router altogether. There's no getting around it: this is a deeply weird option that basically no-one needs (to understand why it was introduced in the first place, see #6197 (comment)).

As of #790 (comment), we'll have a much more sensible approach for disabling the router — data-sveltekit-reload applied to a top-level element. This would mean we can get rid of the router page option altogether.

This does leave a gap though — right now, if hydrate and router are both false, we don't send any JavaScript with the page at all.

Describe the proposed solution

We merge hydrate and router into a single csr option that controls whether client-side rendering/routing takes place. (It's convenient that the acronym works for both.) If csr is false, no JS is sent with the page.

Strictly speaking, this is less flexible than what we have now, but having one-but-not-both be true is both kinda useless and currently buggy. This approach would be much simpler, both in implementation and communication — prerender, ssr and csr are a much more logical trio.

Alternatives considered

Keep the current semantics of hydrate and always include the client-side router.

Importance

would make my life easier

Additional Information

I'm raising this here as an issue rather than a discussion because I expect approximately three people to be affected by this change.

[f-elix]

I must say I kinda liked the idea of being able to make a website without client-side routing that still has JS interactions, but I do understand the technical complications this entails, so its probably for the better!

This is an orthogonal problem, but it would also be nice to be able to disable hydration and re-enable it further down the tree (e.g.: I don't want any js on the page except for a modal component). I realize this is probably more of a Svelte thing than Sveltekit though. Is this something we can expect in the future?

[dummdidumm]

I must say I kinda liked the idea of being able to make a website without client-side routing that still has JS interactions, but I do understand the technical complications this entails, so its probably for the better!

So you want every navigation to be a native navigation? This would be possible with #790 (comment)

[f-elix]

@dummdidumm Yes, the behavior would be the same, but Sveltekit would load the whole router code even if totally unused. export const router = false prevented that.

[Rich-Harris]

The router code, when disentangled from the rest of the SvelteKit client runtime, weighs somewhere in the region of 1.5kb plus the size of the route manifest (which is less than 3kb for an app with 200 routes, and much smaller for most apps), unless you were to include invalidate in 'router code' in which case it would be a tiny bit more. It's small enough that we just don't really need to worry about it.

[f-elix]

Fair enough! i thought it was bigger than that.