WordPress Capabilities that JAMstack Really Should Steal
The precursor of WordPress was called Cafelog, and there’s a sort of architectural fragment left from it that carbon dates its demise occurring sometime in 2004. That fossil page makes clear what the defining idea of b2 (as Cafelog’s underlying software was called) was all about: “pages are generated dynamically from the MySQL database, so no clumsy ‘rebuilding’ is involved.”
Tying a web site’s content presentation to a database made it possible, first, to offer a console where administrators could add and arrange blog articles quite separately from the engine used to deliver those pages. Secondly, the shift made it obvious that, as long as the administrative interface was there, a large selection of tools could be aggregated there in a single view. WordPress carried forward this dynamic connection to a database when Matt Mullenweg and Mike Little forked b2’s code in 2003. In the new blog realm, web pages were produced on the fly from database entries; those database entries got there by way of a backend application. This continues to be the basic operating order of WordPress.
JAMstack Page Speed
Plugins came along in 2004, themes in 2005. Plugins meant that site builders could add prepackaged functionality without having to alter the core blog engine. The addition of dozens of “hooks” several months later meant that developers of plugins could tie functions in their code to specific moments in the sequence WordPress used to serve up each page.
The basic pattern for a blog (and later, any content-centric site) emerged as a generally flawless installation of the free WordPress software, picking a theme so to overlay a specific design look, then choosing and seamlessly installing plugins to provide capabilities that weren’t built into the core. There are some 55 thousand plugins by now, most of them overlooked and unused, but a sufficient number that there are widely distributed plugins to add all sorts of capabilities, including paid subscriptions, custom page (data) formats, specialized reporting, caching of pages and graphics, third-party comment services, anti-spam protections, and so on. Kinsta maintains a page of statistics where the growth of plugins can be tracked.
In a similar vein, Scepter Marketing tracks themes, reporting that there are 211 companies that sell themes (and of course there are multitudes of free themes), with an overall count of 31,000 or so themes.
While WordPress was becoming the dominant web Content Management System (CMS), a great deal of the web that wasn’t running on WordPress had moved to JavaScript. On the back end, where WordPress was written in the PHP programming language, there was a growing wave of JavaScript programmers using Node.js. On the client side of things, JavaScript morphed into several key libraries for creating UI components. There are a lot of libraries, but there’s rarely discussion of them without mention of React.
The chatter nowadays is about JAMstack, which is to say applications that are built with JavaScript, APIs, and Markup. With JAMstack, development has circled back to the days before b2 and its MySQL-constructed pages: once again we seek sites that serve flat HTML pages, often with JavaScript included inline to provide the bells and whistles that web application users have become accustomed to. In this world, a web site creation tool is something that takes your supply of page data (which might or might not be stored in a database) and generates a flat HTML web site.
Static Site Generators (SSGs) essentially take web page inputs and compile a static collection of web pages. In the case of SSGs like Gatsbyjs, the tactic is to deliver an HTML page with enough JavaScript capability embedded in it that it can prefetch data from the server and display interactive components as if they were new pages, when in fact only part of the page is being replaced.
The static approach is attractive, in large measure, because it is, by default, blindingly fast. If you’re determined, you can screw up an SSG site so that it’s as slow as a sloth, but that’s not typically how it goes.
There are lots of ways to go at this basic JAMstack scenario, lots of frameworks and libraries. Sorting them out is part of the brief of PeakZebra.com, but in this particular report let’s lump them together and notice that they tend to be offered to the world as a good way to move from the pre-owned Chevy Tahoe of WordPress to the Maserati that JAMstack can provide.
JAMstack Page Speed
JAMstack proponents tend to be heavily focused on its page delivery speed, with a lot of emphasis placed on how valuable this raw speed is going to be when Google starts using Core Web Vitals as a ranking factor, something they’ve said they’ll do in May 2021.
And it’s blinding fast, done right, pretty much no matter which flavor of JAMstack you decide to use, whether Gatsbyjs or Next.js or 11ty, or whatever. Not only is it as fast as flat HTML pages, but in some instances, it’s actually faster, because it uses JavaScript in embedded pages to preload content before it’s clicked on, displaying that content on the current page, rather than preforming a full page reload. It can be shocking how fast pages load in this kind of arrangement.
WordPress defenders rightly point out that simply using a good caching caching plugin or service can make previously served pages into cached static pages, ready for instantaneous delivery. A well-tuned WordPress installation on a fast server, using a well configured caching capability is capable of impressive performance, however dowdy WordPress in general may seem. Nitropack.io has a particularly interesting spin on this—reading through the explanation on their site is worth your while.
WordPress Is a Little Clunky, Yup
Now, I’m writing this report for publication (at least initially) on a WordPress site, and it will become clear momentarily that I think there’s a great deal to admire in WordPress. That said, though, there really are some things about WordPress that feel a bit creaky.
First and foremost, if you measure a representative sample of WordPress pages around the Web for page delivery speed, you’ll get a lot of mediocre scores—no need to take my word for this, by the way. Have a look, for instance, at this broad investigation of different kinds of sites in the wild and how they performed.
Then, there’s the aforementioned PHP language and what seems to be a widespread perception that WordPress isn’t well optimized internally. I don’t especially buy the argument that an outdated language is what makes WordPress clunky. Yes, most of the front-end design world is using JavaScript and associated libraries (reactjs in particular). Heck, even WordPress is written in JavaScript when it comes to new, client-side features.
But while it’s fashionable to paint PHP as outdated, there’s simply not much substance in that claim. Viewed from a certain distance, C, PHP, Java, JavaScript, TypeScript and no doubt some others that I’m missing here all look pretty much like the C language, just without C’s myriad potential pitfalls. PHP used to be a rather old-school language in terms of support for object-oriented programming and things like closure, but pretty much all the bells and whistles that are enjoyed among the JavaScript cognoscenti have been available in PHP for some several years.
PHP may not inherently degrade WordPress, but one thing that does make it hard to build in extra client-side functionality is that the environment is not merely PHP, but is PHP running inside a framework that is trying pretty hard to completely hide the PHP from you. Perhaps you want to toss a PHP variable into a blog entry. That’s not going to happen in the direct way that PHP was expressly written to facilitate.
In unfettered PHP, you can just embed a variable right in the middle of some text in an HTML page:
<? echo $myHelloMessage; ?>
But in WordPress you cannot embed PHP in your page content. It’s not allowed—and that’s for good reasons, too. Embedding PHP in your page data is an invitation for less experienced programmers (and non-programmers) to get into deep security trouble.
PHP Inside WordPress
You can’t embed PHP, and furthermore the WordPress environment aggressively influences how things get done in code. And serious coding work can get messy. I won’t delve into details here, in part because I won’t claim to have complete mastery of them at this point, but the way you have to tie into “the Loop” at different points in the cycle can make for some seriously disjointed code.
There’s also a lot of ways you can hook into WordPress internals. That’s good in terms of flexibility, but can mean that all sorts of clutter gets hooked in. Things can get bloated and slow in ways that you wouldn’t necessarily anticipate as you add this or that plugin.
Aren’t Dynamic Pages a Good Thing?
Defending WordPress from the claim that it’s clunky also requires that we return to that core truth of WordPress: the fact that there’s a database running in the background. The casual argument in favor of static sites is that they are, well, static.
And yes, having a database means that pages get put together by way of several database queries, at least now and then when the cache system has a miss. But precisely because of that cache system, these pages are going to tend to get stored for re-use, so they are essentially static pages in many instances. Where the database really does add time to the equation is when something dynamic is done that caters to a specific user’s situation or preferences. If a page has to be put together for each user, well, there’s no caching that’s going to help that (um, actually that’s not true, but the details don’t matter here). If the page has to be put together dynamically each time it’s served, then it’s going to be slow.
A framework like Gatsby claims to have the upper hand by using static pages, but of course that’s not quite comparing apples to apples. If a JAMstack site needs to personalize pages on a per user basis, it may do so by way of API calls to a third-party services, but make no mistake, this is still just referencing a database on the back end. In the customized-page scenario, there’s no inherent JAMstack speed advantage. And, frankly, this is a fairly common scenario.
Maybe the database thing doesn’t make WordPress clunkier than JAMstack, but some other aspects of the WordPress ecosystem do produce a certain amount of rattle when you head out for highway driving. WordPress bolted on responsive site design after the fact, with the result that delivery of mobile pages is nearly always worse that delivery of desktop pages. In a world that’s drifting toward mobile first, this is a problem (and it’s a bigger people than most people want to talk about—lots of current websites are utterly miserable performers when viewed on a smartphone). Adding special capabilities to your WordPress is easy when a good plugin is already available, but if you’re trying to build your own application, getting it done with a mishmash of configuration settings, existing plugins, and your own PHP plugin code can make for an inefficient mess that’s hellish to return to later when modifications are needed. Adding a plugin that does absolutely nothing at all drags down page delivery times by a handful of milliseconds.
And even though caching cures a lot of ills, the fact remains that when you turn Google’s pagespeed tests loose on WordPress sites, they tend to produce sluggish results. You might argue that Core Web Vitals aren’t a good measure, but the truth on the ground is that these are the metrics that Google is going to factor into its search result rankings come May.
The upshot here is that more websites are going to built using SSGs in the coming year, if only for the gain in CWV scores. But whether your preferred JAMstack is Gatsby or Next or something else, turning the page and moving to an SSG approach will instantly make you aware of the many wonderful things you’re accustomed to and that have gone missing as WordPress is abandoned behind you.
My purpose here is not to prove that WordPress is outdated or a second-rate CMS, but to point out how many things are right about it. For those moving toward SSG deployments, these are key features and capabilities that need to be carried over to the JAMstack ecosystem as quickly as possible. Otherwise, the vast adoption that WordPress has enjoyed won’t be visited on JAMstack.
The WordPress Theme Approach
You can change the look of a WordPress site in dramatic ways just by changing the theme you are using. For the most part, you can change indiscriminately from one theme to another at the click of a button, and the site still functions as you’d expect. This works because most of WordPress’s use focuses on fairly traditional pages. A page is exactly what you think it is, while a post is a page that has a more clearly delineated chronological relationship to other posts (it’s a blog entry, in other words).
I’ll talk about Gatsby on the SSG side of the coin: that’s the framework I currently know the most about. Gatsby, as it happens, has themes. But it doesn’t have themes in the same way that WordPress does, and the difference is one that matters.
In WordPress, a “theme” is roughly synonymous with a “design.” When you consider using a particular theme, you are mostly thinking about what your site will look like (there are also sometimes extra features built into themes, but even those elements tend to be about the look of the site).
Want a site with a huge picture and just a few words on the home page? Then you might want the “Twenty Seventeen” theme.
Or maybe you want something that looks like a busy magazine site:
You can tailor the look of a theme because, within the administrative console, there’s an interface for changing things like typefaces, accent colors, menu styles, and so on (depending on which configuration options a theme offers).
This works in large measure because, to date, WordPress has tended to be centered on “bloglike” deployments. A theme is about look and feel, or as WordPress.org puts it: “A WordPress Theme is a collection of files that work together to produce a graphical interface with an underlying unifying design for a website.”
Gatsby, on the other hand, says that its themes “are plugins that include a gatsby-config.js file and add pre-configured functionality, data sourcing, and/or UI code to Gatsby sites. You can think of Gatsby themes as separate Gatsby sites that can be put together…” The aim is different, though UI is a factor, but Gatsby themes don’t allow you to “reskin” your Gatsby site on demand.
All that said, I should note that there’s a shift underway in WordPress to themes that function as “builders,” meaning they are drag-and-drop design tools (Elementor and Divi, to take two examples) that let you design whatever you want (within the constraints of WordPress’s blog-like view of the universe). These are practically frameworks in and of themselves, and not surprisingly there are now themes that are only meaningful when deployed at a site that uses the underlying base theme.
In response to the rise of the Divis and Elementors of the WordPress world, WordPress itself has shifted to a “blocks” interface that treats elements on a page in a way that would be draggable in a simpler, kinder world. What’s great about this “Gutenberg” version of the content editor is that it enables you to embed elements (interactive graphs, say) that aren’t part of the normal fare of blog entries.
Themes in Gatsby (as they currently exist) certainly can control the design of the site, and in principle could do the same things that a WordPress theme does, but they install from a developer interface, not from a user interface. You can change them on the fly in principle, but honestly, I wouldn’t bet my career on a swap-out going seamlessly at this point.
Not every Gatsby user is going to want a WP-style theme for their site, but it’s in large part the ability to have a good-looking design out of the box that has made WordPress adoption so widespread. Right now, themes in Gatsby are a developer’s tool. But an enormous number of sites in the world are a home page, an about page, some product description pages, and a blog. These sites need a theme capability that lets them reskin with professionally designed layouts on demand.
People are thinking about this, to be sure. There are several hundred SSG themes collected at JAMstackthemes.dev, for example. Also of interest: https://gatsbywpthemes.com/. It seems clear enough to me that some kind of ecosystem will develop around SSG framework themes, but it certainly remains to be seen how these themes will be managed. (Please be in touch if you’re up to something in this arena.)
[Added 1/8/21] Another good looking Gatsby theme we ran across of late is Flat Magazine. Technically, this isn’t a theme in Gatsby parlance, but is instead a “starter.” There are important distinctions lurking in the difference between “theme” and “starter”: with a starter, you are setting up the look and feel forever, as far as using starters is concerned. With themes, you could overlay a set of new configurations, design elements, and functionality over the top of (or alongside) the existing site.[/end addition]
So: steal the themes, even if they have to be called something else so that they aren’t confused with the existing Gatsby theme capability.
Plugins
Since WordPress doesn’t want developers mucking around in the core code, at least not for one-off customizations, they’ve made it simple to plug in code. If you’re a developer, it’s not too horrible messy to work with. If you’re a user, you can search for, download, and install a plugin from the administrator console. Once you’ve clicked the box to activate the installed plugin, you can tweak it’s configurations from within the back end as well.
Gatsby has plugins, too. But they are more akin to developer libraries. While this sort of library is powerful and enables developers to do things like hook up a Gatsby front end to a headless WordPress deployment, what’s missing here is the “load-and-tweak” simplicity of WordPress. The lack of a plug-and-play variety of plugins won’t matter to developers who are building from scratch. But it will kill the small-business agencies that today build sites predominantly atop WordPress.
Maybe it should be a third-party service with an API, just like headless CMS, but in some way or another, we need those WordPress features to find their way into the JAMstack universe.
The API Thing
With JAMstack, the backend for the blog primarily shifts to a third-party headless CMS provider like Contentful or Sanity.io (see the New World Map for a longer list). A report on the current options will be out on this site in February, but for the moment let’s just say that while moving to a headless CMS is appealing in lots of ways, and in particular it gives you an editing and publishing administrative interface that can have some great bells and whistles, but it doesn’t give you an integrated back-end console.
There are lots of capabilities that the JAMstack world has to date presumed would be likewise handled by third-party API services. Again, see the New World Map for vendors who provide identity, reader comments, edge function support, search, and e-commerce options. We’ll be working through these various subcategories over the next few months.
Using APIs to handle the heavy lifting can offer great benefits, but there’s an appealing and comprehensive reach to the administrative interface on WordPress.
Before you write that comment you’re forming in your mind right now…I am well aware that you can run WordPress as a backend CMS for a Gatsby front end. It’s a great solution, attractive enough that even the Gatsby site uses it, but it still doesn’t give you a console where you can control front end theme selection, or users, or all that good stuff that WordPress has built in over the years.
What needs to be on the JAMstack console is something where WordPress’s experience can be borrowed, but updated. The layout and menuing of the backend can almost certainly improve on the quirks of WordPress (where many UI sins have accumulated).
In Sum
JAMstack should heat up the competition between frameworks like Gatsby and the massive incumbent that is WordPress. In particular, it should shamelessly steal:
- WordPress-style themes
- WordPress-style plugins
- Some kind of option for a native back-end administrative interface
These are all things that JAMstack platforms need to either steal outright or modify and improve. There are interesting arguments for using CMS as a service, but there’s something to be said for the way that you get the CMS in WordPress as part of an administrative console that also lets you control themes, plugins, and a number of user options in a coherent, fuss-free way. If WordPress publishers are going to be coaxed away to JAMstack platforms anytime soon, someone needs to create a way to carry forward the features that grew the WordPress ecosystem to its current gargantuan size.
WordPress has a huge—genuinely huge—number of users who are not looking for edge-case solutions. They want a blog and a plugin that lets them sell some custom hoodies. They want a plugin that lets customers book appointments. And yes, many of them want top-notch SEO performance, which is going to mean fast, performant sites, but there’s a lot of room out there right now for smart companies to build on the ease of use that the WordPress universe is used to.