I still remember the first websites I sold. Simple static sites that no one would want today. However, the last few years have seen the emergence of a technology (or rather an approach to website development) that comes very close to it, but which claims to be much more powerful: the JAMstack.

⚠️ Read more of my blog posts about tech and business on my personal blog! ⚠️

I tested it and adopted it. The JAMstack is also what I used to code the latest version of the www.travel-and-food.com site. I explain here what the JAMstack is and why you should give it a try.

From static site to static site

There have been great periods in the world of the web. The first of these is that of the static site. It wasn't called that at the time. It was a site made up entirely of static files: we wrote the structure in HTML, the design in CSS, we potentially added a little animation with JavaScript, and we stored all this on a server which was content to serve the files at the time requested by the visitor.

Basic. Simple.

But, very quickly, there were limits. It was finally quite complicated to maintain. To modify a site, it was necessary to touch the code. And, annoyingly, the site never changed without developer intervention.

In itself, the static site is fine for displaying documentation, but it is impossible to build something advanced with it.

The world of the web has therefore moved on to a second period, that of the dynamic site. It was a big upheaval. Thanks to technologies like PHP, Java, etc., the server was no longer going to just serve the same page forever. These languages make it possible to generate a new page as soon as a visitor requests it thanks to data stored in databases.

It changed a lot of things. For the first time, people were starting to code smart and useful applications. From the blog to the e-commerce site, everything has been made possible thanks to dynamic sites. Once the site was coded and deployed, Muggles non-developer could modify the content without help from the developers.

Unfortunately, these sites have grown to be cumbersome and slow. Each time the visitor reloaded the page, it was completely rebuilt on the server before being sent. Servers having access to more and more content and services, and doing more and more processing, the increase in loading times could become exponential.

We move on to the third great period of the web universe: dynamic interactive websites. The idea behind this barbaric name is to no longer be forced to generate a page entirely to obtain information, and to no longer be forced to reload a page completely to update the information it contains.

The JavaScript language can update the DOM, but it can also request information directly from the server. If we combine these two capabilities, we get AJAX technology.

This technology has helped to relieve the heaviness of dynamic sites by allowing a web page to be partially updated without having to reload it. Dynamic sites had become even more dynamic!

This led to the different technologies we know today, such as the Single Page Application. Server technologies stay on the server (PHP, etc.) and are used to respond to client requests. The display of the client is done directly in the browser thanks to client technologies (JavaScript and its frameworks). The two parties discuss together through APIs.

With interactive dynamic websites, other problems have arisen. In particular, referencing, because the site being generated on the fly by JavaScript, it is impossible for a search engine to retrieve the content.

To sum up, we have:

The static site:

• ✅ SEO friendly
• ✅ very little resource-intensive
• ✅ fast loading time
• 🚫 requires knowledge of development to update the site

The dynamic site:

• ✅ SEO friendly
• 🚫 slow loading time
• ✅ no development skills needed to update the site
• 🚫 resource intensive

The interactive dynamic site:

• 🚫 not SEO friendly
• ✅ loading time (average) faster than the dynamic site, but 🚫 slower than a static site
• ✅ no development skills required to update the site
• ✅ less resource intensive (average) than a dynamic site, but 🚫 more than a static site

It is clear that the static site retains, despite its simplicity, many advantages for him. Of course, this summary is not true in all situations. It's oversimplified and generalized for the purposes of this article, but you get the idea.

Still, the advantages of the static site have pushed part of the web community to find another solution to these disadvantages than going through dynamic sites. They chose to generate the web pages before deployment instead of doing it at request time like dynamic sites do.

This technology is called the Static Site Generator. The idea is to decouple the data from the site code itself. The static site generator is therefore based on data (often Markdown, text files) to generate a site that will ultimately be entirely static. No need to know how to code to modify the content of a static site while enjoying all its advantages.

The patchwork of the best of the web

Of course, the world didn't stand still while we focused on static and dynamic sites. Many things have happened. Technologies have emerged. They have evolved. And some died.

Why are we talking about this? Because the JAMstack is actually a patchwork of many technologies working together. That's why “stack” in the name. Let's talk a bit about these technologies.

The elements that make up the JAMstack

Web APIs. We already talked about it a bit above. They became essential when we started to want to make machines to discuss between them and later separate the frontend from the backend. They are therefore used to communicate. Many standards exist. The most widely used today is REST, which is based on the operation of the HTTP protocol.

CMSs. I am talking here about Content Management Systems in the broadest sense. Just a system that allows you to manage content whether it's text, products or something else. They have the advantage of being specialized, of simplifying content management, of being known to their niche users and often of offering tools specific to their audience. For example, an e-commerce CMS will know how to manage a product and its variants, taxes on it, currency conversion, delivery conditions, etc.

Continuous integration and deployment pipelines, also known as CI/CD, have been making a lot of noise. They are part of the Architecture as Code movement. They allow to describe build, test, and deployment processes of a project that can be played and replayed as much as necessary. They have many advantages and uses, but we won't dwell on them here. What should be remembered is that they allow you to automate the different steps that we have just listed.

Frontend frameworks have simplified development by taking care of a lot of repetitive tasks for developers. They have helped make the development of more complex sites possible. These are also the frameworks that brought to the frontend a form of stability that already existed at the backend. They have improved website performance by optimizing rendering and display tasks. Last advantage, they make the site more dynamic since it runs directly in the user's browser.

Static site generators. As we explained above, these are tools that will generate a complete static website from an external data source in one build step.

JAMstack: a CI/CD pipeline rather than a new technology

I think you see where I'm coming from. People had the wonderful idea of putting all these technologies together to solve most of the problems listed at the beginning of the article.

Diagram of a JAMstack architecture

There are two ways to update our site:

• edit website code (for travel-and-food.com everything is on GitHub)
• edit site data from the CMS (for travel-and-food.com, I used the Ghost CMS)

These two systems are linked to a continuous integration platform. All software forges have their own version these days (GitHub Actions, GitLab CI, Bitbucket Pipelines, etc.) but there are independent ones like Netlify or Jenkins Pipeline. Travel & Food uses Netlify, which is also its host.

It is the CI/CD platform that will then, as a conductor, take care of all the rest of the process. The CI/CD will therefore run the build of the static site generator. For Travel & Food, I decided to use GatsbyJS as generator. Pendant son build, GatsbyJS connects to Ghost (the CMS) to retrieve the data and loop over it to generate each page of the website.

The static site generator produces a folder containing an HTML file for each page of the site as well as JavaScript and styles. When the build is complete, the CI/CD sends this folder as is to the host.

There is no longer any process that then runs at the host level. Since the site consists of static files, they are served as is when a visitor requests them. No modification or other processing is performed on the files. As a result, we have a huge gain in performance. This also affects SEO and the cost of the project.

When the JavaScript is loaded on the user side, the site “comes to life”, the frontend frameworks take over. We don't have to have non-interactive pages just because it's a static site. Thanks to the JAMstack this is no longer the case.

As frontend frameworks such as ReactJS or Angular support Server Side Rendering (SSR) techniques, a fully static first version of the JavaScript application is available in HTML even before the JavaScript is loaded. Which means that the pure performance as well as the SEO of the site would be better compared to the same site without SSR.

The advantages of the JAMstack

Let's go back to our pros/cons list for the JAMstack:

• ✅ as SEO friendly as a static site
• ✅ as fast as a static site
• ✅ no development skills required to update the site since we use a CMS (or several CMS)
• ✅ very little resource-intensive

We fill in every point on our comparison list. The JAMstack can have yet another benefit – and we'll end on this – and that is to improve team cohesion!

I'm barely kidding. If you think about it, the content creator is happy because he uses his favorite CMS, the developer is happy because he can use his favorite technology and the marketing manager is happy because the site has good SEO performance.