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, a number of technological developments have been created in order to develop websites faster, while also being more performant. 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 a number of website servers (web servers) around the world, then serving website content (files) from the server that is closest to the requesting user. Lowering the distance from the server to the user’s client reduces network latency, so the user receives data faster.

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

What is a file? 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. Understanding the difference between a file and content is important.

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

A limitation of a traditional CDN is that it only stores a file’s contents, as opposed to executing the code within the file. Well… The CDN doesn’t want its web servers to waste time executing code or fetching data from other servers. So the CDN service expects website developers (web developers) to send the “static” (unchanging) content to the CDN. In this manner, a website user only receives data from the CDN, and not the original (origin) web server.

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

A CDN always needs to pull files from a server at least once, in order to serve those files over and over again (to each website user). This is the reason that — 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 Content Delivery Network Worker?

Modern CDNs have developed a technology called Workers, which execute code (JavaScript, WASM) in files that are hosted in a similar manner to static content. When a user requests a web page (which contains scripts on the CDN), the CDN’s web servers will execute code (in the script). This let’s web developers serve “dynamic” (changing) content from the CDN to the website user.

Note: The origin server of a website is still able to serve dynamic content without Workers while using a CDN.

Need clarification on how a CDN Worker works? Here’s a simplified explanation. A web developer pushes a file containing code to a CDN. The CDN creates copies of the file on each server it owns (all over the world). 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).

The web developer is expected to implement functionality in the Worker which always returns a response to the website user. So when code is executed, a web page is sent to the user’s client. However, a Worker’s response may not always be sent to the user directly. This is because serving a web page is a use case of Workers, but not their sole purpose: This becomes significant later.

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.

Most important is that a Server Architecture implies the usage of servers the developer can control. This allows the developer to use a server in a similar manner to a computer you own. As an example, a developer that controls a server will be able to perform 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 (i.e AWS, GCP, CDN, etc).

As a reminder, serving web pages is a use case of Workers, but not their sole purpose. The actual purpose of Workers is to allow developers 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. In other words, 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). These aren’t the same as Cloud Workers, which execute code on the Cloud(i.e AWS Lamda, GCP Functions). CDN Workers represent Cloud Workers that execute code at the edge of a network (i.e Cloudflare Workers). All of these terms involve a computer using an amount of computing power to execute code. As a result, the term “Compute Worker” is used to refer to these Workers going forward.

Serving Dynamic Content

What is the purpose of serving dynamic content? Let’s say that you want to create a website with a personalized homepage upon login (i.e Medium). This requires the web server to execute code that (upon a user’s request of the website):

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: The Compute Worker executes code which checks the user’s login status, then serves them personalized content. However, 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 fetches data from a database, then compares that data with other values. But how do you fetch data from a database? That depends on the server architecture of your website.

Need a practical example of a dynamic web page? You gain access to lots of information about Software Development by becoming a Medium member at https://switchupcb.medium.com/membership. Visit the page to see how a non-member is prompted, but a member isn’t. The condition being whether you are a member or not.

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 (i.e 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 (monolithic architecture) to access all the information you need from said server. 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 (i.e 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 in order to serve dynamic content. However, service architectures tend to be more complex (in order to address scale). So developing a Jamstack service is more complex in exchange for debatable factors. Of course, these factors are what prevents 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 Jamstack is faster than an out-of-the-box WordPress installation, usage of a CDN nullifies that advantage while serving static pages.

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.

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.

This assertion assumes that you don’t use Compute Workers with WordPress.

The caveat of using Jamstack while serving dynamic content is that you must set up a Compute Worker to do so. Otherwise, you must use a third-party service that does these things for you. 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 creating Compute Workers to glue multiple services together. Otherwise, that responsibility is passed on to a third-party service. This 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 — in a dissonant manner — 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.