The Semantics of Jamstack

This content originally appeared on CSS-Tricks and was authored by Mike Neumegen

The past year has seen a healthy debate around the term ‘Jamstack’ as the definition gets stretched to include new use cases. I recently posted my take on a Jamstack definition in “Static vs. Dynamic vs. Jamstack: Where’s The Line?” In this article, I want to look at the evolution of Jamstack and what that means for the term.

Developers have been creating static sites long before the term Jamstack was coined. The most common use case was an easy way for developers to host their blog or open-source documentation on GitHub Pages. Some pioneers were pushing larger, commercial projects on static sites, but it certainly wasn’t as common as it is today.

Static sites had been perceived as limited — old technology from the 90s. Why would forward-looking companies want to use this ancient way of building websites? Phil Hawksworth hit it right on the button in his IJS talk about static being a loaded term:

Are we talking about a static experience, or are we talking about a static architecture?

The potential for ambiguity is incredibly confusing, especially to non-developers. The static websites of the 90s are not the same as modern static sites. There are new technologies that warrant giving static sites a second look:

• JavaScript has evolved into a powerful language for building applications in the browser. Gmail launched in 2004 and was the first mainstream application to make heavy use of Ajax.
• Static Site Generators (SSGs) have brought many dynamic site advantages such as layouts and separating content from code. Jekyll was the first widely popular SSG, launching in 2008.
• CDNs used to be a technology that only large enterprises could afford. When AWS Cloudfront launched in 2008, you could set up a CDN in minutes, and at a small scale, it would only cost you a few dollars.
• Git workflows, and the CI/CD tools built around it, have made error-prone FTP deployments a thing of the past.
• Ecosystem — there’s a growing number of standalone tools you can drop into a static site to enable extra functionality, from search and eCommerce to databases, comments and more.

Jamstack helped change people’s perception of static websites. And the shifting winds on static were what lead Matt Biilmann to coin the term Jamstack itself in 2016. Suddenly, we had a word that captured the benefits of modern static sites without the baggage of static. Cassidy Williams does a fantastic job of capturing the essence of Jamstack:

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.

Jamstack struck a chord with many WordPress developers in particular. Coming from the world of intricate theming and plugin APIs, the simplicity and control you got with an SSG was refreshing. The movement had begun, and a community formed around Jamstack’s decoupled approach.

As Jamstack grew in popularity, so did the size and complexity of projects. We saw the principles of Jamstack move beyond websites, and as they made their way into web applications, we soon reached the technical limits of what a static site was capable of doing. Platforms added new features and workflows to expand Jamstack principles, allowing larger and more complex applications to take a Jamstack approach.

I’m excited to take part in this evolution with CloudCannon. We’re seeing a significant shift in how developers build software for the web. There’s a flourishing ecosystem of specialty tools and platforms enabling front-end developers to do more, and for sophisticated applications to live at the edge.

My concern is we can’t agree on what Jamstack actually means. We have succinct definitions that paint a clear boundary of what is and isn’t Jamstack. Many of my favorites are in this article. We’re seeing the term Jamstack used for more and more dynamic behavior. Some of the community is on board with this usage, and some aren’t. Ambiguity and perception were the original reasons for coining the term, and we’re at risk of coming full circle here.

It’s a difficult problem the Jamstack community faces because there is so much cross-over between the original meaning of “Jamstack” and the new, evolved, more dynamic-ish usage of the word. I’m conflicted myself because I love the idea of applying Jamstack principles to more dynamic approaches. I briefly considered the idea of using “Jamstack” to describe static usage, and “Jamstack++” the more dynamic usage. But quickly realized that would probably create more confusion than it solves.

Matt Biilmann nailed it with Netlify’s announcement of Distributed Persistent Rendering (DPR):

For any technology, the hardest part is not establishing simplicity, but protecting it over time.

This perfectly captures my thoughts. It’s reassuring to know I’m not limited if I build a new project with a Jamstack approach. If my site gets enormous or I need dynamic behavior, I have options. Without these options, Jamstack would be seen as a limited technology for small use cases. On the other hand, the more we emphasize these more dynamic solutions, the further we get from the elegant simplicity that created the Jamstack movement in the first place.

DPR is an exciting new technology. It’s an elegant solution to the painful limitation of prebuilding large sites. For a 100k page site, would I make the tradeoff of prebuilding a subset of those pages and have the rest build on demand the first time they’re requested, thus reducing build time significantly? Heck yes, I would! That’s a tradeoff that makes sense.

I’ve been doing a lot of thinking about where DPR fits into the Jamstack picture, mostly because it’s right on the edge. Whether you include it or exclude it from the Jamstack umbrella has rippling ramifications.

Sean Davis has a Jamstack definition I’m a fan of:

Jamstack is an architecture for atomically building and delivering precompiled, decoupled front-end web projects from the edge.

This resonates with what I believe Jamstack is all about. If we’re to include DPR in this definition, it needs some work:

Jamstack is an architecture for atomically building and delivering precompiled (or on-demand generated webpages, but only if it’s the first request and then it’s persisted), decoupled front-end web projects from the edge.

The official Jamstack definition works better for DPR:

Jamstack is the new standard architecture for the web. Using Git workflows and modern build tools, pre-rendered content is served to a CDN and made dynamic through APIs and serverless functions.

DPR either delivers content using a serverless function or as static file through a CDN so it fits the definition.

It’s interesting to see how the definition has changed over time. Before late 2020, the official Jamstack definition, posted directly on Jamstack.org at the time, was as follows:

Fast and secure sites and apps delivered by pre-rendering files and serving them directly from a CDN, removing the requirement to manage or run web servers.

Technology evolves over time, as does language, so it’s great to see the definition tweaked to keep up with the times. Introducing “serverless” into the definition makes sense on one hand as the technology is becoming more approachable to front-end developers, who are the predominant Jamstack audience. On the other hand, it goes against the core Jamstack principles of pre-rendering and decoupling. Do we need to update these core principles too?

I’m still processing all of these thoughts and ideas myself. I’m a big fan of Jamstack, it has served as a major catalyst for the growth in static site generators, and given us a language to talk about the approach of pre-rendering and decoupling websites. Looking ahead, I can see five directions Jamstack can go:

1. Jamstack is cemented in its original meaning, prerendering and decoupling. The more dynamic, Jamstack-inspired approaches get their own name.
2. Jamstack evolves and the definition and principles are expanded. As a result, the meaning likely becomes more ambiguous.
3. Jamstack is the name of the community. It’s a set of guidelines and there are no hard and fast rules.
4. Jamstack has lifted the baggage of static, and we can talk about static vs. hybrid vs. dynamic websites.
5. Jamstack becomes mainstream enough that we can simply call it modern web development.

There are people in all of these camps pulling in different directions, leading to much confusion and discussion in the community. What is clear is that this community of people is deeply passionate about this approach to building websites. Frankly, I couldn’t be more excited about the innovations happening in this space. What we need is consensus and a path forward. Without this, I believe, for better or worse, we’re going to end up with a mix of options 3, 4 and 5.

---

The post The Semantics of Jamstack appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

This content originally appeared on CSS-Tricks and was authored by Mike Neumegen