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:
Brian Rinaldi is a Developer Experience Engineer at LaunchDarkly with over 20 years experience as a developer for the web. Brian is active in the community running CFE.dev and Orlando Devs.
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 😤
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 😤