The other night at WordPress Sydney, I dropped a five minute brain-dump about some cool things going on in the web ecosystem that herald a new era of WordPress. That’s a decent enough excuse to blog for the first time in two years, right?
I became a WordPress user 9 years ago, not long after the impressive 2.0 release. I was a happy pybloxsom user, but WordPress 2.0 hit a sweet spot of convenience, ease of use, and compelling features. It was impossible to ignore: I signed up for Linode just so I could use WordPress. You’re reading the same blog on (almost) the same Linode, 9 years later!
WordPress
Fast forward to 2015 and WordPress powers 20% of the web. It’s still here because it is a great product.
It’s a great product because it’s built by a vibrant, diverse Open Source community with a fantastic core team, that cares deeply about user experience, that mentors and empowers new contributors (and grooms or cajoles them to become leaders), and isn’t afraid of the ever-changing web.
Another reason for the long term success of WordPress is that it’s built on the unkillable cockroach of the world wide web: PHP.
I won’t expound on the deficiencies of PHP in this post. Suffice to say that WordPress has thrived on PHP’s ubiquity and ease of adoption, while suffering its mediocrity and recent (albeit now firmly interrupted) stagnation.
HHVM
The HipHop Virtual Machine is Facebook’s high performance PHP runtime. They started work on an alternative because PHP is… wait for it… not very efficient.
Unless you’ve goofed something up, the slowest part of your PHP-based application should be PHP itself. Other parts of your stack may exhibit scaling problems that affect response times, but in terms of raw performance, PHP is the piggy in the middle of your web server and data stores.
“But like I said, performance isn’t everything.” — Andi Gutmans
What is the practical implication of “performance isn’t everything”? Slow response times, unhappy users, more servers, increased power utilisation, climate change, and death.
Facebook’s project was released in 2010 as the HipHop compiler, which transpiled PHP code into C++ code, which was then compiled into a gigantic monolithic binary, HTTP server included.
In early 2013, HipHop was superseded by HHVM, a jitting virtual machine. It still seemed pretty weird and awkward on the surface, but by late 2013 the HHVM developers added support for FastCGI.
So today, deployment of HHVM looks and feels familiar to anyone who has used php-fpm.
Want to strap a rocket to your WordPress platform? I strongly recommend experimenting with HHVM, if not putting it into production… like, say, Wikipedia.
Hack
Not content with nuking PHP runtime stagnation, the HHVM developers decided to throw some dynamite in the pants of PHP language stagnation by announcing their new Hack language. It’s a bunch of incremental improvements to PHP, bringing modern features to the language in a familiar way.
Imagine you could get in a DeLorean, go back to 2005, and take care of PHP development properly. You’d end up with something like Hack.
Hack brings performance opportunities to the table that the current PHP language alone could not. You’ve heard all those JavaScript hipsters (hi!) extolling the virtues of asynchronous programming, right? Hack can do that, without what some describe as “callback hell”.
Asynchronous programming means you can do things while you wait. Such as… turning database rows into HTML while more database rows are coming down the wire. Which is pretty much what WordPress does. Among other things.
Based on the WordPress team’s conservative approach to PHP dependency updates, it’s unlikely we’ll see WordPress using Hack any time soon. But it has let the PHP community (and particularly Zend) taste the chill wind of irrelevance, so PHP is moving again.
WP-API
Much closer to WordPress itself, the big change on the horizon is WP-API, which turns your favourite publishing platform into a complete and easy-to-use publishing API.
If you’re not familiar with APIs, think about it this way: If you cut off all the user interface bits of WordPress, but kept all the commands for managing your data, and then made them really easy to use from other applications or web sites, you’d have a WordPress API.
But what’s the point of stripping off all the user interface bits of WordPress? Aren’t they the famously good bits? Well, yes. But you could make even better ones built on top of the API!
Today, there’s a huge amount of PHP code in WordPress dedicated to making the admin user interface so damn good. There’s also a lot of JavaScript code involved, making it nice and interactive in your browser.
With WP-API, you could get rid of all that PHP code, do less work on the server, and build the entire admin user interface in the browser with JavaScript. That might sound strange, but it’s how most modern web applications are built today. WordPress can adapt… again!
One of the things I love about WordPress is that you can make it look like anything you wish. Most of the sites I’ve worked on don’t look anything like traditional blogs. WP-API kicks that up a notch.
If you’ve ever built a theme, you’ll know about “the loop”. It’s the way WordPress exposes data to themes, in the form of a PHP API, and lots of themers find it frustrating. Instead of WordPress saying, “here are the posts you wanted, do what you like”, it makes you work within the loop API, which drip-feeds posts to you one at a time.
WP-API completely inverts that. You ask WordPress for the data you want — say, the first ten posts in May — then what you do with it, and how, is 100% up to you.
There’s way more potential for a WordPress API, though. A fully-featured mobile client, integration with legacy publishing systems at your newspaper, custom posting interfaces for specific kinds of users, etc., etc., etc.
The best bit is that WP-API is going to be part of WordPress. It’s a matter of “when”, not “if”, and core WordPress features are being built today with the WP-API merge in mind.
React
According to its creators, “React is a JavaScript library for building user interfaces”, but it’s way cooler than that. If you’re building complex, interactive interfaces (like, say, the admin back-end of a publishing platform), the React way of thinking is fireworks by the megaton.
For all the hype it enjoys today, Facebook launched React in 2013 to immense wailing and gnashing of teeth. It mixed HTML (presentation) and JavaScript (logic) in a way that reminded developers of the bad old days of PHP. They couldn’t see past it. Some still can’t. But that was always a facile distraction from the key ideas that inspired React.
The guts beneath most user interfaces, on the web or desktop, look like a mad scientist’s chemistry lab. Glass everywhere, weird stuff bubbling over a Bunsen burner at one end, an indecipherable, interdependent maze of piping, and dangerous chemical reactions… you’d probably lose a hand if you moved anything.
React is a champagne pyramid compared to the mad chemistry lab of traditional events and data-binding.
It stresses a one-way flow: Data goes in one end, user interface comes out the other. Data is transformed into interface definitions by components that represent logical chunks of your application, such as a tool bar, notification, or comment form.
Want to make a change? Instead of manipulating a specific part of the user interface, just change the data. The whole user interface will be rebuilt — sounds crazy, right? — but only the changes will be rendered.
The one-way data flow through logical components makes React-based code easy to read, easy to reason about, and cranks your web interface to Ludicrous Speed.
Other libraries and frameworks are already borrowing ideas, but based on adoption to date, number of related projects, and quality of maintenance, I reckon React itself will stick around too.
Connecting the Dots
It won’t happen overnight, but WP-API will dramatically reduce the amount of active PHP code in WordPress, starting with the admin back-end. It will become a JavaScript app that talks to the WP-API sooner than anyone suspects.
Front-end (read: theme) development will change at a slower pace, because rendering HTML on the server side is still the right thing to do for performance and search. But themers will have the option to ditch the traditional loop for an internal, non-remoting version of the WP-API.
There’ll be some mostly-dead code maintained for backwards compatibility (because that’s how the dev team rolls), but on the whole, the PHP side of WordPress will be a lean, mean, API-hosting machine.
Which means there’s going to be even more JavaScript involved. Reckon that’s going to be built the same way as today? Nuh-uh. One taste of React in front of WP-API, and I reckon the jQuery and Backbone era will be finished.
In WordPress itself, most of this will affect how the admin back-end is built, but we’ll also see some great WordPress-as-application examples in the near future. Think Parse-style app development, but with WordPress as the Open Source, self-hosted, user-controlled API services layer behind the scenes.
What about HHVM? You’re going to want your lean, mean, API-hosting machine to run fast and, in some cases, scale big. Unless the PHP team surprises everyone by embracing the JVM, I reckon the future looks more like HHVM than FPM (even with touted PHP 7 performance improvements).
Once HHVM is popular enough, having side-by-side PHP and Hack implementations of core WordPress data grinding functions will begin to look attractive. If you’ve got MySQL on one side, a JSON consumer on the other, and asynchronous I/O available in between, you may as well do it efficiently. (Maybe PHP will adopt async/await. See you in 2020?)
End
Look, what I’m trying to say is that it’s a pretty good time to be caught up in the world of WordPress, isn’t it? 
