Wordpress vs. the future, Part I: the future is headless, and it’s coming for you…
At Boldium, we build websites for a wide variety of clients — some are large companies, with existing technological infrastructure, and some are companies or organizations that are just getting started, and do not yet have web infrastructure in place. We often get asked what sort of infrastructure — CMS, hosting, etc — we recommend. Sometimes, clients are surprised when the answer isn’t always ‘Wordpress’.
For many of our clients, they are already comfortable with Wordpress, or have existing content already living there. We’ve created tooling and methodology here at Boldium to make Wordpress development as manageable, flexible, reliable, and maintainable as we can — but this setup involves a few (very popular) plugins (Advanced Custom Fields and Timber), and a lot of customization. With Wordpress, being the monolithic platform it is, there’s lots to look out for.
Increasingly, we find ourselves being asked about — and recommending — other approaches. But what are the other approaches? When, how, and why are they useful? What’s the right choice for me?
I’m happy to answer all of those questions for you. But first, some history.
How we got to now — a brief history of how Wordpress took over the internet.
The future is here... it’s just not widely distributed yet
Wordpress was created in 2003 as a blogging platform. It looked like this:
The internet — and technology — has changed in a lot of ways since then. We now access content through more platforms and devices — and at a greater rate — than ever before. More people than ever are online, in some fashion, as companies and brands struggle to keep up in this content-driven, multi-channel world. And things that once used to be relatively simple and unregulated — like storing customer emails for an email list — have grown more complex and difficult with the advent of laws and regulations such as GDPR and California’s even-more-stringent CCPA (which goes into effect in 2020). Accessibility and ADA compliance for websites has gone from an undeservedly niche concern to a very real legal liability concern.
Traditional CMS platforms like WordPress were not built to create enterprise-grade omnichannel experiences.
The web has become wildly more complex — not just technologically, but socially, legally, and in every other way. And it will continue to do so, at an increasingly faster pace.
Throughout this period, Wordpress — leveraging its early popularity — has added more and more features, attempting to be all things to all people. Today, 49% of the top 1 million sites on the internet are powered by Wordpress. Wordpress — once a simple blogging platform — now powers everything from small blogs to large eCommerce websites. If you’ve ever had to use a CMS, you’re probably familiar with Wordpress.
Wordpress is no longer a blogging platform. In fact, it has been more than a blogging platform for a long time — It’s now a platform, period. Frontend, backend, plugin interface, admin interface — Wordpress collapses all of these into one ‘thing’. Since Wordpress owns so much legacy mindshare, and runs so many websites, this shapes many people’s perception of what the internet is: one big, centralized, monolithic box, an 18-in-1 Swiss Army Knife. Why wouldn’t you want more?
This centralization isn’t necessarily a good thing, however. The do-it-all-in-one-place approach of Wordpress can create all sorts of problems and complexities in terms of hosting, security, flexibility, and speed — and in a world where optimizing for all of these things is critical, Wordpress is quickly loosing its edge to other competitors, and showing its age.
The Problem of the Monolith
Wordpress’ core DNA — the platform and technologies it was built on — were the product of another time in web development. To enable all these cool features, at the time, seemed to require a PHP server, and require a relational MySQL database, and so on.
The web, though, moves at a lightning pace. So here we are, today — Developer interest and usage of PHP is declining, as it has been for the last several years (according to the TIOBE Index). Javascript is the name of the game — on both the frontend and the backend. Databases-as-services and the world of serverless services have atomized what was once a monolith-by-necessity.
We no longer require all of these things, in one place, to enable great features. In fact, it might be better not to centralize them, and instead distribute tasks (e.g. frontend UI, form submission/data storage, eCommerce, etc) to services that have specific expertise in handling them. We don’t need a big monolithic platform at the core of a web platform. We can be more modular and atomic with how we approach our functionalities and service needs.
This allows us to solve a few problems that Wordpress currently presents:
Security
Because Wordpress has been around so long, and powers so many sites, there is a whole cottage industry around hacking Wordpress sites. There are even bots out there that do nothing other than crawl the web for Wordpress sites and try a bunch of automated exploits on them, trying to break in.
It doesn’t help that Wordpress is a large, multi-pronged platform — a Wordpress server needs to also run/support a MySQL (database) server, PHP, and everything that comes with both of those things (more attack vectors, and more things to keep updated).
Furthermore, for every plugin you add, or line of custom PHP you write, you potentially increase that attack surface even more — our article on maintenance lays out some of the complexities there.
Resources
Wordpress combines the frontend, backend, and a bunch of stuff, all into one platform. This means it’s a big, heavy package that requires more server resources — more CPU power, more RAM. This means you pay more for hosting, because you need a beefier server. It also means your website uses more power.
Why should I care about how efficient my website is?
You might not think too much about how much power/resources your site consumes — but it has real impacts, both on the hosting bill you pay and on the environment. Currently, the internet accounts for about the same amount of the world’s emissions as air travel — the entire aviation industry. The less resources your server uses, the less power it uses. The less power it uses, the better it is for the environment 🌳.
You can get an estimate of how much carbon dioxide your website produces per page view at websitecarbon.com.
With Wordpress, when a user requests a page, the server has to do so much more than simply grab that page and serve it up to them. A page request with a Wordpress server looks something like this (highly simplified):
Wordpress needs to find the templates, query the database, assemble the page with the data from the database, all before finally sending that page to the user. Interventions like caching systems or CDNs can help with all of this, but they also create issues of their own.
Speed
Wordpress is database-based (MySQL). When a user requests a page, it must make database queries, find the appropriate templates, inject the appropriate data and assemble that page on the server side. As with resources (above), caching, CDNs, and other technical interventions can help reduce the impact of this, but the best cure is prevention.
The fewer things we need to ask a server to do before it gives a user a page, the faster that page will be.
So, what are the alternatives?
The web is moving away from the super-centralized, one-web-server-to-do-it-all model, and towards a more decentralized, atomized, and frontend-centric web that uses fewer technologies in smarter ways. This, in a buzzword, is the JAMstack — a major trend in web development over the last few years.
JAMstack (short for Javascript, APIs, and Markup) development takes the centralized, Wordpress-style model and inverts it. Instead of assembling pages from templates + database queries as they are requested, JAMstack development focuses on building these pages (the markup) statically, on the serverside, ahead of time. APIs allow for interaction with external services, to provide functionality such as content management, file upload, etc. — and Javascript comes in to add in frontend interactivity and richer functionality. Together, it’s a perfect storm — a dynamic, interactive website where a user never has to wait for a database on the server-side, one that is faster, more reliable, and more secure.
Who uses the JAMstack? Major enterprise companies with a lot to lose, companies for whom performance, uptime, and security is key. These companies include Airbnb, Nike, PayPal, Red Bull, and Sequoia Capital.
Let’s revisit those problems that Wordpress presents, and see what JAMstack can do about them:
Security
With a statically generated site, there is just a simple HTTP server, serving up assets — HTML, CSS, JS. There is no PHP or MySQL database to keep up to date to avoid security vulnerabilities. Your attack surfaces decreases dramatically. Nothing is unhackable, but you can get yourself a lot closer to it if you’re not running a complicated Wordpress stack just to serve up your blog/brochureware site.
Speed
Again, with JAMstack sites, we just have a simple HTTP server, serving up prebuilt assets. The server doesn’t have to do anything beyond deliver those assets, and therefore the site/page can be as fast as you can build it to be.
Resources
In contrast to a non-statically generated Wordpress site, which needs to run a delicate machinery of database, PHP, and web server, a JAMStack site is already prebuilt and ready to go on the server. This means, when it’s requested, all the server has to do is read the file from disk, and send it over the wire to the user. It doesn’t have to do any extra work, because everything is all ready to go. Giving the server less things to do means less server resources are used or needed to serve a page.
“But why do I care about server resources? Compute is cheap!”, says the CTO or other high-level tech management type in the back of the room.
Well, sure. Compute is cheap. Less compute is cheaper. This might matter less if you’re a huge company, and hosting bills totaling several thousands of dollars a month is considered par for the course (or, it might matter more!). But for smaller companies, startups, or non-profits, the savings can matter.
Furthermore, less server resources to serve your users a site = less power used to do so = better for the environment. That’s right! JAMstack/statically generated sites are, generally speaking, better for the environment.
But Wordpress has been around a long time, right? What about these new up-and-comers? What if they disappear tomorrow?
The thing about Wordpress is it stores all of your content in a database — behind closed doors, accessible (if you really try), but opaque. It locks your site markup down into Wordpress-friendly templates and PHP snippets. If Wordpress were to disappear, or if you need to move your site away from Wordpress and onto another platform — it’s a big deal to move all that data over and migrate everything.
But in the new way of doing things, everything is decentralized. Your content is always easily accessible through files committed to your code repository or through an API, and stored in open, digestible, and portable formats. You can use whatever frontend tooling and technologies you want — or move between them — with ease.
If Forestry — my headless CMS of choice — were to disappear tomorrow, it wouldn’t be a big deal, because I’ll still have all of my content sitting in Markdown files (a portable, translatable, human-readable format), next to my codebase.
Emerging services like Stackbit make this even simpler, by providing a system and tooling for moving seamlessly between different JAMstack CMSs and different frontend tooling, without re-writing anything.
Wordpress Vs. The Future
I’ll fess up: I’ve never been a huge fan of Wordpress (although Gutenberg and WP-API warmed me up to it significantly), but the state of alternatives out there before were simply not good enough. Year after year, I’d look for alternatives, try things out — and year after year I’d be disappointed. I did my best to make Wordpress work for me.
But 2018, in many ways, was the year of the JAMstack — with major tools, platforms, and static-site generators such as Gatsby gaining funding and widespread adoption. The web — as it is wont to do — has hit one of its periodic acceleration points, and the tools have come a long way, very quickly.
So, coming from a person who has wanted viable alternatives to Wordpress for a long time, and looked for them, and come away disappointed — I am happy to announce that the future is here! We now have viable alternatives, and they’re better in a variety of ways and for a variety of use cases.
JAMstack sites do tend to be better suited to smaller sites, rather than huge ones (at a certain point, the time it takes to build the site on the server outweighs any benefits, although it’s getting faster and faster), and sometimes require more developer involvement for things like eCommerce, etc. However, the technology is moving fast, and JAMstack sites are already proving themselves to be better than Wordpress for a variety of use cases. Besides — your site gets better when you have a real, human developer — instead of a machine, or a black box — making decisions with you.
The future is here, and it’s rapidly becoming widely distributed. Wordpress is trying its best to keep up… but the tables have turned. Now, instead of leading the pack, and waiting for others to fall behind, Wordpress is struggling to keep up and maintain relevancy with the new kids on the block — adding in features like Gutenberg (based on React) and native API support as a reaction to the JAMstack trend.
If this is a David and Goliath story, Wordpress is still Goliath.
But, we all know how that one ends.