Speaking not as a dev here, just as a consumer of web applications. I feel I’m often pretty annoyed by some web application’s UX. And I think this is often due to poorly implemented server-side rendering (SSR).
In this post, I want to give a few thoughts on SSR and why I think a simple single-page application (SPA) with client-side rendering (CSR) is the way to go.
With the rise of Next.js (I assume at least that is the reason) more and more web applications are fully server-side rendered.
And I get why. It is simpler. You don't have any loading states, no UI that is jumping around, and your DB access is a simple getServerSideProps away. But the UX suffers in my opinion.
Let's head over to an example of LemonSqueezy.
Clicking around on LemonSqueezy somehow feels clunky. In my perspective, this is the fault of SSR. Each time you click, the server renders the page, sends it back to the client, and the client renders the full HTML.
There is no immediate feedback for the user. So, it often happens that I click a second or third time to make sure something happens.
If you compare that with Stripe it feels much more snappier.
You click on something and as a consumer, you get instant feedback. You still have to wait until the content is loaded. But it feels much snappier.
In my opinion, if two-page switches take the same time it feels much faster if I get instant feedback instead of waiting for a whole page reload (or almost a whole page reload)
Why is SSR so popular?
I think this has two main reasons:
Next.js pushes a lot for it
It is easier
Next.js pushes for it
Once you work with Next.js you will be overwhelmed by how many ways there are to fetch data. Doing everything client-side like in a good old SPA is not the favourite option often.
This is why many developers take SSR now for granted and use it everywhere.
It is easier
The second point what I think why this is SSR is so commonly used is because it is easier. You don't need to think about loading states, error handling, etc.
Also for accessing private data, you don't need to think about APIs, API keys, etc. - hint: you still should think about securing your API.
You simply put it in your fetcher function (like getServerSideProps) and it takes care of it. In my perspective, this comes at the cost of the UX.
When should you use SSR?
Of course, there are cases when it makes sense to render your page on the server side. A good example is Hashnode.
Blog posts need to be server-side rendered because Google doesn't like client-side rendered content.
While it can read it it is often much better to have server-side rendered (or cached) content.
In general, if you have a content-heavy page it makes sense to let it SSR or statically generated during build time.
If your content doesn't change often you can make use of caching. At hashnode, we cache our content for a long period of time and only let it regenerate if something changes (e.g. title or content changes).
There are also great ways to mix server-side rendering and client-side rendering. Remix or the layout approach in the Next.JS app router are great approaches for that.
However, I think for many applications (especially B2B admin/dashboard apps) a single-page application is still the way to go. It requires often fewer resources, is simpler to build, and is simpler to deploy.