Last week, when asked for to share a contrarian position, Nicole Sullivan posted something that drew a lot of people's attention:
Needless to say, the people who love to hate JAMstack loved it and the rest of us (who love to love JAMstack I suppose) were more than a bit put off.
The thing is, Nicole is not wrong. The JAMstack term was, in fact, all about branding. It was created by the folks at Netlify in 2016 as a way of rebranding what, until then, we'd called "static sites." We've seen enough of this kind of rebranding before in the developer ecosystem to be skeptical - such as when Netscape famously changed the name of LiveScript to JavaScript in order to capitalize on branding opportunities with Sun's Java despite the lack of any real-world connection between the two. But, I'd argue that in the case of static sites to JAMstack, the goal wasn't to manipulate developers with empty marketing jargon, but to make the name more appropriate to the solution.
What's Wrong with Static Sites?
We still call tools like Hugo or Gatsby static site generators, so why would the end result of the process not be a "static site"?
The truth is that for a long time, they were by and large static sites. When I wrote my Static Site Generators report for O'Reilly back in 2015, I listed 3 criteria for determining if your site was a good candidate for being a static site:
- Focus on Delivering Content - static site generators at the time were heavily focused on creating and delivering long form content (usually written in Markdown) and that's what they were optimized for.
- Low Degree of User Interactivity - sure APIs existed at the time, but adding something like a login or a shopping cart to a static site was complex and, largely, the services to support that didn't yet exist or were in their infancy.
- Update Infrequently - building and deploying these sites was cumbersome and slow. Services like Netlify were new, so a the time most were deployed via FTP.
As you can see, these do not apply in any way to the modern JAMstack. That's because static sites described only an end result (static files) and JAMstack is about a way of building sites that, while deployed as static files, are far, far from static, either in the build process or in the end result.
Why People Love to Hate the Name JAMstack
First of all, developers love to hate so-called buzzwords even as we proliferate their existence. Think about the fact that you can't use the term serverless without addressing the complaint that there are servers involved (do you know a developer who is unaware that serverless code runs on actual server somewhere?). We talk about IoT, VR/AR (or even XR), DevOps, DesignOps, continuous deployment...the list goes on. For a group that professes to hate buzzwords, we sure do love to use them. And for all our complaints, no one typically has a better, non-buzzword name for things anyway. (Even if they did, wouldn't that thereby be the new buzzword in the end?)
So part of it is generic buzzword hate. The other part is based on a legitimate complaint: JavaScript, APIs and markup (the JAM in JAMstack) can describe pretty much every site on the web. Overly generic sounding buzzwords immediately set off most developer's BS detector.
My answer is twofold:
-
Despite the acronym, JAMstack is more about how you build your site not the ingredients of it. Or, as Divya said in her post What makes a site JAMstack?:
The JAMstack is a methodology rather than an outcome. You could say that a JAMstack site is a static site but a static site is not necessarily a JAMstack one.
I don't have a better name suggestion. I didn't back in 2016 when Netlify first shared the name with me, and I still don't. Do you?
Is there Substance to the JAMstack?
Up to this point, we've covered why a rebranding was necessary for "static sites" and some of the issues people have with the JAMstack name, but back to Nicole's original case that there is no substance to it. Three (or so) years ago, you could make the case since the reality of static sites hadn't changed with the move to JAMstack, even if the rebrand was necessary to counteract people's misconceptions. However, so much has happened in those three years and so much new ecosystem exists around the architecture, that I do not agree that the name is just marketing.
Today's JAMstack ecosystem isn't just about static site generators mixed with some serverless functions and API calls. There are companies and tools built specifically for addressing this architecture, from adding registration/authentication, to enabling ecommerce and shopping carts, to allowing inline creating/editing of content for non-technical content creators. So much has changed in those few years that, in looking to update our O'Reilly book "Working with Static Sites", Ray and I determined it would be basically a complete rewrite.
Yes, JAMstack still sounds perhaps too vague and all-encompassing. It's an imperfect term that can be justifiably called marketing, but it still describes something important that should not be dismissed.
Top comments (9)
There are way too much hype driven development so I think that being skeptical of buzzwords is a helpful attitude in general.
now it's too easy to be picky on the name. we all know that naming is a hard problem of computer science.
Where is the substance? is a better question.
I would reframe it this way:
What are the use cases in the real world?
Which pain points is it solving for whom?
When is it a good trade-off?
And here I think that the JAM ecosystem has pretty good answers to this, no matter how you call it.
By contrast the Bitcoin/Blockchain people make extraordinary claims all the time, but the main non-fake use case they have today is still unregulated internet gambling on the price of the Bitcoin.
I love the philosophy of JAMstack. I'm completely sold on client-side rendering and CDN hosting (and Progressive Web Apps, while we're at it) so why not push as much rendering as possible to build time? I can fetch dynamic data at run-time via API so...why not!?
...but the name does irk me, and I think it confuses and turns people off.
The "J" specifically refers to the subset of the JavaScript that runs in a client. The "M" is just kinda...weird and seems closer to an implementation detail to me, undeserving of a spot in the acronym.
The "stack" is also problematic. I've done a few JAMstack talks and devs that are new to the subject are often tripped up because it's not a prescribed set of components like other stacks (MEAN, LAMP, ELK etc) and the conversation often devolves into what tools are (or can be) JAMstack-y.
That said, I recognize that naming is hard and it's better to have a weak name with an accepted meaning so that we can talk about these subjects at a higher level of abstraction. #TeamJAMstack
For fun, a few other weak terms that I've learned to live with:
You are spot on about the problems with the term...I always end up talking about stacks within the stack. The lack of prescriptive solutions is both a positive and a negative. And, yes, I've also come to accept some other problematic terms for lack of a better option, though I still can't accept "full stack" and I will die on this hill 😤
The funny thing is developer are people and people are simple. I'm a Java developer most of the time and we love entities, beans, dao, dtos and what not because they have a name.
Names actually directly corralate to adoption. So since the above mentioned objects had names everyone used them even in cases where it was not needed and a simple class could have been used. So to stop that an abbreviation, pojo, was spawned (plain old Java object). And then usage of basic Java classes went up.
Think about it. You can say JAMstack to someone and that automatically fills them in on a number of assumptions around the context. It's also easier to Google a name like that than 3 different ideas. People can write about the pros and cons and blah blah blah why mine is better than yours. Standards can be asserted around a name (cough cough agile).
Point being JAMstack while some might hate it. Since it's named they can talk about it. The more something is discussed like that the more of a thing it becomes.
So love it or hate it the name is doing, more the likely, what it was intended to do.
Just for reference here is pojo's wiki (chuckle at the first quote):
en.m.wikipedia.org/wiki/Plain_old_...
You've summed up how I feel about the name, it's not great but it lets us have a conversation about the philosophy behind it without first spending a few hours agreeing upon terms.
See also, "serverless", "full-stack", "software engineer", "software architect", etc
lets just stick with SSR :)
SSR to me implies that it is just-in-time rendered upon request. JAMstack is compiled/rendered at build time. There is a distinction in both deployment and hosting that is critical.
Agreed. The name that works in this case is perhaps pre-rendered. I hesitate to use that in the broader name though as I think it is too deep in the weeds for most folks who would be unfamiliar with JAMstack.
Yeah, pre-rendered makes me think traditional static-site and not what JAMstack is currently capable of.