WordPress and Jamstack

Recently, I hosted a panel at Netlify’s virtual Jamstack conference, which included Netlify CEO Matt Biilman and Automatic founder Matt Mullenweg. The discussion was seen by many as "Jamstack vs. WordPress dispute."

I personally have a lot of thoughts about this and think I am more suitable to be a commentator than a moderator. This is one of my favorite technical discussions right now! So please allow me to write a blog.

Statement: Automattic and Netlify are both active sponsors of this website. I have some production sites that use both, and honestly, I love them all, which is a major point I will try to elaborate on. I happen to be writing and publishing this article on the WordPress website.

History review

1. Richard MacManus published an article “WordPress co-founder Matt Mullenweg is not a fan of Jamstack,” citing the email conversation between them, Matt said, “For the vast majority of people who adopt Jamstack, it’s a backlash.”
2. Matt Biilmann responded to the article "About Mullenweg and Jamstack - Backward or Future?", with a section titled "The End of the WordPress Era."
3. During this period, people commented. Netlify Board member Ohad Eder-Pressman wrote an open letter. Sarah Gooding summarized some activities on WP Tavern (owned by Matt Mullenweg). I'm involved, too.
4. Matt Mullenweg clarified his comments and added some new comments.

The debate was held at the 2020 Jamstack Virtual Conference. There are currently no public video records (sorry).

Architecture comparison

It's a bit weird to compare Jamstack with WordPress. What is really comparable is that they are all possible ways to choose when building a website. Most of this post will keep this in mind and compare the two in this way. The reason why they cannot be compared directly is because:

• Jamstack is a broad description of an architectural concept that encourages the use of static files on CDNs and uses services accessed by JavaScript to meet any dynamic needs.
• WordPress is a CMS based on the LAMP architecture.

The two are not exactly the same.

If we only focus on the architecture for the time being, the objects we compare will be:

• Static hosting services
• LAMP

An example of a static service is to use Netlify for hosting (which is static) and use a service to do any dynamic operations that need to be done. Maybe you use Netlify's own form and authentication features and Hasura for data storage.

In a LAMP architecture, you use MySQL to store data, so you don't need to use external services. You can also use PHP. So with this (and open source software), you have everything you need for authentication. But that doesn't mean you never use the service; it's just that you use the service less frequently because you already have more technology on the server.

Matt B. Call LAMP architecture "monomer architecture". Matt M. objected to this and called it the "integration method." I'm not a computer scientist, but I think both statements make sense. Here is the explanation from Wikipedia:

[…] A monolithic application describes a single-layer software application in which the user interface and data access code are combined in a program.

By this definition, WordPress does seem to be a monolithic architecture, but the Wikipedia article continues:

[…] A monolithic application describes a software application that is not designed to be modular.

From this perspective, it seems that WordPress does not meet the definition of a monolithic architecture. WordPress's hook and plug-in architecture is modular. ?‍♂️

It will be interesting to listen to these two big guys discussing this in-depth, but software is software. A self-hosted WordPress website runs on a server with a full technology stack. It makes sense to make the most of this server (i.e. integration). In the Jamstack method, the server is abstract. All other things you need to do are split into different services (i.e. non-integrated).

The WordPress method does not mean that you never use external services. In both architectures, you may use an e-commerce API like Stripe. You may use services like Cloudinary for powerful media storage and services. Even WordPress’s Jetpack service (which I use and love) brings great power to self-hosted WordPress websites, which runs like a third-party service , by moving asset custody and search technologies to cloud servers. Both architectures are a collection of technologies.

Neither architecture is a "House of Cards" and is not more fragile than the other. All websites may apply the metaphor of “its strength depends on its weakest link”. If the WordPress plugin publishes the wrong version or is broken somehow when uploaded, it may cause problems with my website until I fix it. If my serverless database's API key is invalid, I might have problems with my Jamstack website until I fix it. If Stripe goes down, I will not be able to sell any product on any type of website until I resume service.

Pricing

WordPress.com has a free plan, which is definitely a place to build a website. (I have several.) However, unless you are using a $25 per month business plan, you don't actually have access to developer-level features. Self-hosted WordPress itself is open source and free, but you can't find a place to launch a self-hosted WordPress website for free. It starts at a low price and then gradually increases. You need LAMP hosting to run WordPress. Here are pretty cheap hosting plans:

• Bluehost's "Share" plan starts at $3.95 per month.
• Flywheel's minimum plan is $14 per month. (This website uses Flywheel's premium program.)
• Media Temple's WordPress-specific hosting starts at $20 per month. (This website has been using Media Temple's premium program for a long time.)
• Automatic's Pressable service has a plan that starts at $25 per month.

It costs money from the beginning.

Jamstack is more common to start for free and then incur costs at different points in time. Since Jamstack is relatively new, it feels like the market is still exploring.

• Vercel is free until you need features like team members or password-protected websites. A single password-protected website $150 per month. You can add basic authentication to any server with Apache at no extra cost.
• Netlify is very similar, unlocking features on a higher plan and offering pay-per-site features such as analytics ($9 per month) and authentication ($99 per month for 5,000 active users).
• AWS Amplify starts for free, but like everything on AWS, your usage is billed on a quantity-based basis on many levels, such as build minutes, storage, and bandwidth. They have an example calculation that a web application has 10,000 active users a day, updated twice a month, and costs $65.98 per month.
• Azure Static Web Apps hasn't released pricing yet, but there's almost certainly a free tier or free to use or somehow.

All of this reminds us that Netlify is not the only player in the Jamstack space. Jamstack just means static hosting plus service.

You can't make general statements like Jamstack is cheaper. This depends too much on the use of the website and the needs of the website. For high usage and a lot of advanced services, Jamstack (just like serverless) can become very expensive. Jamstack says their business pricing starts at $3,000 per month, and while you can get features like authentication, forms and media processing, you won't get CMS or any data storage, which could make your costs significantly.

While this WordPress site isn't enterprise-grade, I can tell you that it requires about $1,000 a month for servers, assuming Cloudflare is in front of it to help reduce bandwidth directly to the host, as well as Jetpack's handling of media hosting and search capabilities. Mailchimp sends our newsletter. Wufoo supports our forms. We also have paid plugins such as Advanced Custom Fields Pro and some WooCommerce add-ons. That's not all. Total may be several thousand dollars per month. This is not unique to the integration approach, but it helps to illustrate that the cost of WordPress websites can also be quite high. They don't publish prices (a common strategy for businesses), but Automattic's own WordPress VIP hosting service is definitely priced above four digits, and then you also need to add third-party content.

Bottom line: There are no major changes in pricing here.

performance

80% of web page performance is a front-end problem.

This is true, but it is also based on servers (20% of the initial ). The fastest interface in the world If the server's first request takes a few seconds to return, it won't feel very fast. If you want a fast website, you have to make sure that the first request is very fast.

Do you know what's super fast? Global CDN provides static files. No matter what the backend server, hosting or CMS situation is, this is what you want to achieve. While this is the basis of Jamstack (the static CDN-supported hosting), that doesn't mean WordPress can't do that.

You put an index.html file with static content on Netlify and it will be very fast. Maybe your static website generator will generate that file (it is worth pointing out that it is likely to get content from WordPress). This is very awesome.

By default, WordPress does not generate static files that can be cached on global CDNs. WordPress responds to requests from a single source, runs PHP, then requests content from the database, then assembles the response, and finally returns to the page. This may be quick, but is far less stable than static files on global CDNs and is more likely to be overwhelmed by requests.

WordPress hosts know this and they are trying to solve this problem at the hosting level. Take a look at the WP Engine method. Without you doing anything, they use page caching so that the website can basically return static assets without running PHP or accessing the database. They also employ a variety of other caching technologies, including working with Cloudflare for optimal caching. My shoptalkshow.com website was actually down when I was writing this. I wrote to the host Flywheel to see what happened. It turns out that when I went there and opened a staging site, I switched a wrong switch, turning off their cache. The website cannot handle traffic and crashes directly. Turning the cache switch back on resolved the issue immediately. I'm not using Cloudflare in front of the website, but I should.

Cloudflare is part of the magical tips for making WordPress faster. Just put it in front of a self-hosted WordPress website and you can play a huge role in improving speed and reliability. One of the missing parts is the excellent caching of HTML itself, which they solved this month and are now available to cache as well. Interestingly, caching WordPress means cache requests as static HTML and static assets and serving them from global CDNs, which is ultimately the essence of Jamstack.

Matt M. mentioned that WordPress.com uses a global CDN launched at a specific traffic level. I'm not sure if it's Cloudflare, but I won't doubt it.

After using Cloudflare in front of a WordPress site, the first response number I see is the same as a Netlify site without Cloudflare (as they do not recommend using Cloudflare in front of a Netlify hosted site). This is a double-digit millisecond-order number, very good.

From this basis, any discussion of performance will become front-end specific. The front-end speed strategy is the same regardless of the back-end server, hosting, or CMS situation.

Security

There are many more stories about the hacked WordPress website than the Jamstack website. But is it fair to say that WordPress is less secure? WordPress has been around for about twenty years, and the number of websites built on it is orders of magnitude more than Jamstack. Security aside, considering these numbers, you'll hear more stories from WordPress.

Matt M mentioned that whitehouse.gov uses WordPress, which is obviously a website that requires the highest level of security. This is not to say that WordPress itself is unsafe software. The key is how you use it. Is your password unsafe? No matter what platform you use, it is not safe. Is it unsafe for the server itself to pass file permissions or access levels? This is not entirely the software’s fault, but you may be in this situation because of the software. Are you running the latest version of WordPress? Usage is dispersed at best, and the older the version, the less security it is. Tough.

It might be more interesting to consider attacking the medium . That is to say, at which points may be hacked. If your static files are on static hosting, I think it's safe to say that attack vectors are quite small. However, there are still some:

• Your hosting account may be hacked
• Your Git repository may be hacked
• Your Cloudflare account may be hacked
• Your domain name may be stolen (it does happen)

The same is true for WordPress websites, but there are other attack vectors such as:

• Server-side code: XSS, bad plug-ins, remote execution, etc.
• Database vulnerability
• Run an older version of WordPress
• Login to the system is in the website itself, for example, bad guys can attack /wp-login.php

I think it's fair to say that WordPress websites have more attack vectors, but any website has a lot of media. Hosting accounts for any website are a major medium. Anything in the DNS chain. Any third-party service with login information. Any content with an API key.

Personal experience: This website uses WordPress and has never been hacked, but it is not because it has not been tried. I do feel like I need to think more about the security of WordPress websites than sites built with only static website generators.

Extensibility

Extending any method costs money. This WordPress website has not expanded at scale, but it does require more demanding expansion than entry-level servers. I'm serving all traffic through Cloudflare, so the peak data from the last 30 days shows that I'm providing 5 TB of bandwidth per month.

In the Netlify business plan (get 600 GB of traffic per month, then charge $20 for every additional 100 GB), the calculation is $979. Remember when I said before that this website requires a server of about $1,000 a month? I wrote these before running these numbers, so it was very close (awesome). On the scale of this website, Jamstack is comparable to WordPress. All hosts will charge bandwidth and have an overcharge limit. Amplify charges $0.15 per GB for bandwidth over the 15 GB monthly cap. Flywheel (my WordPress hosting) charges based on monthly visitor caps, and after the cap is exceeded, it will be charged $1 per 1,000 people.

The WordPress extension story is:

• Use hosts that can handle it and have their own mature caching policies.
• CDN everything (this usually means putting Cloudflare in front).
• Ultimately, you will pay for it.

The story of Jamstack extension is:

• Both hosts and services are built for scaling.
• You don't have to think too much about whether this service can handle this or do I need a migration? Extension issues like that.
• You need to consider more about the fact that every aspect of each service will have pricing that needs attention .
• Ultimately, you will pay for it.

I had to migrate my WordPress hosting to find a host that matches the current needs of the website. Migrating a WordPress website is not easy, but it is much easier than migrating to another CMS. For example, if you build a Jamstack website on a headless CMS and the price becomes too high, the cost of migration is greater than switching hosts.

I liked Dave Rupert the other day (in the Slack conversation) about comparing the performance of the two:

Jamstack: Use anything to build your stuff, there are some add-ons that can help you, and use our stuff to deploy it to the CDN so it doesn't crash.

WordPress: Use our stuff to build your stuff, there are some add-ons that can help you, you have to use certain hosts to prevent it from crashing.

There are other types of "extensions". What I think of is the number of users and other things. This is an understandable metric for various services to be used in the pricing hierarchy. But in WordPress it's free. You can have as many users as you like and have as many meticulous permissions as you like. This is just CMS, so adding other services may still be charged per user. Vercel or Netlify charges per user for team accounts. Contentful (a popular headless CMS) starts at $489 per month. Even GitHub’s team tier costs $4 per user if you need any features that a free account doesn’t offer.

Separate the front-end and back-end

This is a big factor that makes people excited about building websites with Jamstack. If all the features and content of my website are behind the API, the front-end can be built as you like.

• Want to build a fully static website? OK, access that API during the build process and do this.
• Want to build a client-side rendered website using React or Vue or anything else? Very good, client access API.
• Want to split the middle, pre-render some, client-side rendering, server-side rendering? Cool, this is an API that you can access as much as you want.

This flexibility is great in a brand new build, but people are equally excited about theoretical future flexibility . If all features and content are API-driven, you can completely separate the front-end and the back-end, which means you can change either side more flexibly in the future.

• As long as your API continues to output what the front-end expects, you can re-architect the back-end without affecting the front-end.
• As long as you get the data you need, you can re-architect the front-end without affecting the back-end.

For websites of a specific size and size, this separation feels "safe in the future". I can't pinpoint exactly what these size numbers are, but they do exist.

If you've ever done any major website re-architect just to fit one party or the other, it certainly feels a wise move to move to a system that separates the backend and frontend.

You can detach your WordPress website (we'll discuss in the "Use both" section), but by default WordPress is a very integrated solution where the front end is built from themes in PHP using a very WordPress-specific API. There is no separation at all.

Developer experience

Jamstack has largely prioritized the developer experience (DX). I've heard some call it "local optimality", which means Jamstack's design revolves around the local development (and local developer) experience.

• You should work locally. You work in your own comfortable (local, fast, custom) development environment.
• Git is the first citizen. You push to your production branch (such as master or main), and then your build process runs and your website is deployed. You can even get a preview URL for the production website for every pull request, which is an impressively powerful feature.
• Use any tool you like. Do you want to pre-built a website in Hugo? Just do it. Did you learn create-react-app at school? Although used. Want to try the latest framework? Even if you try. You are free to build your own way, taking advantage of the fact that you can build and deploy any folder you want in the repository.
• Things you don't have to do are also important. You don't have to deal with HTTPS, you don't have to deal with cache, you don't have to worry about file permissions, you don't have to configure CDN. Even senior developers appreciate that there is no need to do more.

This is not to say that WordPress doesn't consider the developer experience (for example, they have a CLI that does useful operations like building blocks), but I don't think DX is as important to me as the core of the project.

• Running WordPress locally is tricky and requires you to run the (X)AMP stack somehow, which involves in notoriously elusive third-party software. Thanks Local by Flywheel. There is some guidance, but it doesn't feel like a priority.
• What should I put into Git? To this day, I'm still not very clear, but I've basically decided to use the entire /wp-content folder. To me, it feels strange that there is no guidance or obvious best practice.
• You need to be responsible for your own deployment. Even WordPress dedicated hosts don't really do this. This is largely just: This is your SFTP credentials .
• Even if you have a good local development and deployment pipeline set up (I'm very happy with mine), this doesn't really help with the movement of the database, so you need to take responsibility for it yourself.

These are all problems that can be solved, and the WordPress community is huge and you can find a lot of relevant information in it, but I think it's fair to say that WordPress doesn't have DX as its core. Even after all these years, it's still a bit like the Wild West.

In fact, I found that many people simply don’t have a local development environment because of the marginalization of encouragement for a healthy local development environment. It's anecdote, but now I've found myself involved in other people's websites twice that are entirely production-only . It's a different story if they are very simple sites and have default behavior to a large extent, but these sites aren't. They are very complex (much more complex than this site), involving public user logins, paid membership and permissions, page builders, custom shortcodes, custom CSS, and a large number of active parts. This scares me very much. I don't want to touch anything. They are editing PHP on the spot to get things working—as people joked about, denim coding . With a syntax error, the website will crash, and maybe even the page you are viewing.

It's very interesting to power WordPress without particularly good DX. Without DX, there is no Jamstack. This is entirely for developers. For WordPress, most websites may not have developers at all . It is installed (or activated in the case of WordPress.com) and the website owner starts there. Website owners are like developers, they have a lot of power, but may not write any code at all.

To do this, I would like to say that WordPress focuses more on UX than DX, which is a very important part of it all…

CMS and end user UX

WordPress is a very good CMS. Even if you don't like it, there are a lot of people who like it, and the data speaks for it all. When you decide to build a website with WordPress, you gain a lot of the ability to build nearly any type of website you want. It's unlikely to happen with WordPress , I'm pushing myself to a dead end .

This is a big deal. Jenn points out this, pointing out that people who use WordPress are more important than developers’ needs.

WordPress can do a lot of things:

• Blog (or any type of content-centric CMS-style website)…
  • With content preview, this is possible but tricky in Jamstack
• Handle users/permissions…
  • At the administrator/CMS level, and
  • At the user-oriented level (e.g. forums, subscriptions, social, etc.)
• E-commerce
• Processing forms
• Handle plugins to the extreme

Jamstack can definitely do all of these things, too, but now it's Jamstack in the Wild West era. When you look at tutorials on how to store data, they usually involve explaining how to write a single CRUD function for a cloud database. This is the underlying thing, it can be very powerful, but it's very different from clicking a few buttons, and that's exactly how WordPress feels in a lot of times.

I bet I could probably use the Stripe API to piece together a basic Jamstack e-commerce setup, which is pretty cool. But when I need to start thinking about inventory management, shipping areas, product variants, and who knows what complicated things are there in the e-commerce world, I feel nervous, which makes me wish I had something really powerful to help me do all of this.

Sometimes we developers just build websites for themselves (I do a lot of this), but I think developers are mainly building websites for other people. So the most important question is: Does the thing I'm building enhance the capabilities of the people I'm building for?

You can achieve a good website management experience anyway, but WordPress has undoubtedly proven that it offers services in the field without having to put too much effort into custom development.

However, Jamstack has some tips that I hope to implement on WordPress. An important trick for me is: user-submitted content and updates. I actually have three sites that benefit from this right now. A website about conferences, a website about serverless, and an upcoming website about coding fonts. WordPress can definitely do a great job on all three sites. But what I really want is to allow people to update and commit content in a way I can say that: Yes, it looks good, merge. By adopting the Jamstack approach, the content is located in a public GitHub repository and anyone can participate.

I think this is great. It doesn't even necessarily require someone in the public to understand or understand Git or GitHub, because Netlify CMS has the concept of open creation, which keeps the entire contribution experience in the browser and provides a UI for editing.

Use both at the same time

This is an important question I often see being mentioned. Even Netlify itself says "no opposition".

The problem is this:

• "A" in "Jam" stands for API. Use APIs to build your website at build time or at the client.
• WordPress websites have a REST API by default (and can also have a GraphQL API).
• So use this API to get CMS data on your Jamstack website.

Yes, it's totally OK. This works, and people are doing it. I think this is cool.

but……

• Running a WordPress website outside of your Jamstack website means…you are running a WordPress website as well as your Jamstack website. This incurs costs and technical debt.
• You usually don't get all the value of WordPress. Using an API to get data is probably all you need to do, but this is a very, very different way to build a WordPress theme. You don't get any other value from WordPress. What I think of is a situation like this: you find a cool plugin that adds a fancy Gutenberg block to your website. This "just run" on a WordPress site, but it may have some special front-end behavior that won't work if you're just extracting HTML from the API. It may contain some extra scripts and styles that you need to figure out yourself how to merge into your front-end hosting location, as well as maintaining updates yourself.

Here are all participants with a unique “use both” approach:

• Frontity: WordPress's React framework. You can run it behind it and use a Node server, as well as your WordPress website. The Node server renders React to HTML, so you can do server-side rendering for all pages, but you're still building the SPA.
• WP2Static: A WordPress plugin that builds a static version of a website and automatically deploys it when changes are made.
• Strattic: They host dynamic WordPress websites for you (which they call "staging") where you can use WordPress normally. You can then choose to deploy and they will also host a static version of your website for you.
• Shifter: Shifter hosts WordPress websites for you. You have two options: 1) run headlessly (so you just access the API, REST, or GraphQL for the sake of getting the data) or 2) run statically (so when you have everything you want in WordPress, you can deploy it, which will create a static version of the website, they will also be hosted, or you can push it somewhere else like Netlify).

There are many other ways to integrate both. Here is our Geoff and Sarah talking about how to use WordPress and Jamstack both by using Vue/Nuxt with REST API and hosting on Netlify.

None of them are used

Just in case this is unclear, there are definitely many ways to build a website. If you are building a Ruby on Rails website, it's not Jamstack or WordPress. You can think of it as more like a WordPress website because it requires a server and you will use that server to do as much as you can. You can also think it's more like Jamstack because it encourages API and combinatorial services even if it's not statically hosted.

The network is big, guys, it's not a zero-sum game. I totally expect WordPress to continue to grow and Jamstack continue to grow because the network itself is growing . Even if we only consider the percentage of market share, I still think both will grow, pushing anything else into a smaller segment.

choose

I won't even discuss it here. It's not because I avoid favoritism, but because it's not necessary. I don't see the developers there biting their nails trying to decide whether to use WordPress or Jamstack methods to build the website. We have reached the point where the technology is understood enough, and the process is as follows:

1. Wear the right clothes
2. Assessing needs and results
3. Select technology

The above is the detailed content of WordPress and Jamstack. For more information, please follow other related articles on the PHP Chinese website!