Dynamic vs SPA vs Static Websites

You know how the web works - the browser sends a request, the server returns a response. If a webpage was requested, the response contains HTML code which then is used by the browser to render the website.

But how does the HTML code, which is returned, end up on the server? Is it generated "on the fly" (per request)? Is it "pre-generated" (i.e. are the finished HTML pages uploaded onto the server)?

It turns out, that there are three main alternatives when it comes to rendering websites (and the HTML code that is required):

HTML pages are created dynamically, on the server - with the help of a server-side programming language and typically also a "templating engine"

Learn more

The server returns one single, pre-generated HTML page which in turn contains JavaScript code that changes the page dynamically in the browser (this approach is known as a "Single Page Application" or "SPA")

Learn more

HTML pages were pre-generated and are stored as such on the server - typically, those pages are not hand-written but also generated automatically (but before they're uploaded) with the help of a static site generator

Learn more

Go back in time by ten years and this was the most common approach. It actually still is, but Static Pages and Single Page Applications are now rapidly growing and taking significant shares of the overall "website market".

Especially modern websites and webservices (e.g. Netflix, Twitter) are embracing these newer approaches.

But let's take a step back: What are "Dynamic websites"?

It's not a reserved term or anything like that. It simply means that the website you're viewing is dynamically created on the server. And with "website", I of course mean the HTML code, including the information which styles and scripts to attach.

Consider your user profile on amazon.com.

It includes personal data like your name and order history. Obviously, Amazon does not hand-write the HTML code for that page. Still, if you inspect the HTML source code of that page, you'll find your personal data in there.

This means that the HTML code was dynamically generated on the server, by the server-side language used there.

The incoming request was handled by the server as instructed by the language used there. It was parsed and required data (e.g. your name) was fetched from a database. The server-side language then used all that information to generate dynamic HTML code which was sent back in the response the browser awaited.

For this, server-side languages like Node.js could be used - typically in conjunction with specific extensions that make the dynamic creation of HTML code easier. These extensions are also referred to as "templating engines".

The advantage of this approach is that the client (browser) receives the finished website with all the data that belongs to it. That's especially important if the client is not a user but a search engine crawler - it always helps if it sees what the user would see (even though, that's of course not your personal profile page - but the same concept applies to other pages, too).

Another advantage is, that all logic happens on the server, hence the client's machine really only needs to render the HTML code. A task that typically isn't too performance-intensive.

A disadvantage of this approach is that every page a user visits needs to be generated on the server. That means, that the user always has to wait for a new page to be sent. Modern servers and browsers are pretty good at that (e.g. they use caching to avoid unnecessary requests and roundtrips) but still, you have that extra work to be done. Even if just one detail on the page changes and the frame stays the same (e.g. your navigation bar and the footer), a new page has to be requested and rendered nonetheless.

In addition, another disadvantage could be, that developers building dynamic pages need both frontend (HTML + CSS + JS) and backend development knowledge. At least to a certain degree. Decoupling and splitting work is certainly possible but there is a slightly higher dependency.

Single Page Applications (SPAs) are the other extreme: There, all the HTML generation happens in the browser. The server only returns one basic HTMl page for all incoming requests (no matter the URL).

But that single HTML page contains a lot of JavaScript code (typically outsourced into separate files) which is responsible for changing the HTML code (technically, the DOM).

At first, this sounds strange, right?

Didn't the server fetch data from a database to then generate HTML code? Does the client (browser) now do that (connect to a database)?

It's important to understand, that with SPAs, there still is a server involved. Your client-side JavaScript code will not connect to a database. That would be highly insecure since access credentials would be exposed. You can't hide your frontend JavaScript code!.

But the entire UI-updating process will happen in the browser (via client-side JavaScript). This provides a mobile-app-like user experience since the user now never has to wait for a new page to load. Instead, updates and changes happen instantly.

Your app will probably still need some data from time to time but you can simply show a loading spinner on the UI until that data has been fetched behind the scenes (e.g. via AJAX).

Since updating the entire HTML page dynamically via client-side JavaScript code requires quite a lot of JavaScript instructions, you typically use a framework or library for the heavy lifting.

React.js, Angular or Vue.js are the most popular choices.

SPAs are on the rise because they provide such an amazing and fast user experience.

But handling all the UI updates and the content rendering in the browser has its downsides, too.

The biggest disadvantage is that the page you get sent over the wire (i.e. that initial single HTML page that kicks of the SPA) is pretty empty. Typically, there's nothing more than some entry HTML tag and a couple of script and style imports.

That's not great for SEO since the search engine crawler doesn't see all your beautiful content which will eventually be rendered - it just sees the empty page instead. Some crawlers may actually wait for JavaScript to run and render something but they'll never wait for asynchronously loaded data (i.e. for content that first has to be fetched via a behind-the-scenes HTTP request).

There are solutions to that problem - server-side rendering of SPA views for example. But this already sounds a bit more advanced - and indeed, it is. Thankfully, there are initiatives that make that process a bit easier and hence allow you to get the best of both worlds.

Besides the SEO "problem", it's also worth mentioning that more work in the browser also means that more JavaScript code has to be downloaded. And all that code has to be parsed + executed, which of course impacts the runtime performance of the website.

On slower devices and/ or slower networks, SPAs can therefore take very long to load or feel "laggy".

Static pages are the oldest form of web pages. After all, a static webpage simply means that all the HTML content has been created already. The finished pages are then uploaded onto a server and are waiting for requests to fetch them.

If you only need a very basic website where content doesn't change often and where you also have no dynamic (e.g. user-specific) content, such a static page could be all you need.

But now comes the interesting part: Even pages with dynamic content can be converted into static pages. This page (academind.com) is an example - it's actually a static page.

How does that work? Do we write all the HTML code for all our pages manually? Do we copy and paste code from page to page?

No, that would not be feasible at all - leave alone that it would be extremely error-prone.

Instead, we use a static site generator, to be precise, we use Gatsby.js.

A static site generator allows you to define content in a simplified form - often as a markdown document.

For example, this is what a draft of the article you're currently reading looked like:

The static site generator then picks up that content and converts it into HTML + CSS code as instructed by you.

Every generator works differently, Gatsby.js actually uses a React app that it basically builds locally and where it then "visits" every page that would exist in a SPA. Snapshots of these pages then get stored as HTML files - and that's the final output. A bunch of HTML files as they would normally be generated by React in the browser.

We then simply upload these HTML files to our server.

Compared to a normal SPA, the static page approach has a major advantage: The final page is shipped over the wire when requested. No JavaScript code needs to run to draw it onto the screen. Search engine crawlers therefore see what users see. And users don't need to wait for some initial JavaScript code to be parsed and executed.

But the best thing is: Some static pages (including this one), turn into a SPA once loaded.

Hence you get all the benefits of a SPA (fast updates, instant changes) as soon as the user has loaded the first page. But for that first page, you get the advantages of a static or dynamic web page. Pretty sweet! :)

So ... the static page (created with a static site generator that also yields a SPA) is best, right?

No, it's not that easy!

There is no best or worst approach!

All approaches can be fine - it depends on what you're building.

A static page - no matter if created with or without a static site generator - might be a poor choice for a website with content that changes multiple times per hour or minute. Even if the process is highly automated, the page would have to be re-generated and re-deployed constantly! A dynamic page or SPA might be a better choice here!

A SPA in general often is a decent choice - it's especially great for web apps that don't really need search engine crawling.

You could always create your landing pages (that should be found) in a SEO-friendly way (e.g. static pages) and create the rest of the app as a SPA.

The great reactivity and UX makes SPAs a great choice for in-browser apps like Google Docs, the Twitter feed or Netflix.

A dynamic page on the other hand can be perfect if you have fast-changing content and SEO matters a lot. An online shop for example.

As always in life, it doesn't hurt to know all these alternatives - that allows you to pick the right tool for the job you're working on.