{{post.title.rendered}}

// and so on
[/javascript]
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.