Automattic just announced Calypso, which is a radical new interface for WordPress.com.

It replaces the old WordPress.com admin experience with a faster, more modern approach. It uses a Javascript framework called React, which was developed by Facebook. The main advantage of React is that it’s supposed to allow development of web and mobile apps using a similar codebase.

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?

I’ve been working with Javascript apps and WordPress APIs for over a year now, and I have a lot of thoughts on the subject.

Is WordPress going 100% Javascript?

The WordPress.com admin is now all Javascript, but it’s important to note that websites hosted on WordPress.com are still using PHP like normal. The front-end facing WordPress.com sites have not changed, but could they?

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.

Themes don’t have anything to do with an API driven WordPress, you won’t even need one on your site. That’s not to say there won’t be a visual component, but it will be all javascript templating. One example of this is mobile apps created with Reactor.

That’s not to say it’s impossible to use a theme and the WordPress API, that has already been done and will continue. In this case theme developers will require an entirely new approach to the way they build themes. Instead of thinking about template tags and a functions.php file, developers will be using Javascript templating and MVC frameworks.

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:

<?php
/* My Theme */
?>

<article id="post-<?php the_ID(); ?>">
  <h1 class="entry-title"><?php the_title(); ?></h1>
  <div class="entry-content><?php get_template_part( 'content' ); ?></div>
// and so on

It would look more like this (at least in Angular):

<article id="post-{{post.id}}">
  <h1 class="entry-title">{{post.title.rendered}}</h1>
  <div class="entry-content" ng-bind-html="content"></div>
// 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.

Take Gravity Forms for example. They use shortcodes and template tags to display their forms, enqueued Javascript and CSS files, and PHP form processing. If you are using the WP-API, the only thing that comes through is a parsed shortcode, which is just HTML. To make the form work, you’d have to essentially rebuild everything on the app side. This is extremely complex, and at that point, it would be easier to just roll your own solution.

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.

Plugins May Include Node Modules and Javascript Templates

If you have worked with Node, you know you can install a module, which is like a Javascript plugin.

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.

I believe the money will still be in plugins, since it’s easier to control licensing, and the market is used to paying for that. Javascript apps will still need a plugin on the WordPress side, to handle admin screens, custom API handling, etc.

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.

Beyond that, they should support the all the CRUD functions of the REST API by the time it’s fully merged into core next year. Plugin authors would be wise to begin exploring Javascript templating and interaction with their plugin through the API.

Market Disruption for Javascript-First Plugins

There is an opportunity for API/JS first plugins to disrupt the market.

By that, I mean plugins specifically built to interact with WordPress through a Javascript app. Most plugins are fully steeped in PHP and the “WordPress Way” of doing things, which is not always friendly to Javascript. Authors of plugins that are widely used might be slow to adopt this new method, which means their plugins will be difficult to use in apps.

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.

Decoupled WordPress

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.

9 thoughts on “Javascript, APIs, and the Future of WordPress

  1. Really comprehensive look at the market now and I’m the future, Scott. JavaScript first plugins are something that I think will help the WordPress world flourish as you detail here. It’s exciting to think of our community moving more towards “maker” type of modualized marketplaces. There is so much inherent open source philosophy to the core of WordPress that is helping to guide this as you mention, and that fact I think really empowers our community as a whole. Thanks for writing this great analysis!

  2. 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.

    • That’s an interesting idea Jon, using WP along with another backend. Sounds like it might be too much CMS overhead, but for some projects it might make sense.

Leave a Reply

Your email address will not be published. Required fields are marked *