The web has been around for some time. More precisely, almost 33 years since Sir Timothy Berners-Lee implemented the first successful communication between an HTTP client and a server via the Internet in the autumn of 1989 😄. The first-ever website was nothing more than a static page that outlined how to create Web pages and explained more about hypertext. A few years later, in '93, the dynamic websites arose with the appearance of CGI (Common Gateway Interface). This was a way to let a website run scripts (usually Perl scripts back then) on the web server and display the output.
From that point on, web technologies started booming, and the ways of building websites changed tremendously. While this article will not compare different tools or technologies, its purpose is to focus on the different methods we can build websites, the examples used being in regards to Nuxt.js.
Now, for a FE (font-end) newbie, these acronyms in the title might be a bit tricky to grasp at first. Or at least that’s what I felt when I first confronted them - so I took my time to fundamentally understand what makes one different from another, yet with every article I read, I felt like I couldn't wrap my head around these two: CSR and SPA. That's because sometimes SPA was mentioned instead of CSR, and sometimes they were mentioned as two completely separate things. Well, let's establish which is what so that you won't get as confused as I was. 😄
CSR stands for Client Side Rendering and SPA for Single Page Application. CSR is the approach in which the HTML rendering is done in the user's browser, while Single Page Application is the type of web app that incorporates this approach as its behavior. So CSR is the model under which SPAs operate.
Now that I made this clear, I hope you'll understand why both CSR and SPA are used throughout this article in different contexts.
Ok, let’s take a real-life example: you are given the task of creating a web app from scratch.
I’ve created a new Nuxt.js app with the create-nuxt-app command, and it started prompting some configuration options. Let’s stop at the one asking about the Rendering mode for a second, a.k.a. the different strategies to display an interface in a browser.
“Where do you want your JS to render the HTML? In the user’s browser (Single Page App) or on a web server (Universal)?”
To come up with an answer for this question, I'll make it a bit easier by rephrasing it so that it answers itself depending on the requirements needed for the app.
Aaaand drumrolls, please! 🥁🥁🥁
A. Not important => CSR is the way to go.
If you need strong SEO features, then client-side rendering is not your best option.
As stated earlier, with the creation of popular frameworks such as Angular.js and Vue, having the route creation and manipulation being done in the browser was quite a mind-blowing alternative to the former way of URL handling, that being the classic page refresh happening with each user action (good ol' PHP days).
Imagine nowadays having to refresh your page every time when you post a comment or hit the like button! 😅
So by dynamically rewriting the current web page with new data from the web server, the Single Page Applications now have smoother transitions between pages and feel almost like a native app. Ok, now what about the SEO?
Also, the website might get penalized by Google if there is a lot of processing on the main thread (think about downloading, parsing, and running all the Js in order for the HTML to appear on the page).
Last but not least, the performance may cause a nasty UX impact since the entire rendering happens on the client-side, so it relies solely on the user’s device capabilities and computing power. Of course, some devices are powerful enough and can handle this kind of processing, but there are still a lot of devices like cheaper phones or simply… slow internet speed .
So now that the cons of CSR have been stated, let’s see what its strengths are:
1. Development speed
When working entirely on the client side, we don't have to worry about the server compatibility of the code, for example, by using browser-only APIs like the window object.
2. Hosting costs
Unlike traditional HTML pages, which need to refresh or re-render an entire page, client-side rendering simulates different pages but loads them on a single page. This puts less pressure on memory and processing power, which gives you quicker results than server-side rendering.
B. SEO is very important => Universal mode is your choice.
A. SSR (Server Side Rendering)
Contrary to CSR, SSR returns a fully rendered HTML page to the browser because the Vue.js code has already been run in a server environment. When the browser requests the URL, the HTML document is immediately visible, despite not being interactive. Making a static page interactive in the browser is called hydration, and this is the step in which the browser loads the js code that runs on the server in the background once the HTML document has been downloaded. The browser interprets it again, and Vue.js takes control of the document and enables interactivity.
Therefore due to SSR, we now have rendered content for the SEO crawlers to index, and even more quirks, such as displaying the preview of the page that is being shared on social media platforms, all while still having dynamic interfaces and page transitions. On the other hand, there are some SSR caveats that need to be taken into account:
1. Hosting costs
2. Slower time-to-interactive
Your user will see the content sooner, but if they click on something, nothing will happen.
3. It’s incompatible with some UI libraries
If the UI library uses window or document objects, then you will need to fix that or use something else because the web server doesn’t have window or document objects. So, for example, when you use the window object to know the size of the user’s screen, then you should use some solutions which depend on the type of framework you use with SSR (Nuxt will throw hydration errors in the console).
B. SSG (Static Site Generation)
This fits best if you do not need a dynamic website - with no user-specific content, meaning every user sees the exact same thing: no login, no actions that allow sending input data to the server - everything is “read-only”.
Here’s an image of the nuxt-generate command bundling a Nuxt application for production and exporting your application to static HTML in the dist directory.
In conclusion, neither of these acronyms is a fix-all solution. You need to assess your website’s technical needs and challenges before implementing it.
To sum this article up, I’ve noted down the essential ideas behind each rendering option:
The SSR approach is good for building complex web applications that require user interaction, rely on a database, or where the content changes frequently, and the user needs to see real-time changes while also catering for SEO. The downside would be the server maintenance costs which need to be considered.
The SSG approach is good for building low-cost applications in which the content does not change too often — sites whose content does not have to change depending on the user and don’t have user-generated content. An example of such a site would be a small presentation site or a landing page.
The CSR approach would be the way to go for an app where you don’t need to care about SEO scores or Google indexing. Yet you need to serve a more complex UI/UX where users can navigate between pages without having to make a server roundtrip (definition of SPA). All this while having the possibility to host your application on any CDN or static file host like Amazon S3 or Netlify for free or very cheap.
Stay up to date with the tech solutions we build for startups, scale-ups and companies around the world. Read tech trends and news about what we do besides building apps.