SSG vs SSR vs SPA: What Does It All Mean?

Learning web development isn't just about HTML, CSS and JavaScript.

No, it's also about understanding how the web works and, to a certain extent what got us here.

There has been a real push in the last couple of years to bring back and rely on some older, core technologies of the web. We are hearing a lot of discussion of technologies that seem new but are really just a fantastic modern implementation of tried and tested approaches that have been around for a long time.

In this post we are going to explore static sites, server side rendered sites and single page applications and how they fit together in the coming years.

Browsing the web

When you type a url into your browser address bar you are saying “hey, whatever thing lives here …. I want it”

What is returned is a stream of data with some clues to tell your browser “what” it’s being sent so that it knows what to do with it.

Once that data is received your browser will show you it in the best way possible for that content type.

An HTML file will be rendered as a web page, a JSON object will be displayed as text and a directory of files will look like a file explorer.

Static Content

In the early days of the web it was just files on computers that other computers could look at. Your browser would request an HTML file in a specific directory on a remote computer, and that computer would serve that request. Hence the name server. It’s just a fancy word for “another computer that will listen to me and send me stuff”.

These files were just HTML text that your browser would render as a webpage. If the owner of the files wanted to change anything they would need to edit the relevant HTML file and save it.

Hence the name static, if the file never changed, then you would get the same content every time. This was a Static Site. There are now tools to help us generate all these files in a more manageable way and the concept is called Static Site Generation …. But I’m jumping ahead.

Server Side Rendering (SSR)

The problem with static sites is that content can’t be customised in anyway to the user and all content needs to be in a file. Well a server is just a computer, so we realised that rather than sending a request for an HTML file, we could instead send a request to program/application that creates HTML on the fly and sends it back to your browser.

As far as your browser knows, it has been sent HTML so it knows to render it as a web page BUT the server now runs a small program (written in PHP, Java or, more recently, Python or JavaScript) that creates the HTML. This app can be as simple as a templating system, where it grabs some HTML for the header, some HTML for the footer and then inserts the content the user actually want in the middle OR it can be as full featured as Facebook or Amazon.

Suddenly the web could be a whole lot more dynamic as we were rendering our HTML on the server on a per request basis and sending it back to the client AS IF they had just requested a static web page.

This was the start of the modern web, but we needed one more thing to really bring on the Web2.0 revolution.

AJAX

Probably one of the coolest acronyms in the tech industry, it stands for, Asynchronous JavaScript and XML. Forget about the XML bit for the purposes of this discussion, and focus on Asynchronous JavaScript as it was a GAME CHANGER.

We already had JavaScript and it was able to do some interesting and fun things on an HTML web page, but it’s capabilities were pretty limited.

Up to now, that HTML page we’ve been talking about that your browser receives (static or server rendered) would come with links to other files that the browser needed to fetch as well. And those links might include JavaScript files that your browser would request form the server, receive and then execute.

But what that JavaScript could do was constrained to just your browser.

Until AJAX.

This technology allowed developers to write JavaScript that could request content from the server WITHOUT having to refresh the webpage you were on.

This meant you could click a button and instead of causing a page navigation, it would instead send a request to the server for some data. When that data came back the JavaScript that sent the request could process the data and update the webpage …. without a page refresh.

Initially it was clunky and limited BUT finally web pages could function like desktop apps … The age of the web app was born.

Single Page Application (SPA)

As we built upon AJAX and worked out the kinks, we started to realise that if JavaScript could make requests to a server AND it has access to the full browser page the user is looking at …. then why don’t we get JavaScript to render webpages for us, in the browser?

And this is exactly what React, Angular and Vue do for us. When you go to a webpage for a site using one of these you are sent a single HTML file that tells the browser to get a single (usually quite large) JavaScript file.

When that JavaScript file is received the browser executes it and then it gets VERY busy.

That JavaScript file starts requesting data from the server and telling the browser to render different bits of HTML as the data streams in. When you click a button that same JavaScript captures the click event, does what it needs to do and then updates the HTML on the page as required.

In fact, when you click a link on these sites you don’t actually do a page navigation, the JavaScript usually captures this event, requests the data it needs from the server and then renders the correct HTML so it looks like a new page.

“BUT Simon!” I hear you say, “the address bar changes so I must be on a new page”

Yeh, the JavaScript rewrites that so it looks like you navigated to a new page, you didn’t really!

Bringing it home

So that’s the history of the web, where does this leave us now?

Well static sites are incredibly fast, but they have limited interaction and updating the content can be a pain. There is also no concept of “logged in” with a static site, the content is freely available to the whole internet.

Server side rendered apps solve the dynamic problem holding static sites back AND they can have the concept of user accounts and not making everything public, BUT they can be clunky to navigate around and page loads are a pain.

Single page applications solve the problem of page loads and also have the concept of user accounts and making sure content isn’t completely public BUT that initial JavaScript load can be really big, very slow and pretty bad for search engine optimisation.

What is to be done?

Enter the full stack JavaScript framework.

Full stack JavaScript frameworks aim to combine all of the benefits of the above three concepts into a single framework with great developer and user experience.

• They can combine aspects of Static Site Generation (SSG) for the parts of your site that are public and need to be FAST.
• They offer Server Side Rendering (SSR) for initial page loads that require data from a database or from another service.
• They the then drive the browser side interactions and data fetching with the Single Page Application (SPA) technology of React to make sure it feels modern and interactive like people have come to expect.

Learning path

These technologies will drive the future of the web, but first you need to learn the underlying concepts of HTML, CSS, JavaScript.

So if you’re still learning then stay the path on those.

Don’t worry if you didn’t understand all of the above, this is a very high level (which is a fancy way of saying vague 🤣) explanation aimed at raising your awareness so that when you hear these terms you understand how they fit into the bigger web development picture.

90% of being a good web developer is knowing something exists so you can deep dive on it when you need to.

Project

If you’re looking for a project where you can see many of these concepts in action and build a page up from scratch, add functionality in JavaScript and then start interacting with APIs and third part services then my link tree series is for you. We build up a social media link tree from HTML and CSS, adding JavaScript, integrating with Mailchimp, Stripe and Supabase and then wrapping up with deployment to Vercel for hosting!

Part 1 is on YouTube 😀