Prerendering documentation clarification

[benmccann]

The docs say:

In other words, any app that involves user sessions or authentication is not a candidate for adapter-static, even if individual pages within an app are suitable for prerendering.

This is perhaps not quite precise enough and was causing some confusion on Discord. E.g. one user said they wanted to do anything involving auth in onMount. There was also a question of whether this restriction still exists with ssr and hydration disabled

[johnnysprinkles]

Ah that was me! Yes I wanted to represent the runtime-agnostic, serve from non-Node, static SSR camp, where all upstream service calls are made from the client. In this scenario pre-rendering is per route and a parameterized route would just have nothing for the parameters from the server's point of view.

The other issue is how to pre-render each route multiple times with varying parameters (not request-specific parameters obviously, but other more static dimensions like language).

Quick summary of the angle I'd be coming from on this, which I also posted in the discord channel. https://docs.google.com/document/d/1gqleERm2L6zD6HR4VcBCn19Q9Q6t9hdb3b-7_--08iI/edit

[SumitBando]

The "When not to export" verbiage is carried over from Sapper days: https://sapper.svelte.dev/docs#When_not_to_export
Undaunted by the undersell by @Rich-Harris , we went ahead and built a multi hundred page, authenticated, personalized mental health web app, exported and served out of CDN , in production.

My motivation was not having to deploy / maintain / secure NodeJS servers and pay AWS more for SSR.
Our SSR happens during build/deployment on Netlify or Github servers, I see some people refer to this as Static site generation (SSG).
The fact that the CDN servers, physically close to my users, start delivering pages, instead of SSR servers in Oregon means Time-to-first-byte is phenomenally better.

I submitted the PR without knowing the existence of this open ticket.
I will refine the PR to address the review comments.

[johnnysprinkles]

That's cool to hear @SumitBando. I think this issue relates to the new issue I filed, #1533. Your motivation is not paying for Node servers, mine is that at my workplace they literally don't allow us to run Node at runtime in production. Too many bad stories about malicious NPMs I guess.

Your multi-hundred page app actually aligns with my use case. At the moment I'm dealing with a separate issue -- I'd like each of my several hundred routes to have a bespoke tree-shaken single-file JS bundle just for it. Right now if I add something heavy like some D3 stuff, or momentjs, to one page it seems to inflate the vendor bundle that all the pages share. I guess it would be fine to have chunks, given that we're in an HTTP/2 world, but really just need to split it up better.

I see some "mutli page" support in the Vite docs, but I don't think SvelteKit really does that yet. Still exploring...

[johnnysprinkles]

I think my last comment was off topic, but for more about that if you're interested, see #1571