Jamstack’s Complexity Problem

Jamstack’s core promise is elegantly simple: pre-rendered static files served from a CDN, with any dynamic needs handled through client-side JavaScript talking to serverless functions. But as Guillermo Rauch noted at Smashing Conf, it’s less a prescriptive “stack” and more an open-ended approach. That openness cuts both ways.

The very simplicity that makes Jamstack appealing can spawn complexity in practice. Without a traditional back-end server, something as routine as a contact form stops being a solved problem. Netlify—the company most associated with Jamstack—offers its own forms solution, but there are dozens of other vendors vying to fill such gaps. Forms are only the beginning: you also need a CMS or data store, a build pipeline, preview workflows, authentication, and whatever niche features your project demands. Every problem has a Jamstack answer, but stitching those answers together can leave you managing an unwieldy collection of disparate services.

Dave Rupert captured that frustration after experimenting with an Eleventy + Tailwind + Netlify CMS setup:

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.

The WordPress Counterargument

Matt Mullenweg made a similar point in a conversation with Richard MacManus:

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. And it would be more fragile, because the chain is only as strong as its weakest link.

Mullenweg’s critique hits at a real trade-off. If a project truly requires a dozen integrated services with separate logins and billing, a monolithic CMS like WordPress starts looking attractive. Jamstack’s weaker spots—such as content previews, a feature WordPress provides by default—don’t help its case.

Treading carefully here is fair: while Mullenweg has an obvious interest in defending WordPress, Automattic also invests in alternative stacks, and the two approaches aren’t mutually exclusive. On the other side, Ohad Eder-Pressman’s open letter pushes back with equally earnest, if also incentivized, arguments.

Picking Your Poison

Jamstack’s strengths are substantial. Git-based deployments, pull request previews, sub-100-millisecond first requests, and cache management handled automatically—these are features every stack should offer. The decision ultimately comes down to your project’s requirements and your willingness to manage complexity.

Real-world deployments can sit at either end of that spectrum. This site runs on WordPress, and it handles a wide range of features well. A companion Jamstack site is far simpler—just a static site generator with content in a GitHub repo deployed to Netlify—but it gains capabilities WordPress can’t easily match, such as accepting pull requests on content. Both are valid choices, provided you understand what you’re giving up and getting in return.