Disclosure<\/strong>: both Automattic and Netlify are active sponsors of this site. I have production sites that use both, and honestly, I’m a fan of both, which is an overarching point I’ll try to make. I also happen to be writing and publishing this on a WordPress site.<\/p>\n\n\n The debate was on October 6th<\/sup> at Jamstack Conf Virtual 2020<\/a>. There is no public video of it (sorry). <\/p>\n\n\n Comparing Jamstack to WordPress is a bit weird. What is<\/em> comparable is the fact that they are both roads you might travel when building a website. Much of this post will keep that in mind and compare the two that way. Why they aren’t<\/em> directly comparable is because:<\/p>\n\n\n\n Those things are not apples to apples. <\/p>\n\n\n\n If we stick just with the stack<\/em> for a moment, the comparison would be between:<\/p>\n\n\n\n An example of Static + Services is using Netlify for hosting (which is static) and using services to do anything dynamic you need to do. Maybe you use Netlify’s own forms and auth functionality and Hasura<\/a> for data storage.<\/p>\n\n\n\n On a LAMP stack, you have MySQL to store data in, so you aren’t reaching for an outside service there. You also have PHP available. So with those (in addition to open-source software), you have what you need for auth. It doesn’t mean that you never<\/em> reach for services; you just do so less often as you have more technology at your fingertips from the server you already have.<\/p>\n\n\n\n Matt B. called the LAMP stack a “monolith.” Matt M. objected to that term and called it an “integrated approach.” I’m not a computer scientist, but I could see this going either way. Here’s Wikipedia<\/a>:<\/p>\n\n\n\n […] a monolithic application<\/strong> describes a single-tiered software application in which the user interface and data access code are combined into a single program.<\/p><\/blockquote>\n\n\n\n Defined that way, yes, WordPress does appear to be a monolith, and yet the Wikipedia article continues: <\/p>\n\n\n\n […] a monolithic application describes a software application that is designed without modularity.<\/p><\/blockquote>\n\n\n\n Seen that way, appears to disqualify WordPress as a monolith. WordPress’ hook and plugin architecture is modular. 🤷♂️<\/p>\n\n\n\n It would be interesting to hear these two guys dig into the nuance there, but the software is what it is. A self-hosted WordPress site runs on a server with a full stack of technology available to it. It makes sense to ask as much of that server as you can (i.e. integrated). In a Jamstack approach, the server is abstracted from you. Everything else you need to do is split into different services (i.e. not integrated). <\/p>\n\n\n\n The WordPress approach, doesn’t<\/em> mean that you never<\/em> reach for outside services. In both stacks, you’d likely use something like Stripe for eCommerce APIs. You might reach for something like Cloudinary for robust media storage and serving. Even WordPress’ Jetpack service (which I use<\/a> and like) brings a lot of power to a self-hosted WordPress site by behaving like a third-party service<\/em> and moving things like asset-hosting and search technology off your own servers by moving them over to cloud servers. Both stacks are conglomerations of technologies. <\/strong><\/p>\n\n\n\n Neither stack is any more “house of cards” <\/strong>or prone than the other. All websites can have that “only as strong as its weakest link” metaphor apply to them. If a WordPress plugin ships a borked version or somehow is corrupted on upload, it may screw up my site until I fix it. If my API keys become invalid for my serverless database, my Jamstack site might be hosed until I fix it. If Stripe is down, I’m not selling any products on any kind of site until they are back up.<\/p>\n\n\n\n WordPress.com has a free plan, and that’s absolutely a place you can build a site. (I have several.) But you don’t really have developer-style access to it until you’re on the business plan at $25 per month. Self-hosted WordPress itself is open-source and free, but you’re not going to find a place to spin up a self-hosted WordPress site for free. It starts cheap and scales up. You need LAMP hosting to run WordPress. Here’s a look around at fairly inexpensive hosting plans:<\/p>\n\n\n\n There is money involved right off the bat. <\/p>\n\n\n\n Starting free is much more common with Jamstack, then you incur costs at different points. Jamstack being newer, it feels like a market that’s still figuring itself out.<\/p>\n\n\n\n All of this is a good reminder that Netlify isn’t the only one in the Jamstack game. Jamstack just means static hosting plus<\/em> services. <\/p>\n\n\n\n You can’t make blanket statements like Jamstack is cheaper. It’s far too dependent on the site’s usage and needs.<\/strong> With high usage and a bunch of premium services, Jamstack (much like Serverless in general) can get super expensive. Jamstack says their enterprise pricing starts at $3,000\/month, and while you get things like auth, forms, and media handling, you don’t get a CMS or any data storage, that is likely to kick you up much higher.<\/p>\n\n\n\n While this WordPress site isn’t enterprise, I can tell you it requires a server in the vicinity of a $1,000\/month, and that assumes Cloudflare is in front of it to help reduce bandwidth directly to the host and Jetpack handling things like media hosting and search functionality. Mailchimp sends our newsletter. Wufoo powers our forms. We also have paid plugins, like Advanced Custom Fields Pro and a few WooCommerce add-ons. That’s not all of it. It’s probably a few thousand per month, all told. This isn’t unique to any integrated approach, but helps illustrate that the cost of a WordPress site can be quite high as well. They don’t publish prices (a common enterprise tactic), but Automattic’s own WordPress VIP hosting service<\/a> surely starts at mid-4-figures before you start adding third-party stuff.<\/p>\n\n\n\n Bottom line:<\/strong> there is no sea change in pricing happening here. <\/p>\n\n\n 80% of web performance is a front-end concern.<\/p>\n\n\n\n That’s a true story, but it’s also built on the foundation of the server (accounting for the first<\/em> 20%). The speediest front-end in the world doesn’t feel speedy at all if the first request back from the server takes multiple seconds. You’ve gotta make sure that first request is smoking fast if you want a fast site.<\/p>\n\n\n\n You know what’s super fast? Global CDNs serving static files. That’s what you want to make happen on any website, regardless of the stack. While that’s the foundation of Jamstack (static CDN-backed hosting), it doesn’t mean WordPress can’t do it.<\/p>\n\n\n\n You take an By default, WordPress isn’t making static files that are cachable on a global CDN. WordPress responds to requests from a single origin, runs PHP, which asks the database for stuff, before a response is assembled, and then, finally, the page is returned. That can be pretty fast, but it’s far less sturdy than a static file on a global CDN and it’s far easier to overwhelm with requests.<\/p>\n\n\n\n WordPress hosts know this, and they try to solve the problem at the hosting level. Just look at WP Engine’s approach<\/a>. Without you doing anything, they use a page cache so that the site can essentially return a static asset rather than needing to run PHP or hit a database. They employ all sorts of other caching as well, including partnering with Cloudflare to do the best possible caching. As I’m writing this, my shoptalkshow.com<\/a> site literally went down. I wrote to the host, Flywheel, to see what was up. Turns out that when I went in there to turn on a staging site, I flipped a wrong switch and turned off their caching. The site couldn’t handle the traffic and just died. Flipping the caching switch back on instantly solved it. I didn’t have Cloudflare in front of the site, but I should have.<\/p>\n\n\n\n Cloudflare is part of the magic sauce of making WordPress fast. Just putting it in front of your self-hosted WordPress site is going to do a ton of work in making it fast and reliable. One of the missing pieces has been great caching of the HTML itself, which they literally dealt with this month<\/a> and now that can be cached as well. There is kind of a funny irony in that caching WordPress means caching requests as static HTML and static assets, and serving them from a global CDN, which is essentially what Jamstack is at the end of the day.<\/p>\n\n\n\n Matt M. mentioned that WordPress.com employs global CDNs that kick in at certain levels of traffic. I’m not sure if that’s Cloudflare or not, but I wouldn’t doubt it.<\/p>\n\n\n\n With Cloudflare in front of a WordPress site, I see the same first-response numbers as I do on Netlify sites<\/strong> without Cloudflare (because the do not recommend using Cloudflare in front of Netlify-hosted sites). That’s mid-2-digit millisecond numbers, which is very, very good.<\/p>\n\n\n\n From that foundation, any discussion about performance becomes front-end specific. Front-end tactics for speed are the same no matter what the server, hosting, or CMS situation is on the back end.<\/p>\n\n\n There are far more stories about WordPress sites getting hacked than Jamstack sites. But is it fair to say that WordPress is less secure? WordPress is going on a couple of decades of history and has a couple orders of magnitude more sites built on it than Jamstack does. Security aside, you’re going to get more stories from WordPress with those numbers.<\/p>\n\n\n\n Matt M brought up that whitehouse.gov is on WordPress, which is obviously a site that needs the highest levels of security. It’s not that WordPress itself is insecure software. It’s what you do with it. Do you have insecure passwords? That’s insecure no matter what platform you’re using. Is the server itself insecure via file permissions or access levels? That’s not exactly the software’s fault, but you may be in that position because<\/em> of the software. Are you running the latest version of WordPress? Usage is fragmented, at best, and the older the version, the less secure it’s going to be. Tricky.<\/p>\n\n\n\n It may be more interesting to think about security vectors<\/em>. That is, at what points it is possible<\/em> to get hacked. If you have a static file sitting on static hosting, I think it’s safe to say there are fairly few attack vectors. But still, there are some:<\/p>\n\n\n\n That’s all true of a WordPress site, too, only there are additional attack vectors like:<\/p>\n\n\n\n I think it’s fair to say there are more attack vectors on a WordPress site, but there are plenty of vectors on any site. The hosting account of any site is a big vector. Anyting that sits in the DNS chain. Any third-party services with logins. Anything with an API key. <\/p>\n\n\n\n Personal experience: this site is on WordPress and has never been hacked, but not for lack of trying. I do feel like I need to think more about security on my WordPress sites than my sites that are only<\/em> built from static site generators. <\/p>\n\n\n Scaling either approach costs money. This WordPress site isn’t massively scaled, but does require some decent scaling up from entry-level server requirements. I serve all traffic through Cloudflare, so a peak at the last 30 days tells me I serve 5 TB of bandwidth a month.<\/p>\n\n\n\n On a Netlify Business plan (600 GB of traffic for $99, then $20 per additional 100 GB) that math works out to $979. Remember when I said this site requires about a server that costs about $1,000\/month? I wrote that before I ran these numbers, so I was super close (go me). Jamstack versus WordPress at the scale of this site is pretty neck-and-neck. All hosts are going to charge for bandwidth and have caps with overage charges. Amplify charges $0.15\/GB over a 15 GB monthly cap. Flywheel (my WordPress host) charges based on a monthly visitor cap and, over that, it’s $1 per 1000.<\/p>\n\n\n\n The story with WordPress scaling is:<\/p>\n\n\n\n The story with Jamstack scaling is:<\/p>\n\n\n\n I’ve had to move around a bit with my WordPress hosting, finding hosts that are in-line with the current needs of the site. Moving a WordPress site is non-trivial, but it’s far easier than moving to another CMS. For example, if you build a Jamstack site on a headless CMS that becomes too pricey, the cost of moving is a bigger job than switching hosts.<\/p>\n\n\n\n I like what Dave Rupert wrote the other day (in a Slack conversation) about comparing performance between the two:<\/p>\n\n\n\n Jamstack: Use whatever thing to build your thing, there’s addons to help you, and use our thing<\/strong> to deploy it out to a CDN so it won’t fall over.<\/p> WordPress: Use our thing<\/strong> to build your thing, there’s addons to help you, and you have to use certain hosts to get it to not fall over.<\/p><\/blockquote>\n\n\n\n There are other kinds of “scaling” as well. I think of something like number of users<\/strong>. That’s something that all sorts of services use for pricing tiers, which is an understandable metric. But that’s free in WordPress. You can have as many users with as many nuanced permissions as you like. That’s just the CMS, so adding on other services might still charge you by the head. Vercel or Netlify charge you by the head for team accounts. Contentful (a popular headless CMS) starts at $489\/month for teams. Even GitHub’s Team tier is $4 per user if you need anything the free account can’t do. <\/p>\n\n\n This is one of the big things that gets people excited about building with Jamstack. If all of my site’s functionality and content are behind APIs, that frees up the front end to build however it wants to.<\/p>\n\n\n\n That flexibility is neat on green-field builds, but people are just as excited about theoretical future flexibility<\/strong>. If all functionality and content is API-driven, you’ve entirely split the front and back, meaning you can change either in the future with more flexibility.<\/p>\n\n\n\n This kind of split feels “future safe” for sites at a certain size and scale. I can’t quite put my finger on what those scale numbers are, but they are there.<\/p>\n\n\n\n If you’ve ever done any major site re-architecture just to accommodate one side or the other, moving to a system where you’ve split the back end and front surely feels like a smart move.<\/p>\n\n\n\n You can<\/em> split a WordPress site (we’ll get to that in the “Using Both” section), but by default, WordPress is very much an integrated approach where the front end is built from themes in PHP using very WordPress-specific APIs. Not split at all.<\/p>\n\n\n Jamstack has done a good job of heavily prioritizing developer experience (DX<\/abbr>). I’ve heard someone call it “a local optimum,” meaning Jamstack is designed around local development (and local developer) experience.<\/p>\n\n\n\n It’s not that WordPress doesn’t consider developer experience (for example, they have a CLI<\/a> and it can do helpful things, like scaffold blocks<\/a>), but the DX doesn’t feel as to-the-core of the project to me.<\/p>\n\n\n\n These are all solvable things, and the WordPress community is so big that you’ll find plenty of information on it, but I think it’s fair to say that WordPress doesn’t have DX down to the core. It’s a little wild-west-y even after all these years.<\/p>\n\n\n\n In fact, I’ve found that because the encouragement of a healthy local development environment is so sidelined, a lot of people just don’t have one at all. This is anecdotal, but now twice is as many years have I found myself involved in other people’s sites that work entirely production-only<\/em>. That would be one thing if they were very simple sites with largely default behavior, but these have been anything but. They’re very complicated (much more so than this site) involving public user logins, paid memberships and permissions, page builders, custom shortcodes, custom CSS, and just a heck of a lot of moving parts. It scared me to death. I didn’t want to touch anything. They were live-editing PHP to make things work \u2014 cowboy coding<\/em>, as people jokingly call that. One syntax error and the site is hosed, maybe even the very page you’re looking at.<\/p>\n\n\n\n The fact that WordPress powers such a huge swath of the web without particularly good DX is very interesting. There is no Jamstack without DX. It’s an entirely developer-focused thing. With WordPress, there probably isn’t a developer at all<\/em> on most sites. It’s installed (or just activated, in the case of WordPress.com) and the site owner takes it from there. The site owner is like<\/em> a developer in that they have lots of power, but perhaps doesn’t write any code at all. <\/p>\n\n\n\n To that end, I’d say WordPress has far more focus on UX than DX, which is a huge part of all this…<\/p>\n\n\n WordPress is a damn fine CMS. Even if you<\/em> don’t like it, there are a hell of a lot of people that do, and the numbers speak for themselves. What you get, when you decide to build a site with WordPress, is a heaping helping of ability to build just about any kind of site you want. It’s unlikely that you’ll have that oops, painted myself into a corner here<\/em> situation with WordPress. <\/p>\n\n\n\n That’s a big deal. Jenn put her finger on this<\/a>, noting that the people who use WordPress are a bigger story than a developer’s needs.<\/p>\n\n\n\n WordPress can do an absolute ton<\/em> of things:<\/p>\n\n\n\n Jamstack can absolutely do all these things too, but now it is Jamstack that is in Wild West territory. When you look at tutorials about how to store data, they often involve explaining how to write individual CRUD<\/abbr> functions for a cloud database. That’s down to the metal stuff which can be very powerful, but it’s a far cry from clicking a few buttons, which is what WordPress feels like a lot of the time.<\/p>\n\n\n\n I bet I could probably cobble together a basic Jamstack eCommerce setup with Stripe APIs, which is very cool. But then I’d get nervous when I need to start thinking about inventory management, shipping zones, product variations, and who knows what else that gets complicated in eCommerce-land, making me wish I had something super robust that did it all for me.<\/p>\n\n\n\n Sometimes, we developers are building sites just for us (I do more than my fair share of that), but I’d say developers are mostly building sites for other people. So the most important question is: am I building something that is empowering for the people I’m building it for?<\/strong><\/p>\n\n\n\n You can pull off a good site manager experience no matter what, but WordPress has surely proven that it delivers in that department without asking terribly much in terms of custom development.<\/p>\n\n\n\n Jamstack has some tricks that I wish I would pull off on WordPress, though. Here’s a big one for me: user-submitted content and updates. I literally have three websites now that benefit from this. A site about conferences<\/a>, a site about serverless<\/a>, and an upcoming site about coding fonts<\/a>. WordPress could have absolutely done a great job at all three of those sites. But, what I really want is for people to be able to update and submit content in a way that I can be like: Yep, looks good, merge.<\/em> By having gone with a Jamstack approach, the content is in public GitHub repos, and anyone can participate.<\/p>\n\n\n\n I think that’s super great. It doesn’t even necessarily require someone from the public knowing or understanding Git or GitHub, as Netlify CMS<\/a> has this concept of Open Authoring<\/a>, which keeps the whole contribution experience in the browser with UI for the editing.<\/p>\n\n\n This is a big one that I see brought up a lot. Even Netlify themselves say “There is no Versus.”<\/a><\/p>\n\n\n\n Here’s the deal:<\/p>\n\n\n\n Yep, totally. This works and people do it<\/a>. I think it’s pretty cool.<\/p>\n\n\n\n But… <\/p>\n\n\n\n Here’s some players that all have a unique approach to “using both”:<\/p>\n\n\n\nHistory<\/h3>\n\n\n
The Stack<\/h3>\n\n\n
![\"\"](\"https:\/\/css-tricks.com\/wp-content\/uploads\/2020\/10\/Untitled-5.svg\")
![\"\"](\"https:\/\/css-tricks.com\/wp-content\/uploads\/2020\/10\/Untitled-6.svg\")
LAMP: Server that does a bunch of work as the hub, reaching out to a few services if needed.<\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n![\"\"](\"https:\/\/css-tricks.com\/wp-content\/uploads\/2020\/10\/Untitled-4.svg\")
Pricing<\/h3>\n\n\n
![\"\"](\"https:\/\/css-tricks.com\/wp-content\/uploads\/2020\/10\/Untitled-7.svg\")
<\/figure><\/div>\n\n\n\nPerformance<\/h3>\n\n\n
![\"\"](\"https:\/\/css-tricks.com\/wp-content\/uploads\/2020\/10\/Untitled-9.svg\")
index.html<\/code> file with static content, put that on Netlify, and it’s gonna be smoking fast. Maybe your static site generator makes that file (which, it’s worth pointing out, could very well get content from WordPress). There is something very nice about the robustness and steady foundation of that.<\/p>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/10\/Screen-Shot-2020-10-20-at-8.36.39-AM.png?resize=687%2C68&ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/10\/Screen-Shot-2020-10-20-at-8.37.27-AM.png?resize=687%2C73&ssl=1\")
Security<\/h3>\n\n\n
\/wp-login.php<\/code><\/li><\/ul>\n\n\n\nScaling<\/h3>\n\n\n
Splitting the Front and Back<\/h3>\n\n\n
![\"\"](\"https:\/\/css-tricks.com\/wp-content\/uploads\/2020\/10\/Untitled-10.svg\")
Developer Experience<\/h3>\n\n\n
master<\/code> or main<\/code>), then your build process runs, and your site is deployed. You even get a preview URL of what the production site will be for every pull request, which is an impressively great feature.<\/li>create-react-app<\/code> in school? Use that. Wanna experiment with the cool new framework de jour? Have at it. There is a lot of freedom to build however you want, leveraging the fact that you can run a build and deploy whatever folder in your repo you want.<\/li>\/wp-content<\/code> folder. It feels weird to me there is no guidance or obvious best practices.<\/li>CMS and End User UX<\/h3>\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/10\/Screen-Shot-2020-10-20-at-3.53.48-PM.png?resize=501%2C455&ssl=1\")
<\/figure>\n\n\n\nUsing Both<\/h3>\n\n\n