I’ve spent more than enough time talking about my position on using WordPress as a platform for writing web applications, but there’s one aspect of doing so that I don’t think that I’ve actually bothered discussing very much.

Namely, if WordPress is suitable as a platform for application development, then does it make sense to use it when another framework, set of libraries, or core tools may also fit the bill?

WordPress As An App Platform (Or “It’s An App For That”)

Though I’ve spent a significant amount of time about WordPress as a viable platform here on this blog, the longest and arguably most detailed post I’ve written about this particular topic has been on WP Daily.

Using WordPress For Application Development

I mention this here in order to give some context for what I’m about to share, and so that there’s some background to my general stance on the topic.

That said, we know that WordPress provides a solid foundation for certain types of web applications – especially those that require content management – and I’d even argue that most sites and applications are all driven by content management.

I mean, it’s all in how you define content, right?

Anyway, I’m not necessarily wondering if WordPress is the right tool for every job – I don’t believe that. In fact, I don’t believe that any language, platform, or framework is the right tool for every job; however, given an idea for a number of web applications, I’ve found myself wrestling with whether or not WordPress should be used as the underlying platform for the solution.

The Tradeoffs of Frameworks and Platforms

I often hesitate to call WordPress a ‘framework,’ though I’ve done this before. Honestly, I view it more as a platform.

After all, most frameworks don’t provide you with a fully functioning application right out of the gate. Instead, with frameworks, we’re typically responsible for the following:

  • Designing the database schema
  • Creating the database
  • Setting up any administrative backend or dashboard
  • Setting up the presentation layer
  • Implementing and user-level authentication (and roles that may be needed)

With WordPress, you get most of that out-of-the-box.

Of course, it’s not without it’s tradeoffs. For example, you’re given a fixed database schema, and there may be things you need to add, remove, or modify in order to abstract WordPress away from the end user.

Though I consider myself to be early in my career, I’ve been around long enough to hear developers claim that they want to be able to do things faster (such as setup the underlying database), but that they simultaneously want more control over things which, as far as I’m concerned, comes at the expense of time.

So there’s definitely a balance to be struck.

An Attempt at Pragmatism

From a pragmatic standpoint, I tend to believe that we need to use the best tool for the job, but the “best tool” can vary based on the number of tools with which you’re familiar. Furthermore, I’m of the mindset that we should go deep rather than wide when learning our set of tools.

To that end, it could take years before we’re more than competent and capable with a variety of toolsets.

So in an attempt to be pragmatic, part of me is apt to say that if you have an idea or a gig that you’re tasked with building, and you can do it in WordPress, then go for it; however, the other half of me fears that when WordPress is your hammer, every potential web application looks like a nail.

Then again, can’t this be said about any language, framework, or platform?

For now, I think that whether or not we choose to use WordPress as a core for all of our applications is a decision that’s based on whether or not we – as developers – have another alternative with which we can just as easily, just as quickly, and just as cost-effectively use to solve a given problem.

I view this is a strong opinion that’s weakly held, and I’m looking for other opinions.