What is Jamstack?

⚠️ This post is over two years old and may contain some outdated technical information. Please proceed with caution!

A common question I get asked is “What is Jamstack?” I’ve been working with Jamstack solidly for over five years now, and I wanted to take an opportunity to demystify this technology stack, and reassure you that Jamstack has absolutely nothing to do with toast and butter (even though we wish it did). In this post, we’ll explore what Jamstack is, why Jamstack entered the web dev scene, “Jamstack-adjacent” technologies, and how you can get started building on the Jamstack.

If you’re here for the TL;DR, I got you.

Jamstack is an architectural model centred on serving pre-generated, highly portable static assets from web development platforms, usually via a Content Delivery Network (CDN). Jamstack architecture is elevated and enhanced by a wide variety of modern adjacent development tooling such as serverless and edge functions, content management systems, version control integration, and API services.

Jamstack is a way of working. It’s not a group of frameworks or services or tied to any particular brands or tech stack. Jamstack is defined by how you build websites, rather than the tools with which you choose to build them. And it evolved out of the need to solve some very interesting problems.

The term “Jamstack” has been around since 2015, and came from the brains of Matt Biilmann and Chris Bach, founders of platform for modern web development Netlify. Back then, Jamstack meant using a combination of JavaScript, APIs, and Markup together to build static sites — websites that are packaged up and served as static HTML files and assets from a CDN. These static sites might exist as a collection of HTML files in a code repository, or they may be generated using a static site generator or build script, where a set of instructions as code turn template code into static HTML files and store them on a CDN.

Jamstack was originally named JAMstack with uppercase JAM to describe the combination of technologies mentioned above. It has since moved to Jamstack to reflect its evolution to an architectural approach, instead of describing the technologies that might be used. You don’t necessarily have to use APIs — or even JavaScript — to build a Jamstack site!

That’s the terminology covered, but what was different about Jamstack when it emerged in 2015?

Traditionally, requests for web pages were processed by a managed server (more on this later), which did the job of building HTML documents in real-time before sending it back to the user’s browser. If the web page was big and complex, and if the page request was far away from the origin server, this meant that websites could be slow, resulting in a bad experience for the end-user. As more and more people started to use the web for everything, a fast experience was key to making websites usable, accessible — especially on slower internet connections, making sales, distributing information, and growing your business.

Jamstack solved this problem in two ways. Firstly, Jamstack sites centre on pre-generating and storing website pages in advance — meaning a server doesn’t need to build anything at the time of a page request. Secondly, these pre-generated static assets are served from a Content Delivery Network (CDN) — a network of servers distributed around the world, working together to serve cached content to users from the closest server location possible. This guarantees a much faster experience than the traditional request, build, and serve model from a fixed server location. (It’s worth mentioning here that the traditional architecture described above is still alive and kicking, and Jamstack provides an alternative way of working, should it fit the needs of the project or product.)

Before Jamstack, websites were built using entire full stack frameworks that comprised the back end server code, front end templates, databases — everything. New product features could take weeks to build, test, and release to production, software upgrades could be risky and difficult to roll back, and development environments were difficult to provision. Jamstack shifted to a decoupled architecture. This means back end API services, front end templates, databases, and all other services are separated and streamlined, allowing developers of different disciplines to build, test and release in parallel with each other, and go faster.

Jamstack sites are front end (client) code that may or may not speak to a separate back end server and/or APIs. During the build process, a Jamstack site can call out to any number of external API services to fetch data to pre-generate static pages. Once a Jamstack site is built, it is cached as an immutable deploy — a set of static files that cannot be changed. This means that a Jamstack site in production can be rolled back and forward quickly and easily between deploys should the need arise. What’s more, a breaking back end API change would have no effect on a static Jamstack site until the next time the site is rebuilt, making Jamstack sites more stable and less prone to bugs once they’re deployed to production. Speaking from experience, this decoupled approach also empowers front end developers to have full ownership of their code, processes and practices, without being at the mercy of a massive monolithic full stack scary codebase.

During the time of the massive monolith and the request-build-serve model, development and IT operations teams were responsible for managing their own servers (hence, “managed server” above). This came with a number of challenges, including managing security and software upgrades, DNS (!), and scaling the availability of servers up or down when website traffic increased or decreased. Jamstack hosting providers take care of all of this for you, meaning you can focus on writing the code that builds your product, instead of stressing about the infrastructure.

This has also greatly lowered the bar for entry to building a website and putting it live for the world to enjoy. With Jamstack, even a beginner developer can put a website live in a matter of minutes. Write a static HTML file, put it on a CDN, automatically get a URL and SSL certificate, and share it with your friends.

Remember — Jamstack is an architectural way of working. Jamstack does not dictate what technologies, frameworks or web development platforms you choose. All Jamstack requires is that you centre your project on the concept of serving static assets from a CDN. You can choose to use serverless functions, edge functions, content management systems, other API services and more to enhance and enrich your Jamstack site — but at the core of Jamstack is a static-first approach without a managed server.

Jamstack projects have the following characteristics:

• Ready-to-serve assets

• Any interactivity provided without a managed server

• Any interactivity provided by some combination of JavaScript and decoupled services via APIs

If you’re brand new to Jamstack, I personally don’t recommend starting out with a static site generator right away. Instead, I advise starting as small as possible. A Jamstack site can be as simple as:

• serving a single HTML file (a ready-to-serve asset)

• from a web development platform such as Netlify (no managed server)

• that calls out to an external API on the client to get something done (if it needs to)

And the great thing about Jamstack is when you’re ready to add new features and functionality to your site, you don’t need to start again from scratch. Add extra pages when you need to, maybe add in a static site generator or build tool to generate dynamic pages at build time. Add extra functionality when you need to; maybe you’ll use adjacent technologies like serverless functions — if it fits.

There’s no magic formula for Jamstack, but at its core, a Jamstack site is a set of pre-generated static assets served from a CDN. So, choose your project, choose your platform, start small, relish in the glow of serving static files from a CDN, and enjoy the ride.