In my last article for Torque on thinking like an app I intentionally did not address how mobilization of WordPress changes the way we approach development in terms of deciding what to build. In this post I will discuss my thoughts on the technical changes that occur when we are doing the actual development.
Keep in mind that, for now, when we are talking about developing WordPress apps, we are actually talking about building a specific app for a specific purpose, not building a reusable app to be repurposed by others, similar to the way we write plugins and themes.
Reusable parts for the REST API, like many of the plugins and themes we have today, may very well be on the horizon for creating a WordPress app economy. But we are not here yet, and we will have to wait and see how it plays out.
What Standards Still Apply?
You can draw on what you’ve learned from theme and plugin development when you start working on an app, but keep in mind that not all of the same rules apply. This is largely because you’re not making code for distribution on thousands of sites, which is typically the case when making any specific site.
When developing a website, be sure that your client can swap out any theme, plugin, or custom code and still have the site work properly. This kind of modularity is a big reason why they are using WordPress to create their site in the first place.
When you’re building an app, I think (though I could be wrong) it is safe to assume that it is “your app” and that mentality actually shifts the thinking of how to keep it working.
Similar to site development, you have full control over your stack, so there is no need to think about backwards compatibility with older versions of WordPress or PHP. Nor is there any reason to burden yourself with anything but the latest versions of WordPress, PHP, or HHVM.
When it comes to plugin and theme development, playing nice with other plugins and themes is of outmost importance. Even when I’m called into write custom code for a site, I always make sure that I’m following the WordPress standards and best-practices fully because I have no idea what plugins and themes a client might want to add in the future.
Hardcoding a link to a script or stylesheet in the HTML header is considered bad practice in a client project or theme; but hard-coding them makes my code more readable to non-WordPress developers on the team. It also shaves time off of my initial page load. In this case, it’s a minor thing, but when you start to think about all of the things you normally do, just to be safe, you’ll quickly realize how these minor things add up.
Also, where you put your code (i.e., in a theme, plugin, mu-plugin, or somewhere else) is very different. You don’t need to always think in terms of themes or plugins, or even entirely in WordPress. In many cases, building out of the must-use-plugins, or mu-plugins, directory makes a lot of sense.
In plugin development, it would be unreasonable to assume that an end user would integrate with another PHP framework like Laravel. However, if you want to build half of your app in Laravel, you can, or if for some reason it makes more sense to use Symfony’s event router instead of WordPress hooks, then go ahead.
How Do You License It?
When you develop a WordPress theme or plugin for distribution, whether you license it correctly or think you can actually add a restrictive license is, on a practical level, meaningless. Anyone can redistribute and reuse your code in whole or in part, unless you are electing to use the AGPL.
When building an app, most of the time you don’t have to distribute your code. So its license is less important.
I like to keep my code public as I think it will help my business. Similarly, it helps protect the safety of my users, since the security of my code can be independently audited. For those reasons I want the protection of the GPL or similar licenses.
Do You Use Plugins?
Personally, I still use plugins, but I tend to stick to the plugins that I am actively involved in as a major contributor.
Making part of the stack code that isn’t unique to your project, although efficient, is a big risk. If you don’t have an in-depth knowledge of the plugins you choose, then you run the risk of overlooking potential issues along the way. Similarly, you may also be stuck maintaining them if the original author drops support.
There’s lots to be said about how the WordPress REST API will open us up to using non-WordPress specialists.
This is especially true for front-end work, which might be totally decoupled from WordPress. For server-side, however, you should have an intimate knowledge of WordPress core, the REST API, and whichever plugins you’re using. For that you need a seasoned WordPress PHP developer, preferably one who is a contributor to all dependencies involved.
Ultimately, plugins are like any other dependency in app development. They can potentially speed up development by allowing you to leverage other people’s work instead of doing it yourself. Each dependency, however, reduces the control you have over your stack and increases your chances of having issues.
How Do You Make Your Front-end?
The front-end of your app is where the real differences will come into play. When using an app, users expect that it will be highly dynamic, limited in page views, and work offline.
Now Is The Time To Experiment
The WordPress REST API offers an an exciting, new breadth of opportunity as we discover new ways to use it to enhance our overall experience with WordPress. The most exciting part, as I hope this article and its less technical sibling have shown, is that it opens up a new way of thinking and approaching our work.