The JAMstack has seen a fantastic rate of acceptance over the past few months, and myriad tools and services can now be used to create fast and dynamic web applications. The JAMstack advocates atomic deploys, which yields more frequent, easier deploy cycles, meaning the latest updates are delivered to users in a simple way.
This has changed the entire development workflow. Traditionally complex applications and features such as authentication, checkout, payment systems, and media management can now be added by a few lines of code. Furthermore, with the JAMstack we no longer use monolith applications, but instead develop smaller components and atomicly deploy them to a global CDN (edge servers). Developers can leverage static site generators, and enhance their site using client-side JavaScript and myriad APIs, which means that they only need to focus on one thing: development. There’s no need to deal with DevOps related tasks.
In this article, we'll review why you should care about this new stack and how to best use it to build faster, more secure websites. You can also watch the talk I gave on this topic at Front Conference in Zurich below.
Tamas Piros - Unleash the Power of the JAM Stack from Front Conference Zurich on Vimeo.
What is the JAMstack?
The JAM part of JAMstack is an acronym of the three core concepts that are the heart of the stack: JavaScript, APIs, and Markup. But we need to dig a little bit deeper to find out what the JAMstack is capable of, and how we can use these technologies together to enable great experiences.
A better, albeit longer, description of the JAMstack is that it allows us to create performant websites using easily accessible services and deploy them faster, without the need for an origin server.
The last part of the description is curious. How come there's no origin server?
An origin server is a server that has an application running on it—typically a web server such as Apache or Express—that is capable of accepting requests and providing a response.
The key takeaway from this is that when you think about a classic setup like the LAMP stack, generating a page happens at request time: a user clicks on a link, a PHP file gets loaded, that file may make a request to a database by way of an SQL query, it gathers data and returns some template which is then rendered as HTML, and that's what the user sees as the end product. This process happens whenever the same page gets loaded, although there are some caching mechanisms available, which means that querying for the data may not need to happen every time. However, the concept is still there: we have server-side code to execute on each request.
"In other words, we pre-render the markup, so that when a user requests a page, there's no need to do server-side code execution at all."
With the JAMstack, our approach is slightly different. What if we generate the HTML files based on templating logic and structure, ahead of time—at build-time? In other words, we pre-render the markup, so that when a user requests a page, there's no need to do server-side code execution at all. The resulting HTML code can be placed to any hosting provider's server, to GitHub Pages, or even just to Amazon's S3, and be served immediately.
The Complete Guide to Web Design Project Management
Read our complete guide to web design project management for developers, designers, and marketers. Learn how to work with stakeholders, manage budgets, and keep your clients happy.
Learn morePre-rendering with static site generators
To achieve what we discussed earlier, we need a tool that is capable of pre-rendering markup. Static site generators (SSG) are designed for precisely this purpose. There are a few static site generators out there today, most of which are based on popular JavaScript frontend frameworks such as React (Gatsby, Next.js) and Vue (Nuxt.js, Gridsome). There are also a few that are non-JavaScript based, such as Jekyll (Ruby) and Hugo (Go aka Golang), or ones that are based on vanilla JavaScript (11y).
"How we pre-render the markup is agnostic to what programming language we use for the tool doing the job."
At this point, you may be wondering why the 'J' in the JAMstack is for JavaScript, when we are talking about Ruby and Go for SSGs. This is, in fact, a question that comes up during most of my talks and workshops. The critical difference is that the static site generators are related to the 'M' in the JAMstack—the markup. How we pre-render the markup is agnostic to what programming language we use for the tool doing the job. The 'J' (JavaScript) bit refers to the fact that we can enhance the application using various JavaScript functionalities, but that's 'client-side' within our app.
This leads me to the second letter in the JAM—APIs.
You might also like: An Insider's Look at the Technology That Powers Shopify.
APIs
You’ve probably heard the expression "standing on the shoulders of giants" before. I find this quote to be very relevant here. Let me give you two examples.
Traditionally speaking (think the LAMP stack), creating a contact form was somewhat challenging. We had to create a form using HTML and JavaScript, and we had to send the data from the form to a backend (PHP) for processing. The server not only had to process the data, but also had to have a mail server configured and running, so that an email could be sent with the data processed from the front end. This required Unix knowledge, amongst other programming skills.
Another example is authentication. Authentication is typically hard: we need to store the username/password combinations in a database, make sure it's secured, generate cookies and tokens, validate them, and so on. But what happens when the database load triples? What if we never had a separate auth database? How do we scale these separately?
Today, there are a lot of services out there that help us create contact forms and authentication more easily. Formspree is one example for contact forms. All we need is to add an action
attribute to our form that points to https://formspree.io/my@email.com
, and that's it.