Rich Harris explains why SvelteKit pushes for Server Side Rendering (and against SPA / CSR)

Since I began my journey into headless / jamstack concepts and modern javascript frameworks, rendering modes were always a tricky part to get my head around. There is for example this informative, but possibly difficult to understand comparison on web.dev/rendering-on-the-web/:

I totally get most aspects technically, but the real question is: "How should I build my web app?!?!". #DecisionFatigue 🤯😉

Therefore it was super interesting to hear Rich Harris, creator of Svelte(Kit), reacting to this topic. He collected questions in a reddit thread called "What frustrates you in using Svelte?" and answered some of them in his talk at SvelteSummit (great format!).

Just for context beforehand - a simplified version of my personal journey:

• In regards to Sustainable Web Design I initially had the goal to use "full Static Site Generation (SSG)". This works fine for many use cases - but I also learned that this has its own challenges, e.g. on a site with > 1000 blog posts.
• The next mode which is easy in regards to hosting the final site is the Single Page Application (SPA) mode. This is essentially a page placeholder with some (rather big) .js files which will do all the data fetching and page generation after page load (= CSR = Client Side Rendering). While many hate these "SPA monsters", they sure are easy to deploy: Just upload the html file with the .js files.
• And there is server side rendering (SSR) which requires a (sometimes pricy) special webspace provider with NodeJS support, e.g. Vercel, Render, etc. Or you need to use a Virtual Private Server with NodeJS (which can be managed via cleavr or - as I learned recently - LaravelForge).

Here is the question which resonated to me because I was always somehow sceptical about Server Side Rendering (SSR) because of the hosting requirements (and costs):

It's a sveltekit thing, but I really dislike how heavily SSR is pushed. Search engines do actually run JS so CSR isn't a big deal for SEO, and the slower first page speeds do negatively impact googles search rankings. And to turn it off I need to write a hook function and install an adaptor. It's not very ergonomic.
To be fair, Next.js also heavily pushes SSR because it's maintained by the folks at Vercel.

Here is the insightful reaction of Rich Harris at 4:50:00:

So, quick notes about this, according to Rich Harris:

• Don't use SPA unless you have a very good reason
• Advantages of SSR:
  • google search bot does run javascript, but this process is less reliable (and happens less frequently) than pure HTML scanning (without javascript) => server side rendered content will be indexed more reliable and more frequently
  • SSR is good for performance, data can be fetched instantaneously
  • resilience: javascript can fail for various reasons client side, because you don't have control of how it is executed

Thanks to this I do understand the push for SSR better and it sure has advantages as well. Most noteworthy is the advantage that we would never have to discuss SPA monsters again in future ;-)

More resources about this regarding SvelteKit:

• SvelteKit adapter node for SSR
• SvelteKit appendix for all rendering modes
• SPA mode docs in adapter-static (with warning)

Important: Single Page Application (SPA) mode should not be confused with Static Site Generation (SSG) via adapter-static. SSG wasn't mentioned in the talk, but seems fine (with some limitations) according to https://kit.svelte.dev/docs/appendix#ssg:

Static Site Generation (SSG) is a term that refers to a site where every page is prerendered. This is what SvelteKit's adapter-static does. SvelteKit was not built to do only static site generation like some tools and so may not scale as well to efficiently render a very large number of pages as tools built specifically for that purpose. However, in contrast to most purpose-built SSGs, SvelteKit does nicely allow for mixing and matching different rendering types on different pages. One benefit of fully prerendering a site is that you do not need to maintain or pay for servers to perform SSR. Once generated, the site can be served from CDNs, leading to great "time to first byte" performance. This delivery model is often referred to as JAMstack.

But as already mentioned it has some challenges and some use cases are easier to solve with SSR.

Would be interesting to look into SSR vs. SSG (and all the variations of these modes, e.g. prerendering) in regards to #SustainableWebDesign. 🌱

To be continued ... Please let me know if you have interesting resources about this as well!

PS: There is also a recent episode on the Changelog podcast, didn't listen to it yet: Were SPAs a big mistake? and some insightful links in the latest JAMstacked newsletter #55. In regards to web accessibility Manuel Matuzović wrote a summary: https://www.matuzo.at/blog/2023/single-page-applications-criticism/.

New resources:

• Deploy SvelteKit with SSR on Coolify (Hetzner VPS)
• Host SvelteKit apps with SSR-support via ploi.io (on Hetzner Cloud)
• Hosting SvelteKit as SSR on mittwald SpaceServer

Comments

[Matthias Andrasch]

Saw this tweet today as well: "Client side rendering is still pretty good. Don’t let the server components hype make you think you need them for everything. If you’re building a highly interactive app (you could see it being a native app) e.g. Figma, Spotify, Google Drive, etc., CSR is fine and way simpler!
(All for new techniques btw! I think it’s good to be super clear what use cases new tech is good for and what the tradeoffs are too. 👍)" twitter.com/devongovett/status/152...

[Matthias Andrasch]

Also a good addition:

"SPAs were the solution to missing browser features. Now that new functionality like the Shared Element Transition API is developed, they might become less important."

twitter.com/stefanjudis/status/152...