The Jamstack Identity Crisis: an Even-Handed Overview

The community is abuzz.

The last few months, we've been debating — as a community — what the Jamstack even is. In the way of a quick summary, we largely split into two groups:

1. The Pragmatists

   This group, pioneered by people like Hashicorp advocate Jeff Escalante, Forestry developer Franck Taillander, and Layer0 CTO Ishan Anand, is pushing to drop the name Jamstack because it's growing increasingly pointless as a descriptive term. They believe its trendiness has worn off and it's becoming restrictive and ultimately vexing as we fight about what's included in the definition.

2. The Resolutionists

   On the other side of the aisle, you've got the folks who want to fix the definition of the Jamstack to include new practices rather than ditch it altogether. In this camp, you've got industry leaders like Bud Parr of the New Dynamic, Brian Rinaldi from StepZen, CloudCannon CEO Mike Neumegen (who wrote an excellent article on this just a few days ago by the way), and the king of performance and accessibility Henri Helvetica.

So far, we've been trying to place a clear border through a fuzzy gradient. We've been asking: "where do we draw the line between Jamstack and the other?"

We're starting to see a consensus, though. Attitudes are cooling and people are starting to come together on a solution. Here's the gist of what they're agreeing on:

The Jamstack as a set of best practices.

It's not a dichotomy anymore. The question is no longer, "is this site Jamstack?" The question is now, "how many Jamstack techniques does this site incorporate?"

That undercuts the whole premise of the earlier debate. If the Jamstack is no longer a restrictive and exclusive category, then you don't have to drop the name entirely to start using some non-Jamstack techniques like dynamic rendering on a monolithic server. You also don't need to redefine the Jamstack to start doing bigger and better things, because you can use the Jamstack label to talk about some of your site without sounding like a purist. Now, we don't need to draw a clear border through a fuzzy gradient, trying to separate Jamstack from the other. We don't even have to place our site on that spectrum at all.

Here are some of those principles:

1. Jamstack sites don't rely on dynamic page-building code on the server.
2. As much content as possible is baked into the markup at build time.
3. Extra functionality is primarily added with third-party APIs.
4. Any necessary custom server-side code is organized in manageable, atomic, decoupled microservices.
5. Most of the necessary assets for the site to load are held close to the client in a CDN.

Perhaps you are prerendering most of your site, but the backend API you've created for yourself is based around a monolithic architecture because your particular use case requires it. That doesn't have to be controversial! You've just used some Jamstack techniques in combination with some more traditional techniques to create an application that works best for you. We can all agree that a hybrid approach like this will — in many but not all situations — work better than either extreme, right?

Consensus is good...right?

From one point of view, absolutely! People who were, at one point, not seeing eye to eye are now cooperating, and that sure is lovely to see.

On the other hand, one of our favorite business articles over here at TakeShape, a 2016 post on the blog "Conferences that Work" entitled "When consensus is dangerous", makes a great point:

"The value of consensus is in the process of seeking it — not a “yes, we have consensus!” outcome."

It's the old adage "it's the journey, not the destination" playing itself out over again. If we focus on the outcome of what the community largely feels the Jamstack is, we might be missing the underlying lesson. This whole ordeal just goes to prove that the people who are participating in this discussion are doing so because they have a passion for whatever they feel the name "Jamstack" represents. That's what's really binding this otherwise heterogenous and diverse community together!

So let's find something new to argue about.

At the Jamstack Philly: Summer of Jamstack event that we organized on July 1 and August 4, 2021, the closing keynote argued that we'll see the next few years of Jamstack development marked by four major trends:

1. We'll take Astro's motto to heart and start seriously shipping less JavaScript. That means going back to the simplicity and bare-bones, lightweight structure of the first Jamstack tools (like Jekyll) while retaining all the functionality of the big platforms that came later (like Next.JS).
2. We'll help non-developers to work with us on equal footing, finding ways to get them interacting with us in the same tools and codebases with clever and intuitive GUIs.
3. We'll see tools that we've come to love like Netlify or Vercel start to separate from the pack with platform-specific features in order to stay relevant.
4. We'll adopt new terminology for the newest techniques we're using (for example, DPR) that are far less specific — in other words, get rid of that spectrum entirely. Some are suggesting calling it just "modern" development.

Let's talk about those! Let's ask new questions to keep the process of consensus going:

1. How far can we push HTML and CSS (and WASM?) to replace the need for the slow and burdensome JavaScript?
2. What tools can we create to remove the encumbrances of our non-developer colleagues and help them work with us on the same plane?
3. If platforms have to innovate independently to stay in business, how can they maintain the cross-platform values that the Jamstack is based upon?
4. If the term Jamstack grows insufficient as we consider more and more practices "best" outside of that immediate category, what terminology will we use to describe what we're doing?

Here at TakeShape, we're putting our money where our mouth is and investing in the future tooling of the Jamstack. We're building out a concept called an API mesh: a tool to stitch together the inconsistent APIs and external services we use all the time in the Jamstack. That's one of the most common tasks we use serverless functions for, and it sure has never been a simple task. All those inconsistencies make merging the data from those disparate services quite a bear, but by offloading that difficulty to a third-party API mesh like TakeShape, you can get only the data you need from a single GraphQL endpoint. It's the key to modern Jamstack development and part of the answer to the four questions above.

We'd love to hear your thoughts on those four questions too! Make sure to tag us on Twitter at @TakeShapeIO and @jadenguitarman with your thoughts and check out our site at TakeShape.io to learn more about our plans.