In Part 1 of this series titled “WordPress vs. Jamstack in 2020”, we discussed an articled penned by Richard MacManus of The New Stack. In this post, which was an interview of sorts with Automattic CEO Matt Mullenweg, MacManus highlighted Mullenweg’s criticisms against Jamstack. Tribalism is rampant in technology. Whether it’s iPhone vs. Android, HEY vs. Gmail, or Notion vs. Trello, calling out the opposition will typically result in backlash. In this case, Mullenweg’s criticisms against Jamstack spawned various rebuttals, one of which came from Matt Biilman, the CEO of Netlify. In this post, we’ll take an in-depth look at Biilman’s response from a blog post titled “On Mullenweg and the Jamstack – Regression or Future?” – Don’t you just love Big Tech drama?

Let’s get started.

In Biilmann’s response to Mullenweg, he starts off by recalling a personal experience from a decade ago at a trade show.

Around ten years ago, before Netlify, I was working on a CMS that competed with WordPress, removing a lot of the operational hurdles of hosting, scalability and operations. We had a booth at a trade show right next to a competing managed CMS and we got to talking about the elephant in the room: WordPress, the absolute dominant player in our space. We had to acknowledge that, even if it was a much larger competing product, it was also a brand we simply couldn’t directly market against. The developer community had rallied around the platform, the open source project, and the ecosystem.

To be honest, I almost stopped reading after seeing this paragraph. If you look at the last sentence, you’ll see that Biilmann is talking about how the “developer community” rallied around WordPress. To be clear, Biilmann says “developer community”. Not “blogger community”, “user community”, or even “WordPress community”, but specifically “developer community”.

A few paragraphs later, Biilmann writes this.

Fast forward ten years and WordPress appeared at the top of the list of most dreaded platforms according to Stack Overflow’s 2020 Developer Survey. 67 percent of developers using WordPress indicated they want to move off of the platform. The excitement amongst web developers has shifted dramatically.

This pretty much puts the nail in the coffin for me. To address Mullenweg’s criticisms against Jamstack’s user experience for “website management” (e.g. slow site builds, reliance on multiple services, etc.), Biilmann pulls out statistics from Stack Overflow’s 2020 Developer Survey – a study that in no way represents how WordPress is being used by non-developers.

Recall that in Part 1 of this series, I primarily discussed the user experience between WordPress-powered and Jamstack-powered sites. I went down this route because Mullenweg’s initial criticisms about Jamstack mostly revolved around user experience, and not developer experience.

In fact, the opening paragraph of MacManus’ original article specifically cites “website management” as one of Mullenweg’s criticisms against 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.

Here’s another example of Mullenweg drawing user experience, and not developer experience, comparisons between Jamstack and WordPress.

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.

In the context of static site publishing, “rebuilding sites” is much more of a user action rather than a developer action. For example, when I publish a new post, GitHub rebuilds my site with Hugo and deploys it to Cloudflare Workers Sites.

Lastly, Mullenweg’s comments on the cheapness of WordPress shared hosting is a clear indicator that he is arguing from a user experience standpoint.

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

So, this brings me back to my original point from Part 1 of this series – this debate is silly and unproductive. Just think about what’s happening here. Mullenweg makes claims that WordPress is better than Jamstack from a user experience perspective, and Biilmann starts off his argument by talking about developer experience instead. To put it simply, this debate has now shifted from WordPress (software project) vs. Jamstack (software development philosophy), which is already a comparison between apples and oranges, to WordPress User Experience vs. Jamstack Developer Experience.

Debates like these never end well because it’s clear that both sides aren’t actually interested in a real debate. If they were interested in having a real debate, they’d work together to set some ground rules and context to ensure the presence of an actual point to the debate. Instead, we now have a situation where both sides are doing nothing more than preaching without truly listening to the other side. Mullenweg’s main point is the ease of use of WordPress (this is clear from his initial interview with MacManus), while Biilmann’s main point revolves around Jamstack’s supposedly superior developer experience.

Even though this is already a flawed debate, let’s go ahead and see what Biilmann has to say because he does make some decent points about Jamstack’s developer experience, even though it doesn’t really have anything to do with Mullenweg’s initial user experience-inspired criticisms of Jamstack.

First off, I think Biilmann drawing comparisons between “WordPress vs. Jamstack” and “Blockbuster vs. Netflix” is a great way to set the stage with some old-fashioned drama. The problem with this comparison is that it’s only drama, and doesn’t contain any actual substance. Blockbuster was a business that enabled consumers to watch TV shows and movies by renting physical media. Netflix is a business that enables customers to watch TV shows and movies by paying a monthly subscription. Blockbuster and Netflix are comparable because they both provide the same end product – media playing on your screen.

I don’t think Blockbuster vs. Netflix analogy translates well to the WordPress vs. Jamstack debate for a few reasons. First, WordPress and Jamstack do not provide the same end product. Since WordPress is a full-fledged CMS, or content management system, it provides a user with complete suite of tools to publish, manage, and display content out of the box. On the other hand, Jamstack is software development philosophy, and it doesn’t really have an end product at all. Secondly, Blockbuster failed because it failed to predict the future potential impact of online streaming on consumer convenience. In other words, it did not recognize that people wouldn’t want to make the trek to a physical store to rent a movie when they could just log in to a website to watch a movie.

Netflix won because it made media consumption more accessible and convenient. You no longer needed a car and spare time to drive somewhere just to be able to watch a movie at home. At this time, I don’t think the same can be said about WordPress vs. Jamstack because, once again, they don’t compete in the same space. Perhaps this Blockbuster vs. Netflix analogy would work better if the “WordPress vs. Jamstack” debate was shifted to a “Integrated Development vs. Jamstack Development” debate. Even then, I think it’s still much too early to call integrated development the Blockbuster of this debate.

Let’s shift back to Biilmann’s comment about WordPress being the most dreaded developer platform from Stack Overflow’s 2020 Developer Survey.

Fast forward ten years and WordPress appeared at the top of the list of most dreaded platforms according to Stack Overflow’s 2020 Developer Survey. 67 percent of developers using WordPress indicated they want to move off of the platform. The excitement amongst web developers has shifted dramatically.

Similar to Mullenweg in his original criticisms of Jamstack, Biilmann also engages in cherry picking to fit his bias. Simply stating that 67% of participating developers hate WordPress without making it clear that this is a relative metric is disingenuous because it fails to highlight WordPress’ market share. At this moment, WordPress powers over 35% of the modern web, which means there are literally millions of people around the world using WordPress everyday. At the same time, there is a finite number of developers around the world. Since WordPress is the most popular CMS in the world, it doesn’t surprise me that it accounts for a significant amount of global mindshare and stakeholder opinions. In other words, I think the primary reason for WordPress receiving so much hate (and so much love) is its popularity and market share.

Another example of this phenomenon is, drum roll please, JavaScript – which, ironically, accounts for the “J” in Jamstack. JavaScript doesn’t have the best reputation in the developer community, and people LOVE to hate on JavaScript.

Here are a few examples.

Personally speaking, I don’t hate JavaScript, but many of my developer friends do. It’s not my first choice for backend development, but I understand its importance in the context of modern web development – especially for frontend work. When I ask my friends why they hate JavaScript, many of them can’t come up with a concrete answer to support their opinion. This just goes to the show how powerful tribalism really is. People willingly factionalize themselves into tribes, and preach narratives that sometimes directly contradict what they’re preaching. Biilmann supporting his anti-WordPress narrative with a statistic that shows 67% of developers dreading WordPress is a perfect example of this.

If developers dreading something is a good indicator for how bad that something is, then JavaScript must be terrible as well. The takeaway here is that people hate on JavaScript and WordPress because they are popular. The more popular something is, the more polarization-generating potential it has. This phenomenon applies to things outside of technology as well. If a celebrity endorses a presidential candidate, a lot of people are going to share their opinions about the endorsement. Meanwhile, if a non-celebrity endorses a presidential candidate, it’s not going to generate nearly as much buzz.

Alright, let’s move on to Biilmann’s next set of comments that discuss “the end of the WordPress era”.

When WordPress was really top of mind for developers, version control was still not in broad use for the majority of developers, amongst the ones using it – continuous integration was rarely practiced and continuous deployment was the bleeding edge.

GitHub led to a whole different level of adoption of version control amongst web developers, and not just for revisions of source code, also as the main collaborative layer between developers and even as the workflow layer driving deploys and rollouts.

The world of WordPress largely felt foreign to this, with lots of styles and theme information living in a database and a self updating system that would happily overwrite its local install with no source revision management.

Version control from a WordPress standpoint is a tricky topic. While I wouldn’t call WordPress Git-native, I also wouldn’t write it off as being a platform that is inherently incompatible with version control. In this section, Biilmann engages in another round of cherry picking with the goal of presenting WordPress in a negative light. I’d argue that, “the world of WordPress… with lots of styles and theme information living in a database… with no source revision management” is largely a misrepresentation of modern WordPress development.

This is another example of why it’s important to set ground rules and context for this debate. WordPress, in its current state, is used by many different people who possess varying degrees of technical knowledge. For example, if an average user wants to add some additional CSS, he or she will most likely install a plugin like Simple Custom CSS to get the job done. This plugin uses the MySQL database to store settings, and it ensures that the custom CSS is injected into the correct place in the HTML document. So, in a scenario like this one, perhaps Biilmann is correct when he says “lots of styles… with no source revision management”.

However, recall that Biilmann’s argument against Mullenweg is developer-oriented rather than user-oriented. In this context, Biilmann’s claim that WordPress has “lots of styles and theme information… with no source revision management” doesn’t exactly hold true. Similar to Jamstack development, modern WordPress theme development is 100% compatible with Git and other version control systems. As a WordPress developer, it’s possible to set up an offline development environment that mirrors an online production environment in a Git-controlled configuration.

There’s nothing about WordPress that forces developers to commit theme and functionality code directly to a MySQL database. As someone who works at WordPress hosting company, I witness version controlled deployments to the Kinsta website all the time. CSS and JavaScript can be written directly into static files that can be version controlled. Similarly, site functionality code can be committed to functions.php, which is another static file that can be version controlled – no MySQL database involved.

Next, Biilmann goes into WordPress’ lack of abstraction in the “view layer”.

Anyone really adopting the full set of these tools would quickly stop really feeling at home in a WordPress ecosystem where each individual plugin had its own opinion on the frontend layer, where Git was never really a first class citizen and where the view layer was a mix of serverside PHP tightly coupled to MySQL queries without any clear API as an abstraction layer between.

Quite frankly, I think these arguments from Biilmann are very weak. First off, the claim that “each individual plugin ha[s] its own opinion on the frontend layer” simply doesn’t make sense. In a Jamstack environment, a developer can write coherent code that doesn’t make any assumptions about the frontend (e.g. HTML document structure, CSS formatting, etc.). There’s nothing about WordPress that makes it impossible to do this. If you’re a WordPress developer writing a plugin, you can do so in a way that respects a predefined set of rules.

I think Biilmann’s claim about individual plugins having their own frontend opinions refers to assumptions baked into plugins available on the WordPress repository. Why is this a problem? Installing a plugin from the WordPress repository is a game of economics and opportunity costs. For casual WordPress users, I don’t see the problem with installing a WordPress plugin that has baked-in assumptions of how to display content on the frontend.

For business and enterprise-level WordPress users who require conformity, developers can still code WordPress plugins in a way that doesn’t bake in plugin-specific assumptions about how to present frontend content. Biilmann makes it seem like this whole issue of “frontend opinionation” is exclusive to WordPress. It’s not. The same issue applies if you download a random React module or Hugo theme. Unless you share the exact same coding conventions and architectural opinions of the original developer, the same issue still applies.

Regarding Biilmann’s comment about WordPress not having any API or abstraction layer, I have to wonder if he’s aware of WordPress’ REST API. The claim that WordPress’ view layer is only a “mix of serverside PHP tightly coupled to MySQL queries” is an outright lie. There’s nothing stopping anyone from using WordPress as a REST API backend with a Jamstack-powered frontend. In this model, the frontend would make queries to WordPress’ REST API, parse the JSON response, and display the necessary content on the frontend.

In fact, Netlify – the company that Biilmann leads – published a blog post about using Ghost as a REST API backend for Jamstack-powered frontends. Going by Biilmann’s mental gymnastics, Ghost must not have a “clear API as an abstraction layer” either. If that were the case, why does Netlify openly promote using Ghost as a REST API backend for a Jamstack frontend?

Don’t answer that. It’s another rhetorical question.

Up next, Biilmann complains about WordPress performance, scaling, maintenance, and security. Here’s what he says.

Once the charm of the fundamental architecture of WordPress seemed to be going away, the obvious pains around acceptable performance, scaling, maintaining, operating, and securing WordPress installs started feeling like an ever increasing burden rather than a reasonable trade-off.

I partially agree with what Biilmann says here. During my time as a WordPress support engineer, I witnessed firsthand the difficulties involved with WordPress performance, scaling, maintenance, etc. With that said, I don’t think the situation is as dire as Biilmann makes it out to be. Let’s break down his claims one by one.

  • WordPress Performance - By default, requests to a WordPress site need to be individually processed by PHP workers. After a web server receives a request, it hands it off to a PHP worker to build the HTML page. In most cases, this process is bottlenecked by CPU resources. Fortunately, page caching addresses this performance bottleneck by storing completed HTML pages that can be served for future requests. Going beyond the server level, Cloudflare’s Automatic Platform Optimization (APO) for WordPress takes caching one step further by caching HTML at edge servers.
  • WordPress Scaling - Scaling is hardly an issue for modern WordPress deployments. With server-level page caching (default configuration on most WordPress hosts) and extended caching services like Cloudflare APO, WordPress is extremely scalable. Kinsta powers WordPress sites that receive millions of visitors a month with zero issues. Scaling is more of an issue for dynamic sites like WooCommerce-powered stores, but it’s not exactly a major problem. Furthermore, I’ve yet to see a Jamstack-powered ecommerce experience that rivals WooCommerce. Until that exists, I think the scaling debate should be restricted to scenarios that can be compared.
  • WordPress Maintenance - The term “maintenance” is vague, so I’m not 100% sure what Biilmann is referring to. When I think of WordPress maintenance, I think of server, plugin, and theme updates. Nowadays, most WordPress hosts take server management out of the equation. This means WordPress users don’t have to worry about updating Ubuntu, PHP, etc. With regard to plugin and theme updates, I do see this as a legitimate complaint. I’ve worked on hundreds, if not thousands, of WordPress sites in the past few years. The claim that most people don’t update WordPress core, plugins, and themes in a timely manner is 100% true. Fortunately, recent versions of WordPress are starting to push automatic updates more and more.
  • WordPress Security - In the context of WordPress, security is primarily a function of a high-quality WordPress host and keeping software up to date. If your site takes these two factors into account, then it’ll be secure. I think WordPress’ ease of use also contributes to its reputation of being insecure. WordPress’ low barrier of entry means it’s used by every demographic from non-technical to extremely technical. This is a tradeoff that Jamstack has yet to experience, so I think it’s a bit unfair to call out WordPress for being insecure in the context of a WordPress vs. Jamstack debate. At this time, Jamstack is only accessible to technical individuals. If Jamstack technologies are made more accessible to non-technical people in the future, it’ll be interesting to see how Jamstack security evolves over time.

After reading Mullenweg’s initial criticisms against Jamstack, I wholeheartedly thought I’d be siding more with Biilmann on the majority of the presented issues. However, after reading through Biilman’s response a few times, I actually find myself stuck somewhere in the middle, or perhaps somewhere outside. The more I think about this debate, the more I’m convinced that it’s yet another case of industry titans fighting to preserve self interests and market share without stopping to think about whether the debate is actually grounded in reality.

Reading through Biilmann’s response, it’s easy to see that his focus is primarily on developer experience. While Biilmann does mention consumer-oriented Jamstack products like Stackbit and Tina CMS, I think it’s a little pointless because these two services are still very much not tailored towards non-technical users. Furthermore, Biilmann specifically mentions the developer community’s issues with WordPress multiple times throughout his response. At the same time, Mullenweg is clearly focused on the user experience for non-technical users. This is apparent when you consider the majority of Mullenweg’s criticisms against Jamstack mentions things like site build time, the accessibility of WordPress shared hosting, Automattic’s WordPress.com platform, and more.

So, not only does this debate involve two things that shouldn’t be compared – WordPress (a software product) and Jamstack (a software development philosophy), Mullenweg and Biilmann take it one step further by niching down to a debate that pitches the development experience of a software product against the user experience of a software development philosophy. In the end, I don’t think anyone is going to win this debate because it’s, quite frankly, a stupid conversation to be having in the first place.

In some respects, I think this kind of public discourse is needed to a certain extent. Mullenweg and Biilmann are both responsible for the growth of their respective companies, so these kinds of debates shouldn’t come as a surprise. I also think these discussions also have the potential to grow usage and mindshare of both WordPress and Jamstack. People love drama, so if the differences between the two technologies can be highlighted in a dramatic context, I think it can potentially have a positive impact on adoption.

In either case, most things in life are best in moderation. When witnessing these sorts of debates between industry titans, it’s important to step back and analyze what’s at stake for both sides. As WordPress and Jamstack evolve over the coming years, I hope the two camps can grow up and realize the two technologies are completely interoperable. There are valid use cases for using Jamstack by itself, Jamstack with a WordPress backend, and WordPress by itself.

What are your thoughts on the Jamstack vs. WordPress debate? Let me know on Twitter, or send me an email.