I’ve been catching up on WordPress podcasts recently, and I came across an episode of The Matt Report (one of my favorite WordPress podcasts) that discussed an ongoing feud between Matt Mullenweg (CEO of Automattic) and Matt Biilmann (CEO of Netlify). The topic of this podcast really caught my attention because I’m a huge supporter of both WordPress and the Jamstack, and I actually use both of these web technologies on a daily basis. In this post, we’ll take a look at the arguments from both sides, and I’ll share my thoughts on why I think this debate is a silly one to be having in the first place.

What is WordPress and Jamstack?

First, let’s establish some context by defining “WordPress” and “Jamstack”. If you’re already familiar with these two terms, feel free to skip ahead.

WordPress is an open source software project, and it happens to be the world’s most popular CMS – 35% of the web is powered by WordPress.

Jamstack, short for “JavaScript, API, and Markup Stack”, is a web design philosophy and doesn’t refer to any single specific software platform or product. It’s an alternative to traditional monolithic and server-side software development practices – of which WordPress is a product of. The Jamstack philosophy encourages users to serve pre-generated static files (HTML, CSS, and JS) and rely on client-side JavaScript execution for dynamic functionality.

The takeaway here is that WordPress is a software project, while Jamstack is a software development philosophy.

My WordPress and Jamstack Experience

Before we get into the meat of the debate, I want to set the stage a little by quickly going over my experience with WordPress and the Jamstack. I’ve been a WordPress user for over 10 years, and I currently work at Kinsta, a managed WordPress hosting company. During the past decade, I’ve dabbled in everything from blogging with WordPress, to designing personal WordPress themes, to running a successful retail business with WooCommerce. Nowadays, I work with WordPress professional everyday, and still use it for a few select side projects.

Last year, I decided to move my personal blog over to Hugo, a static site generator written in Golang. While my particular use case for Hugo doesn’t embody every aspect of Jamstack philosophy, I guess I can still call it Jamstack-ish because I do serve pre-built HTML files from a CDN (Cloudflare Workers Sites) and rely on client-side JavaScript for certain dynamic functions. Since I use Hugo for my personal blog, which I work on weekly (if not daily), I can honestly say that Jamstack plays a very important role in my life.

The point that I want to get across here is that I love and work with both WordPress and Jamstack on a daily basis. The worst technology debates in the world are the ones where the participants – both the direct participants and their respective camps on the sidelines – don’t have a real understanding, whether that be intentional or unintentional, of the thing they’re debating against. Unfortunately, I think this WordPress vs. Jamstack debate has sort of devolved into unproductive bickering with cherry-picked arguments. With that in mind, I’d like to add some fuel to the fire, and share my thoughts on this debate as someone who works with and knows both WordPress and the Jamstack.

Matt Mullenweg’s Issues With Jamstack

To kick things off, let’s take a look at some of Matt Mullenweg’s original comments against the Jamstack in an article published by The New Stack.

The article starts off with this introduction.

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.

So, shots are fired immediately. Mullenweg thinks Jamstack is a “backward step for the web”. Let’s take a look at why he thinks this is the case.

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

We’re only two paragraphs in, and there’s already an example of cherry picking to fit a bias. According to Mullenweg, Jamstack has less usability and functionality than WordPress. When making an argument for or against something, using sweeping claims like “usability and functionality is actually lower” is exactly what you shouldn’t do. The main issue with this sweeping claim is that the Jamstack can also be more functional and usable depending on the exact context.

For example, the offline experience is one of my favorite aspects of publishing with Hugo. I can write, format, and preview a post (including images, CSS styles, and JS functionality) anytime, anywhere – no Internet connection needed. This may sound like a non-issue in 2020, but for someone who often travels to the countryside, an offline-mode that allows me to preview a replica of my live site allows me to stay productive. I’m well aware that there are various writing apps with offline modes that support WordPress, but this not the same thing as being able to write and preview an entire post offline. In this respect, I would say that Jamstack is more usable than WordPress.

Secondly, using the term “functionality” as an argument against Jamstack makes very little sense to me. Jamstack, by design, allows you to add any functionality you want. If you need search functionality, you can integrate something like Algolia. Similarly, if you need image optimization, you can add Imgix or Cloudinary to your stack. On a related note, I’d also argue that Jamstack has a much higher functionality-to-usage ratio than WordPress.

In other words, if you know your Jamstack site will only require five specific features, you can add those five features and nothing more – this would give you a functionality-to-usage ratio of 1:1 or 100%. WordPress, on the other hand, ships with a ton of features that you may never use. With this in mind, I think it’s important for Mullenweg to specify exactly what he means by “functionality” because just saying Jamstack has less functionality than WordPress isn’t really saying anything – mostly because it’s comparing a web design philosophy (Jamstack) with an actual software product (WordPress).

Alright, enough about usability and functionality. Let’s move on to Mullenweg’s second comment comparing Jamstack with Movable Type, and the slow build process of static sites. Before we get into my thoughts on this topic, let’s quickly discuss what a “build process” is. Static site generators take Markdown files and HTML templates, and generate HTML files that can be uploaded to a web host. The process of rendering the HTML files is typically called the “build process”.

As you may have guessed, Mullenweg’s comment about static sites being slow to build is yet another example of cherry picking to fit a bias. I know this is the case because Hugo, the static site generator I use for this blog, takes less than five seconds to generate my entire site. Furthermore, when I’m actively working on a new post or redesigning my Hugo site, the live reload feature rebuilds pages in less than 50 ms – I wouldn’t call this slow by any stretch of the imagination.

Sure, there are static site generators that are slow. Gatsby, one of the most popular static site generators in the world, is one of those slower options. However, there is something to be said about selecting the right tool for the job. If you’re working on a static site with a ton of pages, you probably wouldn’t even be looking at Gatsby in the first place. Instead, you’d probably stumble upon Hugo after doing a Google search for “fastest static site generator”.

With that said, I don’t think Mullenweg is necessarily wrong when he says “the bigger your site gets, the slower it is to rebuild”, but the way he puts it just rubs me the wrong way because it’s purposely vague to fit a bias – and I think he knows this. The problem with this statement is that it only addresses relative metrics. Yes, the more pages a static site has, the longer it’ll take to build. What this statement doesn’t convey is the scale of the time difference, and this is an extremely relevant piece of information to take into account. For a fast static site generator like Hugo, the time difference is going to be on the order of milliseconds to seconds – hardly an issue for 99.99% of publishers out there.

To make things worse, Richard MacManus, the author of this article on The New Stack, only gives one example of a static site generator. Again, this is yet another example of cherry picking to fit a bias. Don’t worry, by the end of this post, you’ll have enough cherries to feed yourself for a lifetime. In support of Mullenweg’s comment on static site generators being slow to build HTML pages, MacManus cites a tweet about Gatsby’s “molasses-slow builds”. I don’t have a problem with MacManus pointing out Gatsby’s slow build times. That’s a perfectly reasonable critique of Gatsby, and it’s also the main reason why I chose not to use Gatsby when I was testing out various static site generators for this blog.

What I do have a problem with is MacManus failing to give static site generators the benefit of the doubt by creating a level playing field for both sides. To do this, MacManus could’ve presented a counterpoint to Mullenweg’s comment about slow build times by highlighting the fact that there are static site generators like Hugo that have extremely fast build times. I’m not sure whether omitting the “entire picture” was intentional or not. Either way, it’s a disservice to readers because it effectively misrepresents the capabilities of static site generators at large, by drawing comparisons exclusively to Gatsby, which is widely accepted as one of the slowest options in the industry.

Okay, moving on.

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.

MacManus’s next point questions the “need” for “websites or blogs to have their entire sites pre-rendered and delivered across a CDN every time a new page is published”. There are quite a few misconceptions here, so let’s break it down.

First of all, what’s the big deal with pre-rendering a blog to static HTML? Sure, if you’re coming at this from the perspective that Gatsby is the only static site generator, then the time-to-benefit ratio of pre-rendering to HTML is definitely up for debate. However, Gatsby is not the only static site generator out there, so once again, why does pre-rendering to HTML even need to be a debate?

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

It is debatable whether most websites or blogs need to…[be] delivered across a CDN every time a new page is published.

To me, the way that MacManus phrases the usage of CDNs in delivering statically-generated sites makes it seem like some sort of unjustified proposition. Because, once again, why does using a CDN to deliver a site even need to be debatable in the first place? Services like Netlify, Vercel, and Cloudflare Workers Sites are CDN-native by default. If you deploy a static site to one of these platforms, then your site will automatically be pushed to various data centers around the world. There is literally no other choice when using these services.

On a technical level, pushing static sites to CDNs makes sense. In today’s world, a significant amount of Internet traffic is generated by Google search queries. As we all know, Google takes page speed into account when generating search results. By pushing HTML to a globally-distributed CDN, pages load faster across the world. With this in mind, why wouldn’t companies like Netlify offer this as a standard service? At the same time, if you use a static site generator for your site, why wouldn’t you want your site to load quickly around the world? Again, I just don’t see why this needs be a debate at all. It’s a win-win situation for both consumers and service providers.

Up next, Mullenweg discusses the fractured nature of Jamstack-based sites, and compares it to the monolith that is WordPress.

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

Jamstack is a fractured and flexible web development philosophy by design. Thus, I think saying that “you can patch together a dozen services” is actually a compliment of sorts. The latter part of the first sentence is what really irks me. Mullenweg’s financial comparison – “…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” – is disingenuous and disgusting.

First of all, what does “similar result” mean?

Again, it’s an extremely vague term that can be twisted to apply to a number of scenarios. Again, vagueness allows for subsequent cherry picking to fit a bias. Personally speaking, I’ve never encountered a Jamstack user who is paying hundreds of dollars a month to run a static site. I’m sure there are businesses and enterprises out there with hefty hosting bills for their Jamstack-powered sites, but I’m pretty confident that these people wouldn’t necessarily fall into the shared hosting category if they had decided to use WordPress instead.

Over the past two years, I’ve had the pleasure of talking with dozens of WordPress and Jamstack users. From those discussions, one easily-extractable data point is that WordPress hosting is more expensive than Jamstack hosting. Most of the Jamstack users I’ve talked to use either Netlify or Vercel for hosting their static sites – both of these providers have very generous free tiers. On the other hand, you’d be hard pressed to find a high quality WordPress host that offers custom domain support for free.

My monthly hosting bill for this blog is approximately $15.10/month. I pay $10/month to Imgix for dynamic image transformation and optimization, $5/month to host on Cloudflare Workers Sites, and $0.10/month for storing images in a Google Cloud Storage bucket. Keep in mind these costs are discretionary and not required. If I go bankrupt, I can get rid of Imgix and move from Cloudflare Workers Sites to Netlify or Vercel. For $15.10/month, my static site, with dynamically-generated responsive images, is pushed to Cloudflare’s edge network, and fully loads in under one second across the world.

I know, I know. Now, I’m the one who’s cherry picking to fit a bias. Not exactly, because I understand that my $15.10/month use case is not necessarily a good representation of other Jamstack users who are paying to host static sites. For example, an enterprise using Gatsby (a slow static site generator) may require a paid Netlify plan due to build time restrictions. In that situation, I concede that it’s very well possible that hosting a Jamstack site can cost a few hundred dollars a month. However, based on my personal research, experience, and discussions, I have reason to believe that the overwhelming majority of Jamstack users are paying between $0-$10/month for hosting.

I really find it hard to believe that Matt Mullenweg doesn’t know that many Jamstack users are hosting static sites on Netlify and Vercel for free. Do a Google search for “WordPress vs Jamstack”, or “WordPress vs Gatsby”, or “WordPress vs. Hugo”. To prove my point, here are five posts on the first page of Google when searching for the term “WordPress vs Hugo”.

1. Switching From WordPress to Hugo (Smashing Magazine)
2. My Impressions of Hugo as a WordPress Developer (DEV)
3. I Finally Migrated My Blog From WordPress to Hugo (Julien Renaux)
4. Switching From WordPress to Hugo (Brian Li)
5. WordPress vs. Hugo (Amer Khalid)

All five of these posts mention hosting on free services like Netlify and GitHub Pages. The concept of deploying a static site for free is also pretty common on #JamstackTwitter. I really can’t fathom why Mullenweg draws such a contrasting financial comparison between Jamstack and WordPress because it ignores two very important aspects of reality.

1. The majority of Jamstack users are using static site generators to generate personal blogs, business landing pages, and informational sites. For most Jamstack users, fulfilling this use case results in a monthly hosting bill of $0-$10/month. Most importantly, the cost does not depend on the number of page views per month because hosts don’t need to account for CPU time, which is typically the most expensive component of a server.
2. The majority of quality WordPress hosts use a “visits per month” billing model. For example, WP Engine’s $25/month plan provides up to 25,000 visits per month. The next tier at $95/month supports up to 100,000 visits per month. I have many thoughts on the “visits per month” billing model, but that’s a story for another post. There are certainly exceptions to the “visits per month” model in WordPress hosting. For example, Cloudways uses a bandwidth-based pricing model instead. However, the top tier established players that host WordPress Core use the “visits per month” billing model for the most part. If I was hosting this blog (a fairly successful, but not super popular website) on WP Engine or Flywheel, my monthly hosting bill would be closer to $100 instead of $15.10.

My main issue with Mullenweg’s financial comparison between Jamstack and WordPress hosting is the purposeful omission of context. Sure, if your goal is to build a Jamstack site that duplicates every single feature in WordPress, you’ll probably have to deal with a high hosting bill – but I doubt many end users, if any, are actually doing that. Furthermore, arguing for the merits of WordPress with the cheapness of shared hosting is a really bad take. Cheap shared hosting from the likes of Bluehost, HostGator, and other EIG-owned hosts should never be used to convey the superiority of WordPress because those hosts have a terrible reputation and track record. Ironically, Bluehost is still the top recommended host on WordPress.org. I guess those affiliate commissions must be pretty good.

To summarize, I think Mullenweg’s claim that Jamstack sites are exponentially more expensive than WordPress sites to host is the perfect example of a straw man fallacy because it assumes the existence of an unrealistic scenario and makes exaggerated claims with the sole purpose of fitting a bias. Again, the reality is that the majority of Jamstack static sites – blogs, personal sites, business landing pages, etc. – can be hosted for less than $10/month. At the same time, the current WordPress hosting ecosystem is largely comprised of vendors that use a “visits per month” billing model. Therefore, I’d wager that on average, it’s much cheaper to host a Jamstack-powered static site versus a WordPress site. The only situation where this wouldn’t be the case is one where you construct a scenario with parameters that misrepresent how WordPress and Jamstack are being used in real life.

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.

The fragility of Jamstack is another point of Mullenweg’s that I disagree with. If you choose to create an analogy that correlates various Jamstack components with chain links, it’s very easy to paint a picture of fragility. However, why is Jamstack analogous with a chain in the first place? A broken chain implies an ecosystem that can’t be quickly stitched back together, and that’s precisely what Jamstack is not. I view Jamstack as more of a Formula One car where components are hot-swappable – if the left tire has too much wear, swap it out and you’re back on track in no time.

Let me give you an example from this personal blog, which as I mentioned earlier, is built with Hugo and hosted on Cloudflare Workers Sites. Currently, the site is served from Cloudflare Workers Sites, but I also deploy it to Netlify and Vercel. Thus, if I ever experience a deployment issue with Cloudflare Workers Sites, I can just point my DNS records at Netlify or Vercel and get on with my day.

Mullenweg’s comment about “breaking the entire flow” is applicable to WordPress as well. If you think about it, modern deployments of WordPress actually resemble a fragile link, at least much more so than modern Jamstack deployments. A typical WordPress site consists of various components in a chain – MySQL database, PHP (WordPress Core), and a web server (Nginx or Apache) hosted on a single server.

• What happens if the database gets corrupted?
• What happens if you update to the latest version of PHP and break your site?
• What happens if PHP crashes because you accidentally deleted a semicolon somewhere in your theme code?

The answer to these questions, of course, depends on the WordPress deployment configuration in question, but the end result is the same. Some work will need to be done to bring the site back online – whether that be rolling back to a previous backup, switching over to a backup instance (which is very expensive by the way), or calling your developer to wake up and fix a semicolon disaster.

Moving up to the application level, the fragility of external services still applies in the context of a WordPress site. Let’s say your Jamstack-powered online store uses Stripe’s API for payment processing. If Stripe goes down, your site can no longer process payments. This sucks, but WordPress does nothing to fix this issue. If Stripe’s API goes down, WordPress-powered stores using WooCommerce and Easy Digital Downloads wouldn’t be able to process payments either. Similarly, what if the search functionality on two sites – one WordPress, one Jamstack – was powered by Elasticsearch? If the Elasticsearch cluster went down, both sites would be affected. There is nothing special about WordPress that makes it more resistant to fragility.

With that said, I once again don’t think that Mullenweg is completely wrong about the fragility of Jamstack. If a Jamstack developer builds something with no redundancy, there is obviously going to be an innate factor of fragility. One of the beautiful things about Jamstack is the relative ease of stitching different services together for the sake of redundancy. Going back to my previous hosting example, an up-to-date version of this blog is hosted on three providers simultaneously. Similarly, if a Jamstack-powered photo gallery relied heavily on edge image optimization to maintain decent page load times, a developer can integrate both Imgix and Cloudinary to reduce the chance of a complete site breakdown.

Building redundancy into a product or service is trickier for things like user identity and payment processing, but the important thing to keep in mind is that it’s not impossible – it’s simply a game of SLA-influenced economics. For example, on my personal blog, I’m not likely to integrate two different image optimization services in a primary/backup configuration because the economics don’t make sense. Minimizing costs is a higher priority for me than ensuring 100% uptime for displaying optimized images. Conversely, a high-value enterprise doing millions in revenue every month may find it necessary to duplicate various parts of their stack across different service providers. For example, Stripe could be a primary payment processing API with Square as a backup. The point here is that Jamstack is horizontally scalable. If your use case warrants maintaining multiple services for a single task (e.g. payment processing), you can go ahead and build out your stack with this in mind. This is flexibility born out of fragility, which is very different from fragility.

Next, MacManus points out something very important.

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.

Finally, here’s something that I agree with MacManus and Mullenweg on. I don’t think Jamstack is necessarily a “set of solutions”. To me, it’s more of a design philosophy that shaped the development of a set of Jamstack-friendly solutions – perhaps a different way of saying the same thing. The funny thing about this sentence is that, in some ways, it’s the only thing that needs to be said because it makes a very important point about this Jamstack vs. WordPress debate. This sentence confirms that Mullenweg understands that Jamstack (a design philosophy) and WordPress (an actual software product) are fundamentally different things.

This is precisely why I think this whole debate is sort of a joke. Positioning WordPress and Jamstack as enemies is unproductive and childish because there’s actually very little to compare. As I opined on the debate in this post, I realized that Mullenweg and MacManus were only able to draw their comparative conclusions after establishing vague scenarios that allow for cherry picking. This is the case because a “WordPress vs. Jamstack” debate is very different from a “WordPress vs. Ghost” debate. The latter is actually a valid comparison because both WordPress and Ghost are content management systems. On the other hand, a “Jamstack vs. WordPress” comparison requires one to first formalize a bias to establish a competitive context because a natural one doesn’t exist. Again, this is because Jamstack is an idea, while WordPress is a product.

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

I often see the “but it relies on several different services” argument against Jamstack. To me, this argument doesn’t really say anything because being able to rely on multiple task-specific services is a core principle of Jamstack. The ability to offload certain functions (e.g. payment processing, user authentication, etc.) to specialist companies is literally what many people love about Jamstack. Thus, positioning this core principle as an argument against Jamstack is completely pointless. It’s the same thing as saying “WordPress sucks because you need to install PHP”. I wouldn’t even know what to say if someone came to me with that complaint about WordPress.

Moving on, the reliance on multiple services is not something that’s exclusive to Jamstack sites. A typical WordPress configuration also relies on multiple services. I say “typical” because MacManus’ WordPress.com example isn’t a good representation of what most people think of when they hear “WordPress”. Automattic’s WordPress.com offering is a heavily modified version of the open source WordPress Core, and that’s one of the reasons why it functions more like a SquareSpace or Wix-esque SaaS experience.

Anyhow, back to the topic of reliance on multiple services. Internally, WordPress relies on a MySQL database, PHP, and a web server. Just because these services are unbranded, outside the scope of corporate interests, and typically live in a single server doesn’t make them any less susceptible to failure. As someone who’s worked on the frontlines of WordPress support, I know this to be true. Externally, WordPress sites rely on CDN providers to deliver static assets and DNS providers to resolve domain names to IP addresses.

Alright, we’re almost at the end of Part 1 – I promise.

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

Here, MacManus circles back to Mullenweg’s two criticisms against Jamstack.

1. Slow build times.
2. A fragile chain of services.

My hope is this post has provided some clarity into this debate. I refuse to believe Jamstack is slow and fragile by default because those attributes only manifest if you purposefully use Jamstack in a very specific way.

1. If you’re using Gatsby and build time is a major bottleneck that is affecting your bottom line or happiness, then switch to a faster option like Hugo. One of the best things about being human is the ability to understand and adapt. The “Jamstack build time is slow” argument makes no sense in this respect.
2. Fragility is applicable to both WordPress and Jamstack, and once again, it depends on how you design and implement your stack. WordPress can be resilient. Jamstack can be resilient.

WordPress vs. Jamstack – A Flawed Argument By Design

Alright, let’s wrap up Part 1 here. I’d like to close off by sharing my thoughts on MacManus’ closing paragraph from his article on The New Stack.

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.

This final paragraph has convinced me that this “WordPress vs. Jamstack” debate is silly and unnecessary. In this paragraph, MacManus claims he won’t be moving his site over to a Jamstack-powered solution anytime soon because “WordPress has better content management functionality and requires less work to maintain”. This single sentence solidifies this debate as nothing more but a tactic, perhaps an unintentional one, to generate an emotional response from both the WordPress and Jamstack camps.

Why do I think this?

WordPress has “better content management functionality” because it’s literally a content management system. Jamstack is a set of design principles and best practices, and not a software product for creating and managing content. If you understand this, you’ll realize that this debate’s existence relies on a biased and manufactured set of rules that forces Jamstack into being something that it isn’t.

In closing, I think this debate needs a change of perspective. Perhaps one of two options below would make for a more productive and less pointless discussion.

1. WordPress vs. XYZ CMS built with Jamstack principles.
2. Jamstack design principles vs. Monolithic design principles.

That’s it for Part 1. In Part 2, we’ll take a look at the Netlify CEO Matt Biilmann’s response to Mullenweg’s claims against Jamstack. Stay tuned!