WordPress for app development
torquemag.io
torquemag.io
Advantages:
* Can use WordPress plugins for rapid development.
* Can use a WordPress theme for a quick beautiful design.
Disadvantages:
* Large amount of internal overhead (which caching plugins won't solve)
* Plugin conflicts must be handled manually
* Need to maintain proper versioning when adding/removing/updating plugins.
* Your website is a beacon for hacker attempts because it's running Wordpress.
It's good to work with WordPress in a pinch, but if you can build an app using traditional tools, it's better in the long run.
* You only need to learn to use one hammer for everything.
Disadvantages:
* Eventually you'll realize the things you've beat into shape tend to fall apart.
The growing pains and the transition to a "real" solution later on will be a huge pain in the.... It's literally a duct tape hack more than an actual app. The database models and security of apps built on top of WordPress are horrible most of the time.
I agree that WordPress is enabling for a lot of people who bootstrap this kind of things and are not tech savvy or don't have the funds to build an application. I also know that it's scary to tackle these things when you don't know where to start. A false assumption people fall for a lot of times is that it'll be cheaper that way. It won't. If you consider starting with WordPress you should keep in mind to change the framework as quickly as possible. A good time to change it is when the idea is validated. But in reality people keep patching and patching until it collapses.
We had to take the hit, realize and admit that, "Well, browsers are nearly everywhere, it's what people are used to."
Now, I see the "browser app" people saying, "Why would you run apps in Wordpress, the browser is so much better, less overhead, better designed for it."
What's next, people using "Yo" as an app platform? ;)
Wordpress is still very much stuck in the old-school PHP world: download one big codebase, add some Wordpress specific packages (themes and plugins). That's a far away from where modern PHP is: smaller components brought together with composer and packagist. Which leads to more nimble frameworks for putting together web apps, picking and choosing the right set of components. Don't like Doctrine, use Propel, or RedBean, or Eloquent.
It's okay if your app fits into Wordpress' constraints of the world.
My concerns over the current state of Wordpress as a web-app framework:
* Plugins are special snowflakes, and so raises a gnarly set of conflicts and issues.
* Themes that do a lot more than theming - like WPGeo, which is an entire location-based functionality. It's like there's a packaging construct that involves themes + set of plugins that's missing. So themes become a dumping ground for any code.
* Dependence on global variables (like $wpdb)
* The datastore being SQL is leaked through the codebase.
* The visual layer drives the processing - so themes take control.
* Plugins are wordpress plugins, not well-built PHP packages.
* The extension mechanism (pseudo-event-binding through global functions) makes any code "Wordpress code", it's a lock-in.
* The custom data storage is a joke and inconsistent. serialised php being stored in mysql field, or serialised JSON. Wordpress is missing a mechanism to encourage structured data. I care about the quality of my data, my app needs to care too.
* Unit tests. Wordpress' architecture makes decent unit test coverage difficult.
* The quality of third-party plugin development isn't great. Understandable considering the typical Wordpress audience. If the plugin works, great. If there's a conflict, that can open up a pile of hurt.
* Essentially it's a code-coupling problem. It's difficult to disentangle. So you're mostly writing Wordpress specific code, not componentised PHP modules.
I like the admin interface, I wish that was a separate component that could be forked, and used as the basis for a web app.
I can't see how Wordpress can deal with these issues in a backwards compatible way. Yes, they can create a modular and componentised core that can be packaged up for use outside of Wordpress, but at some point there's going to have to be a shedload of Adaptors to translate that clean crafted and organised code into a bunch of global variables and global functions that themes and plugins rely on.
I can see good bits of Wordpress (like the admin ui) being forked off into separate projects and worked on in isolation to the point they catch up with modern PHP development. But these won't be backwards compatible with Wordpress without a grungy wordpress layer over the top.
Perhaps the damning thing is the lack of a consistent and appropriate data model, backed with a properly structured database. Sure, I can define my own relational database, do by hand what a content management system should already be doing for me - at that point where's the benefit? What if I want to be using a noSQL store instead?
It's hard to justify starting with Wordpress, when there are so many much better frameworks available for PHP that are more suited to packages and componentised code.
First step, up-to-date autoloader and namespaces.
Thanks for the Craft CMS pointer. I did not spot that when looking for something more modern that supported custom content types last year. I played briefly with Bolt CMS, but it didn't quite feel right to me.
I'm a mostly-WordPress developer (for now) learning NodeJS and seeing how all of these things combine to make the ecosystem less-than-optimal for "real" app-building. Some are more damning than others but it's hard to see how WP could start where it is now, a competent and popular CMS, and get to where it supposedly wants to be, an app platform, without breaking much of what's built on it already.
Your comment "It's okay if your app fits into Word[P]ress' constraints of the world" rings totally true. In fact, it's worth it to give the platform a try for an app-y project so you have something to compare it to, especially if that's where you're starting. Because my experience is so WP-heavy, the projects that I've wanted to build are colored by that. Now that I'm exploring a new stack, many of these assumptions seem ridiculous.
Thanks again for taking the time to put this all together.
I've written plugins which used a PSR-0 autoloader, and namespaces, and considered templates to separate code from data, and realized very quickly that scaling that in Wordpress means treating every plugin as, essentially, its own completely autonomous and globally-running web framework (and also they didn't actually run on the particular site I wrote them for because they weren't running an up to date version of PHP.) It's difficult to write good code for Wordpress when for all your know your plugin is one of a hundred in someone else's install.