Gray Area on When to use Different Rendering Modes CSR, SSR, SSG
Introduction:
Over the past years, We had base pure Front-End frameworks like React, Angular, and Vue, all of them provide client-side rendering(Single Page Application), then we discovered our needs for different renders modes. We had different renders modes and different frameworks support each one of them, but the problem many developers can’t quite wrap their head around when to build an app as a pure SPA and when it’s better to use an SSR or SSG.
It’s clear that there is no sense to use an SSR framework for building a todo app, as it makes no sense to build your blog as pure SPA, or maybe there is? This is the thing. It feels that there is a gray area on when to use what. which approach would be the best to use for building an app?
So we will explain in this article:
1- Each Render Mode and the strong, weak points
2- when to use each one of them
3-Frameworks for each render modes
Please follow Me over Medium, to get a notification about my new articles. I’m active on Twitter @IbraKirill.
Client-Side Rendering
Client-side rendering, or CSR, is the most common way of rendering React, Angular, Ember.js, Vue…. apps. With a client-side rendering solution, The server renders a blank page with a script tag pointing at the app’s bundle. The blank page is sent to the client browser, which starts to run the app, compile everything, and then makes whatever API calls it needs to and renders the contents of the page.
Strong Sides:
· Fast on the server: Because you are only rendering a blank page it’s very fast to render.
· Supports Single Page Applications: Client-Side Rendering is the only model that supports Single Page Applications or SPAs.
Weak Sides:
· No initial render: You are sending a blank page to the customer. So if your app is big, or the customer is on a slow connection, that’s going to be less than ideal.
· Security: Compare to the traditional page Single Page Application is less secure due to Cross-site scripting (XSS).
· Memory Leak: Memory leak in JavaScript can even cause a powerful system to slow down.
· Being empty <body> means there will be not content to crawl the data for a search engine, so SEO is the biggest weak point here especially if you want many users to reach your web app.
Server-Side Rendering:
is the ability of an application to contribute by displaying the web-page on the server instead of rendering it in the browser. This means if you have an application that is server-side rendered, your content is fetched on the server-side and passed to your browser to display to your user. With client-side rendering it is different, you would have to navigate to that page first before it fetches data from your server meaning your user would have to wait for some seconds before they’re served with the content on that page. Applications that have SSR enabled are called Server-side rendered applications.
The Server-side sends a fully rendered page to the client; the client’s JavaScript bundle takes over and allows the SPA framework to operate.
Strong Sides:
· Content immediately available: Because you are sending rendered HTML to the client who will start to see content almost immediately. Content is up to date because it fetches content on the go;
· No additional client fetches: Ideally the server rendering process will make all the required calls to get the data, so you won’t be making any additional service calls from the client. At least until the user starts to play around with the page a little. your users’ devices have little relevance to the load time of your page.
· Great for SEO: Search engines like HTML content. If you are using client-side rendering only then you are counting on search engines running your Javascript, which may or may not happen, but here crawlers of search engines will fetch your content faster and easier.
If you want to Dive into Server Side Rendering with React, I advise you with the following course.
Weak Sides:
· Slower on the server: You are rendering the page twice, once on the server, and once on the client. You are also probably making service calls from the server to render the page. All of that takes time so the initial send of the HTML to the client could be delayed.
· Incompatible with some UI libraries: If the UI library uses window or document objects then you are going to need to fix that or use something else because Node doesn’t have window or document objects, example when you use window object to know the size of the screen of the user to render specific components, then you should use some solutions which depend on the type of framework you use with SSR.
I advise the readers for courses with online degrees from European universities, many of them are free.
Static Site Generation
is a software application that creates HTML pages from templates or components and a given content source. You give it some text files and content, and the generator will give you back a complete website.
OR Easier Description:
Static Site Generation is like Server Side Rendering with the exception that you render the pages at build time instead of at request time. this means is that your site pages are generated at build time and your site content does not change unless you add new contents or components and “rebuild” or you have to rebuild your site if you want it to be updated with new content, or some developers make cronJob to rebuild again every period of time ( schedule a deploy to happen every 24h) to catch any new components changes or updated data from the database.
Strong Sides:
· Fast website: Since all of your site’s pages and content have been generated at build time, the client will start to see content almost immediately. Plus, you do not have to worry about API calls to the server for content and this makes your site very fast.
· No additional client fetches: Ideally the server rendering process will make all the required calls to get the data, so you won’t be making any additional service calls from the client. At least until the user starts to play around with the page a little.
· Great for SEO: Search engines like HTML content.
· Security: Statically generated site is solely composed of static files, the risk of being vulnerable to cyber attacks is minimal. This is because static generated sites have no database, attackers cannot inject malicious code or exploit your database.
· No Server: You don’t have to run a server. So you don’t need to monitor that server and you are going to get far less pager duty pings.
Weak Sides:
· Can be slow to rebuild large sites: · Build time would increase depending on the size of the application.
· Incompatible with some UI libraries: If the UI library you like uses window object then you are going to need to fix that or use something else because Node doesn’t have window or document ob.
· Content can become stale if it changes too quickly, to update its content, you have to rebuild the site.
When to use what:
It feels that there is a gray area on when to use what, so let’s solve this gray area:
It depends on the type of your web application, what are requirements for it, As Example, I have a dashboard Admin panel for an E-commerce website, specific users who are responsible for an E-commerce website will use the dashboard, do you think they need SEO or external users to reach dashboard, So Single page application (CSR) is a good option for these kinds of applications. If your experience requires a login to view the content and it’s customized per user (e.g. Settings Pages, Bank Accounts, etc.) then Client-Side Render is appropriate.
Static Generation and Server-side Rendering are two forms of pre-rendering. Prerender means that Framework generates HTML for each page in advance, instead of having it all done by client-side JavaScript. It is better with performance and SEO
The SSR approach is good for building complex web applications that require user interaction, rely on a database, or where the content changes very often. This is because content on these sites changes very often and the users need to see the updated content as soon as they’re updated. It is also good for applications that have tailored content depending on who is viewing it and applications where you need to store user-specific data like email and user preference while also catering for SEO. An example of this is a large e-commerce platform or a social media site.
The SSG approach is good for building applications that the content does not change too often — sites that the content does not have to change depending on the user, and sites that do not have a lot of user-generated content. An example of such a site is a blog or Public content or a personal website.
SEO is a major requirement: If your pages need to be traversable by search engines then use Server Side Rendering or Static Site Generation if it fits the model.
Big Note: SSR is (unless cached) requested to a server on each render but SSG is requested on the build. You should ask yourself: “Can I pre-render this page ahead of a user’s request?” If the answer is yes, then you should choose a Static Site Generation.
Example: in SSR: the user request page domain.com/students so request goes to the server and get data of this page, but SSG it is only one static build version so each time user gets this page from static build version.
Frameworks for each render modes:
For React-based developers: NextJs support SSR — SSG, and GastbyJs , react-static for SSG.
For Vue-based developers: NustJs supports SSR — SSG, and Gridsome, vuepress for SSG.
For Angular based developers: Angular Universal supports SSR, and scully for SSG.
Conclusion:
Different Rendering Modes are great tools for different types of web applications, Many developers face grey area on when to use what. In our Article, we figure out when to use each render mode, and now the grey area becomes white area, I hope :) :).
I hope I added value, If you enjoy reading the article and want to support me as a writer, you can buy me a coffee!
If you want to Dive in and learn NextJS, or Gatsby, or Nuxt.JS Vue, or GridSome Vue from scratch, I advise you to choose one of the following Courses:
NextJS Bootcamp Course, The Gatsby Masterclass Course, Nuxt.js — Vue.js Course, and Blazing-Fast Vue and GraphQL Course.
If you want to Dive into React 18 with practical examples, I advise you with the following course.
If you want to Dive into Best Practices Patterns in React. I advise you with the following Course.
