The web has been around for some time, and now we have a lot of tools and ways to build websites. Over the years, the trends changed and now it seems like we’re heading back where it started…in a way. You’ll see in this article what I mean by that.
This article is not going to compare different tools or technologies, but it’s going to focus on the different methods we can build websites.

In order to understand what options do we have when building a website, we’ll go through the history of websites and how they evolved.

Static websites

In the early days of the internet, the web pages were entirely static HTML documents, meaning that the browser was simply making an HTTP request to the webserver which responded with the HTML file — the file was already created and stored somewhere. Pretty simple, but that meant someone had to create an HTML file for every page found on the website and it had no dynamic content.

Server-side rendering (SSR)

Those issues were solved by introducing the server-side rendering — and it’s a simple concept — the browser makes an HTTP request to the webserver, the server it’s generating the HTML response and it’s returning it to the client (the browser). This allows the server to serve dynamic data which can be fetched from a database or from an external service. By doing this, the websites can now contain user-specific information - one example would be when I log in to a website, it says Hello, Florin instead of Hello User. This is achieved by using simple templates with placeholders for the dynamic content.
The example above would be implemented something like this:

<pre> <div> Hello, #{user.name} </div> </pre>

It seems to work well, but it also has some disadvantages — it forces the browser to refresh the page in order to get the new HTML content.
This means that if we want to have a website where we want to be able to leave comments on some articles, once the user submits the comment, the page will be reloaded. Might not seem like a big issue, but it may become annoying for the users.

Client-side rendering

The websites started fetching data asynchronously from the server (usually in a JSON or XML format) and rendering the content by itself using AJAX requests (note: Ajax is getting replaced by the Fetch API).
This approach allowed us to build websites with a better user experience, to interact with the users without the need to reload pages, and even render the entire page on the client-side — those websites are called Single Page Applications (SPA).

While it has a lot of advantages, there are also scenarios where client-side rendering is not the best option. When it was launched, SEO was a downside since most of the crawlers were not executing the javascript part and they were basically crawling empty websites since the content was not rendered. This was fixed by most web crawlers in the meantime, but there are other SEO-related issues. E.g., your website might get penalized by Google if there is a lot of processing on the main thread (which usually happens when building a single page application).
And besides the SEO score, the performance may be an issue for the users since the entire rendering happens on the client-side. Of course, a lot of the devices are powerful and can handle this kind of processing, but there are still a lot of devices like cheaper phones or computers which may struggle.

Server-side rendering … again

Since rendering HTML directly in the browser has some limitations, we thought to use servers for this again, but this time with modern javascript frameworks like Nuxt JS which is an open-source framework based on Vue JS. Nuxt JS actually works in multiple ways, allowing developers to build SPAs, server-side rendered websites, and even static websites.

Nuxt allows you to build modern web applications, using Vue js but it also runs a server that is rendering the HTML instead of the client. This is solving both the SEO and performance issues while keeping a nice experience for the users.

Static websites strike back

I mentioned before that Nuxt allows static website generation and you might be wondering why anyone would need that since server-side rendering works so well now.
Well, for starters — you may not need a dynamic website; think of a presentation page with an about page and maybe a portfolio that is not updated quite often. And another reason would be the costs and complexity of hosting the website. A static website can be hosted for free or almost for free (extremely cheap) on a CDN.

For the users, it would work like in the old days, the browser requests a web page to the server which returns an HTML file, but for the developer, it offers a lot of benefits compared to simply writing HTML files.
It allows us to reuse components or part of the website — e.g., you have a landing page and an about page and you want the header and the footer to be the same on both pages. You can simply create two components that are going to be reused on those pages without the need to re-write the same HTML code thus making the development faster and easier to maintain.

But Nuxt offers more than that, it allows you to fetch dynamic data from different sources (let’s say an API) and generate HTML files with that content. In other words, you can get almost dynamic content by rebuilding the HTML files when you need to refresh the content.
And to give you an example where this would be useful — consider having a blog, there is no client-specific content, so it doesn’t need to use a server to render it since it’s always going to be the same output. Instead, we could use a headless CMS to store and publish content and then trigger a re-build on our website which would generate new HTML files with the new content.

So, now that we went through all this information, let's circle back to the initial question.

What are the differences between static websites, single-page applications, and server-side rendering?

Static websites are a great option for a simple landing page or blog with low maintenance and low costs, if you aim for a better user experience and a bit more complex sites where users do not need to reload pages, a Single Page Application (SPA) would be the go-to option, and if you want the full-pack where you solve both performance and SEO challenges, we recommend you server-side rendering, using Nuxt and Vue js. These being said, it all depends on your needs, budget, and the long-term goals of your site.

If you need help in building your next web app, platform, or site, and you are not sure which solution would be the best for you — drop us a line in the chat and we will do our best to provide you with the right solution!

About the author:
Florin is the Head of Web Development at Wolfpack Digital and an experienced full-stack developer who has a great understanding of web development tools.
He is one of the geekiest developers we know: he graduated Computer Science at the Technical University of Cluj-Napoca, working mostly with Ruby on Rails and Javascript and he loves sharing knowledge and keeping up with (new) technologies.

Florin

written by this author