You know there’s headless WordPress, but may not be clear on how you’d make it happen. Or, more importantly, why you’d make it happen.
What is headless WordPress?
Let’s start with a quick rundown of what makes a WordPress site headless, why the naming in this case is exactly backwards, and just generally get ourselves on the same page.
The conventional headful approach
Normal WordPress is a world in which the action happens on the server. A website visitor requests a page from the server and the server assembles the page components (header, body, footer) from the database and any relevant templates. This is sent to the browser, any browser at all. And if something happens down there on the browser, it will result in a new page being requested from the server.
Where this basic operation is perhaps most clearly visible is when the site provides some kind of data application. Maybe it’s a CRM application, so you might request a list of clients in the system. You get a display of the first 25 of them from the server, say. If you want to see the next page of clients, a new page will be requested from the server. If you want to see a particular client, a new page will be requested to display that client’s information. If you change the information for that client and want to save it, you’ll submit a form to the server and a new page will be delivered to show the update.
Meanwhile, in the rest of the universe
For most of the rest of the web, this isn’t typically how an application works, however. If you start with an application that shows a list of client records, then when you want to see the next page of them, a request will be sent to the server to retrieve only the data for the clients that need to be shown. The page with the client list won’t be replaced; rather, the new set of clients will be displayed on the existing page where the previous clients were listed.
It’s possible that you can edit any of the client fields you can see on each row of the listing. Let’s say you do this and press a save icon at the end of the row you’ve changed. Again, this doesn’t result in a new page being requested. Instead, the listing continues to show the change you made and the change is sent as an update request to the server.
The server, in other words, is just supplying data at this point, not pages (though, in our scenario, it probably supplied the initial listing page).
Decouple this
There are two things we should notice about this scenario. First, there’s got to be some kind of back end that answers requests for data and updates, even if it’s not supplying the pages. Second, the pages still have to come from somewhere. But the pages and the data don’t really have to come from the same place, and thus we can say that the presentation and the data have been decoupled.
When you decouple the head of a thing, well, it becomes headless. So the baseline idea of headless WordPress is that there’s a WordPress server running, but it’s not supplying the pages that the website visitor is seeing.
So where are the pages coming from? That depends, but most scenarios out there on the web right now fall into the basic pattern of using React (or some React framework that extends React) to create pages that can be retrieved from web servers as plain HTML and JavaScript files. These pages aren’t assembled or calculated on the server end, they are simply sent to the client as they stand. You’ll hear these scenarios referred to as static sites. That’s because the server doesn’t muck around with them–they can be plenty active once they are displayed in a browser window.
One question that may already have popped into your mind is: what is React? And that’s an excellent question, but not one that we’re going to answer in any detail here. Suffice it to say, it’s a pre-built set of capabilities implemented in JavaScript, where the capabilities mostly have to do with user interactions.
The key thing is that JavaScript and React are capable of asking the server (or more than one server) for data that it needs to display. The server that sends the data down to the browser in the headless WordPress scenario is, you guessed it, a WordPress server.
Headless
There are plenty of headless scenarios where the server isn’t a WordPress server and there are even scenarios where there arguably isn’t a server in the traditional sense.
But we’re talking WordPress here. In that scenario, there are two primary ways that WordPress might interact with whatever’s going on down there at the browser window. It may, in the older and more widely adopted approach, use a REST API to make requests for data (or requests to place or update data on the server). Making a REST call is based on requesting a particular URL and it either places any changeable data at the end of the URL (as parameters) or it arranges them in the same way you might arrange data when posting a form to a web server.
The other approach out there these days involves using a Graphql interface. This is more like opening a window directly into a database and making queries. The details of this don’t much matter for this discussion, the point is that it’s possible to install a plugin that creates a Graphql access point for a WordPress site.
Wait, but why?
Why would you take this headless approach, though?
The obvious first answer is that it enables you to have a different language and framework running on the client side of things. If you want a React application that serves up a lot of server-side content, using WordPress as your CMS might very well make sense.
Additionally, though, it gives you the capability to render and rerender a page in sections, so that you aren’t necessarily requesting a whole new page from the server every time anything happens.
Now, as it happens, you can pull off this same trick using the new Interactivity API in WordPress, because it makes the front end capable of doing various things on its own. It let’s you build a “headless-seeming” user experience completely within a WordPress context.
It’s not clear yet how well the Interactivity API will fare, as it’s still relatively early days, but it’s an interesting option for dynamic front ends (plus it’s in use within WordPress core, so it’s not likely to go anywhere anytime soon).
WordPress makes a pretty solid CMS, particularly where the content is of the human-readable sort.
If you land in certain corners of the Twittersphere, you’ll find yourself surrounded by people who are wildly enthusiastic believers in the power of NFTs (non-fungible tokens) to change the relationship between creators and consumers.
By extension, they are at least a little enthusiastic about cryptocurrency as a means to an end, though they are quick to point out that they aren’t at all like the real crypto enthusiasts, who just want to get stupid rich by purchasing lots of Bitcoin and other blockchain currencies and then “hodling” it forever (that is, holding it).
There’s also a great deal of interest and activity around the underlying blockchain technology that makes NFTs and hodling possible, though there’s maybe a little less wild fervor. So is it time to bring blockchain to WordPress?
Probably nothing
These folks are probably onto something, even if the sheer enthusiasm and the whiff of naivete is a little off-putting. The slang (like saying “probably nothing” as an ironic way of saying that some NFT development is likely to be huge, but whose importance is overlooked by the public at large) can get old. But in any case, on to something. It’s just an open question whether what they are on to is the same thing as whatever it is that will ultimately wind up mattering. Indeed, there are some interesting things that a business (whether a solo creator or something bigger and more traditional) could potentially do with blockchain technology and something like either minted coins or NFTs.
For some, there’s a real opportunity there, so the pressing question becomes: what’s the shortest distance from whatever I’m doing on the web now and offering some sort of blockchain capability?
There’s a reasonable likelihood that you are running your website on WordPress, meaning that the question will ideally boil down to installing a blockchain plugin or two. As we know, plugins can be magic.
But before having a look at the current assortment of “early phase” plugins that handle various blockchain-related tasks, let’s talk about why you’d want to get your WordPress site tangled up in the cryptocurrency world and what you’d actually be trying to get done.
Blockchain Potential Benefits
If you’re running a “non-crypto” website or business (and this is most of us), you may be wondering why you should even bother with blockchain and cryptocurrency.
Crypto Payments
One answer may be that you have enough cryptocurrency users in your customer base or target demographic that it makes sense to accept payments in Bitcoin and/or Ethereum.
NFT sales
A fancier possibility is creating NFTs of some sort and selling them to the NFT collectors out there (of which there are surprisingly many). I don’t know if any of the NFT fervor, especially around JPEG art, makes any sense, but in a way it doesn’t matter. People want these sorts of things and the prices paid for them are occasionally staggering. Plus, depending on what you are doing and how novel it is, this may be a form of getting your name out there (that is, marketing) while the interest level is insanely high.
To create NFTs, you need to create the data (the picture, the text) that will be the “contents” of the NFT, which is just the normal process of creating such things. But after that, you’ll need to either mint the NFTs yourself or provide a way for buyers to mint them as they buy them.
Creator Coins
Elsewhere in the world of tokens, there are interesting experiments underway with what are being called “creator coins” or “community coins.”
You can mint NFTs, as mentioned above, but you can also mint tokens that are “alt-coins.” They are cryptocurrency that’s built on top of other cryptocurrency, by way over oversimplifying.
When I was talking about creator coins a couple of weeks ago, I singled out Rally as a startup that was leading in building out this kind of alt-coin production:
Dogecoin is the alt-coin people talk about, mostly in a sort of disbelief that there’s such a thing as joke-but-real money. But Rally envisions spinning up lots and lots and lots of alt-coins, one per creator/entrepreneur. Because Rally is an Ethereum sidechain, the coins are actually tied back to a currency system that in turn ties back to what most of us still (archaic fiat-currency boomers that we are) think of as real money.
I think it’s fair to say that we’re still figuring out what it means to launch your own creator coin, but the underlying thinking is that this gives you a way to have a self-contained economy in the community that supports you. People buy your tokens as a way of supporting your work (think, approximately, Patreon, but with crypto). You as the creator at the center of this economy can reward fans for contributing their time or feedback or enthusiasm using the coin of the realm. And holders of the coins will, in most instances, receive whatever it is you’re creating, on a scale commensurate with how many coins they hold.
If this sounds vague, that’s because the whole thing is still vague, but we’re seeing early experiments in using these sorts of tokens as event tickets, as access to community sites, and a way to buy a book that keeps you “invested” in the community going forward.
Rally’s raison d’être is making it easy and seamless to create your own coin. But that’s not at all to say you couldn’t roll your own, using an Ethereum sidechain like Solana (this sidechain has the low “gas” costs you’d need if you were minting a lot of coins). If you do that, though, you’ll need an interface for doing the minting, need to connect that minting process to a wallet that supported Solana, then need a mechanism for making a small, private market for the coin.
There are code libraries out there for doing all these things. There’s even a few sites emerging that are doing these sorts of things on WordPress sites. Web3WP.com, for example, lets you mint a one-off version of the WordPress mascot Wapuu, should you be overtaken by any desire to do that. More broadly, it seems likely that creator coins may be one of the more interesting places to consider blockchain in WordPress environments.
WordPress blockchain plugins
There are already over a hundred blockchain-related plugins in the WordPress.org plugin repository, though only a handful have more than one or two hundred active installations out there in the world. There are also a growing number of plugins available outside the official repo.
As you’d expect, some of these various plugins are fairly arcane. One provides a websocket attachment to the Executium network, for example (40+ installations).
Others do the sorts of things you might be interested in doing to get your feet wet. The NFT Maker by Tatum (see below) plugin let’s you…yeah. And you get your choice of the Ethereum, Polygon, Binance Smart Chain, Celo, and Harmony chains.
So here’s a few plugins of note:
Crypto Price Widgets
Dip a toe into crypto by providing basic price information on your site. Crypto Price Widgets – CryptoWPdisplays the current prices of various coins in one of over twenty supported currencies. You can throw this widget into a sidebar or use shortcodes to drop prices into pages anywhere at all.
LikeCoin
From the plugin description: “LikeCoin aims to empower content ownership, authenticity, and provenance. Creators can register content metadata to guarantee its integrity by acquiring an International Standard Content Number (ISCN). ISCN is a tool to authenticate and track content, just like a digital footprint.”
This is one PeakZebra will dig into in more detail in the next few weeks, as there’s a lot of interesting stuff lurking in this approach.
Tatum – NFT Maker
If you want to dive into making and selling NFTs, this seems like the most straightforward path. You can mint tokens and sell them on the site, though you can’t let users mint the NFTs themselves, a capability that some sites are using. The reason for this exclusion, I suspect, is the Tatum plugin’s business model. The plugin is free, but you’ve got to buy credits to pay for the gas transaction fees that arise in the process. And heads up: if you’re minting on the Ethereum main chain, the gas fees can be very high.
WordProof does pretty much exactly what it sounds like it does, creating a hash of your latest post and writing it to the Ethereum blockchain, thus providing proof for the long run that you published exactly that version of the post on exactly that day and at that time. This may not be something you think you need (and you may be right), but one scenario is intriguing. If you’re a smaller website and you publish something wonderful, but a big site steals your piece and throws it up online right behind you, that site might actually get indexed by Google faster than you (sites with more traffic get higher priority), making you look like you stole the piece. This would theoretically let you set the record straight.
Anyway, you get ten stamps a month for free, after which you pay a few bucks per month. This uses the blockchain in a sensible way, but you won’t feel like your site has joined the web3 era just because you use it, because it hides the whole blockchain business from you.
WPSmartContracts
Despite the “smart contracts” moniker, this plugin lets you carry out a number of different, basic cryptocurrency tasks. It focuses on the Ethereum blockchain, and enables you to create ERC-20 tokens, Initial Coin Offerings, and has basic support for NFT marketplaces. The various things you can do with it are broken up into “flavors” of contract, with the simplest stuff being free and other flavors costing a small fraction of an Ether (though, note: a small fraction of an Ether is still some money, given that Ether is trading at over $4600 as this is written).
Blockchain in WordPress? Still Early Days
There’s still a lot of inventing on the fly in the world of smart contracts, NFTs, and alt-coin. But there’s also a lot of momentum behind it and there are likely some opportunities to be rewarded just for getting to the party early. Using plugins, particularly as they become more capable and robust, may very well be a way to get out in front of the pack while they struggle getting their blockchain programming skills up to snuff.
A long, long year ago, it seemed prudent to bring up a few things that worked well in WordPress that were missing in Gatsbyjs. For instance, one-click exchangeable Gatsby js themes.
Some, but not many, of those holes have been filled in various ways, but others remain (and probably will remain). But time has pushed each of these web frameworks down the road a piece, meaning more developers have had more, different experiences with them. A knock-on effect of this is that it’s now clearer what it would be most useful to beg, steal or borrow from WordPress.
WordPress vs Jamstack
To be clear, Gatsby and WordPress are trying to solve somewhat different problems.
Nor is anyone saying there’s something terribly wrong with Gatsby (or Next.js or Remix Run, the new kid on the block). WordPress is monolithic, the Jamstack crowd is looking for the Great Decoupling, plus static pages, plus edge functions, plus GraphQL queries to anything you might once have tackled with a REST API.
Jamstack is aimed squarely at developers, not people who just want to drum up a website with their contact information and a few brochure pages. At the same time, a lot of the world’s websites are running on WordPress, frequently on fairly straight-out-of-the-box WordPress. That is, these are not people (and marketing departments) who are going to fall into the arms of Gatsby, even with a Gatsby template for a blogsite. They’re not going to be pushed into those arms, either, not by the need for blazing-fast speeds and not by their desire to move to a “friendlier” cloud CMS.
As far as speed goes, last year’s “theft” essay got at something of a fundamental truth:
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.
Another thing happened in the course of the past year: Google rolled out the Core Web Vitals algorithm update that had us all worried about whether our web pages were as blindingly fast as they needed to be to rank. And it turned out not to make all that much difference. The WordPress sites of the world did not drop off the face of Google Search Engine Results Pages (SERPs).
So if you’re running a website on WordPress and wondering whether you need to high-tail it to Jamstack, the pressure is off, by and large. It’s still nice to have a screamingly fast site, of course, and it’s nice, most folks seem to agree, to work strictly in JavaScript, rather than PHP, as is used for the core of WordPress.
The Headless WordPress CMS Approach
The Jamstack response is to argue that the point of decoupling the front end from the back end is that the back end can still run a WordPress stack. In Gatsbyjs, you’ve got the rather sweet option of using WPGraphQL (with a hat tip to Jason Bahl (@jasonbahl) for putting that great WordPress plugin in motion).
That’s good stuff if you’re a developer, but on the flip side, all sorts of very useful things drop out of play if you abandon the WordPress monolith you’ve been running. And they’re mostly gone even if you keep running WordPress, but use it as a headless CMS.
For one thing, the WordPress theme you’ve been using on the monolithic site is gone, with the design coming from the front-end side of the house.
You can deal with this by getting a theme that behaves and looks more like WordPress—have a look at GatsbyWPThemes for a run at that (and I plan to dig in, try it out, and write about it before long, following on a great conversation the other day with Alexandra Spalato, one of the company’s founders.
In short, you can’t just point your Gatsby front-end at your WordPress theme.
It might seem like this should be doable because, after all, a theme is basically a bunch of CSS in a style.css file.
But it’s not nearly so simple. For one thing, there are also template files that determine what the various repeating sorts of pages (blog entry lists, the blog entries themselves, and so on) should look like. These are written in PHP and HTML, using conventions that are very closely tied to WordPress.
I’ve wondered in the back of my head whether it would be very hard to just write a simple (but would it be?) cross compiler to translate from the PHP files to more Gatsby-native templates. It wouldn’t shock me to see something like this get cooked up before too long.
Jamstack Admin
But even if we get to that point, where WordPress themes are convertible to Jamstack scenarios, you still won’t be able to jump into an admin console, look at a list of themes currently downloaded for use on your site, pick a different one, and hey presto, have a new and different look instantly online at your site.
You can’t do that because, duh, there is no admin console for that Gatsby site of yours.
If you build your site with a CMS and some other, separate services for identity management, database interactions, and localized customization, you have many things to manage and no centralized console.
If you’re a relatively low-code user of WordPress, what you’re going to be missing most of all is that you can’t jump into the WordPress plugin section of the console.
Gatsbyjs Plugins
Now, Gatsby does have plugins. These plugins have some of the same uses as WordPress plugins, but they are designed to be consumed more or less as libraries that the developer has access to. Next.js has plugins, pretty much along the lines of Gatsby, along with some interesting third-party twists. For example, Grouparoo has a system for adding plugins that grab non-static content to add to pages.
All that said, I’m not aware of any way on the Jamstack side of things for a third-party to program some simple little bit of functionality—to take a trivial example, giving you the ability to create pop-up footnotes within your text content[footnote]Why look, here’s just such a plugin in action.[/footnote]—that you can download and just start using at runtime and without having to work it into the fabric of your own custom application.
Anybody who’s worked in WordPress knows that plugins can be an incredibly powerful way to get a lot done without having to do any real work. Books are always mentioning how many tens of thousands of plugins are out there. The huge number thing is nonsense, because there are all sorts of duds and orphans in the pool. But the decent plugins (and there are certainly a few thousand of these) out there make it possible for you to add nice bits of extra functionality because it’s already coded and it’s available with no fuss.
WordPress plugins are a different animal, and Jamstack needs to steal this version of the plugin thing wholesale.
Gatsby JS Extensions
To keep things straight, I’m going to dub the Jamstack version of plugins “extensions.”
Extensions should snap into a Jamstack framework along the same lines as their WordPress forebears. In other words, they should register callbacks to their functions with named events in the Jamstack process.
So, if we imagine that there’s an event in a Jamstack site where a user logs in, that event might be called “user_login”. In the plugin, we’d include a function called greet_user() that did whatever we’d want to do now that the user was authenticated and we knew who it was. In addition to declaring and defining the function, a separate line of code would “hook” the “user_login” event, along these lines:
register_action( 'user_login', 'greet_user' );
Thus the user lands on the site, which because this is Jamstack is a bunch of basically static pages, there’s a login routine that does whatever it does, calling back to some remote service for authentication. When the user successfully logs in, the Jamstack page currently loaded “fires” the “user-login” event and calls back any functions that were registered for this event.
Since we registered for this event, our greet_user() function will be called, we’ll do whatever we need to do, then the function will return to the overall process of showing pages and interacting with the user.
Jamstack Architecture: Complicating Issues
A bunch of things add some measure of complication to this, compared to the WordPress version of it.
No admin interface. We don’t have the admin interface for adding and activating (and deactivating, and configuring) these extensions. For now, let’s pretend that this is no big deal. (It’s probably actually a big deal, because you probably want to build it so that non-developer admins can use and tweak extensions. That’s kind of the whole point of them, at the end of the day. But where does this thing live? Static pages on the client? But most clients aren’t admins…)
Adding events to static pages. WordPress goes through its whole process for each and every page it serves, meaning there’s a centralized point (the code on the server) from which to execute events. It doesn’t matter where the user first lands—every page does this. With Jamstack, on the other hand, the user could request any page, so every page will need to know whether and how to fire events (or report back to some process that fires them).
Generation time and runtime. WordPress is a simple process, dynamically building the page from header to footer, calling things along the way. Jamstack, on the other hand, has generation time in addition to client runtime, which of course is running on the edge in a browser. So there needs to be mechanisms for extensions that allow functions that do their work as pages are being generated (changing the text content of certain kinds of pages, for instance, with these changed pages thereafter being static) and functions that are shipped out to the client side, to be invoked at the appropriate moment, for instance, changing the content of a page as a React component switches in new content.
Common variables and functions. This is probably the least of the issues, but it will enable extensions to do more work if there is a common environment in which extensions run (particularly on the client side). A WordPress developer has a huge list of functions and globally retrievable variables that describe the current state of the platform, who the current user is, what the URL of the current page is, what the URL of the folder that holds the templates is, what day it is, and so on. If all this sort of stuff is predefined, everybody knows what’s going on. Otherwise, everyone gets to reinvent the wheel for each outing.
Getting back to my example of adding support for pop-up footnotes, the extension version of this would perhaps use a simple character sequence to denote footnotes in normal running content text, maybe something like [fn]comment that makes up the footnote[/fn].
When the content is being rendered at the client, assuming we’re in a Gatsby-like environment where React is going to load in the content for the component on the fly, the content would be retrieved but, just before it was displayed, an event would fire and a callback would be made to the footnote extension.
The Callback Process
In WordPress, the content that goes in the middle of the page is accessible through a function call to, catchily enough, get_the_content(). Let’s assume there’s something similar available to the extension, that the content is scanned for the [fn] marker, and that some spiffy extra stuff is injected.
Now, when the text is rendered onscreen, it includes a numbered footnote that pops up a note when hovered or clicked.
Whoever developed this hypothetical site was not involved in making this happen. One of the site’s content developers (with appropriate administrative clearance) decided it would be great to have footnotes, found a footnote extension that had the right look and feel, installed the extension, and then added the markup to the content.
The Upside of Aggressive Borrowing
I don’t pretend to have worked out all the answers here, but none of the issues I’ve mentioned seems insurmountable.
And there could be some real upsides to having a bunch of capabilities ready to plug in and go, just by checking the activate box.
Menus, for example. WordPress menu configuration is something that could be handled by an interface on the generation side. In WordPress, I can write my own menu code if I want to, but if not, I can configure all sorts of things, beginning with the location on the page where the menu appears (and whether it’s sticky, and so on). All that stuff just happens. Building this as an extension in a Jamstack environment would mean faster deployments and more options for who changes the menus and when.
Other examples: language localization, widgets that display links to related content, vast functionality additions like WooCommerce (a widely used plugin that provides a full range of ecommerce site capabilities), and so on.
On the one hand, Jamstack seems to be slowly reabsorbing dynamic capabilities because, whaddya know, those dynamic things were nice to have. On the other hand, the flip toward static first, backend decoupled seems like the best approach now that there’s enough tools to make this more sophisticated architecture readily available. It’s an opportunity to borrow from time-tested approaches such as those that were gradually built into WordPress over the years. We should be able to benefit from the experience and rebuild these things cleaner and faster than ever.
All on my very own I started thinking that a genuinely new angle on book publishing might be offering crypto coins related to the book. Or possibly the author. It turns out these things already exist and they are called creator coins.
As usual, the internet was a bit ahead of me on this (though not by as much as it usually is). It’s 2021 and the ‘creator coin has arrived. Let’s talk about what the people who are using it are cooking up for themselves.
Like Doge, But Not Really
All of this starts with blockchain, but that’s not actually something we have to talk about in detail here. Suffice it to say, with blockchain, you have a foundation for creating digital money that can’t be forged and that maintains a ledger of transactions that can’t be tampered with. The proto-crypto currency, the wild one with the crazy fluctuations and concerning level of electrical power consumption, is Bitcoin.Creator coins live on a different blockchain, the grown-up one (sort of): Ethereum.
The currency that’s native to Ethereum is called ether, but creator coins don’t use ether. They are different coins that also use the Ethereum blockchain.When people are waving their hands around, what they say about creator coins is that they let you “participate in the economy of these artists.”
Those are words from Bremner Morris, who actually probably wasn’t just waving his hands around. He’s community-appointed CMO and CRO for Rally, which is a big fish in the still-small pond of creator coins, as well as a former Patreon executive.
Rally
Let’s look at Rally: it’s an infrastructure that can mint ERC-20 tokens, thereby essentially drumming up new “alt-coins” at will. Dogecoin is the alt-coin people talk about, mostly in a sort of disbelief that there’s such a thing as joke-but-real money. But Rally envisions spinning up lots and lots and lots of alt-coins, one per creator/entrepreneur. Because Rally is an Ethereum sidechain, the coins are actually tied back to a currency system that in turn ties back to what most of us still (archaic fiat-currency boomers that we are) think of as real money.
No, Seriously
If you’re not in the crypto world yourself and/or haven’t been observing the absolute webmadness of non-fungible tokens (NFTs), you may be wondering if I’m even being serious here.
So let’s be clear: people (that is, creators) are actually doing this. Rally itself is only setting up new coins by invitation at this point and there are only a couple hundred creators at this point. But the top several coins have capitalizations that are fast approaching a half-million dollars. And by dollars, I mean actual, fiat-currency dollars.
What does capitalization mean in this context? When people use $RLY coins (which are the coins that provide cross compatibility among all the different alt-coins Rally creates) and buy a specific creator coin, they pay for them, paying whatever the current market rate for that specific coin is. As I write this, for instance, the most expensive coin costs $41.58 per coin while a $HUEVO coin costs 9 cents.
When you buy a particular coin, you own the coin, plus you may also “get” benefits associated with owning specific amounts of the coin (in terms of current value or actual number of coins). For instance, you might get access to a video chat with the coin issuer if you own, say, at least 10 coins.
Now, anybody who plays in this space hardly gets through their first sentence before they tell you that creator coins are not investment securities.
I think Rally is out in front on this and I think they’re on to something. If you can move coins, you can become a sort of web influencer on steroids, plus direct money.
There’s a lot more to it than what I’ve covered so far, but I wanted to get to this particular point: Cryptocurrency gives you as a writer or artist or consultant or public intellectual or whatever else, gives you the ability to create a “currency of audience.” You may be selling tshirts with it, just like the old days, but the odds are you’ll be creating far more complex ways to provide products, services, and community access, and you’ll be able to control and influence the way it works in your specific situation.
There are lots of static site generators (SSGs) out there these days, coupled to a lot of different headless content management systems (CMSs), using various development frameworks, running with various templating languages, and making life seem a lot more complicated than it probably needs to be. But you may still be scratching your head and asking, what is a static site generator?
With that in mind, this article aims to explain in a more general way what’s going on in a typical SSG these days. Because even though there are a lot of different names flying about, there are some key general elements and processes that are common pretty much across the board.
What Is a Static Site Generator?
Let’s start at the beginning: a static site generator (SSG) takes some “source” files that describe a website and, processing those files, creates the files needed for the website that was described.
I think of it as basically a compiler. You have some source code, the compiler runs, and out comes a binary executable that you can run on your computer. I realize that, in the current web world, developers work largely with interpreted languages, not compiled ones, but bear with me.
The SSG, in other words, is an application that reads some files, processes their contents, and then writes some new files, with the new files constituting a web site. This process is the heart of the matter, the place where the magic happens, and so on.
The Website
The SSG creates a website and that website is a website that you could (sort of) say has no moving parts. This is why people talk about “static” sites.
Now, the simplest website is one that is made up entirely of a single HTML file. This is nothing more than a text file with some special “markup” tags and it is very fast and very simple for a web server to send off to a browser that has requested the page across the internet.
All the web server has to do is grab that one file, stick some delivery headers on it, and send it on its way. This can happen with almost instantaneous speed if the internet connections involved are fast ones.
This speed is one of the key benefits of static sites, even though they aren’t as simple as a single HTML file. Generally speaking, though, they are nothing more than HTML files, CSS (style) sheets, possibly the occasional javascript file, and whatever images are displayed on the site. They are all 100% ready to deliver whenever they are requested, with no additional processing needed.
Why the Build?
The reason the world needs SSGs is because there are generally lots of pages of content that need to go into a website. We don’t really want to have to create HTML versions of all the content—and there’s a pretty simple reason why this is.
I’m old enough to have coded a couple early commercial sites on the web. Every page on those sites was individually created in HTML. If there was a menu at the top of the page, it was there it was copied from some other page and pasted there. If you wanted the currently selected menu item to be highlighted, you had to make a version of the menu with the selected element set in reverse text (or whatever the treatment was) that was specific to the page you were working on.
A site with a hundred copies of the same header, except for which selections are highlighted, is a mistake waiting to be copied and pasted. There are typically lots of repeated elements on web content pages (footers, anyone? Sidebars?), and hand management is a fool’s errand.
The world could have moved to SSGs then and there, twenty years ago, but what happened instead was that web servers became integrated with databases. In this scenario, the server would assemble the elements of each requested page as it was requested. The header would be connected to the newly fetched main page content, then the footer retrieved and tacked on, then the final page shipped off to the user.
This is still how most web sites work and such web sites are said to be dynamic.
An SSG does the same assembly that a dynamic web server might do, but it does it before the website is served to users—it does the page creation in advance.
Thus…
So, an SSG needs to get the headers, get the sidebars, get the footers. It needs to get the main bits of content for each page, along with the titles and subtitles, anything that needs to be on each page.
So there’s the actual generator, the SSG, and there’s some kind of store for page content, and there’s some way of describing what each kind of generic page will look like in HTML.
In a simple example, there’s the SSG called Eleventy. It takes page content (in the simplest setup) in more-or-less plain text files called “Markdown files.” It arranges the content from those files with guidance from a templating system called Nunjucks. A diagram might look like this:
In the case of Gatsby, the SSG is Gatsby, the simplest data source is the same markdown that Eleventy uses, and the templating is handled by functionality that comes with the React JavaScript framework. Same diagram, different labels.
Jekyll is yet another SSG, in this case written in Ruby. Again, the simple way to feed content data to it is once again Markdown, and the templates for how the content fits on the final HTML pages is a system called Liquid.
If you take a look at the ridiculously long list of SSGs maintained by Netlify at https://jamstack.org/generators/, you’ll see that each listing mentions the language the SSG uses and which template systems it supports. Looping back to Eleventy for a second, it actually supports several other templating languages beyond Nunjucks: Liquid, Handlebars, Mustache, EJS, Haml, Pug, and JavaScript template literals.
Beyond Markdown
If you want to capture the content of a blog entry, Markdown is a nice, clean way to do it. SSGs tend to support it as the entry-point content data source. It was sufficiently prevalent in the early days of SSGs that when Netlify was looking for some kind of term to encapsulate all the different approaches to SSGs being created and coined the term “jamstack,” the M stood for Markdown. (The J stood for JavaScript and the A stood for APIs. A person could argue pretty convincingly that none of these three selections were accurate, but it did at least spell something recognizable with “Jam.”)
There are lots of other options beyond Markdown, including using the same sorts of databases that dynamic web sites use. This isn’t the article to dive into all those options.
There’s also more involved than just plain-old HTML. There need to be CSS files, frequently there need to be JavaScript libraries to handle user interface elements that click and move and so on within the client browser window, and the SSGs that use the React framework play some pretty fancy tricks with swapping components in and out on the fly at the client browser.
But the basic setup is that the SSG is an application that takes content data from sources like markdown files or headless CMS services (such as Contently and Sanity and Ghost and lots of others), uses templates to create the layout of the output pages, and when it’s all said and done, creates a static site.
Of course, there are some other bits that you may be curious about beyond this simplest reduction of what makes an SSG what it is. For one thing, you may be wondering about the API part of the original JAMstack term (these days, Jamstack is used predominantly as a term that doesn’t specifically stand for anything, but instead refers to the entire ecosystem). That’s coming up shortly.
In WordPress, you can get lots of potential looks and (to some extent) behaviors just by installing a “WordPress Theme” and activating it within the admin panel of your WordPress instance. This site, PeakZebra, for instance, is running the Extra theme, made by ElegantThemes. It’s based on their Divi page-builder franchise, with page builders being a discussion for another day. There are endless WordPress themes, but there are not really static site generator themes–not in the same sense.
I’m running Extra on this site, but I could just as well have run Hestia or TwentyTwenty or GrilledFish as the theme for this site (OK, actually, I made up GrilledFish… But then I looked just to make sure there wasn’t one, and of course there was). There are, at least in theory, some 30,000+ themes (you’ll see much higher estimates, but this number comes from Scepter, which made a noble effort to weed out unmaintained and unused themes).
This is a smart setup. It makes it easy to go from something that has a bunch of “cards” on the front page to something that has more “flowing” dynamics. If you are a dentist and you want a site that “looks like a dentist site” (I have only a vague idea of what that look might be), you are quite certain to find a theme that has calm, serious fonts, a “safe-feeling” color scheme, and so on.
Themes Play By The Rules
This only works because the things that themes can change are (mostly) completely pre-defined. You’d think that’d make all WordPress sites look vaguely the same, but in fact there are lots of things that it’s completely kosher to change, so the range of possible designs is enormous.
In a slightly confusing (but practical) move, WordPress allows themes to use a “functions.php” file, which can contain absolutely whatever functions a theme designer wants to build in. Anything you can do in a plugin, you could at least in theory accomplish by leveraging the functions.php option.
One of the more confusing things to wrap one’s head around in the WordPress ecosystem is that—even as WordPress creator Matt Mullenweg keeps pushing the notion that open-source software is the best way to make software, and even though everything that swims in the WordPress ocean has to honor WordPress’s free software licensing, there’s a huge trade in “premium” themes, for which you’ll chunk out, typically, $50 to $75 for use on one web site.
Premium or not, each WordPress theme consists of a subdirectory in the “themes” folder, a “style.css” file, and a “functions.php” file. Generally, there are also a number of “template files” and a bunch of other optional stuff as well. The TwentyTwentyone theme (which comes as part of the base WordPress install these days) has a directory listing that looks like this:
If you download a theme, all these files come bundled up in a zip file that WordPress expands into a folder with the same name as the theme.
Meanwhile, In the SSG World…
If you’ve used React, particularly in the context of a static site framework like Gatsby for Next.js, you’ve dealt with components that render pages or parts of pages. That’s exactly what’s going on here, just in PHP rather than JavaScript.
It’s different, though, in this respect: You can’t download a new Gatsby theme and just turn it on (Gatsby has a “themes” concept, but it’s more for supporting particularly functionalities—like a blog that uses Contentful as its headless CMS). If you were going to do this with Gatsby, then you’d need to be using a common, agreed-upon manifestation of Gatsby that understands, for starters, that there might be more than one theme installed at this site, that themes are in a specific folder, that the active theme is, say, named in the Gatsby config file, that elements used in page and partial templates are named using conventions that theme designers can rely on and use, and so on.
The setup here would be different in another way: the style components would be incorporated when the site was rebuilt, not at run time. But that doesn’t really change anything.
What this presumes is a general-purpose set of rules for, say, Gatsby sites that are essentially blog sites (to take one obvious example) about what CSS files are in play and how blog listing versus single-entry page scenarios are built.
Particularly given that WordPress provides a model to work from (and one can imagine an improvement or two), this is doable. I even wonder if it could be sorted out in such a way that this sort of theming might work on more than one static site generator framework. This is one thing that I’m looking at as a PeakZebra project and I’ll keep you posted. If you’re laboring in the same fields, please be in touch.
Gatsby (the company) held a “summer camp” online earlier today and used the occasion to push the new “functions” capability into general availability. Functions is interesting in and of itself, but equally interesting was the way that Gatsby, and product director Dustin Schau (@SchauDustin ) in particular, were talking about what the rollout meant for Gatsby (the framework).
Pointing out that “rich web experiences are now the norm, not the outlier,” Schau went on to say that this “relies upon dynamic functionality.”
Whoa, that’s dynamic…
This marked a change in tone from the usual “make some API calls if you really must have dynamic functions” train of thought in the larger static web site community. Schau went on to say that there’s a spectrum ranging from all dynamic to all static and Gatsby is “shifting left” toward more built-in dynamic support.
The trick to all this is, no surprise, the support for functions. I haven’t dug in and tried to do things with functions yet, but there’s definitely a nice clarity and neatness to the basic idea, which is that if you write and export a function in a file that you’re storing in the “api” subdirectory you’ve created in your “src” directory, this function will be run at the network edge at runtime. So, to take a minimal example, if you create a function that returns the current time, it will execute when the user is looking at the page that renders it, will run right then and there, and will display the actual current time in the browser.
You don’t need a function to get the current time displayed, but stop for a moment to think about how clean the basic setup is.
In one of these functions, you have to take care of two variables that are passed in, the first being Node’s request object and the second being Node’s reply object. This, roughly speaking, means you can easily act like you’re dealing with a POST or GET request and spit your results back out as a reply. You can also redirect fin the reply object, which is a clean way to chain together different functions.
Developing with Gatsby Functions
You can test sites with functions in your local environment—it works with versions of Gatsby from 3.7 up (which is roughly as of the very latest available version, at least as this is being written). If you deploy using Gatsby Cloud, yup, it just works. Netlify (which has its own function capability that’s not Gatsby specific) has also added support for Gatsby functions, so that works too.
This really is a different animal than what we typically might call an SSG. At the same time, it’s not the same thing as just throwing up a server on the back end to handle the dynamic stuff. Pushing the dynamic functions out to a serverless edge compute scenario gives you inherently faster performance for dynamic features, gives you the same inherent “magic” scalability that you get by running static sites on CDN’s, and for me at least, it raises some questions about how data is synchronized across, say, an enterprise application.
To put it another way, I don’t yet entirely understand where the data comes from, though presumably its accessible using the exact same mechanisms you’d normally think of within React. But… from where? I’m sure it differs by application and whether you have any margin for slightly stale data.
More to explore in this regard, and I’ll follow up when I know more.
Gatsby says recordings of the presentations (there was more than just the function announcement, including a nice demonstration of putting together a few functions who’s patterns you’re likely to encounter in typical applications) will be up in a few days. The demos are worth checking out. I’ll update with a link when they’re up.
The world needed a term for the things that we think of now as “Jamstack,” so I’m not a bit sorry that Netlify cooked it up. But even as it was coined, what was actually out there didn’t fit the term. Some of the front-running static site generators didn’t use JavaScript. Markdown was still perfectly feasible, but commercial projects were on a fast track to headless CMS.
Jamstack is at least a little catchy and fun. But it doesn’t really capture what’s important about the underlying architectural shift. Neither does “Static Site Generator,” and it suffers from the additional downside of sounding like a description of something bad.
And even if last year was, as Brian Rinaldi suggests, the year that Jamstack went mainstream, most people in the tech world really haven’t sorted it out or thought about it as something they might use. This is changing, but I think the change would be faster and cleaner if we had some sort of overarching term that did some positive work for us. Think of the usefulness that terms like “Web 2.0,” “mobile first,” and “cloud native” have had.
With this in mind, I have searched for the perfect term.
Searched, and come up a bit short. I do, though, have some directions. My hope is that someone will pick up one of these directions and hit on exactly the right term.
Edge. One salient piece of the architectural equation is that static sites are best deployed to a CDN, so that lots of copies of the pages live at the edge of the network. “Edge” sounds considerably more useful than “static.”
Fast. Even if we think we’re stuck with “static,” maybe it could be “Fast Static”?
Client stack. Or maybe “client-native architecture”? Something that reflects how much heavy lifting is carried out within the browser.
Distributed. Or some sort of name that gets at the idea of serverless and edge-function?
Dymaxion. Buckminster Fuller used the term for all sorts of things. Sure, it sounds (and is) straight out of the first half of the last century, but isn’t that really just a tinge of retro cool. Or, heck, “staxion”?
Rendering. Something like “atomic rendering” or “forward rendering”?
Martian. Or some other word that sounds kind of cool, but has no particular technical connotations. Think “Java” and “Struts” and “Ruby” and so on.
If anything springs into your head, why not throw it out on the twitters with a #renameJam tag? Whether or not anything in my list leads to a new name, we really could use a better name. And one way or the other, I’ll bet we’re using a different collective term by 2022.
I got a chance to look at another one of the major headless CMS (hCMS—the ‘h’ is decapitated) contenders, namely ContentStack. In a world where it’s hard to tell one hCMS from another, a couple of ContentStack’s differentiators are what it calls ‘modular blocks,’ an intuitive setup for managing multi-language environments, and ‘environments’ that allow you to keep development, testing, staging and production sites (or whatever arrangement you prefer) cleanly side by side.
It’s probably also fair to say that ContentStack is the hCMS that most squarely positions itself as a primarily enterprise solution, something that’s reflected in its pricing model. There’s no free tier to rope in the dev community (there’s a free trial, but only for two weeks). The “Start” plan is $995 per month; the “Grow” plan is a stiff $4500 per month. If you want to run more than one site on an account, you’ll need the “Scale” plan, which, um, costs more. Other gating factors among the plans are limits on API calls, the number of content types you use, and how many entries and assets you manage within the service.
All plans involve the modular blocks support, which some of ContentStack’s rivals don’t have, but which is analogous to the Gutenberg editor that WordPress introduced in their 2018 5.0 release. In both arrangements, a web page is conceived of as a stack of blocks from the top of the page to the bottom, with options for some blocks to be set side by side, giving you the ability to create columns within your pages. You can drag the blocks to where you want them on the page, or click on them to edit their content and configuration options.
The content type editor at ContentStack.
The left column shows you the types of blocks you might add to a content type; the right column shows you the properties of the currently selected block.
This is fairly similar to popular block-oriented editors in the WordPress environment, such as Elementor and Divi. Here, for instance, is a “template view” of a page in Divi (when editing in Divi, the default WordPress editor is overridden).
Divi calls this “wireframe mode”
Note that you don’t really get any sense of what the blog entry or the WordPress page is going to look like when you use a “block grid” view like these. In the headless CMS world, this is solved by having a staging site where you can generate the updated site and view it by way of the resulting pages. In a Divi or Elementor scenario, the editor can be toggled into a WYSIWYG mode that is possible precisely because the editor is constrained to what’s possible to produce within WordPress. You get, not surprisingly, a far clearer sense of what your work is going to look like on the actual site. Here, for instance, is the page shown in a block grid above when viewed in Divi’s more commonly used mode.
In this mode, you can edit text directly, as it will appear in the published page. Other things require you to click on the options and edit in a modal view.
One thing that has to be admitted is that putting this sort of editor on top of the WordPress framework, which is already arguably a little jumbled from years of adding bits and pieces, creates an editing environment that has mysterious moments of sluggish response, lots of quirks, and more than its fair share of bugs. It is almost certainly easier to create a clean, reliable headless CMS (even one that mimics some of the look and functionality of traditional WordPress, as some hCMS’s do) than it is to perch one atop the venerable WP platform.
It’s possible, within ContentStack, to create new block types, including ones that call out to third-party services. At the recent GatsbyConf 2021, a brief demo of personalization vendor Uniform’s integration with ContentStack showed that it was easy to embed Uniform blocks that would either make notes about a user’s behavior on a site (remembering which entries in a blog they’d looked at, for instance), or alternately display content with different versions chosen according to the notes previously made. The ability to perform this sort of integration without writing it in custom code on the static generator side of the equation could well prove interesting to potential ContentStack customers as these sorts of integrations proliferate. As for Uniform itself, we’ll tackle that on another day.
In summary, here are key characteristics of ContentStack:
Leans toward enterprise IT scenarios
Allows creation of large numbers of different content types
Has good support for multi-lingual and multi-channel scenarios
Built in “environments” allow easy separation of development, staging, and production versions, along with ability to track all the elements that made up a given release (tagged by you at release time) and with granular support for rollbacks.
Builds content types on a “modular block” model, which can be a powerful enabler for content creation teams
The online virtual GatsbyConf, which kicked off today, announced at least six significant updates, including a 3.0 release of Gatsby itself; a new component that goes beyond the already savvy Gatsby-sharp handling images used within Gatsby sites; and the addition of a CDN service (in partnership with Fastly) to the Gatsby Cloud service. Additionally, there were new, substantially changed releases of key plugins tying Gatsby to headless instances of WordPress, Shopify, and Contentful.
Patrick Sullivan, Senior Product Manager at Gatsby Core Team, noted that the past year has seen a 40% increase in the number of Gatsby sites on the web, but conceded that there were “a number of struggles with using Gatsby.” Toward addressing issues such as build times, especially as part of the local developer experience, Gatsby Senior Software Engineer Lennart Joergens walked through two significant updates being released as part of 3.0. First, local development warm rebuilds will use a “query on demand” capability so that only altered pages are regenerated.
Joergens showed a second change where the directory structure of content in a site can be mapped onto the source file directory tree. You might have a “products” directory, a “shirts” directory within it, and then the slug for each file will reflect a product name. This is the sort of organization good developers tend to lean toward in any case, but here the logic that’s encapsulated in the setup can be combined with the partial rebuild capability so that, as Joergens demonstrated, changing the name of a shirt product causes several pages to rebuild (because there are links on other shirt pages to this product along the lines of “you might also like”), but changing the description on the shirt page causes that page only to rebuild, because that’s the only place where that text is rendered.
Video of the event will be posted on YouTube, but aren’t up yet (we’ll update to link to them when they are)
The Chasm
More than one speaker in the conference lineup—and this includes Product VP Dustin Schau —talked about website creation as a function of two presumably rather different groups: marketers (for the words on the pages in the site), and developers and designers (for the site itself).
Nick Gernert, CEO of WordPress VIP (the high end consulting and hosting arm of Automattic), took the position that the JAMstack world has been too focused on tools to grease the skids for developers (and enhancing performance), but would need to shift the priority to enabling creators (that is, the marketers). He proposed a website version of Maslow’s Hierarchy of Needs, where the base of the pyramid is Security and Scalability, and the peak is the “meaningful content experience.” Just below the peak? Agility.
Seize (and Discard) the Moment (Library)
One final takeaway: more than once in presentations during the day, the moment.js library was called out as something that, when used, causes an outsize bump in the size of your JavaScript bundles. You’ve been warned.
A second day of the conference will offered several workshops, including a 101 course to get yourself started with Gatsby.
