Whew, I have *thoughts* on this article from @ricmac: https://thenewstack.io/is-jamstack-toast-some-developers-say-yes-netlify-says-no/
Jamstack as a meaningful term lost a lot of power because it was diluted to include practices that went against the original definition.
If we want Jamstack to continue to be relevant and useful—we (as a larger community *independent* of Netlify) need to clarify the definition to have a meaningful and consistent technical foundation.
Zach Leatherman 4343 replies 3131 likes1313 reposts Original on Mastodon43 replies
and that’s maybe the uncomfortable crux of the thing—Netlify doesn’t seem particularly interested in investing or shepherding a community around Jamstack moving forward (whether it agrees that the term is toast or not) evidenced by shuttering the Jamstack Discord, the retirement of Jamstack Conf, the likely closure of the Jamstack Community Survey (given @seldo’s departure).
For me the logical next step here would be for new leadership to step in to clarify and shepherd Jamstack moving forward.
Personally, I nominate @remotesynth 😅
@zachleat Agree with all your points. I'm torn because the closest replacement is "full stack JavaScript" and I don't like that at all. So, I'd love to keep the term in some respects (though we could debate if it's too late already) but Netlify would have to decide whether they want to maintain control or actually keep the term and community alive.
@remotesynth yeah—maybe I should ping some Netlify folks.
I don’t think I would agree with “full stack JavaScript” either since I’d argue that Jekyll was OG Jamstack. @bridgetown is another modern Jamstack tool, too!
@zachleat agreed. But there's no good alternative at the moment.
@remotesynth @zachleat zero build steps, dynamic rendering, and a cache-control header is quite reasonable (but ack it's not a slick pitch)
@brianleroux @zachleat So ZBSDRCCH for short. 🤣
@remotesynth @zachleat gesundheit
@zachleat Rule 1-100 is "Jamstack is SSG only". I will die on this hill.
@zachleat @ricmac I try to think back on what my pitch was to clients back in the day. I recall points like:
Price: hosting a static site is easy!
Performance: a static site is wicked fast and with a CDN, never worry about traffic spikes!
Security: you can't hack into a static site! And atomic deploys means we can roll back at any time!
Cheap Development: I can whip a static site together much faster than a huge, cumbersome WordPress deploy!
No Maintenance: host the latest commit forever!@zachleat @ricmac So for me, JAMstack simply clarified that we could still layer in some "dynamic" features like a shopping cart or a contact form or an events calendar right on top of the static part, plus we could minimize promoting the term "static" which to normies doesn't mean anything useful.
I still think all of these aspects are 100% cool!
@jaredwhite @ricmac yeah!
My 🌶️: request-time rendering (what some frameworks call SSR: Remix, Enhance, Next.js ISR, even Eleventy Serverless/Edge) is *not* Jamstack
@zachleat @jaredwhite @ricmac Not spicy 😅
Enhance is a full stack web framework thing.
It aims to be as easy and accessible as JAMstack things (arguably some ways to go on this). But the JAM definition was changing right as we started talking about the project. So… 🤷♂️
To me, JAM was: “add dynamism to static sites without introducing a 1st party server” - but I don't even think that was well agreed upon.@tbeseda @zachleat @jaredwhite @ricmac that being said, having heard what Brian and Simon have said multiple times, the argument ends up being that SSGs aren't needed anymore because tools like Enhance make SSR performance impacts negligible...meaning no need for JAM at all.
@remotesynth @tbeseda @jaredwhite @ricmac yeah, that’s where I get lost, personally. I think there is room for both and more-so SSG is a better default for a lot of projects—but I’m also fine agreeing to disagree there too
@jaredwhite @zachleat @tbeseda @ricmac I like this. Perhaps:
JAM
JAM+
JAM Ultra
JAM Ultra 256GBThoughts?
@remotesynth @jaredwhite @zachleat @tbeseda @ricmac Seriously - no one suggested JAM XP ?
@raymondcamden @remotesynth @jaredwhite @zachleat @tbeseda @ricmac
Minimalist
APIs
Reactivity
Markup
Async
LLM
Automation
DNS
EventsOr MARMALADE for short.
@Jbasoo @raymondcamden @remotesynth @jaredwhite @zachleat @tbeseda @ricmac Vote to make this the official theme song https://www.youtube.com/watch?v=RQa7SvVCdZk
@jaredwhite @zachleat @remotesynth @tbeseda @ricmac Missed opportunity to call it JAMax
@zachleat @remotesynth @tbeseda @jaredwhite @ricmac If you don't need dynamic personalization use SSG but if you do I've found SSR to be the better solution. I've been bitten, more than once, by folks who say they only need a static site then as soon as it is released they start asking for dynamic capabilities and now you have a round peg/square hole situation.
@zachleat @remotesynth @tbeseda @jaredwhite @ricmac Although performance may be negligable, the other reasons @jaredwhite mentioned remain valid to go SSG-first, but it’s becoming more of a DX/maintenance/financial thing than something users reap the benefits from; we’re entering preference territory. (Although I do think good DX leads to better products so yay to SSG!)
@timsev @zachleat @remotesynth @tbeseda @ricmac One more data point to throw out:
Helped a client upgrade their SSG site a while back so it could pull data down from Prismic.
Recently heard that a new regime in town decided to ditch everything and recreate the site from scratch using Wix. 😅
I think some devs out there may not care to admit that while we're over here squawking about SSG/SSR/JS/PHP/Ruby/whatever, people running orgs are clicking buttons on Squarespace or Shopify…
@jaredwhite @zachleat @remotesynth @tbeseda @ricmac Definitely! It’s one of the reasons I’m in the automation (with a web UI) space, which is less under threat by these website builder tools that are arguably kinda good. We can argue over quality, but full control, no big investment upfront, and only for a couple of $currency a month that’s probably less than your average SLA? Sounds great
@timsev @jaredwhite @zachleat @tbeseda @ricmac iirc under the covers wix is ultimately an SSG
@jaredwhite @timsev @zachleat @remotesynth @tbeseda @ricmac Real talk.
I'm busy at my main job, but when I have prospective side work, I sometimes find myself evaluating if I should experiment with a new stack or if I should point them to Wix or some equivalent (which could save them and myself time/effort in the long run).
The first approach is so tempting due to the nerd/research appeal, experience it provides and etc.
@remotesynth @zachleat @jaredwhite @ricmac I think a lot of what JAM addressed was speed and cost (in addition to dev accessibility!). IIRC this is also why we started down the SPA path too. Servers were slow to query dbs, render HTML, and then real pricey to scale. These are much less true now. Though, we do need to work on making full stack (“multi-page”?) apps easier to build. That's something I always enjoyed about the JAM philosophy.
Oh and there's definitely room for more static sites 👍@remotesynth @tbeseda @zachleat @jaredwhite @ricmac
It was never about performance, was always about ease of deployment. There, static is undefeated.
@tbeseda @jaredwhite @ricmac Glad to hear that it’s not a spicy take! (and yeah, that largely encompasses what I thought the definition was too)
@zachleat @jaredwhite @ricmac
from what I recall of the initial pitches I heard, it was static assets and all interactivity happened client side through javascript, so I don't think thats a 🌶️ , I think thats what it was sold as.
I think it was an overreach, maybe to hold more under the same umbrella and inflate popularity numbers?@zachleat @jaredwhite @ricmac COULD NOT AGREE MORE! That's just PHP reinvented.
@jaredwhite @cferdinandi @zachleat @ricmac now that’s it. That part. I seriously don’t get this unreasonable hate for PHP.
Reinventing dynamic websites on the jamstack, but we‘ll charge extra for its services. And it only works on our service so you’re locked in.
Oh wait, sounds almost like a business case.
@nachtfunke @jaredwhite @zachleat @ricmac I literally wrote an article the other day about how are use plain old PHP files to create API endpoints for things. I love, PHP! Unironically!
