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.
I suspect that being a WordPress developer isn’t especially fashionable these days. You’re not a rat fink or a fool if you’re a WP developer, but you’re not the it kid. At least not in the developer crowd. WordPress has just been around too long to be the thing.
That said, developing software in the WordPress ecosystem can be just as interesting as being that on-the-edge dev who codes React components that interact on the fly with distributed network microservices. (In fact, these days you can be that guy coding in React right within WP, though it’s too early to say if that’s a good thing or not).
Toward the end of this piece, I’m going to provide links to resources that a person would need to have under their belt to enter confidently into WordPress development. How to become a WordPress dev? Learn the things on the far end of the links I’ve put into that list.
The Age-and-Complexity Factor
Today’s WordPress is the result of a gazillion revisions, and even the first pass of the code, almost twenty years ago, was a fork of an existing blog-creation utility. Lots of rethinking, lots of code changes. It’s complex as a result. People say it’s easy to use but I’m not really so sure about that.
You can switch back and forth among thousands of pre-created looks and feels (that is, themes), so it’s powerful in that respect, but it’s also true that this works because the underlying presumption remains that we are dealing with something that is or is very like a blog. We’re just switching the colors around on a page that reliably has a bunch of stock components (the text, the header, the footer, a search bar, etc).
You can’t pick a random website out there and tell immediately whether it’s running on a WordPress installation. But then again, If you looked at the last thousand new WordPress launches, you’d find a high percentage of sites that had a recognizable “WordPress” look.
The look is a header with a horizontal menu, a hero image, a title, text paragraphs, and a sidebar down the right rail. Like this:
What used to be a Drupal site is a WordPress site these days.
So, big hero image. There’s also a very characteristic WordPress effect that zooms out the photo as the page is loaded. (It’s a CSS effect, really, nothing to do with WordPress from a technical view, but way overused in pre-developed themes and page builders for WP.
What’s below the image, further down that same page? This:
It looks pretty good.
Click on a story link and you get a header, a text section, and, well actually, the text pages on the site are considerably simpler and cleaner than one is used to seeing. So, this:
Clean.
Rather than something like this:
I don’t love the design, but I’d never disrespect the Pergola Garden.
I should emphasize that I’m not knocking Martha’s basic format (can I be honest, though? I can’t believe Martha’s site isn’t better looking than this). When it’s the right approach, center content and sidebars is the way to go. And you can design horrible versions of this or fantastic ones.
But while I think a perceived frumpiness may being weighing on WordPress (use of WordPress from increasing every year, notwithstanding), design isn’t really the direct purview of the WP developer, and it’s the developer aspect that I want to turn to.
The Language Problem
When the internet decided that browsers should be capable of doing more things than displaying text, the language used for adding some programming to web pages was JavaScript, so PHP found no role in client-side, front-end programming. PHP runs on servers. PHP makes you put a frigging dollar sign in front of all your variable names. (Actually, these days, there are usages where you wind up with dollar signs in JavaScript, too. And what’s wrong with dollar signs, anyway?)
[et_bloom_inline optin_id=”optin_2″]
WordPress Developers: Three Different Kinds
WordPress developers, as opposed to theme designers, fall into what I think of as three categories.
The first is people writing the code for WordPress itself. Anyone can throw their hat into this ring, because WordPress is an open-source project. But when I talk about WP developers in this article, I’m not really talking about WordPress Core developers.
The second sort of WordPress developer is someone who knows their way around WordPress, knows how web style sheets work, knows good themes from junk themes, has experience with the most widely used plugins that extend WordPress’s capabilities, and knows how to take all these things and craft a solution. This is someone who probably does some coding, can write a plugin in PHP in order to smooth over a bump in the works, and who can absolutely help you avoid those early mistakes that take a lot of time to correct later.
There’s a huge ecosystem out there for this sort of WordPress developer, and rightfully so. For all its surface calm and order, the internal workings of WordPress are the result of years of tweaking and extension while trying to maintain backward compatibility. There’s a whole universe of craziness and detail lurking there. People who really understand how the parts fit together and can control things without blowing your site up are people who provide extremely valuable services.
My heart’s with the third group, though. These are the folks who write more complex plugins. They write shopping cart plugins, newsletter plugins, calendar management plugins, and so on. Historically, they have done their programming in PHP. That’s shifting, but most WP custom coding still happens in PHP.
I started my coding with the C programming language. As I’ve mentioned elsewhere, many languages out there look a whole hell of a lot like C, or its C++ descendant. PHP, for instance, looks like C, just with annoying dollar signs pasted in front of variable names (and a few dozen other annoying changes that I think were thrown in spitefully). JavaScript is C thrown into browsers, with a bunch of stuff stripped out for simplicity’s sake, then gradually added back in over the years.
C made it trivially easy to screw up memory management and mistake pointers to variables for the variables themselves. The later languages made it very hard to make these basic mistakes, so I’m not sorry to have moved on from C. But my point is that PHP is like C which is like JavaScript.
JavaScript is on trend
Now, JavaScript is undeniably trendy. It would have to be, because it’s what’s built into all the browsers in the world. People who didn’t want to code in PHP on the server anymore made a server-side setup for JavaScript, in the form of Node.js. And it’s pretty sweet, I’m not gonna lie.
Yeah, JavaScript is sweet. On the client side, all sorts of wildly capable libraries and frameworks have been created, of which the one that really grabs me is React. It grabs everybody who dips a toe into it. I’m restraining myself from taking a big detour to talk about why React is cool.
You know how you can tell JavaScript is absolutely the height of fashion just now? Because people using it are ready to look past all sorts of “extra step” things you have to put into the mix to really play ball with JavaScript. I’m talking about Babel, Webpack, and the way you can’t code for the front end without running Node.js (a backend piece) and its toolset. Oh, probably include React in that list, though React brings more benefit than extra learning curve.
React
I’m not the only person out there who thinks that React is the cat’s meow. WordPress used it to build their new Gutenberg editor system as well, and multiple facets of the future of WordPress are written in React.js.
Yeah, yeah, the server-side core is still written in PHP, but the move to JavaScript within the fortress walls was the death knell for PHP. Even WordPress has given up on it (sort of).
And you can take a step back and just maybe worry that WordPress itself looks less than brand new and exciting. I mean, you know that company Culture Trip? OK, it’s entirely possible that you don’t because I at least am not aware of them being a household word. But they did get funded to the tune of $80 million (on top of a $20 million Series A round).
In a Medium blog post about changing tech stacks, note the implicit world-weary sigh in the first sentence:
Culture Trip’s website used to be a WordPress site. Now it’s a flexible, universal (isomorphic) JavaScript App powered by Next.js, React, MobX and Styled-Components on the front-end that uses WordPress as a semi-headless CMS.
I mean, holy freaking cow! You want to waste your life in WordPress after you’ve read about what Culture Trip did? I mean, 2019 was probably not a great year to invest in a travel-related web business, what with the pandemic arriving and all, but this puppy is universal (isomorphic). You heard anyone describing their WordPress site that way lately?
Yes, do note that they are still running WP on the back end for this ass-kicking site of theirs. This time around, we’ll skip getting sidestepped on WP as a headless CMS, but it’s a huge, interesting topic.
But here’s my point (and yes, I do have one, though it’s taken me long enough to get to it): WordPress is a fascinating development environment, PHP is basically the same as JavaScript, so who cares if we’re writing PHP, and a tremendous amount of junk that you’d have to go off and find a library for if you were coding in JavaScript are already turned up and running in WordPress, so you only write the code that does something new and different.
If you wind up as a WP developer it will not have the adverse effect of stunting your growth, either as a developer or as a human being.
Coding within the WordPress universe can be pretty interesting. There’s a whole world in there, largely driven by callbacks to functions you’ve written (though, in fact, pretty much everything in WordPress itself is implemented as callback functions, so it’s not just you.
Each time a page is served up by WordPress, there’s a sequence of events that has roughly the complexity of whatever list NASA put together to launch a Saturn V rocket. At each point in the sequence, WordPress checks to see if a some process has registered a callback function for that point, then calls each function in turn (based on a priority ranking that you can manipulate to increase or lower the priority of your own functions).
You kind of have to stub your toes as you learn the quirks of this process, but it’s incredible how much nuanced control this enables you to have when creating a plugin.
To take an important instance of this up for a moment, there’s an action (those points in the sequence I mentioned above are referred to as actions and filters—they are slightly different from each other, but they each call back to a registered function that “hooks” the action or filter) that gives you a chance to create new post types.
Custom Post Types
Content posts are the primary elements of WordPress as a content management system. WordPress began life with the assumption that it was going to store blog entries, and that each blog entry would be several things (the title, the publication date, the text itself, and so on) stored together. But lots of other things (non-blogpost pages, to take the next post type that WordPress added, but also stored media, site navigation menus, and any behind-the-scenes prior revisions of posts) can be stored as “several things stored together.”
What makes WordPress more of an application framework than you might think is that you, as developer, can decide that you want other sorts of things to be stored this way, and thus you can create new Custom Post Types (CPTs). You might decide that your web site will have “sections” that you can treat as grouped into multisection publications, along the lines of an ebook.
In this example, “sections” will be more or less the same thing as regular old blog posts, but they’ll be grouped differently, can be sorted in some other way than the reverse chronological order that blogs generally use, and can have different layout and styling.
Or if you built a site for selling event tickets, you might have a CPT with entries for each event (event description, date, time, venue, and so on).
Layout and styling are in the “theme” category rather than the “plugin” category, but when you’re creating applications that organize themselves by using CPTs, the look and behavior of pages within this CPT becomes an important part of overall development. And, indeed, the template for a given type of page is, in fact, a PHP file. It’s a template, yes, with baseline text and HTML tags and so on, but in some situations a great deal of actual code winds up in those template files.
If you’re a hip cat and you’re working with Gatsby, you are doing largely the same thing when creating React components that will render portions of the various pages on your site. If you like doing it in Gatsby and React, there’s really no reason not to think you won’t like doing the same basic stuff in PHP files inside WordPress.
It’s real development, rewards your increasing understanding of WordPress internals in that ‘instant-gratification’ reward system that is such an addictive part of learning new things in programming, and lets you build surprisingly complex applications all by yourself, because you’re able to operate at a high level of abstraction in a system that has a huge range of capabilities.
A huge amount of the world’s online business is for small things and mid-sized audiences. People using highly tailored applications—things that run low-volume ecommerce sites or that manage architect offices or manage bids for roofing contractors—get more than enough performance from WordPress.
If you’ve got content that needs to slaughter PageSpeed scores, sure, maybe you need a statically generated site (like something done in Gatsby, as per the above). But in point of fact it’s entirely possible to generate static pages from plugins within WordPress (if you’re curious, here’s more about how I do this).
You can also get better performance from nothing fancier than a well-tuned cache for your static pages and elements.
Given the modest traffic and transaction rates that most custom-programmed WP sites get and the ability to make static versions of posts and pages, WP is mature, sure, but also still pretty limber. It’s still the popular choice for most business websites and, it’s going to be dominant for years.
There’s work to do, the programming tasks can be subtle, demanding, and rewarding.
What to Learn
As long as we’re here, we should talk about the skill set. It’s straightforward, but not necessarily easy to get everything into your head that you’ll need to be a successful developer in this environment.
First, you need to know your way around setting up and running a WordPress site. I think the best way to get started is to get a cheap web hosting account at a place that offers users the Cpanel interface for loading software on their account. Get into Cpanel and install WP. Figure out how to make a site that looks like Martha’s. Then figure out how to make one that looks even better.
You want to know how to create new posts, how to create “pages” that aren’t posts and how to manage access to these pages using menus. How to install and swap out WP themes. Then find some basic tweaks that you can handle with one of the tens of thousands of existing plugins out there.
Everything about everything in WP is described, sometimes quite cryptically, in the WP Codex. For elucidation in bite-sized pieces, there are sites like WPBeginner.com. There’s a good video tutorial from FreeCodeCamp.
Beyond baseline WP admin mechanics, you should know a reasonable amount about HTML and CSS. There’s really no way to work on the web without understanding these two fundamental pieces. HTML is no big deal (though make sure you’re clear on what the DOM is within a browser, along with the subtle ways in which it represents but isn’t the same thing as the HTML for a page). CSS can be a complex beast, alas. People tend to give it short shrift and then they live in fear of it for the rest of their coding careers.
A good resource for both HTML and CSS is W3Schools.com. PHP and JavaScript, too.
I haven’t taken it myself, but Josh W. Comeau is on the cusp of the general release of an online course that covers CSS soup to nuts. I’ve seen bits and pieces and they are interactive and engaging. He’s not giving it away, by any means, but it’s probably worth the ticket price.
The Actual Development Part
After that, you’ve got to know how to program. Server-side pieces like plugins continue to be written primarily in PHP. Client-side stuff is JavaScript. If you are comfortable in one you can get coding with the other in relatively short order (add or remove the dollar sign in front of variable names).
While PHP is the core of WordPress, if I were starting from scratch, I’d learn JavaScript first. You’ll find more resources, and generally better ones, than you’ll find for PHP. And though I’ll annoy some folks by saying this, you’ll find more of the resources pushing you toward a better grade of programming. PHP is capable of all the elegance and cutting-edge techniques you can throw at it, but it has a history of people writing (and sharing) fairly messy hacks. When you look for “how to do this or that” in WordPress, it will help if you can distinguish clean, well-coded examples from solutions that have edge-case bugs and are insecure.
As you learn to code, you should start looking at how themes and plugins are built in WordPress. Build minimal versions of each, then try tackling increasingly demanding tasks, especially on the plugin side of the equation.
Ultimately, you should figure out the workings of Gutenberg “blocks,” which are the emerging new paradigm for building things in WordPress. Since new blocks are coded and the whole block thing is still very much in process, there’s going to be a lot of work on this front over the next couple of years. See here for a quick introduction to the development side of Gutenberg. The tutorial at Delicious Brains is more hands on and has some good insights.
Are you thinking about jumping into WP development? If so, what are you hoping to do with it?
One thing I always wished I’d had in my last “real” job (as an editorial director) was a way to link from web content I was currently writing to content I knew we were creating in the near future. A future URL. Of course, I could have just written in the links, but they’d by definition have been broken, at least until the scheduled pieces actually went live.
TLDR: I wrote a WordPress plugin to do it, which, if it’s of any use to you, can be found on GitHub here.
Back at the old job, we were, in point of fact, required to find places to link to our new content from existing older content and there were people on the staff tasked with editing the older stuff and putting those links into the older posts. And going to this extra trouble absolutely made sense from an SEO standpoint (and still does, and is routinely ignored by content teams far and wide).
What I wanted was a way to embed the link, but not have it go live until a certain date. Now that I run my own shop, it occurred to me that there was no reason I couldn’t just build this for the current WordPress-based version of PeakZebra.com.
Now, part of the point of PeakZebra is to migrate from WordPress to a Jamstack site, something I’ve written about here and here, to take a couple of examples. So I didn’t want to create something that would break on a static site. As we’ll see in a moment, I can actually do a somewhat better job of this forward linking in a hybrid site that’s half statically generated and half dynamic WordPress.
Plugins and Filters
To handle the job in WordPress one wants a plugin. From my point of view, there was no reason not to write this in PHP, the core WordPress language. Architecturally, WordPress operates by executing a series of “actions” and “filters” as each page is dynamically created and served to requesting web browsers. The execution of each action and filter is hooked to various functions, and a developer writing a plugin gets most of the work done by hooking custom functions to the appropriate actions and filters.
As an aside, actions and filters are secretly the same thing, so basically all I’m saying here is that I can pick a moment in the page-creation cycle and tell WordPress I want it to call a custom function I’ve written at that particular moment.
In this “future url link” scenario, all I really want to do is grab the main bunch of content on the page (what we’d typically call the blog post), search for my special kind of date-sensitive link, and enable or disable it before letting WordPress continue to serve up the page.
The Future URL Format
I called the primary function for this processing “handle_future_urls” and then hooked what is arguably the most important of the WordPress filter hooks, namely “the_content”. Setting up the callback looks like this:
This statement is the first bit of code in my plugin and it executes as WordPress is getting ready to serve a page. Later in the process, when the page’s primary content has been called up from the database, WordPress will call my function handle_future_urls();
When that function gets called, it’s with one parameter, $content, a string that contains all the words that make up the center of the page. This can be lots and lots of words—it’s all the stuff on the middle of the page that isn’t the header, footer, or sidebar widgets.
You’re handed the content, you do whatever you want to it, and then you return the modified string of content from your function. In all honesty, it’s easy peasy and I think it makes it clear why WordPress has proven to be so extensible, versatile, and popular.
In this case, I decided I’d work with a format that put the future link not in the standard HTML a tag, but in a nonstandard tag that took this format:
[[http://example.com/theurl|September 1, 2021]]then some anchor text[[end]]
It’s probably pretty obvious how the future URL format works. If you put a link like that while you’ve got the futureURL plugin loaded and activated, you’ll either get a link in your copy or you won’t, depending on the date when it’s being viewed.
It’d be nice if the page updated to just an ordinary URL once the date had passed, just to save processing time. So… that’s coming along… And in case you were wondering, yes, there is a [[https://peakzebra.com/futurefixedurl|September 15, 2021]]future link[[end]] embedded in this paragraph, linking forward to the post I’ll write when I’ve made that update
Proponents of GraphQL interfaces are quick to point out that this approach allows you to easily use WordPress as a headless Content Management System (CMS) with a static site serving as your front end.
They’re not wrong. And as a developer, using the WPGraphQL interface is a lovely experience. With this approach, you create something like a Gatsbyjs site and the generator for that site sucks up all your blog entries and pages from the WordPress instance and spews out HTML pages, as all Static Site Generators do. All these blog pages display lightning fast and give you a blazing static WordPress site, but right out of the gate you’ve lost at least two functions from your old WordPress: comments and search.
In many cases—particularly pages that serve marketing goals—you don’t want the comment system turned on anyway. That said, there still may be situations (actual blog entries, possibly) where comments are a good idea. And while search is less important on, say, a landing page, in general it’s hard to see why you’d willingly give up support for search for a site as a whole.
The “standard” way to return comment, search, and other dynamic functionality to a static site is to use third-party services that offer APIs. So, maybe Algolia for search or Disqus for comments. There are upsides and downsides to this approach but I won’t belabor them in this piece.
WordPress Under, Static Over (WuSo?)
With all this in mind, I set out to create a site that’s static on the front end, but that understands when something is supposed to be dynamic and links back into the WordPress site in order to get the dynamic services WordPress normally handles. During the handling of the request (in real time for the user), a new static version of the page is updated to the static version of the site as needed (if, for instance, a new comment has been added—the static page will now show that new comment).
Initial Caveats
When I first started experimenting with this, I was impressed by how simple it seemed. If you have a static page and you leave the standard WordPress comment section on it, but simply change the link that the form sends its GET request to back to the original WordPress site, it’s almost frighteningly seamless (at least it is if the static page looks exactly like the WordPress page—more on this later).
It wasn’t actually quite as seamless as I initially thought. Or at least not as easy to make really work.
So, yeah: getting the new static page updated with a new comment requires sorting out a lot more details than you might initially expect. Additionally, while the update of the comment itself isn’t susceptible to race conditions caused by other comments arriving at the same time, some approaches to updating the static page open a small window of chance that one update will get temporarily overwritten by another one (the way I’m currently going about this, though, seems to avoid this problem).
One more important caveat: a significant security boost can be had by taking your WordPress site offline whenever you’re not updating the content. In this scenario, which is the one that current plugins like WP2Static and SimplyStatic provide, only the static site is available to would-be attackers, and it’s hard (though not entirely impossible) to successfully compromise a static site.
There are a couple of service providers—Strattic and HardyPress—that run your WordPress instance in a virtual container (I think they both use Docker containers) that is spun up only when administrators log in through the service’s front end. Otherwise, the dynamic WordPress site is spun down and simply isn’t there to attack. It’s ingenious, from a security point of view, and both vendors have added functionality to support search and comments. In other words, these guys already do the basics of what I set out to do, and fairly affordably too.
I have some further destinations in mind, though, about which more in subsequent posts. So I needed control of the underlying code and the ability to release plugins for some of the functionality.
WordPress Under
In an approach where dynamic components are being handled by a live WordPress site, that site obviously has to be up and running somewhere. Exactly where that is can vary, to be sure, and putting it somewhere hard for random scans run by hackers to find could theoretically lower your attack profile, but of course the rewritten links in your static code, pointing back to the WordPress instance, make it readily findable to anyone who understands even basic HTML. (Could this be made more bulletproof? Maybe. Possibly one has an edge handler of the sort that Netlify offers to static site creators and it serves as an intermediary between static user and WordPress instance… Something to think about.)
All that said, if you’ve been running your site on WordPress up to this point and been basically OK with your security posture, you’re no worse off for having that same site still running behind the static site. And you’re arguably a little better off, because attackers who are using scanners to look at your domain for signs that you are running WordPress may not find them, since your installation is running a bit behind the scenes and doesn’t have quite the directory tree that a WordPress-only site would have.
The Over/Under Setup
As I noted, you could put the WordPress installation pretty much anywhere, but to keep myself sane while running a bunch of these setups, I decided to have the static site running at the “top” of a domain (where you’d normally find your WordPress entry point, index.php) and then have the entire WordPress site moved to a subdirectory within that top level. I tend to think of this as having the WordPress site in a directory that’s “under” the static site. At first, I literally called this folder “under,” and inside of it you’d find the usual WordPress directories: wp-admin, wp-contents, and wp-includes. More recently, I’ve changed the “under” directory to names that are randomly generated, password-like strings, things like “df2CvIE9etuVJX4snt7N” so that automated hacking tools would be less likely to stumble into it (though, again, all the links from static to dynamic pages include this subdirectory name and someone expressly looking for it can readily find it).
Creating the Static Site
As I’ve already hinted at, there are a couple of easy ways to create a static version of your WordPress site if you don’t want to jump to a full-blown static site generator (SSG) like Gatsby or Next.js. These come in the form of WordPress plugins: SimplyStatic, WP2Static and Export WP Page to Static HTML/CSS.
I’m going to write in more detail about these in another article, but here are a few salient facts.
SimplyStatic doesn’t work on Windows platforms right now, which is a problem more for local development than for most production sites, which tend to be running on a Linux variant. It works very cleanly in my experience and you can point the output directly at the “over” root directory, which saves some extra fiddling.
It’s pretty fast at the task, even though it (as well as WP2Static) only does full builds (almost certainly a deal killer for really large sites).
It creates a new directory for each file it encounters as it spiders through your site. Inside that folder is an index.html and a subfolder with all the assets required to display the file.
If you’re looking to display a few pages, this is perfectly fine. For a whole site, you wind up with all sorts of duplicated files, all of which are also sitting in subfolders within the underlying WordPress site. So while I would generally give SimplyStatic high marks, the asset folder-palooza isn’t ideal for our purposes.
Having a separate folder for each page is the easiest way to have URLs match what you’ve got in your WordPress site, so it makes sense that plugins would go this route and, indeed, it’s what I currently do. This is another thing I’d like to look at further, however, when other more pressing bugs and issues are ironed out.
Then, there’s WP2Static, brainchild of Leon Stafford, who seems to just live and breathe the open-source approach. I don’t have a lot to say about it, because it does exactly what you think it does. It’s the incumbent option for this sort of plugin.
There’s also Export WP Page to Static HTML/CSS, by ReCorp, which has a free version that only lets you process a list of files, and there are limits on even this. If you buy a license, you can export as long a list as you like, plus you can instead export the whole site. I tried both versions and both work, even on Windows, but the pro version is licensed via Freemius, which I find a pretty unpalatable approach.
And there’s a new kid on the block that I just ran across and haven’t looked at yet, called WP2HTML. The static world is a busy place these days, I guess.
With any of these plugins, you have two problems left unaddressed. First, you have copies of all the image and other assets. This makes sense for their main use case (that is, making a static site that is fully independent of the WordPress site), but is total overkill for us, because we could just as easily bring in our assets from WordPress.
Second, neither approach saves you from the sometimes breathtaking bloat in CSS and JS files within WordPress themes. The static version will be static, but it will still load in all the junk it loaded in with your big, fancy Divi-based WordPress theme. It’s possible that your Google Pagespeed scores won’t improve a whit (though, for the most part, you’ll still see improvements, especially on your mobile scores).
It appears to me, from my preliminary soundings of the tangle of code that is Export WP Page to Static HTML/CSS, that it does make some effort to cull out unused CSS code, but honestly it looks like it doesn’t actually cull out much. This is reasonable insofar as it takes a fair bit of logic to figure out, site-wide, what can actually be cut. Nothing I’ve looked at so far looks at the site in toto—they work entirely on a page-by-page basis.
What one really wants is a plugin that doesn’t change URLs that don’t need to be changed. If you think about it, actually, most URLs could continue to point wherever they already pointed. In fact, they all could, with the exception of links to other static pages.
And all we really need for the static version of the site is the HTML pages. So what we want is sort of like what SimplyStatic and WP2Static spit out, but just HTML files. For each of the HTML files, the links that are “staying the same” actually need to be adjusted to point down to the “under” directory.
All right, I concede that what I just described in no way fixes the style and JavaScript file bloat issue. But there are ways to tackle this and I’ll talk about my approach in upcoming posts.
How to Get a Static Page
Both WP2Static and SimplyStatic do what you might expect in order to get all the pages in a site: they start at the index page, look through all the links on the page, determine which ones are in the same domain, then recursively look at the pages on the ends of each of those links.
Both of them then cleverly use Ajax requests to have the pages at URLs returned to them. It’s smart and I may well use the approach in a later iteration of this over/under thing. But for now I went a different way, an inherently incremental one.
The Output Buffer
PHP has this wonderful and weird couple of functions that access a built-in buffer construct. It’s exactly the sort of thing you might imagine would get created in a language designed almost exclusively to create web pages on the fly.
With the output buffer, you can turn it on before WordPress would normally have written anything, then capture everything that WordPress writes into the buffer. Before you let go of the captured page, you can make whatever substitutions you’d like.
This is where things get interesting. You’re going to return the “native WordPress” version of this file, except that all the links to HTML files within the domain are going to be rewritten to point up to the top level where the static site lives. But we’re also going to write a version of the file up to the static level, overwriting the one that’s already up there with a more current version, and in that version all the links that aren’t links to HTML pages will be pointed “down” into the “under” directory.
Search requests are handled differently, in that no permanent static page is created. Instead, the regular WordPress page is created, but all links to HTML pages on the site are rerouted up to the static version of the site.
It probably goes without saying, but every URL that contains “wp-admin” (that is, every page in the admin console) is left to run dynamically on the site.
Still Clumsy
It’s a pretty simple setup and, if you choose a “sane” theme for your WordPress site, it’ll be fast, and in fact your Pagespeed scores will probably improve on the static site. I’ve run against three popular free themes as I write this and they all come out blinding fast and kind of “just worked.”
Crazily enough, with this approach many of the plugins you might be using will still work (though of course plenty of them won’t). Plugins you use to add features like sliders—things that are inserted into the page as it is created—will still be inserted and will wind up in the static versions of the pages. If they rely on JavaScript functions to, say, make the slider work, they’ll include .JS files that will be included (with a rerouted URL) in the static version.
For the most part, things like form builder plugins still work. You build the forms within the admin console as always, then the forms are inserted into the pages as they are being dished out for conversion to static versions.
One regrettable thing that does get broken in an important way is user management. You can login through the back end, as per usual, and any pages you access on the dynamic WordPress site will work as always, but if you have front-end controls on what users or non-users can’t see, the static versions of these pages will be flummoxed. The best approach to fixing this is something I’m still looking into, but I suspect it boils down to writing static-page calls into the WordPress REST API.
The Current State of Play
I’ve got running code at this point, but there are lots of gotchas that require tweaks and rethinking of algorithms. But all the same I have a site running (well, most of the time) at PeakZebra.link (not .com, which is where you are right now). It gets blown away and reinstalled, functions added and deleted, and themes swapped out pretty frequently, so I’m by no means suggestion you run over and see what you think of it, because it’s entirely possible is that you’ll think it’s broken.
On the other hand, it wouldn’t surprise me if I got to a point fairly soon where it becomes usably stable. I’ll come back and revise this entry at that point.
The end game, I should mention, is to produce “better-than-native” static pages, by which I mean pages that look like the WordPress site they come from and that still have WordPress dynamic functions, but that have optimized those pages in various ways.
Readers of PeakZebra already know that I’m pretty impressed with the way Gatsby uses React such that React components can be swapped in and rerendered within static pages at run time, so it’s probably no surprise to learn that I either want to convert the output either to straight-up Gatsby source code or else output static files that use some of the same React tricks.
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.
