JAMstack Introduction - A better way to build websites.

What is the JAMstack?

In short the JAMstack is a mixture of static HTML files, some browser JavaScript and server APIs.

So instead of PHP, .NET or NodeJS that runs on the server, the server just sends HTML files and CSS/JS/IMG assets.

In 2008 I worked at Kurier, a big news site in Austria. Back then, processors were not as fast as today, and RAM was still expensive and far from the RAM sizes we find today on servers.
We still managed to process a large number of page visitors though. This was mostly done through pre-rendering nearly all pages as static HTML files on the server´s hard disk.
Whenever an editor added or changed an article, it was not only stored in the database but the HTML files were generated too.

It was a very efficient system which could handle very high visitor rates without overloading the server.

The JAMstack is similar to that and it enables you to do a lot of cool stuff that makes operation and programming easier. The biggest advantage compared to the past is that we can assume that every visitor has JavaScript enabled and JavaScript has evolved significantly.
With that we can do things that weren't possible in the past, like manipulate the navigation history, store states and even install our website as an app on the customer´s device.

Benefits over a "classic" website

Websites built with the JAMstack can be much faster and speed is the among most important thing for a website. A nice looking page is worth nothing if it doesn't reach the user.

At a JAMstack website the server doesn't need to compile the HTML for each request, it just loads a file from the hard disk. This has a positive effect on the TTFB (Time To First Byte) time and the browser knows early on what additional assets will be needed to render the page.
RAM consumption on the server side should also be much lower because we don't need a script interpreter on the server side and the connection requests are completed faster.
On a classic website we can use a proxy cache to achieve speeds that are close to those of static HTML files, but only from the second visitor of the page on. The first visitor will not hit the cache and has to wait until the page is compiled.

The frontend has complete control over the HTML, CSS and JavaScript code. We can use the framework that best fits for our needs and we don't have to worry about a CMS that dictates the HTML code.

Additionally it can be possible to completely build a page without knowledge of PHP, .Net or any other server side scripting language.

Hosting "just" HTML files makes things simpler. We don't need a server with a lot of power, so the costs are significantly lower and hosting small websites can even be completely free.

Architectures compared

A classic website would look something like this:

PHP gets processed, often there are multiple PHP files and database queries on the server side.

With the JAMstack things are different, the pages are generated at the time the website is deployed.

We get something like this:

Much simpler.

Dynamic content and Content Management Systems

Elements that are dynamic (e.g. weather data, prices, stock statuses,…) are fetched using JavaScript from REST or GraphQL APIs.
These APIs can either come from an third party provider or from our own servers.

Editorial content with Headless Content Management Systems.

There are websites which you deploy only once and then they hardly change at all, and there are websites which are intensively maintained by editors.
These editors need a user interface where they can write and manage the content.

This is where headless Content Management Systems come into play.
In principle, they are like normal CMS with the difference that they don't output HTML. All you get from them it is the data served over a REST or GraphQL API.

So with a headless CMS we may have an architecture like this.

Static files from one source and another source for the content data. This gives us a tremendous flexibility. We get a modular system where the data is separated from the system that displays it.
Which framework? VueJS, Angular, React, Vanilla JS? DIV, SECTION or SPAN elements? It doesn't matter, do what ever best suits your needs and not what a CMS dictates you.

You can even connect several different frontend systems to it. Browsers, iOS apps, Android apps, the new fancy device on the market…
Everything can use the same data source.

As I worked at Restplatzbörse we were using Typo3 v7.6 LTS and we wanted to add a "defer" attribute to a script tag. Unfortunately this is only possible starting with version 9.0.
An update to this version would have been too much effort at that time.
With the JAMstack it´s a no-brainer, within 2 minutes it could have been done.

Possible pitfalls with JavaScript and SEO

A fast delivery of HTML and assets is useless if the JavaScript code takes ages to be processed. With every website we have to watch out for the size of JavaScript and that the execution time is not too long for mobile devices. (Codespliting can help here)

The Google crawler can usually execute JavaScript without problems. There should be no problem with content that is loaded via JavaScript. Google uses a real Chrome browser for crawling which is relatively up to date, but you still have to be careful when using JavaScript APIs which were added in the latest version.

Headless Content Management Systems

There are already a lot of headless CMS systems. Directus, Strapi, Prismic, Storyblok just to name a few.

Depending on your needs you could also write your own backend system. In this case you should also separate the API from the backend userinterface.

This is the maximum of flexibility. The backend for content editors is just another "frontend" to the API and offers all the features that we also have at the vistor frontend system.