DEV Community

Discussion on: Is JAMstack All Branding and Little Substance?

Collapse
thejoezack profile image
Joe Zack • Edited on

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:

  • Driveway / Parkway
  • Full-Stack
  • Serverless
  • Software architect/developer/engineer
Collapse
remotesynth profile image
Brian Rinaldi Author

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 😤