The paradigm shift in website publishing
Last weekend, as I chatted to the mechanic who was diagnosing why our car wouldn’t start, he said “I charged my pressurised tyre jack last night but forgot to put it back in the truck. So this morning I’ve already done two manual tyre changes. What normally takes me five minutes took 25 minutes.” The clincher was what he said next:
You don’t miss good tools until you have to use the old tools.
The web is a quarter century young and all the tools we use to make the web are mutating works in progress. We’re starting to see platform maturity this decade and with this, a second generation of tooling methods has also matured, driven eagerly by the platforms themselves, well honed in the battle for your eyeballs. Given this, it shouldn’t surprise you if I tell you there is a paradigm shift happening in modern web development.
Proprietary web publishing is being overrun
So for the past four years or so, this blog has been running on WordPress. It was as fast, as custom, and as free of plugins as I could possibly make it, but WordPress is cumbersome, and there’s only so fast and pleasant to use you can make it.
Tania Rascia, The End of an Era: Migrating from WordPress
I think we’re seeing a generational shift in web development between the proprietary bundled systems of the dominant web publishing platforms that emerged a decade or more ago as they struggle to modernise and compete against the fundamentally different approaches of modern web development, where a multiplicity of unbundled API services can be integrated together in a technology stack customised to publishing requirements. And the divide will grow because the proprietary systems must use their legacy tech stack for the backward compatibility of all their mid- to long-term subscribers.
Let me give you an example of how this is happening. Some of my clients have small- to medium-sized legacy websites on Wordpress. By legacy, I mean these websites have been alive for a number of years, I’ve inherited the project and it’s my job to maintain and extend it’s lifespan. Because they need a website.1
The problem I’ve seen lately is that these kinds of legacy websites are slow, graceless experiences and my clients and their audiences are starting to sense it. So they’re asking me to upgrade these experiences but a quick glance at the codebase tells me 1) it’s no wonder they’re slow and graceless, and 2) I know there’s a better way to do this.
And this better way starts with understanding three important facts:
APIs change everything. In the past, bundling features into a web publishing tool made sense. It wasn’t easy to integrate services with an external API because the technology wasn’t available. But now it is. So instead waiting for your publishing platform to become a swiss army knife, you can choose to integrate an API-based service who lives and dies by doing that one service better they ever will.
Microservices can afford to do a better job. In the past, your website publishing platform was probably what we now know as a CMS. Like Wordpress. This platform would handle not only the CMS but also the building of your user interfaces. Today the UI build doesn’t need to be tied to the publishing platform, and there are better tools for that job that will never be integrated back into the older publishing systems because backward-compatibility prevents it.
The new web publishing tools
We’re underinvested in developer tooling. Industry-wide, there are enormous efficiency gains still to be unlocked—tools today remain quite primitive.
Patrick Collison, Stripe CEO
If someone were to publish a new website today, so that it becomes a valuable asset tomorrow, what exactly are these better tools? And why?
In contrast to allowing a web publishing platform to determine the quality of your web publishing workflow based on their priorities and subsequent slow-moving feature set, the JAMstack method gives you the freedom to create a flexible, customised technology stack that exactly suits your needs.
Serving prebuilt markup
The most significant gains in website loading speed have been made by prebuilding entirely flat web pages (that is, a “statically generated site”) and serving them through a cached Content Delivery Network (CDN). By prebuilding the markup—that is, the scripts, styles and information within each web page—it does away with dynamically building pages on-the-fly with calls between a database and a remote server during delivery (otherwise known as “server-side” rendering), such as what happens with Wordpress.
This simpler delivery method is not insignificant. Serving prebuilt markup is not just easier to create fast page loads, it’s also far more secure, with a far lower cost of scaling, and it completely removes the need for a backend. Yep, that’s right: no backend operating systems, web servers, databases or different programming languages. Serverless cloud hosting is now a utility.
Publishing with automated webhooks
An ecosystem of deployment tools has also attached itself to your code repository, allowing easy, limitless publishing via Continuous Deployment (CD) methods. New builds—that is, a newly published website version—can be automatically triggered by webhooks based on scripts that are run when committing code to your website’s code repository.
By hooking these deployment systems into with “headless” or “decoupled” Content Management Systems (where your content is integrated into yoru website front-end via an API), a robust, error-free deployment pipeline can triggered by anyone, developer or not, with a click. No more accidently overwriting the wrong file on your FTP and scrambling for the backup you didn’t make.
Updating the shared beliefs of website publishing
When a paradigm shift occurs it’s rarely because the old methods don’t work or aren’t popular anymore. It just that the old guard can’t change their identity quickly enough to keep up with the opportunities the shift provides. They’ll want to keep playing to their prowess and strengths, but instead they accidently display their generational bias (a variation of the Shirky principle but for first-gen web developers, if you will).
Meanwhile, the new breed of crafted web experiences are being built with new tools made by a different generation of web developers who haven’t had to unlearn the previous generation’s best practises.2
As Patrick Collison noted above, the current paradigm of development tools will come to be seen as primitive in the near future. Which means the paradigm shift happening in web publishing tools will continue unabated, widening the gap between legacy web experiences and the new wave of crafted experiences.
Paradigms are the sources of systems. From them, from shared social agreements about the nature of reality, come system goals and information flows, feedbacks, stocks, flows and everything else about systems.
Donella Meadows, Places to Intervene in a System
Now is the right time to jump on the bandwagon, where you’ll get the optimism and efficiency of a new generation of tools which will help you create superior website interfaces that also easier and faster to manage, iterate on and scale. The new tools are better and they’re already here. They’re just not evenly understood yet.
1. Despite all the social media publishing platforms available, a website is still where a business can retain most control over the presentation of their core value proposition, and it's probably still the first thing a potential customer will click to from a search. Oh and forget native apps for business value props, web search well and truly beat them.
2. I’m not a born developer and I don’t have the baggage of having transferred out of a decade of PHP in the early 2010s. Instead, I was a graphic designer for well over a decade before I started learning to program. There was a lot I haven’t had to unlearn because I never learned it in the first place.