About three years ago, I wrote a post for Torque titled “Yes, You Really Can Use WordPress To Build Apps.” In 2014, this was an emerging idea, but now it’s done quite often. The WordPress REST API, as well as a shift in how we think about WordPress, has contributed to this change.
At LoopConf this year, Ryan McCue, the co-lead developer of the WordPress REST API gave a talk called “Next Generation WordPress.” He said that we’ve gone from the WordPress as a blog, to the WordPress as a CMS, to the WordPress as a platform era. It’s a great talk, you should really watch it on YouTube.
In the talk, Ryan talks about the need to prioritize developer experience. In general, WordPress core decision making is driven by a user-first approach. Decisions are made based on what will benefit users. And that’s great. WordPress is always going to be driven by platforms like WordPress.com or StudioPress.com that serve bloggers and SMB who need a website that just works and those who create similar experiences on self-hosted WordPress. This is an example of how WordPress is being used in nontraditional ways.
Here’s the thing. I’ve been one of the loudest proponents of using WordPress as the backend for an app. I’ve been telling everyone to learn a JavaScript framework or two and use it with WordPress, while I’ve been learning Angular and VueJS.
But, when I get done with this article, I’m going to start hooking the VueJS front-end I built for the next iteration of Caldera Space — a web app for extending the powers of Caldera Forms — to its back-end. And that backend is built in Laravel.
I feel kind of guilty about it, but as far as PHP development goes, I don’t think you can beat the developer experience of Laravel. WordPress, not even close. That’s a problem.
Modernization FTW
The WordPress REST API is an amazing tool. It was built to be extended in a great way. The infrastructure for creating custom REST API routes is very well done and provides a developer experience that isn’t present anywhere else in WordPress.
The REST API provides a flexible and extensible abstraction for the current HTTP request. We don’t have that anywhere in WordPress. REST API endpoints have declared schemas, that can be read by humans and clients alike.
We don’t have a defined schema for what custom fields a WordPress post type uses. The WP_HTTP_Request object isn’t available to us in any other context. The new WP_Hook class doesn’t provide any type of registration of parameters for hooks.
Modernizing the most important parts of the WordPress API – WP_Rewrites, the task system (WP_Cron), the plugins API (hooks), etc. isn’t a user facing feature. None of that is a priority for WordPress 4.8. But this idea that if users can’t see an improvement that it’s not important to them is a false equivalency. I think users want results, and results come from developers with the tools to get the job done.
Decoupling FTW
What’s awesome about building traditional WordPress sites is that we can get so much done with plugins. But, plugins tend to be very strongly coupled to the traditional WordPress request lifecycle.
Plugins are a major part of what makes WordPress so powerful. But if the current plugin stack is going to be a part of the platform era of WordPress, as developers, we’re going to need to separate all of the different parts of our plugins, so that developers can choose to use parts of the plugin. WooCommerce is doing a great job of reworking their code around CRUD objects.
For example, eCommerce is tricky. You need infrastructure for products, customers and payments. If you want to use WordPress to power a SaaS that has a front-end decoupled front-end, then you are likely to use these things separated from the standard product display and shopping cart.
I wrote recently about the challenges of adding a REST API to my own plugin Caldera Forms. Form plugins provide both a front-end form and a data storage layer. Decoupling those two, so that the storage layer can be used separate from the standard forms has been a challenge, but it’s helped us improve our add-ons that work with entries in new ways. It’s helped other developers satisfy their client needs.
No one is ever going to use “great database abstractions” to sell their product. I get that.
But the work to create a better developer experience for WordPress developers is going to lead to better, cooler features we can list on our website.
Open Source FTW
WordPress plugins are just part of the amazing list of open-source tools we get to use with WordPress. When working with the WordPress REST API in a non-traditional way, we have a lot less tools available to us. That’s a function of time and will change.
There are some great examples of open-source tools allowing for innovative new ways of using WordPress. For example, the Moxie LEAN stack for using AngularJS with WordPress and existing plugins, the NodifyWP platform for building Isomorphic web apps with React and WordPress and the NodeJS client for the WordPress REST API. We need more an more of these and to open source them.
Part of the issue here is that these things defy the traditional containers for WordPress. They don’t fit into the “plugin” or “theme” box. So they don’t get the same support as others.
PHP7 FTW
Before I end this post, I have to point out we can only modernize WordPress using last decade’s PHP. PHP has come a long way since PHP 5.2. We’re hampering ourselves
If we want to get serious about being a platform for building web applications, we need to end support for PHP 5 as fast as possible. The L*MP hosting stack that got us here, isn’t going to get us where we’re going. Making PHP7 required, not recommended, for hosting WordPress is a great first step. Of course we probably also need to make Node a part of that stack, but let’s not get too carried away…
I ❤️ WordPress
Look, I was having a serious discussion about getting a WordPress tattoo recently, because I love being a part of this community and what it has given me. But, if we want WordPress to be the platform that the modern web is built on, we need to take the technical debt problem seriously.
WordPress has an infrastructure problem. I hope that we prioritize paying down these technical debts as much as we are prioritizing end-user experience.
I said before that I would be finishing this post and then going back to working on a Laravel app. But first, I need a sandwich and while I’m working on that, I’ll take scope out what it would take to make all or part of the app in WordPress instead. I’ll share what I learn.
2 Comments