The paradigm shift in website publishing

—— essay —— 8 mins

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.

The arrival of new tools is making the old tools painful. Web developers already understand this. And slowly, as a new breed of javascript-powered websites are using new techniques that result in no page loads, no server side rendering and pre-fetched assets—all of which result in signficantly better user interface performances—it's becoming obvious to audience and business alike that something is afoot.

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.

  • Javascript is everywhere. With the maturity of Node.js, developers haven't had to change languages between server-side (the backend) and client-side (the browser) environments for a while. That has allowed innovative new techniques to emerge and mature: code/data splitting, pre-loading, pre-caching, image optimisation and bucketloads of other enhancements—difficult or impossible to do with straight HTML, unheard of only a few years ago—are freely available in opensource frameworks.

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?

The JAMstack

JAMstack is an acronym (Javascript, APIs and Markup) that symbolises an approach to building websites where each part of your website publishing system—interface building, content and services management, and hosting—is treated as a separate concern. These concerns are then integrated together within a web development workflow so that you can create your own customised "technology stack". Because each concern is isolated, it allows free choice of the best tool available for that concern within the context of your business requirements.

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.

Building the front-end with Javascript

Beginning in 2013 with Facebook's React.js and Vue.js 9 months later, Reactive Javascript libraries have proven to be a faster, more performant and highly flexible method for building your user interface (UI). More than just handling templating, they efficiently manage interface "state"—how the UI reacts to interactions—to make code more predictable and easier to debug. They are now regarded as the go-to method for building performant interfaces, and you can easily hire programmers for them because of their dominance within the programming language market.

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 brand & value proposition sites, web search won.

  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.