Site Rendering - CSR, SSR & SSG explained

Alex Cerda — Tue, 11 Jan 2022 20:44:07 +0000

Once upon a time all websites were static. We would have simple websites with minimal dynamic content, so the server would load up a HTML page with CSS and some basic JavaScript for the client to display, without too much trouble...😬

Nowadays, we desire a lot more complex & high performant websites with not only good search engine optimisation (SEO - so Google can easily return our site when a user searches for it) but also fast and responsive load times ⏰.

There are 3 main technologies in which websites can be rendered, oftentimes easily confused, but no fear - after this article you'll be a site rendering connoisseur 🚀

Client-side rendering (CSR)

First off, we have CSR, which arguably is the most different of the 3.

Client-side rendering is used by the most popular JavaScript frameworks that we all know and love, such as React, Vue.js & Angular. In such websites, the heavy lifting is done by the client (surprise surprise) or browser - whichever term you prefer to use.

The browser essentially receives an empty HTML file and JavaScript is in charge of putting together the content of the page. Once the page has been put together, what is dynamically shown on the page from then on is also determined by browser JavaScript, as opposed to a server sending up a fully rendered dynamic page (which we will get to soon!). Seeing as the browser assembles the page, loading times tend to be a little longer in this type of website. But after the initial page load, it's super fast to handle dynamic content as everything that is needed to be done (such as making any API calls) is done within the browser!

Single-page applications (SPAs) are an example of client-side rendering, where the initial request serves up a single HTML file and all other DOM page structures are manipulated by the client. Our handy tools like React & Vue.js are perfect for creating SPAs 😇

Server-side rendering (SSR)

Next up we have SSR, where the heavy lifting is done by the server (shock!). In these websites, the user makes a request for a page, the server listens to this request and composes the page with HTML, CSS & JavaScript. It then sends up a fully rendered page to the browser. This means the initial page load is fast but every subsequent request for dynamic content requires the server to put together the page all over again, so it can be slower than CSR after this point.

However, note that SSR websites are great for search engine optimisation. Crawlers can easily deduce the content of the page as it has already been rendered before being sent up the wire.

Static site generation (SSG)

Finally we have SSG. Similarly to SSR, SSG involves pre-populating the page with content so that when the user loads the page, a fully rendered page is served. The key difference between SSR & SSG is when the page is put together. In SSR the page is put together by the server. In SSG the page is populated at build time. All API calls required to populate the page with content are made at build phase, cached and then deployed to a static hosting service like AWS S3 or Netlify. In SSG websites, no server is needed to render your page! 🤯

Tools such as Nuxt.js or Next.js are perfect for SSR & SSG

For SSR: In these frameworks, the websites are loaded on the server and the data is brought into local browser state, which can then be easily manipulated on the client, reducing load times.
For SSG: Nuxt.js & Next.js give the ability to statically generate your website, packaging it up into static files ready to be deployed to your hosting service of choice. Any pages that have been excluded from site generation will typically fall back to an SPA and be rendered on the client.

And that's all folks! 🎉 I hope after reading this, you'll understand the key differences between SSG, SSR & CSR. And of course, if you have any more questions, please don't hesitate to contact me in the links below! 😊👋

Twitter || GitHub

Coding for Beginners: VS Code, CLI & Version Control

Alex Cerda — Thu, 17 Sep 2020 21:37:06 +0000

I’ll begin by giving an overview of 3 key tools we’ll be using. After I’ve defined them I’ll give you examples of how to use them together!

(BTW I’m a Mac OS user, so if some commands aren’t the same for your operating system, please give it a quick Google!)

1.1 Visual Studio Code
1.2 The Command Line Interface
1.3 Version Control
1.4 Putting this all together

1.1 Visual Studio Code (VS Code)

First things first, we need somewhere to write your code! Visual Studio Code is my favourite source code editor (or Integrated Development Environment if you want to use the fancy term) and it’s free 😍.

It provides various inbuilt tools that we’ll be needing, so go ahead and click here to find out how to install it.

1.2 The Command Line Interface (CLI)

Next, I’ll talk briefly about the CLI. At a simple level, it is a window where you can write commands that tell your computer to carry out some actions, for example, to create/modify some files or initiate some process. Each operating system has its own name for this (eg. for Mac OS it’s called Terminal) but don’t worry about this as VS code provides its own CLI and that’s what we’ll be using (we can begin to see why I’m a fan of VS code!).

1.3 Version Control (Git)

Developers need a way to track their code. Of course, you could save a new version of the same file every time you changed it juuust in case you wanted to go back to a previous version at some point in the future, but that’s just super inconvenient and you’d end up with hundreds of files! Not to mention if you’re working in a team. So that’s why version control was born, and in particular we’ll be talking about the most popular one called Git (interesting name right 😅?).

Install Git from here.

1. 4 Putting This All Together

Go ahead and open up VS code, then click Open Folder.

Make a new folder, call it something fun, select it and click Open.

You should now see on the left hand side the first icon is selected, with the file view open. There are no files in there at the moment so it’s empty.

Now let’s open the command line. Click the triangle in the left-hand corner, followed by the Terminal tab.

Now you have the command line open and it’s pointing to the folder you just made, great!

Let’s tell Git who we are. Paste these commands into your command line then set a username and email (choose your own here):

>> git config --global user.name "your_username"
>> git config --global user.email "your_email"

Now let’s initialise Git:

>> git init

We’ve now added version control tracking.

Add some files via the command line using the touch command.

>> touch file1.js file2.js

Hit enter and you should see your left hand file view with two empty JavaScript files!

Note, the U next to each file. This stands for Untracked. Git has recognised that we have added two new files, that we haven’t yet committed to track. If you click on the 2, we can see our version control in more detail!

So, how do we tell git to track these files? There are two steps to do this. First we must git add the files, so Git knows which files we want it to track. Then we git commit the files, along with a short message explaining what the changes for this commit are. We can add/commit either via the command line or with the help of VS code to do this for us under the hood. BTW we can’t commit without adding some file first!

1. Via the command line

>> git add .
>> git commit -m "Add my first javascript files"

Note: The . here means all!

2. Via the VS code version control tab

Whichever way you did, if you now check the git log via the command line, you should see your first commit has been logged and the files in the version control tab have been cleared!

Congratulations! You’ve completed your first git commit 🥳

Now, if you go back into file view and open up one of the files, type something in the file and hit Save.

You should see a little M which stands for Modified. Git has recognised something has changed in the file, so you’d have to commit again if you want to clear that notification!

Some Caveats

We’ve just been looking at Git locally. This means that only our computer currently knows about our Git tracking. We can use Git to track files remotely so other people can access our versioned code, via the wonderful GitHub for example. We would similarly use add/commit as we have done here, but we will also have to git push our changes to some repository (which is essentially a folder of all of our code) for other developers to see. We will have to git pull other people’s changes too if we want to see their changes locally. But don’t worry about this for now, we will return to these terms in some future articles!👾

Hope this helped some of you aspiring coders set a foundation for what’s to come! And of course, if you have any questions, please feel free to give me a message 😌