Automattic just announced Calypso, which is a radical new interface for WordPress.com.
WordPress.com now uses an API to communicate with a Node server, instead of processing with PHP. The advantage of this is that it’s much faster and more interactive, and there are no page refreshes. It’s the same approach that makes many mobile and web apps tick, and it has the performance many users have come to expect these days.
This is a huge shift for WordPress.com, and it’s a major milestone for WordPress in general. Even though many sites and apps have already been taking this API driven approach, this marks a huge shift in WordPress development philosophy.
The question I’m wondering is, where is this all going? What does this shift mean for developers, products, and WordPress core?
It would be super cool if WordPress sites could all be single page web apps, the same way that the new admin is. Unfortunately, it will be a very long time until that happens.
WordPress core will support an API as soon as the WP-API is fully merged, sometime next year. Posts and pages are not hard to turn into an app, it’s all the stuff added on top of core in themes and plugins.
Fun fact: Node/PHP is not an issue here, you can still run single page web apps without Node.
Themes are less important with an API
If a WordPress site is 100% API driven, a theme will not be used at all.
One interesting concept is a WordPress API theme.
WordPress API Themes
WordPress themes are dependent on PHP right now, but if you are using an API, you could build a theme out of HTML/CSS/JS.
Instead of looking like this:
// and so on
It’s a similar concept, but the difference is that we are starting from scratch. There are no helper functions like `wp_kses()` or template tags like `get_header()`. There is no functions.php file, and no action or filter hooks.
There’s a lot of work to be done with API Themes, and there may be a market for done-for-you templating. These will already include the code needed to fill the templates, so you can just add your site url and it’s already a finished app.
One example of this is a project I called wpIonic, which is an Ionic/AngularJS starter mobile app that interacts with your WordPress site through the WP-API. All you have to do is add your site url, and customize as necessary. It’s pretty bare-bones example, but it could be one part of a larger done-for-you WordPress app project.
The hard part about this will be helping the end user customize these apps without coding. I can also see a market for app builders, not just mobile apps but web apps too.
Plugins are the biggest hurdle
The biggest thing stopping WordPress sites from becoming fast, single page apps is plugin support.
Plugins are the most powerful part of WordPress, because they allow you to extend it and customize it. One of the lessons we learned building Reactor is that people love their plugins, and they really, really want them to work in their apps. The problem is that once you start using an API, plugins don’t work anymore.
Eventually plugin developers will add support for the WP-API, but it will be a long time. Not a single plugin I use regularly supports the WP-API natively, and it’s been around for more than a year (granted, in beta).
Even when plugin authors add support for the WP-API, it’s not a plug and play situation. If you are building a web app with AngularJS, you still need to write a lot of custom code to make things work. All of the HTML/CSS/JS in your app will be written by you from scratch, until developers start releasing code for you to use, which is already happening. This brings me to my next point.
For example, there is an AngularJS based library for interacting with the WP-API called Wp-api-angularjs. It handles much of the code you’d need to write in an Angular app to interact with a WordPress website through the WP-API.
Going back to our Gravity Forms example, they could release a node module that helps you work with their forms through the WP-API (or their own API). If they also released a node module that contained JS/CSS files, and possibly some templates or directives to render the forms, it would be really easy to use. (One problem is that it would have to be usable with different libraries, such as Angular, React, Backbone, Vanilla JS, etc.)
Is There Money in Node Modules?
Most node modules are free, it will be hard to incentivize product developers to create and maintain these. It may become a community thing, where developers release them as open source projects.
What Developers Need to Do Now
Developers need to add their public plugin data to the WP-API at a bare minimum.
For example, a plugin like Advanced Custom Fields needs an easy to use admin interface to choose which fields are exposed to the API. Right now you can use a custom plugin, but plugins need to support this natively.
There is an opportunity for API/JS first plugins to disrupt the market.
Using our Gravity Forms example, if there were a forms plugin specifically built to be used in an app, I would use that instead. It would save me a lot of time, and I would be happy to pay for it.
I’m sure most large plugins will support the WP-API eventually, but by the time they get around to it, it might be too late. It will also be much harder for them to add JS/API support and templating, as opposed to someone who can start from scratch with that approach.
Custom WordPress admins are the most obvious thing that’s going to start happening. Calypso is the first large-scale example of that.
Let’s say you build a site for a Church, and they are not tech savvy. You could build a custom admin for them that only shows relevant menus like Sermons, Video, and Comments. You could create a custom page editor for them that only shows a couple of fields, like a video upload button, title, and description.
This could all be in a super fast single page web app built with AngularJS and the WP-API. Sure, it’s possible to hack up the WP-Admin with PHP and CSS, but it wouldn’t be as fast or as custom. You could also build them a mobile app to edit their site on the go using the same codebase, compiled with PhoneGap.
What does a decoupled WordPress mean for the future? Here’s what Chris Lema had to say:
In order to succeed in 10-15 years, WordPress will have to both embrace the outside edges of the broad adopting community (small businesses) and simultaneously extend itself to work within the enterprise as a good corporate citizen. Thankfully we’re doing the work around APIs that will enable both of those things.
You can imagine a lot of innovation around user interfaces that are detached from WordPress (which fully utilize the API) so that we can find the user experiences that small businesses can and will easily adopt.
And you can imagine the integrations that will be developed using the same APIs so that WordPress can talk and leverage connections to Oracle, PeopleSoft, SalesForce and more.
Innovation is Good
All of the things I’ve mentioned in this article are a pretty big departure from what WordPress has traditionally been used for. This is a good thing.
Technology needs to evolve or else it will be replaced by something newer and better, and this evolution of WordPress will help it flourish in the coming years. It also means there will be a lot of change.
WordPress and the micro-economies around it will also need to evolve, or they will be replaced. The most successful WordPress products in 5 years will not look like the ones today.
WordPress is 25% of the web today, will it be 25% of apps in 5 years? We’ll see.
Have you seen Picard? It’s an experimental theme (more proof-of-concept) that uses React and the WP-API. Perhaps a small indication of the future of themes, at least in the short term.
I’ve been thinking about this too.
Just when I was starting to feel that WordPress was growing stale and stagnant something comes along truly disruptive. Exciting times!
Time will tell however if it succeeds in reinvigorating WP though as there are still a lot of hurdles to cross.
I do think plugins will need to move to API first development ASAP. I think that’s second ary to JS first development. As such I’m already looking for resources on how to do that. How to handle custom tables in WP while being API friendly.
One interesting thought I had I haven’t heard discussed much is that one of WP’s _key_ features has always been WP Comments. It’s one the the suckage point of using things like Jekyll, Drupal, etc… is that for the most part you’re stuck using Disqus or something like it. There are “difficult” to implement options like HashOver that are still technically self-hosted, but nothing really compares to WP comments.
What happens if one builds a front end in Jekyll, but powers the comments with WordPress? It’s possible now, but I haven’t seen it and it would be interesting if nothing else.
Thanks for writing this great analysis!