WordPress is a 20-year-old Content Management System (CMS) that powers 42.8% of the internet using Linux, Apache, MySQL, and PHP. In that time, several technological developments were created to develop more performant websites faster. Yet WordPress continues to dominate the internet.

Jamstack is an 8-year-old “software architecture” that powers 1.2% of the internet using JavaScript, APIs, and Markdown. The architecture claims to make the web faster, more secure, and easier to scale. It also advertises how it builds upon tools developers love, which results in “maximum productivity”.

So why hasn’t Jamstack replaced WordPress yet?

The idea behind Jamstack is that you serve your website from a Content Delivery Network, which pulls the website’s files from a Serverless Architecture. 

But what does that mean?

What is a Content Delivery Network?

A Content Delivery Network (CDN) is a service — provided by companies such as Cloudflare and Fastly — that speeds up the time it takes for a website user to load a website page (web page). This service is implemented by hosting several website servers (web servers) around the world, which serve website content (files) from the server closest to the requesting user. This implementation lowers the distance from the server to the user’s client, which reduces network latency, so the user receives data faster.

In other words, a CDN represents a cache located “on the edge” of a network.

How Does a CDN Work?

You must understand the difference between a file and content.

A file is a virtual representation of paper that stores bits (1s and 0s). On the other hand, content is a human construct used to represent media (which files can contain). However, it’s also common for people to refer to file contents as the data within any file.

A “PNG Image” is a file with a “.png” extension which contains image content.

A technical limitation of a traditional CDN is that it only stores a file’s contents rather than executing the code within the file. This limitation exists because the CDN doesn’t want its web servers wasting time running code or fetching data from other servers.

So, a CDN service works by requiring developers to send “static” (unchanging) content to the CDN. Then, when a website user requests the website page, the CDN sends the static content from the CDN instead of the original (origin) web server.

A “PNG Image” is an example of static content.

A CDN must pull files from an origin web server at least once to serve those files repeatedly (to each website user). This requirement is why — in pull-oriented CDNs — the first visit to a web page after it updates is slower: The CDN must fetch the updated version of the web page from its origin server.

Of course, not all CDN’s are pull-oriented.

What is a CDN Worker?

Modern CDNs have developed a technology called Workers, which execute code (JavaScript, WASM) in files hosted similarly to static content. When a user requests a web page referencing scripts hosted on the CDN, the CDN's web servers will execute the hosted script's code. This implementation lets web developers serve "dynamic" (changing) content from the CDN to the website user.

Note: A website's origin server can still serve dynamic content without Workers while using a CDN.

Need clarification on how a CDN Worker works? Here’s a simplified explanation.

1. A web developer pushes a file containing executable code to a CDN.
2. The CDN creates copies of the file on each server it owns (all over the world).
3. When a website user requests a web page, a Worker is scheduled to handle the request by executing the code in the file that the developer sent.

Serving a web page is a use case of Workers, but it is not their only purpose. For more information on an implementation of a CDN Worker, read “How Workers Work (Cloudflare)”.

What is Server Architecture?

Server architecture refers to the system design of a network of computers (called servers). In other words, a server’s architecture shows how a group of computers interact with each other. In the context of a website, server architectures are used to serve a single website page from multiple computers.

The significance of a Server Architecture is that it implies the usage of servers the developer can control. This control lets the developer use a server like a computer you own. For example, a developer that controls a server can perform setting configuration, file management, and program execution.

What is Serverless Architecture?

A Serverless Architecture is a type of Server Architecture that involves the usage of servers the developer has no control over.

😑 Yes. You read that right.

In Serverless Architectures, the responsibility of server management is transferred to third-party services (e.g AWS, GCP, CDN, etc). Developers use Workers to run functions (lambdas, etc) without managing a server. Then, the third-party service charges the developer for the used computing power.

Since these “functions” are typically executed “on the edge”, using a serverless architecture is also referred to as “serving from the edge”.

A Serverless Website is a website that is built using a serverless architecture. This is the server architecture that a Jamstack website uses to serve web pages. So, Jamstack is an implementation of a Serverless Architecture that uses Workers to push files to a CDN.

What’s confusing is that many terms are used to describe similar functionality to Workers.

• Web Workers represent background threads that execute code (on the same computer).
• Cloud Workers execute code on the Cloud (e.g., AWS Lamda, GCP Functions).
• CDN Workers represent Cloud Workers that execute code at the edge of a network (e.g., Cloudflare Workers).

All of these terms involve a computer using computing power to execute code. So, going forward, the term “Compute Worker” refers to these Workers.

Serving Dynamic Content

What is the purpose of serving dynamic content?

Suppose that you want to create a website with a personalized homepage upon login (e.g., Medium). This personalized homepage requires the web server to execute code upon a user’s request of the website that:

1. Reads the user’s request to determine their login status.
2. Serves a variety of (static) content depending on the user.

In this case, the website’s homepage is “dynamic” because it changes upon the condition of the visiting user:

1. The Compute Worker executes code which checks the user’s login status.
2. The Compute Worker serves personalized content based on the condition of the user's login status.

It’s also important to consider how the Compute Worker checks the user’s information.

It’s typical for a website to store user information in a database. So, in this case, “checking the user’s information” implies that the web server:

1. Fetches data from a database.
2. Compares that data with other values.

Need a practical example of a dynamic web page? This blog contains posts which require a membership to read such as "The Hectic Creation of GME".

See how a non-member is prompted to purchase membership, but a member isn't? The content you receive depends on the condition of your membership status.

How To Serve Dynamic Content

There are multiple ways to serve dynamic content.

1. Use an origin web server to directly serve dynamic pages: The usage of server-side code to generate content dynamically is implied.
2. Use an origin web server to directly serve static pages which contain iFrames (i.e YouTube Video Embeds) or request information from other services: The usage of client-side code to generate content dynamically is implied.
3. Use an origin web server behind a CDN with “page rules” (which are request handler rules configured using a reverse proxy). Then, serve static pages depending on the page rule.
4. Use a Serverless Architecture (e.g. CDN Workers) to serve dynamic content in a server-side or client-side manner.
5. Implement any combination of the above.

It’s common for dynamic content to require code that interacts with API services and data storage solutions.

With a server, you can create a monolithic application which uses a single server (in a monolithic architecture) to access all the information you need. WordPress is a monolithic PHP application that uses a MySQL Database and an Apache Web Server to serve web pages from a single server.

Without a server, you must use the network (internet) to connect multiple services of a website (e.g., user, billing, roles, etc). This behavior is a function of service architectures.

When Do You Need Microservices? Using Jamstack, there is no choice: You must use a push-oriented CDN and Compute Workers to serve web pages.

In each implementation, you must write code logic to serve dynamic content. However, service architectures tend to be more complex (to address scale). So, developing a Jamstack service is more complicated in exchange for debatable tradeoffs. And these factors are what prevent Jamstack from replacing WordPress.

So what are those factors?

Important Qualities of a Website

Performance

In theory, a serverless architecture is faster than a single server architecture because the serverless architecture serves information from the edge (which reduces latency). Using this logic, Jamstack is faster than an out-of-the-box WordPress installation. However, nothing stops you from using a “serverless” product — such as a CDN — with a server architecture.

Jamstack uses a push-oriented CDN to serve web pages from the edge. A WordPress server can use a pull or push-oriented CDN to serve web pages from the edge too. So, while an out-of-the-box Jamstack instance is faster than an out-of-the-box WordPress instance, usage of a CDN nullifies this advantage.

But what about performance under load?

In a Server Architecture, a single server handles all incoming requests from website users. This means that a user’s usage of the website COULD effect the performance of other users’ requests (when the server lacks adequate processing power). Since WordPress uses a single server architecture, its performance is limited by the server.

When it comes to serving dynamic pages, the performance of a specific Jamstack implementation is based on the implementation of the Compute Worker. Since these workers serve requests in isolation, one user’s usage of the website will NOT effect the performance of other users’ requests.

But usage of a CDN with WordPress can also nullify this advantage. So, with the correct implementation, there is no difference in website performance between WordPress and Jamstack.

The only difference between serving dynamic content using Jamstack is that you must set up a Compute Worker to do so. Otherwise, you must use a third-party service.

So how easy is it to add dynamic functionality in Jamstack compared to WordPress?

Ease of Use

When you set up a WordPress server, you own a database, the ability to run programs, cronjobs, and more. The Advanced Custom Field (ACF) plugin allows you to add fields to the WordPress Database — albeit in an Entity Attribute Value (EAV) table — without being a programmer. Combine this functionality with a User Interface (UI) plugin such as Admin Columns, and the result is Supabase with a website attached.

The plugin ecosystem that provides this featureful functionality is what powers the usage of WordPress. A developer can create a plugin using the PHP programming language. However, installing that plugin requires no technical skill. As a result, WordPress serves business users who need websites.

On the other hand, Jamstack implementations typically require you to compile website sources using a Command Line Interface (CLI) and in the worst case, Git. Most people do NOT want to spend their time fiddling around in the terminal of a computer. Especially those seeking a Content Management System (CMS) solution that is used to create CONTENT.

Considering the above, a WordPress replacement fails the moment that a user is required to open up a terminal (to update content). Requiring the user to type the letters “g— i— t” is just the nail in the coffin. But Jamstack turns that nail into a stake by requiring the user to also develop custom services.

That’s a stake right through your heart. Ouch!

Unlike the WordPress plugin system, Jamstack services aren’t likely to work with each other without custom code. So, the user must spend time developing Compute Workers to glue multiple services together. Otherwise, that responsibility is passed on to a third-party service.

And this lack of software interchangeability happens because the definition of Jamstack is extremely loose.

Search Engine Optimization

I had a friend who spent an entire year building a Jamstack website. Upon finishing, he got so excited that he hosted a release party to showcase the website before it went live. The showcase was going amazing, until someone asked him: “How do you configure SEO for the website?”

My friend clicked around in his terminal for a second before pausing, then looked at us. His eyes were dulled in defeat. He just spent all of this time working on a website that wasn’t even going to show up on Google. Devastating. He proceeded to stand up. Turn to the nearest window. Opened it. Then jumped.

Why Jamstack Is Failing

Built For Performance. Still The Same Speed.

Jamstack advertises better performance than WordPress, when usage of a CDN nullifies this advantage for static content. When it comes to dynamic content, Compute Workers can also be used with WordPress, which makes the performance argument obsolete. Let’s not forget that most Jamstack developers oppose service architectures  because “most people don’t need that level of scale”.

Serving Developers Over The Business Case

WordPress serves the business case first. The software is easy to set up and maintain for end users. The plugin system — while limited to the PHP programming language — makes it easy for people to add new functionality to a website. In contrast, Jamstack serves developers first. Users must spend time developing their own services or relying on third-party services to implement basic features.

An Ambiguous Definition

Most important is that Jamstack is an illusion. Not real. The definition changes year after year because Jamstack is a buzzword that was created to serve the pockets of Netlify. In its current form, Jamstack describes the process of “using Serverless Compute Workers to push files to a Content Delivery Network (especially Netlify)”.

Jamstack didn’t invent JavaScript, APIs, or Markdown. Jamstack didn’t invent the concept of a Content Delivery Network. Jamstack didn’t invent compute workers or the serverless architecture. Jamstack didn’t create the practice of decoupling frontend and backend services. Jamstack didn’t even invent putting it all together!

The Future of Web Development

Jamstack claims to be “the future of web development”, but is just a rehash of modern development practices. The performance gains are theoretical. Its productivity claims are subjective. The definition is too ambiguous to create a cohesive ecosystem. So, it’s no surprise that the “WordPress Killer” has failed to live up to its reputation.

Jamstack won’t replace WordPress.