After my Ok Boomer post, I wanted to dig into “JAMstack” technologies and try to challenge my assumptions about modern web development. As it turns out, while this is a term I’m only recently familiar with, the JAMstack concept is actually about four years old (at the time of this writing), which feels like forever in this industry. For comparison, React was initially released about 6.5 years ago. This is the trap of talking about technologies from the perspective of being an old fart in the programming community: tastes move so quickly that by the time you’re aware of the cloud, you’re already shaking your fist at it.
The JAMstack has been iterated on since 2016, so there are a ton of great online resources and blog posts about it. Instead of adding to the noise, I thought I’d highlight some of the resources I found most useful for someone new to the concept. If you’re unfamiliar with the phrase “JAMstack” or are trying to wrap your head around it, here’s my list of reading materials to get you started.
Tune Up Your Definitions
The obvious place to start is the jamstack.org website. Maintained mostly by developers at Netlify, this site has some good links. Unfortunately, it’s pretty abstract and doesn’t actually tell you much about what a JAMstack looks like in practice or how to get started. I would recommend checking out a few of the videos under the Resources section, but otherwise, you can just bookmark this site to check back later for future improvements.
A better intro to JAMstack is the Why you should be using JAMstack blog post from June of last year over on the LogRocket blog. The author, Obinna Ekwuno, does a good job providing some historic information on web development stacks (remember LAMP?) and how the JAMstack compares.
Get Amped By the Possibilities
Now that we’ve got a basic picture of what a web app developed and deployed on a JAMstack looks like, let’s take a closer look at workflows and how you can actually create a JAMstack site. This New to JAMstack post on the Snipcart blog, by Mathieu Dionne, does an excellent job of summarizing the history of JAMstack methodology. Mathieu dives into the goals and components of a JAMstack and the specifics of getting started with a new project. There are also a bunch of other great resources linked throughout the post.
Towards the end, there’s a section on “Refuting common objections,” which is pretty terse. To better understand how a JAMstack can handle some of the more dynamic and complex aspects of modern web apps, check out this excellent recent post on Smashing Magazine, Adding Dynamic and Async Functionality To JAMstack Sites, by Jason Lengstor, another Netlify developer.
Finally, you can dive into this very thorough three-part tutorial on building a fully dynamic polling app on a JAMstack (Part 2, Part 3). There are a few parts that are a bit out of date now, but it’s still an excellent example of exactly how to develop such an app.
Kick out the JAMs
After all of this research, I’d summarize my own understanding of the JAMstack as a web development philosophy primarily concerned with eliminating server-side rendering of pages and maintenance of custom backend server architecture. Technically, a basic HTML page with zero Javascript, stored in an Amazon S3 bucket, would be a JAMstack site.
But maintaining such a site, especially routed behind a custom domain, with multiple pages and added dynamic functionality, would be a real pain. Companies like Netlify and tools like Gatsby.js aren’t explicitly part of the JAMstack architecture. They’re part of the solution for creating things on a JAMstack architecture like a Progressive Web App built with React that manages complex user state and queries 3rd-party APIs.
Netlify specifically has created a whole business model around reducing the friction of creating and hosting JAMstack sites. In fact, this post on Netlify’s deploying and routing infrastructure provides some cool insight into how they’ve turned something like S3 file storage into a real deployment and hosting platform.
Have We Reached Peak JAMstack?
Despite all of the great writing I’ve linked to here, there are obvious use cases where a JAMstack still isn’t the right tool for the job. For example, an app with extensive user-generated data that makes up the majority of the rendered content isn’t going to be able to take advantage of the performance gains of pre-rendered static assets. In fact, that kind of site may be faster in a traditional isomorphic server-rendered architecture than a JAMstack-like SPA that has to make a query to a 3rd-party API for data before it renders any change of content. This isn’t something that can be “fixed” in a future version of the architecture; it’s just a natural limitation of building sites in this way.
So where will the JAMstack concept take us in this new decade? What I’m most excited about going forward is something I actually couldn’t find much writing on—deploying apps compiled with WebAssembly to a JAMstack, aka the WAMstack. The blend of highly-performant code and pre-compiled assets delivered via CDN seems like the logical next step for games and other resource-intensive web apps. A great early example is Google’s Squoosh App, which does image compression with native codecs right in your browser (even offline!).
Overall, I came away excited to try using JAMstack best practices on the next relevant project I could. I still find myself cringing at some uses of the term “serverless,” and I certainly don’t believe that this spells the end of the need for DevOps and custom IT hardware. But I don’t think the concept of the JAMstack is a fad that will go away anytime soon.
If you care at all about delivering the best possible experience to your users, it’s well worth taking your time to become familiar with it.