[PinkPigeon]

It's sort of funny to see how this has suddenly become such a big term. I started out building a CMS that deploys static sites. I did that because I didn't want to deal with DBs / Wordpress, etc. I just wanted to quickly throw static pages onto a CDN and not worry about hosting. Netlify and the likes enabled this and I thought it was rather fantastic. So easy to deploy, very little performance worries, no DB to secure etc. etc. Then the JAMStack term started showing up (pushed by Netlify initially, I believe?). And you're right, just like 'serverless' (which is a ridiculous misnomer), I think this is just the kind of thing that's needed to get non-technical people on board with a better way of doing things.

At the same time, I think there's true advantages to this approach, so long as you do things right and don't fall into the traps of paying through the nose for things that should be cheap. cough Netlify form handling.

The challenge for Netlify (and my own business as well) is finding a way to capitalise on static sites, so often they will decide on some arbitrary metric and restrict that.

So, while I think the term jamstack may go away, I feel the idea behind static sites probably won't. To be able to make a whole shop, including financial transactions, without a DB in sight is quite appealing imo.

Just don't get suckered into the walled gardens / closed ecosystems out there.

[felipeccastro]

I get how static sites are useful for readonly content, but what do you mean by "financial transactions without a DB in sight"? Even in jamstack you still have an API backed by a DB, no?

[PinkPigeon]

Ah, you are right, my wording was imprecise.

If using something like snipcart, you can then have a whole shop without you yourself having to maintain or admin a DB, it's all managed by a third party. They do, however, still maintain a DB themselves.

For my product I am planning to create a Stripe-based shop-module, which would allow anyone to create a shop using their own Stripe credentials. This would require some API calls coordinated by our own server and therefore some DB entries, at which point the sites cannot be considered pure readonly from our side.

All of this reminds me of the horrible misnomer 'serverless'...it's servers everywhere. And even the whole 'without DB' moniker doesn't hold up if things get a bit more involved. Maybe ultimately it's worth calling it the "let's try to keep sites as static and readonly as possible"-stack ;)

Thanks for the observation!