WordPress Co-Founder Matt Mullenweg Is Not a Fan of JAMstack

Matt Mullenweg, founding developer of WordPress and CEO of Automattic, thinks the currently trendy JAMstack approach to website management — which decouples the frontend from the backend, and doesn’t require web servers — is a backward step for the web.

“JAMstack is a regression for the vast majority of the people adopting it,” Mullenweg told me over email. “The usability and functionality is actually lower. Even rebuilding sites in JAMstack harkens back to the Movable Type days, where the bigger your site gets the slower it is to rebuild or update templates.”

The rebuild process he’s referring to is the generation of static HTML pages, which in the JAMstack model is typically done by a “static site generator” — popular examples of this type of product include Gatsby, Jekyll, Next.js and Hugo. After rendering into HTML, the pages then get distributed to content delivery networks (CDNs) — like the one Netlify provides. This makes JAMstack websites faster than sites that rely on web servers (see WordPress), because they’re delivered to end users from local networks rather than from a server that resides somewhere across an ocean.

But while page download for users is typically very fast in the JAMstack model, the build time for publishers can in some cases take thirty minutes or more. Indeed, Gatsby was in the news last week for (among other things) being too slow. An aggrieved ex-Gatsby contractor, Nat Alison, claimed in a long Twitter thread that Gatsby had “molasses-slow builds.”

Being new to Gatsby, I spent the first few weeks getting acquainted with the platform. The thing that immediately stood out was how *slow* the website took to build. 30 minutes to compile the docs, blog, plugin list, etc. etc…

— Nat Alison (@tesseralis) August 12, 2020

Gatsby and other static site generators are working on ways to do incremental builds to address this problem, but Gatsby’s CEO Kyle Mathews admitted to The New Stack that “build times are proportional to site size and specific features that are used” and that “some very large or image-heavy sites can take that long.”

To Mullenweg’s point, it is debatable whether most websites or blogs need to have their entire sites pre-rendered and delivered across a CDN every time a new page is published. And as a long-time blogger myself, it does remind me of Movable Type — which I eventually migrated away from (to go to WordPress), partly because of slow build times.

With that said, there is a big difference between an old Movable Type website from 2005 and a JAMstack site now. Despite the word “static” being used a lot in JAMstack, these websites can be very dynamic. Indeed, one of the advantages of JAMstack is that developers can more easily integrate APIs and serverless functions into their site.

A Fragile Chain?

Which brings us to Mullenweg’s next gripe about JAMstack: that it relies on too many different services.

“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.”

For the basic set of website functionality — content management, build, web hosting, and design — Mullenweg has a point that JAMstack is a set of solutions, rather than being a monolithic system like WordPress.

My own experimental JAMstack blog doesn’t cost me anything to run, but it does rely on several different services. I run it on the open source Hugo framework, deploy it on Netlify via GitHub, and I now use a “headless CMS” service called Forestry. That’s four separate systems I rely on, whereas I could run the exact same blog with just WordPress.com (Automattic’s hosted solution).

As I pointed out in my columns about Gatsby’s “content mesh” and the headless CMS vendor Strapi, the JAMstack experience for content managers is not optimal. However, where the benefits of JAMstack kick in is on the development side. Developers have reason to be excited about frontend development platforms like Vercel and innovations like Netlify Functions.

If you think about e-commerce, for example, a JAMstack site can use the Stripe API to integrate a shopping cart system. A recent Netlify blog post showed how you can “sell products on Jamstack sites using Stripe Checkout to process payments and Netlify Functions to securely create Checkout sessions.”

You can integrate Stripe into a WordPress site too, of course. Typically that’s done via the WordPress plugin system (there are multiple plugin options for Stripe).

Is there a chance that the Stripe API could temporarily fail or have glitches, and thus cause problems for the website using that API? Yes, and yes — for JAMstack and WordPress, this is a risk. Indeed, if you have any experience with WordPress plugins, you will know they can cause the odd technical issue with your site.

Conclusion

While I think Matt Mullenweg raises two valid points of criticism about JAMstack — slow build times and a “fragile” chain of services — it should be noted that WordPress also has its critics in 2020. A WordPress site can be painfully slow sometimes, perhaps due to a faraway web server or a troublesome plugin. And the Gutenberg block-based editor, introduced into WordPress 5.0 in December 2018, has attracted plenty of criticism (it currently has an average rating of two out of five stars on wordpress.org).

Personally, I like the Gutenberg editor, as it makes content creation a more modular experience — which is almost a necessity in the modern web. But it did have teething problems when it was first released and it took me months to get used to it. Not dissimilar to my current experience using JAMstack. The price of change is that it can often be disorienting at first.

So would I migrate my personal website from WordPress to JAMstack? Even though my WordPress site runs too slow for my liking, I won’t be moving it to JAMstack any time soon. That’s because WordPress has better content management functionality and requires less work to maintain. But I’ll be keeping an eye on JAMstack and will continue experimenting with those technologies. The speed benefits for end users are hard to argue against, plus I’m intrigued by the opportunities for developers.