
Table of contents
TLTR
There are various approaches to the architecture of a website or web application. One of the emerging solutions is called Jamstack, which has very specific characteristics (function decoupling, content pre-rendering, modularity, GIT-based, and versioning) that lead to significant advantages in terms of performance, security, scalability, and cost-effectiveness.
The Jamstack approach’s main drawback is the need for more effort (time and costs) compared to pre-packaged solutions, making it suitable only for those seeking quality and performance.
Introduction
In a recent article, we discussed how our website achieved the highest possible score on web.dev/measure, Google’s official tool for measuring website performance. For the mentioned site, falegnameriamuraro.it, we implemented an innovative web architecture called Jamstack, using a JavaScript framework named Svelte *.
In this article, we aim to describe the technological choices we’ve made to illustrate, and hopefully make understandable, the differences, advantages, and disadvantages compared to more well-known and conventional solutions.
* For this project, the stack is complemented with Tailwind CSS for styling, Netlify CMS as a headless CMS, and Vercel for deployment.
The Jamstack Architecture
At the foundation of everything lies a new method, a new paradigm for creating websites and web applications, which has been named Jamstack (originally JAMstack). Mathias Biilmann, CEO and founder of Netlify, a company that provides cloud computing services focused on these technologies, coined the term. Here’s his definition of Jamstack:
“A modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup”.
Mathias Biilman
Jamstack is not a language, framework, or tool. It’s an approach to web architecture, grounded in these three pillars:
- JavaScript
- APIs
- Markup
Javascript
All dynamic functionalities are managed through JavaScript, the programming language of the web, in its various forms and manifestations, libraries, and possible frameworks.
API
All server-side functionalities are abstracted and encapsulated within reusable APIs. These are standardized procedures that allow a software application to integrate and communicate easily, securely, and efficiently with other applications.
Markup
The Jamstack architecture relies on HyperText Markup Language content, the web standard, served as simple static files that are distributed across the network in the fastest and most efficient manner possible, through a Content Delivery Network (CDN).
Principles and Characteristics
Now, let’s provide an overview of the prominent characteristics of the Jamstack architecture. It’s not easy to discuss complex topics in a concise and simple manner, but we’ll give it a try to provide at least an idea of the key differences compared to traditional approaches.
Function Decoupling
In 2021, the majority of websites are built using a CMS like WordPress or a site builder like Wix. In both cases, code, content, and design are managed by a single system, a single complex monolithic application.
The “engine” resides in the backend, where the logic and operational code of the entire application are located, and where templates are inserted. The backend also includes a CMS (Content Management System), used to create and manage content, which is stored in a server’s database.
When users access the website’s pages, the required content is fetched from the database, assembled into templates, and served in the browser.
In a Jamstack application, all these processes are decoupled and managed separately by specialized, independent applications. This approach also offers extreme flexibility and technological freedom, making it possible to easily replace different system elements, composing different technological stacks as needed.
Content Pre-rendering
In a Jamstack website, the entire frontend (what users see and experience in their browsers) is built in advance of user requests: content is always ready to be served in the form of highly optimized static pages.
Even with a traditional CMS, content can be pre-cached, which, in many ways and within certain limits, functions similarly to content pre-rendering in a Jamstack architecture. Beyond the potential superiority of one solution over the other, the underlying logic of operation remains fundamentally different:
- A CMS is a dynamic application that can pre-cache static content in advance.
- A Jamstack site is a static application capable of making all necessary dynamic calls.
In a traditional CMS-based site, most of the work is done in the backend, on the server side. In a Jamstack application, the focus shifts almost entirely to the frontend, directly in the user’s browser, where requests for dynamic data originate only when necessary.
Modularity
The fundamental modularity of the Jamstack approach allows for virtual connections to various services via APIs. This enables both avoiding reinventing the wheel each time and building extremely complex applications, integrating them relatively easily with specialized or advanced services.
GIT-Based and Versioning
One of the features of Jamstack, often overlooked, is that it’s based on GIT.
What is GIT? GIT is arguably the most important tool for software developers.
It’s a robust version control system, tracking all changes made to source files over time. It’s a highly useful tool for small projects and essential for complex projects where multiple individuals work asynchronously and nonlinearly.
Interestingly, GIT was created in just a couple of days and nights (!!!) by Linus Torvalds, the controversial and brilliant father of Linux.
Thanks to GIT, all the source code of a Jamstack website or application is stored on online repository services like Github, Bitbucket, Sourceforge, making saving, sharing, comparing versions, and more, easy, fast, and secure.
The result is that with a few simple commands, a developer can save their work to the cloud, a colleague can download it to their computer, share it with others, compare different code versions, revert to previous versions (!!!), and much more.
Advantages of Jamstack
Now that we have an understanding of what the Jamstack architecture is and how it works, let’s explore the most important and interesting aspect: the advantages of this approach. Some of these advantages have already been hinted at and are direct consequences of the characteristics we’ve just discussed.
Performance
In the Jamstack architecture, content is already prepared (pre-rendered) and distributed across the network through a Content Delivery Network (CDN). From a speed perspective, this is currently the best technological solution available.
To illustrate the difference from a site built in a traditional manner using a CMS, let’s make a comparison using a metaphor.
Imagine:
- a reader (a web user) goes to a library (the browser on their computer or smartphone),
- they order a book (type in the URL of a web page),
- the book isn’t available in the library (it’s not in their browser’s cache).
Let’s see what happens in these two different scenarios.
| The library (the browser) sends the request to its wholesaler (network node). | The library (the browser) sends the request to its wholesaler (network node). |
| The wholesaler forwards the request to the publisher (server hosting the site). | The wholesaler already has a printed copy of the book and immediately gives it to the library (the content was pre-rendered and distributed across the network through a CDN). |
| The request is forwarded to the print department (CMS), | |
| where an operator retrieves the document templates from the storage (database). | |
| The document is printed (content rendering in the template), | |
| and delivered to a courier (network server), | |
| who sends it to the wholesaler (network node), | |
| which finally delivers it to the library (the user’s browser). |
This metaphor, though rough and approximate, helps us understand why there are (few) sites that load and become interactive in a couple of seconds, and (many) others that take around ten seconds or more.
Like other professionals (not many, to be honest), we at Antartika have been addressing performance issues for many years. Even for sites we create using “traditional” CMS platforms (like WordPress, for instance) we offer advanced and performant solutions, such as content pre-caching and distribution through CDNs. Unfortunately, this isn’t the case for the vast majority of websites currently on the internet.
Security
A Jamstack application mainly exposes static content, which inherently lacks vulnerabilities. Alongside static assets, only the APIs of dynamic microservices are exposed as potential attack points. These APIs are few in number and easily controllable (for instance, through read-only implementations whenever possible). This is in stark contrast to a classic monolithic CMS, where various dynamic functions (core application of the CMS, template, plugins) constitute vulnerabilities and potential attack points.
In a nutshell: the risk and vulnerability factors of this architecture are predominantly human-related, pertaining to passwords and authentication processes of microservices. With rigorous management of these aspects, a level of security that is hard to match can be achieved (though it’s important to note that absolute security doesn’t exist, and any network-connected service can’t withstand an attack conducted with nearly infinite power and/or nearly infinite duration).
Cost Efficiency
Firstly, as mentioned earlier, the Jamstack architecture shifts much of the work from the backend to the frontend, from the server to the browser. This also has an important economic consequence, which we’ll now explore. In the process of creating and consuming content on the web, there are two costs:
- the cost borne by the platform hosting and publishing the content (servers and energy consumption);
- the cost borne by users utilizing the content (devices and energy consumption).
Hence, shifting a substantial part of the work from the server to users’ clients also shifts a large portion of the costs to users (for an individual user, these costs are so low that usually, in more fortunate and affluent parts of the world, they’re not even perceived or considered).
Secondly, the Jamstack architecture, as previously explained, minimizes the number of exchanges (requests and responses) and the amount of information transferred between the server and the client (thus reducing resources and energy needed).
As a third and final consideration, it’s worth adding that the adoption of this approach by developers often stems from a significant focus on performance, hence the speed and efficiency of code. This also translates into less hardware usage and energy consumption.
Due to these three factors just mentioned, it’s reasonable to believe that the Jamstack architecture could have competitively lower operating costs compared to traditional solutions. Although specialized hosting service providers in this field are still relatively few, it seems that the offered prices are quite accessible, and many providers also offer generous free tiers that might be sufficient for many small businesses.
Scalability
Building on GIT and utilizing static content and microservices, deploying to one of the various cloud computing services specializing in the Jamstack architecture (Netlify, Vercel, Gatsby Cloud, etc.) takes just a couple of clicks and a little more.
All the effort put into developing a content delivery strategy, even for complex applications, ends here—it can be easily and economically outsourced to one of these specialized providers. And as the necessary resources grow, upgrading to a higher service tier can be accomplished with just a couple more clicks.
Drawbacks: Costs
The fact that it’s a completely custom-made solution comes with obvious advantages but equally evident disadvantages: unlike a WIX website or a WordPress site built with a standard template, Jamstack is not a ready-made solution that works “out of the box.”
The Jamstack architecture needs to be thought out and designed case by case, in terms of customizing services based on specific requirements. There are many questions followed by diverse answers and technological choices. For instance:
- Should a JavaScript framework be used? If so, which one? React? Vue? Angular? Svelte?…
- Is a site generator necessary, such as Next, Hugo, Gatsby, Jeckyll, Nuxt…?…
- For styling, what’s used? Tailwind? Styled Components? CSS Modules?…
- Is a CMS needed? Which one to choose from the dozens available: Strapi? Ghost? Contentful?…
- Which hosting to use? Netlify? Vercel? Heroku? AWS?
- etc.
Choosing the right stack is a complex task that considers many factors, including available skills and the development team’s preferences. Once the most suitable solution is designed, all the different pieces need to be taken and assembled together. Certainly, this requires more time and effort compared to a pre-packaged solution, which can be bought ready-made and only requires pressing the power button.
Conclusion: Jamstack is for the Competitive
To draw conclusions and summarize the key differences between a traditional monolithic application (WordPress, Joomla, Drupal, etc.) and Jamstack, let’s make a comparison with the world of bicycles.
The traditional solution corresponds to a mass-market bicycle:
- it can be bought at a supermarket or a specialized store;
- there are many models available, with varying prices and qualities (some excellent);
- some customization is possible (color, saddle, wheels, etc.).
The Jamstack solution is a custom-made bicycle:
- it’s tailor-made by an experienced craftsman;
- offers virtually infinite customizations;
- is assembled individually, piece by piece
- with extreme attention to detail.
Those who buy a custom bicycle often spend hundreds or thousands of extra euros to have components that allow them to reduce the overall weight by a few kilograms or a few hundred grams.
Similarly, in a highly performant Jamstack solution, developers often spend hours or days of work to eliminate a few tens of kilobytes of weight, and consequently, reduce average loading times by a fraction of a second.
The Jamstack architecture isn’t a solution for everyone: it’s an advanced solution that’s suited for those willing to invest in quality and performance and can appreciate how these translate into a competitive advantage for their business.
It all depends on needs and objectives: if the purpose is occasional leisurely rides, spending thousands of euros on a competitive bicycle is utterly unnecessary. If the goal is to compete in the Paris-Roubaix race, a high-end bicycle is indispensable, and a few hundred grams more or less can make the difference between victory and trailing behind.
Table of contents


