Add appendix regarding different rendering methods

[benmccann]

This is one piece of background that a lot of new users seem not to have a good understanding of. While we assume a background in HTML, CSS, and Svelte some discussion of rendering might be warranted since SvelteKit at its core is a rendering engine. It helps explain what SvelteKit is, how it's unique, and the value it provides.

This closes #1508 which inspired this PR as a possible alternative way of covering this info. Also closes #1397

[SumitBando]

The intro text explaining the key concepts will be very valuable for new users.

The intro text reflects a bias towards SSR being generally superior.

SSR is clearly superior / only choice for devices without modern JavaScript.
Other than that, it depends.

On #1508 you wrote: 'Instead of making a single round trip over the internet to the backend server, you are more likely to have to make multiple round trips over the internet to render the page'.
For many years complex applications use a backend-for-frontend pattern, so that each page / refresh uses a single purpose-built API call. With the widespread adoption of GraphQL, everybody who needs it, does so.

If the prerendered pages are already cached on the client, APIs have to do less work and transmits fewer bytes. So SSG+CSR wins.

You say 'SSR is generally better for SEO'
SSR is only superior against somebody rendering static pages on the client through APIs.
This is solved by fully prerendering static SEO pages.
SEO does not apply to post login dynamic pages.
So the correct statement is 'SSG is best for SEO'

It is great that SvelteKit now allows per page SSG.
I expect people will use SSG everywhere possible, and SSR or SSG+CSR as appropriate.

The SSG style was critical for building our app as PWA, since the device may not be able to reach the SSR servers when needed. Pre-rendered pages are cached on device, app is mostly functional offline, and syncs with backend when connected.
A reference to PWA somewhere may be useful.

[benmccann]

On #1508 you wrote: 'Instead of making a single round trip over the internet to the backend server, you are more likely to have to make multiple round trips over the internet to render the page'. For many years complex applications use a backend-for-frontend pattern, so that each page / refresh uses a single purpose-built API call. With the widespread adoption of GraphQL, everybody who needs it, does so.

Not sure if it really matters unless it's being added in the text here, but even with GraphQL you'd probably still end up making more round trips than a traditionally SSR'd page: once to get the HTML, once to get the JS, once to make the API call

If the prerendered pages are already cached on the client, APIs have to do less work and transmits fewer bytes. So SSG+CSR wins.

It's rare that you could cache the whole page such that you'd avoid API calls, but in the case that you could do this you could cache the page with any rendering solution so it's not a point in favor of one approach over another.

So the correct statement is 'SSG is best for SEO'

It would be basically equivalent to SSR, but I don't expect it'd necessarily be much better unless there's something I'm overlooking

[SumitBando]

Not sure if it really matters unless it's being added in the text here, but even with GraphQL you'd probably still end up making more round trips than a traditionally SSR'd page: once to get the HTML, once to get the JS, once to make the API call

It's rare that you could cache the whole page such that you'd avoid API calls, but in the case that you could do this you could cache the page with any rendering solution so it's not a point in favor of one approach over another.

My observations (the submitted PR) were not theoretical, but based on happy results building a PWA with Svelte, designed to work offline.
The statically generated html+js are cached by ServiceWorker.
If online, each page typically needs a single API call, the payloads are small compared to html/css.
If offline, works off of localStorage when viable.

[Rich-Harris]

This is a lot of content to have before the 'getting started' block — the introduction should really be just that, people shouldn't have to scroll through multiple screens before they see npm init svelte@next my-app.

I'd argue it's also a little confusing to have

The core of SvelteKit provides a highly configurable rendering engine

so soon after

SvelteKit is a framework for building extremely high-performance web apps

Perhaps it would make sense to have a separate 'terminology' or 'glossary' section at the end?

[benmccann]

Thanks for the review @Rich-Harris. I've updated it if you've got a chance to take another look

[changeset-bot]

⚠️ No Changeset found

Latest commit: b22160e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR