What is Jamstack, and how is it different?
Jamstack stands for JavaScript, API and Markup: the pages are HTML and CSS already built, JavaScript serves the dynamic functions that call the APIs, and the APIs provide the back end of the application. The pages sit on a CDN, a distributed network that is closer to the person looking than a single server is.
Jamstack is an approach to web application architecture based on a few essential principles for building websites and web applications that are high-performing, scalable and secure. The term “Jamstack” is an acronym that stands for “JavaScript, APIs, and Markup”. Specifically, “Jam” stands for JavaScript (a programming language used above all in Web applications), APIs and Markup (HTML and CSS code that gives formatting instructions to browsers).
The term “stack”, on the other hand, refers to the combination of the three elements just mentioned, a combo that lets software developers build applications or websites.
However, before we can talk about Jamstack, you need to be clear about what an API is.
APIs: what they are and what they are for
APIs are the way one application asks for and retrieves a set of data from another. How does this process work? An application sends an API request (HTTP Get, that is, a simple HTTP message) and the API responds with a JSON containing the information we asked for, the reason we queried that API in the first place.
The diagram shows all the types of HTTP messages that can be sent to an API, each with its own function, and where relevant the CRUD acronym as well:
Let’s look together at the different types of HTTP messages and what they do:
- POST is meant for creating something in the application
- GET is used to read something in the application
- PUT is meant to add something to the application, in the sense that it replaces the information itself
- PATCH has the same function as PUT but, in adding something to the application, it modifies the existing information
- DELETE deletes something in the application
The response to this request comes as a JSON or in an XML format.

To understand what APIs are, how they work and what they are for, the example of a weather App is often used: anyone can build a weather App, but without the data on temperature, rainfall and wind it is completely useless.
So how do you retrieve all the weather data that exists? It is practically impossible. If there were no APIs built by someone and made available to anyone who wants to query them with their own App, retrieving weather data in real time would not be feasible.
Once our App goes and fetches the weather information (which we asked it for) by sending a GET to the APIs made available for querying, the requested information comes back and our App shows it to us in the style and graphics we designed for it.
Characteristics of a Jamstack architecture
As mentioned earlier, the term “stack” refers to the combination of three elements, a union that lets software developers build applications or websites.
What characterises these, or a Jamstack application, is that they are built using only these three elements. The website or web application the user sees is built with HTML and CSS markup code. In all of this, JavaScript is used for all the dynamic functionality needed to call the APIs, which provide the application’s backend.
Why is the backend in Jamstack lean and light?
Because developers who use Jamstack for their applications do not have to build a backend network underneath the frontend; on the contrary, they can rely on existing APIs to make their websites or applications work. When a developer wants to create new features, or extend or change existing ones, they do not have to spend hours writing all the code in the backend: they only need to create a new API that provides the data and, if necessary, extend it later for future applications too.
The difference between the traditional backend approach and a Jamstack architecture
To understand how an application or a website generated with a Jamstack architecture works, think of the financial sector and the thousands of continuous price fluctuations that characterise the European stock market.
There is a big difference between an application built the traditional way and one with a Jamstack architecture. Follow this example: imagine a developer building a web application the traditional way (that is, with a large backend structure) able to manage, monitor and provide continuous updates on the price fluctuations of stocks on the European markets. In this case, the developer creates a backend structure that runs on a server. So, when the user opens the application to check the fluctuations, the developer’s server generates HTML pages that display the stock data and sends them to the user. Unfortunately, though, the application turns out to be very slow because, before the user sees these pages, they necessarily have to wait for the backend application to run, for the HTML pages to be generated and for the HTML to reach their device.
This is the traditional approach, and we have also made this summary diagram:

Now think of the same application, but built using the Jamstack approach. In this second case Antonello does not have to build the application starting from the backend, but create a series of HTML pages, which are light, simple and quick to produce. He then stores them on a CDN (Content Delivery or Distribution Network), that is, a geographically distributed network of computers optimised to improve performance, which serves resources to Web users. When one of them opens the application, the CDN immediately delivers the HTML pages requested.
This process is faster than Antonello’s traditional server, since the CDN is much closer, by definition. Meanwhile the application also makes an API call (with a GET) to ask for and read the changes in European stock market prices directly on the HTML page.
And so the application loads and works much faster, and Antonello, for the continuous updating of stock prices, does not need to write the code that handles the backend work on the server.
This is the Jamstack approach, where the developer only creates HTML pages and works on existing APIs or, at most, extends them.
Here is a diagram of this second method too:

Three advantages of a Jamstack architecture
Now that you know the difference between an application built the traditional way and one with a Jamstack architecture, let’s sum up the advantages you can get with the second strategy:
- Performance – Almost all the content in a Jamstack application is made of static HTML files, served through a CDN, and this is certainly the fastest way to make web content available to the user.
- Scalability – When you have a “scalable” application you have a product that can respond correctly and flawlessly even during peaks of use, all thanks to the fast frontend and the lean backend.
- Engagement – A Jamstack application allows a more engaging development experience, since developers can concentrate on building the frontend interface without worrying too much about the backend or about performance problems.
To take full advantage of a Jamstack architecture and transform your digital experience, contact us today. We are here to guide you towards the future of the web.
