An intro to the JAMstack

An intro to the JAMstack

You may have heard about the JAMstack. Like many people, including myself, your first response was probably to bemoan yet another client-side architectural development. "Javascript fatigue" almost certainly crossed your mind. I'm here to reassure you that it's not some complicated new framework or web technology. It's just a set of principles for building applications. There are also some tools that make adhering to these principles much easier.

So, what is it?

The JAM in JAMstack stands for client-side Javascript, reusable API's, and prebuilt markup. The gist of it is that applications use Javascript for dynamic capabilities such as routing, fetching data from API's, and updating content. All static content is rendered via prebuilt markup.

These principles provide several benefits. By removing the need for communication between the client and server to display non-dynamic content, the client is able to be much more autonomous. Deployment of the client is less likely to be gated by updates to backend services, decreasing days to deployment for a significant portion of your codebase. The use of prebuilt markup means that more of your content is already available via the cdn that serves your client-side code, improving site performance.

All of the associated benefits come without giving up on the things that people do enjoy about modern web development. You can still use your Javascript framework of choice and the latest ECMAscript features.

That being said, there are some new tools to pickup and learn. They provide a ton of value and the learning curve is negligible compared to picking up an entirely new Javascript framework.

Static Site Generators (SSG)

As I've mentioned above, one of the key elements of JAMstack applications is the use of prebuilt markup. Think of every server-side template you've ever used. Without a doubt, many of the pages generated from those templates did not really have to be rendered on each http request for a given page. The templates served as a convenient way to avoid manually writing tons of HTML. That's exactly what these SSGs do. You define a template within the framework of an SSG. Then, the SSG processes that source and outputs it in a static format of JS, CSS, HTML, and other assets. It provides the convenience without losing the performance benefits of static content.

Managing Deployment

Updating a codebase every time that the static content changes will lead to more deployments. Luckily, there is a large community working to make automated deployments much more straightforward. One of the big names that you will come across when searching for a solution is Netlify. Their service will update the available version of your content following commits to a git repository.

Getting Started

Once I understand the concepts and tools around a new framework or technology, my next question is usually around how much is required to get it up and running. For JAMstack applications the answer can be very straightforward, but in true client-side fashion, there are a ton of options. Here are a few that I recommend:

  • Netlify Templates
    These templates allow you to deploy an app for a variety of SSG libraries on Netlify with one click. You will be able to connect and view the code in either Github or Gitlab. There will also be a live version available for testing at a randomly generated url.
    If you want to get up and running a bit faster, then you can use a Codesandbox template to view the code for a SSG like Gatsby with the option of deployment via a few different services.
    -Local development with Static Site Generators
    For a local development option, you could follow the instructions by Gatsby or Hugo to generate your first project.


We've gone over the basic principles of JAMstack applications and the tools to help you get started. I hope that you've found this introduction to be useful. These concepts and tools will certainly play a role in my workflow going forward.

Subscribe for my latest posts and weekly news review