Author: Cassidy Williams
Chances are, if you’ve been interested in web development lately, you’ve heard the term “Jamstack” thrown around. It can be confusing and hand-wavey, so let’s learn about what it actually is, why you want to use it, and how you can apply it to your projects!
A little history
Matt Biilman coined the term JAMstack (later changed to Jamstack) in 2015 while working on projects and sites that were being called static but were… more than static. These sites had the front end separated from the back end, meaning the building stage was separated from the hosting stage, and they took advantage of modern Content Delivery Networks (CDNs.) They were interesting, but there wasn’t yet a word for them. And thus, JAMstack was born! The acronym originally stood for JavaScript, APIs and Markup, but because these sites were so much more than that, “Jamstack” evolved from an acronym into a name!
What makes a site “Jamstack?”
My favorite definition to wrap my mind around Jamstack is the following:
Jamstack is about building web applications in the same style as mobile applications: the UI is compiled, and then data is pulled in as needed.
- Me, Cassidy, hello
I didn’t fully understand what the big deal was about Jamstack until I started thinking of it this way. Data can be pulled in whenever you like (e.g., when you build the site, when you load the site, when content is visible, when content is interacted with). It’s about the separation of concerns when you build it!
A lot of folks think to build a dynamic website, they need to build a server-side rendered application (where the server sends all of the HTML/CSS/JavaScript needed, and these are compiled when a user asks for it) or a client-side rendered application (where pretty much the entire application is built inside the user’s browser). These are still totally valid mental models, but they are different from Jamstack. They both follow the idea that a user asks for the page and that the application returns to the user. Jamstack still has elements of this, but the major difference lies in when.
The phases of rendering
In a Jamstack website, there are two phases of pulling and compiling pages, content, and data: Build time and run time.
- Build time: When you host your website, you can pull in data as soon as it’s pushed. As the site compiles the native HTML, CSS and JavaScript, the APIs are called, the CMS is pinged and the database is queried. If you pull your data here, when your user goes to your website, you don’t have to make any more data calls! The APIs were queried once at build, and because the data are the same for everyone, you don’t have to worry about being rate-limited because the data were already pulled and the site is built once with it. This is ideal for pages whose data don’t change a lot per user, like marketing websites, blogs, or e-commerce sites.
- Run time: This part of Jamstack is similar to a single-page application or a client-side rendered application. The data may be more user-specific or need to be updated frequently, so it has to be run in the user’s browser. This may be something like the current inventory of a product on a website, the current logged-in user’s avatar, or the weather at a user’s given location. Server-less functions can be particularly useful for querying data here, as well.
Brian Rinaldi, editor of the Jamstacked Newsletter, phrased these concepts of data very well: “Dynamic data isn’t just a client-side thing in a Jamstack application, and Jamstack developers need to think about each piece of content/data in terms of when it should be retrieved and rendered.” Once again, it’s all a matter of when!
Decoupling
The real power behind Jamstack development is decoupling your systems and services. By giving them a clean separation to run your site, each of them can be independently swapped out or upgraded and can own a certain domain of what you’re building. You can have one service handle authentication, one handling content, a couple handling the database and even different parts of your front end in different repositories. The massive amount of services and tools that you can use to put your sites together is growing daily and it’s an exciting time to be building in this way.
Start your own Jamstack website
You can start implementing the Jamstack style of development today. Your work has probably, at one point or another, fallen under this definition without your realizing it! The shift away from large, monolithic applications is happening in a big way and the future of web development is bright.
Here’s a set of resources that may be useful for you as you go off to build your own Jamstack-style sites:
- Jamstack Conf
- JAMstacked newsletter
- Jamstack Themes
- Site Generators for Jamstack sites
- Jamstack Slack and in-person events