2020 was a terrible year for a lot of things but it was a pretty good year for the Jamstack. We not only saw a lot of startups in the Jamstack space getting massive funding, but also big companies jumping in as well. For example, Microsoft launched Azure Static Web Apps and, more recently, Cloudflare launched Cloudflare pages. As I argued in the recent issue of Jamstacked, I think we will look back on this year as the year the Jamstack went mainstream.
But are these sites truly Jamstack? I’d argue that, on the one hand, how we define and redefine the Jamstack term doesn’t matter at all in practice, while on the other it is actually really important.
There has been lively debate within the community about whether these sites are Jamstack or not. As with every debate about the term Jamstack, this is colored by the fact that Netlify largely created and maintains the term. This has become more pronounced as Jamstack has gained popularity and, in particular, as companies have jumped into the ecosystem. For instance, while I’m not privy to any of the internal discussion, I largely suspect this is why Microsoft uses the phrase “static web app” rather than Jamstack – because it can be hard to disassociate promoting Jamstack from promoting Netlify. This is no more obvious than with Vercel’s recent funding announcement, wherein the company went from being a Jamstack promoter to attacking the concept of Jamstack as “the dogmatism of pure static.”
Thus the debate has gone from whether hybrid SSR/SSG sites were Jamstack to whether they represented what you might call a post-Jamstack concept.
You may wonder why anyone cares about such an esoteric debate and you’d have a point. The reality for most developers is that these definitions are pointless in the day-to-day work. We aren’t paid according to our strict adherence to the concepts of Jamstack, but to get the job done. If the requirements of a site are best served by building it fully SSR, partially SSR or fully static, then that’s what we should do. We may have a preference for one type of solution, which may guide us, but it doesn’t – it cannot – restrict how we ultimately solve the problem.
This leads many developers to often see this as a debate about marketing. After all, they say, Jamstack was just a marketing term created by Netlify to popularize a set of tools (static site generators) that, not coincidentally, were how you built sites to run on Netlify.
That’s true but…
Let’s go back to 2016 when the term Jamstack was created. Having been an active proponent of static site generators for already some years by that time, it was obvious to me and to others that there was a real perception problem. “Static sites”, as we called them, were seen as purely a niche solution primarily for developer blogs and developer portfolios (and maybe, to a lesser degree, for documentation). No one would build a serious site with a static site generator, right?
By defining a new term, one that dropped the problematic use of “static”, Jamstack helped change the perception of these tools – but it did more than that. It helped define a concept around which we could organize – write Jamstack books, host Jamstack conferences, run Jamstack meetups and so on. Doing so doesn’t just require a term, but a term that has understandable meaning and value to the community. Jamstack was clearly defined enough that it accomplished this and, in my opinion, helped drive the use of these tools from a fringe solution in 2016 to a mainstream one as we enter 2021.
Which is where we get to the problem of how we define Jamstack going forward…
My one big criticism of Vercel’s “attack” on the concept of Jamstack is that it didn’t offer any clearly defined alternative. We “don’t care if an application is CSR, SSR, SSG, etc. as long as [our] end-user is delighted” is exactly the sentiment I shared in the “labels are meaningless” section above but it is not a principle or concept we can organize around or evangelize. It only says what it isn’t not what it is.
My personal definition has room for hybrid solutions, but it is static first, by which I mean every route is assumed to be static unless the specific requirements for that route prevent the possibility of a static solution. So this is a site built upon statically generated assets sprinkled with SSR where necessary, not an SSR site sprinkled with static routes. That is not to say there is anything wrong with the alternative, just that it isn’t Jamstack – and that’s fine, do what works for you. I personally believe that many, if not a majority of, sites on the web can work in a static-first hybrid model of Jamstack. I also think adding some sprinkled SSR doesn’t overly dilute the value of the term.
So for 2021, let’s start first by dropping the JAM acronym (in my opinion, it creates more confusion than it helps nowadays). It’s just Jamstack not JAMstack. It’s an architecture or a methodology rather than a “stack” of specific tools – so, yeah, the stack part of the name is a bit confusing but it’s the name we have. Let’s define Jamstack as static-first and not static-only, making room for hybrid solutions. Finally, as a developer, do what you need to do regardless of whether it fits neatly into Jamstack or not – but learn about and apply Jamstack principles wherever you can for the benefit of your project.