What does the future hold for Jamstack?

I recently participated in a panel discussion around the future of the Jamstack. While the “tech stack” is not being talked about as much anymore, there was an obvious passion and love from the panelists and the audience watching.

Without a corporation driving the term forward, is there a path for the Jamstack to continue as a term and as a community?

That is the question that the panel comprised of Cassidy Williams, Salma Alam-Naylor, Zach Leatherman, and myself attempted to answer.

You can watch the full video here, but I’ve also compiled some of the discussion points that I found interesting for this article.

#Proposed Tenets of the Jamstack

During the panel discussion on the future of the Jamstack, several proposed tenets were highlighted as key aspects of this approach to web development.

Immutability

We found the concept of immutability to be incredibly important, despite the jargon-y nature of the term. The idea of achieving discrete deploys that wouldn't break, regardless of the timing, was important.

Both Cassidy and Salma mentioned specific times that immutability was important with Salma mentioning a blog post she had written that included a link to a previous deploy that eventually broke because of using ISR – a feature often considered “Jamstack” in nature in the previous definition.

From "compile", to "build", to "delivered as"

Another important aspect we discussed was the idea that the Jamstack should involve the compilation or building process that ultimately results in static HTML, CSS, and JavaScript files. This lends itself to the ideas of both portability and immutability. Still, it is an important step in making sure we have a definition that can mean something instead of the current definition that tries to be too much to too many people.

During this segment, I mentioned that if we framed the Jamstack more like how TypeScript gets framed, it might find greater traction with the tech community at large.

By raising analogy, I think the idea that errors happen at “compile” time keeps one of the important aspects of the Jamstack alive: If you push code with a bug, it should error the build and not break your website.

We also discussed whether or not a CDN is required for the Jamstack. Most people would agree that CDNs are important, but I think most of us were on board with the idea that a single HTML page could be considered “Jamstack” even served from a static server and “built” by just typing HTML and not at “build time.” There’s definitely more to be discussed here, but HTML definitely feels like the important part.

Portability

We also agreed that avoiding vendor lock-in is crucial for the Jamstack ecosystem. We see the ability to seamlessly switch between different services or platforms without significant disruptions as a positive aspect that was partially destroyed as Jamstack hosting companies actively began to strive for lock-in with certain features and proprietary services.

As mentioned with the compilation tenet, the ability to move a set of files from one service to another should be possible. We also suggested that potentially a set of specifications around things like serverless/edge functions and other functionality would be beneficial to making developer experience around the Jamstack and other technologies stronger.

Cassidy raised the analogy that with the Jamstack, we could view the browser as an operating system, and treat our websites and apps as pre-packaged applications that run on that OS. With that analogy the idea of specifications feels stronger, as the browser itself runs on specifications that all major manufacturers work to agree upon.

#Is Jamstack evolving from a tech stack to a pure community?

A large part of the discussion also centered around the idea of the Jamstack as a community rather than a tech stack. The technology didn’t matter as much as the group of people who discussed the technologies that centered around a set of core tenets.

We all discussed how the community felt and what sorts of values the Jamstack community brought to us as community members.

A large thing we’ve been missing since the closing of official Jamstack community spaces is the idea of cross-technology information sharing. Whether that’s using multiple SaaS solutions in one example or sharing the newest information from technologies that we don’t follow, having a community in one space meant that it was easier to stay “up to date” with the overarching technology space surrounding the Jamstack. Things like new APIs, media services, CMSs, databases were all shared, discussed and experimented with. In the current age of the community, we’ve fractured into technology-specific communities and this umbrella space is lacking.

#Hearing from the audience

While the audience was relatively small (only 55 viewers at its max), it was highly engaged and seemed to really resonate with much of what the panel was discussing. It feels like there’s still some hunger for the ideas of the Jamstack, and I think a hunger for the community that we’re all missing.

#Where we go from here

While we don’t have any concrete plans, I think it’s safe to say that the concepts of the Jamstack are still resonating with folks and it’s still an important space to operate in.

I was very happy to see folks being passionate about this space that I’ve worked in for many years now. I think there will be more discussions about this in the future, and while the Jamstack (as we’re hoping to define it) is not for everyone or every project, I think it still fills an important niche in our web development ecosystem.

I know I’m not ready to give up on it.