This post is free for all to read thanks to the investment Mindsers Club members have made in our independent publication. If this work is meaningful to you, I invite you to join the club today.
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.
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
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.
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!
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.
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.
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.
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.
Join 200+ developers and get notified every month about new content on the blog.
No spam ever. Unsubscribe in a single click at any time.
If you have any questions or advices, please create a comment below! I'll be really glad to read you. Also if you like this post, don't forget to share it with your friends. It helps a lot!