What are SPA, SSR, and SSG?

Introduction

With the growth in SPA over the last few years, using frameworks like react,(react is a library?) the web has become less performant and not SEO-friendly

What is a SPA?

SPA, or Single Page Application is a method of creating Javascript application, which on calling the domain url gives the browser back a bundle of JS assets. These assets run on your browser like vanilla JS, giving you the illusion that you are running a multi page application with routing and other features which isn't true.

Problem with SPA

1. No real routing - When you open a route in the SPA application, no real routing happens, instead the JS on your browser checks the window.location and renders the view which your application dictates This is how it works in react-router. This can be a problem if you are trying to generate a sitemap for your website, as no real routes exist and making sure a direct route access doesn't break stuff requires unnecessary amount of rewiring in the application.
2. Slow load times - The load time can be slow because there is first a download phase(i.e. server responding with JS assets) and then a render phase(converting those JS assets into HTML and CSS to be visible) which both happen after the client's first request.
3. Not SEO friendly - Search engines work by employing crawlers, which look into the webpages and create indexes of those webpages by assigning them relevance rank based on the keywords and key-phrases. The problem with SPA is the crawler's can't(or more accurately won't) render the javascript while crawling into them. Which means they won't be able to discern the relevance and accessibility of the webpage, among other important metrics. This means your web app will not show up in the google search, or more likely not show up with the complete details present in it.

How to tackle this?

Many ways have come up to tackle this problem, namely - SSR, SSG, and MPA. MPA frameworks like Astro.build deserves its own shout out, so I will keep my focus to the first two only.

---

Server Side Rendering(SSR)

What is it?

Server Side Rendering, is exactly what it sounds like. It renders the code on the server rather than passing it to the client to render. This means the javascript will run on the server as if it were a browser, and then the generated webpages will be sent over to the client. This fundamentally solves the problem by hiding it from the client, but it has its own perils.

The pros

1. Faster loads - The rendering can happen on a powerful server which would reduce the render times for large applications hence improving the overall speed of the application, even improving Web Performance
2. Real routing - The routing which happens this way is more real routing(well kind of) than SPA because when the route query is made to the server it evaluates and renders the relevant only assets, unlike SPA which gives all the assets all at once.
3. Hidden application logic - You can query your database directly from the application logic and that can get hidden away because assets are only exposed to the client post rendering. Which means any logic which you would like to bury in the server side of things can be done more easily and make the code more coherent.

The cons

1. Memory intensive - The application which would've been rendered in the browser will now be rendered in the server, which will make initial load slower. This also means, that memory intensive tasks like rendering will now be performed on the server making your application consume a lot more memory.
2. Hydration hell - Since their is no real browser in the server, and it is just pretending to be a browser to generate the assets their will very often be render mismatches, i.e, what the server renders will not be same as what the client renders. To tackle this problem, most SSR frameworks will use a technique called hydration, where after loading the assets they will re-render the assets in the client (usually in the background), and then compare the two results. If they mismatch, it will be a hydration error. This can lead to confusion on which render to pick since, this choice can vary from situation to situation.
3. No stateful rendering - The server should never hold any states about the users. For eg - AuthN/Z tokens(or cookies) should live on the browser and server should only have the responsibility of verifying if these are valid or not. But what should happen if your client renders differently based on presence of these tokens? One simple example is on some social media platforms you will get to see the full content once you are logged in but not otherwise. You might see extra information on a page if you are the owner of that page. How should the server render this page without actually having the relevant information? Either by passing the tokens for every render request(making the process more expensive and slow) or by not doing this at all, i.e., falling back to client side rendering.

---

Static Site Generation(SSG)

What is it?

Static Site Generation, is the process of generating static assets from the JS code at the time of building. This means all the JS code will be converted to HTML much before any requests might come to the server. This process is wonderful but with its own cons.

The pros

1. SEO friendly like SSR - In terms of being SEO compatible this might be equal to SSR, if not better
2. Better load times - Unlike SSR the loads are not happening on the fly when a request arrives but instead happening during the build meaning the server has to only send the static assets, which can be sent via a CDN for great load times.
3. No hydration - Because of build time rendering the actions are more predictable and free from hydration issues.

The cons

1. Extremely slow build times - Since the rendering is happening during the build time, it can end up slowing down the build process to a great extent.
2. Revalidation issues - The problem of rehydration is now replaced with revalidation, which is, the application now needs to keep track if there has been an update in the codebase, and redo the build process if yes, add slow build time to this and it becomes a nightmare to maintain. Their are techniques like ISR(Incremental static regeneration) to tackle this issue but they make the development cycle prone to more bugs.
3. Stale render state - If you updated your codebase, their will be a time window between that to your changes getting built to the next validation check event from the client until which, the client might see an old version of your application.

---

Conclusion

There is no one technique to rule them all, and each process has its own pros and cons. This articles aims to help the reader make a better choice when choosing the tech stack for their next project and be aware of the problems which exist with each of the technique.