There is a bit of an irony with Jamstack.
The concept is simple: you put pre-rendered, static files on web hosting (a CDN) designed to do that well. That’s it. If you need to do more, anything you do from there is done with client-side JavaScript, which is likely talking to serverless functions because that’s the spiritual partner to Jamstack on the back end. I heard Guillermo Rauch say at Smashing Conf the other day that it isn’t exactly a “stack” in that it’s almost entirely non-prescriptive in what you do. While I like the word Jamstack, that also feels fair.
The irony is that while the concept is simple, that simplicity can be the cause of complexity.
Netlify, the company largely behind Jamstack, knows this. They know that without a back-end server with back-end languages, something like a basic contact form gets complicated. Instead of being in no-brainer solved-problem territory, we have to figure out another way to process that form. So, they solve that problem for you (among others, like auth and serverless functions). But there are tons of other companies that want to be that cog in your machine.
That’s just one potential complication. What do you use for a CMS or other data storage? What is your build process like? How do you see previews of content changes? How do you do auth? What if you need some fancy calendar widget? What if you want to sell something? Anything a website can do, Jamstack has an answer for — it’s just that combining all those answers can feel disjointed and potentially confusing.
Dave recently played with Eleventy + Tailwind + Netlify CMS (which is Jamstack-y) and said it felt like cattle herding:
So my little mashup, which was supposed to be just 3 technologies ended up exposing me to ~20 different technologies and had me digging into nth-level dependency source code after midnight. If there’s an allegory for what I don’t like about modern-day web development, this is it. You want to use three tools, but you have to know how to use twenty tools instead. If modules and components are like LEGO, then this is dumping out the entire bin on the floor just to find one tiny piece you need.
“The tangled webs we weave,” indeed.
In a conversation between Richard MacManus and Matt Mullenweg¹, Richard quotes Matt:
You can patch together a dozen services, each with its own account and billing, for hundreds of dollars a month, to get a similar result you’d have for a few dollars a month using WordPress on shared hosting,” he said. “And it would be more fragile, because the chain is only as strong as its weakest link. You are chaining together different toolsets, logins, billing, hosting… any part of it going down can break the entire flow.
If I was considering Jamstack for a particular project, and the grand total really was twelve services, I probably would reconsider, particularly if I could reach for a tool like WordPress and bring it down to one. There are plenty of other fair criticisms of Jamstack, particularly since it is early-days. The story of “CMS with Preview” isn’t particularly great, for example, which is a feature you don’t even think about with WordPress because, duh, obviously it has that.
And Jamstack can do some things that are very ahead of the game that I cherish. Git-based deployment? All websites should have that. Previews of my pull requests? Hot damn. Sub -100-millisecond first requests? Yes please. Not having to diddle with cache? Sweet. Catch up, other stacks.
I’m saying there are baby bear choices to be made here. You get there by doing what you’re probably already doing anyway: putting your adult pants on, thinking about what your project needs, and choosing the best option.
I have production WordPress sites. Like this one! It’s great!
I have production Jamstack sites. Like this one! It’s not a complicated web of services. It’s a static site generator with content in the GitHub repo deployed with Netlify. While CSS-Tricks can do about 100 things that this site can’t, it has a few tricks up its sleeve that CSS-Tricks can’t do, like accept pull requests on content.
I feel like I’ve chosen pretty well in all my cases.
- While Matt is clearly incentivized to defend the WordPress approach, it feels to me the opinions here are genuine; in part because Automattic invests in alternative stack approaches, and that WordPress and Jamstack are not mutually exclusive. I enjoyed responses to this, like Ohad Eder-Pressman’s open letter, which is also full of incentivized-but-genuine thoughts.
I think you should play with Publii, it’s great static cms that works locally.
I wonder if there isn’t a bit of a “local optimum” problem going on with Jamstack in that we’ve focused on that specific pattern and kept refining it, without considering that it might not always be the best choice (like this article points out).
That’s why I personally like what Next.js is doing by supporting both the “traditional” static approach but also dynamic server-side rendering, and even (as I understand) hybrid apps that include a mix of both.
Yes. This is where I am currently putting my time and energy.
I agree…
Nextjs + Vercel seems to be ahead of the curve?
I agree with this article. The biggest issue I currently have with Jamstack is that if I want to do more than just a few static pages with a couple dynamic bits, I need to shell out to one of the many startup services that duct-tape the hole. And all those small companies have uncertain futures, as most startups do, and I would end up trusting vital parts of my website (including hosting and forms) to several companies that may not even be around in 2-3 years.
So, the fight between JamStack and WordPress began. JamStack is amazing but current scenario makes it ideal choice only for developers. For those who have less or no coding experience WordPress is good.
Yeah, many Jamstack projects go from “wheeee it’s so simple and shiny!” to “yikes, how did we end up having to patch together ten services to make this work?”
That’s where static WordPress products and services may help bridge the gap. I’m not referring to the headless approach to WP, which is cool but loses many of the benefits that WP offers like the previews that you mentioned. Rather, the services that allow users to use WP as usual and get the CMS, build, previews, etc. all rolled into one, and then deploy to a Jamstack/static architecture. One example of this is Strattic (I’m the CEO), which is a static hosting and publishing platform for WP so our users manage their WP site as usual, and click one button to deploy to static.
Correct me if I’m wrong, I’d really like to see an article on this subject:
The problem with the concept of just putting just some static files and relying only on client-side JS is that the end result is not crawlable by most bots.
I say most because Google just started recently processing javascript. But most crawlers still don’t and they except the content retrieved from the server to contain all the necessary data.
Which doesn’t happen if you have no server-side rendering.
How does Jamstack fight this, if there isn’t a server that dynamically renders the page content?
It’s funny how times have changed in the perception of Jamstack. I feel like early days it was all “Jamstack is only good for static site generators” which are wonderful for SEO. I think it’s super fair to be worried about SEO if you do entirely client-side rendering. I’d say if you really care about SEO, find a way to make sure your content markup is there on that first request for the HTML. Prerender as much as you can. Find a way. Check out this new breed of “edge handlers” / “edge workers”, I think it’s gonna be a huge concept. You can do things like Ajax requests at the CDN level before the HTML comes down at all. Big opportunity to do dynamic things and not hurt SEO.