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.

Category:
Articles
Tags:

Join the conversation! 17 Comments

  1. Whether or not it’s wise to use it as the final application framework, I do think it’s very good for rapid prototypes of web apps.

    • I definitely agree – especially as a foundation for many ideas which we need to test and don’t want to get into big budgets.

      And then if the idea/app/startup/project (whatever you call it) can genereate revenue, customers then I would rethink basing it on WP.

      • And then if the idea/app/startup/project (whatever you call it) can genereate revenue, customers then I would rethink basing it on WP.

        This is not a loaded question – asking purely to hear your rationale as this is something that I think a lot about as well, but why would they rethink on basing it on WordPress if the current iteration of the application is working (and assuming that it can continue to be maintained)?

        • Well I have a good example based on my experience.

          My client requested an app from our company and from the start I said that WordPress is maybe not the best option considering app specification. That is why I have proposed going with Laravel or something like that.

          As the client was pretty familiar with WordPress and he wanted to keep the budget low he really wanted to base it on WordPress. So I did it as requested – its built on WordPress and the app is getting its first clients.

          In June, after 6 months of app being online we will sit down and discuss pros and cons of the “current state”. We will be able to tell whether “WordPress” way is working for us or should we switch to other platform.

          The best thing is that building that “working prototype” on WordPress helped to minimize costs by a half. Thats very important factor for various projects – that they can test the idea without getting deep into the pocket

          • I dig this example – really good points here.

            I’ve been hearing a lot about Laravel recently, too. Seems really cool. Have you happened to try Yii? If so, how does it stack up? I’m interesting in tinkering with a couple of other frameworks and Laravel is on my list.

            • Honestly I never had a chance to dig deeper than some hello world examples, but as my Code Igniter is “kind of abandoned” I’m looking towards Laravel now.

              Also maybe max 10% of my work in last 2 years is not WP related, so I’m not feeling to strong to tell anything about current frameworks state :)

    • I started to respond to this in a comment, but it ended up resulting in me writing about about this topic next week.

      The short answer is that I agree that it’s good for rapid prototypes of web apps, but I also don’t think it has to stop there. After all, WordPress scales pretty well so why should it be limited to RAD?

      Granted, I know you aren’t really saying it should – I’m just tossing that out there (as I have read it before and it seems relevant :)).

  2. Hey Tom

    I’ve talked about this before, but I think WP does have all the essentials for building a web app, however there are scenarios where specific types of apps are better suited to other frameworks. I know if I was building a real time app I would probably lean towards writing in NodeJS rather than WP not because it can’t be done but because of it’s built-for-purpose.

    I think for most ‘client’ projects WP can be used as the app framework, I’ve just completed a facebook app using WP and the facebook javascript API, and while it was successful it was also very slow. I probably should have written it in node or ruby to handle the ajax calls better.

    I think it’s more a mindset though, most developers dont view WP as a framework, they view it as a blog or CMS, and that’s limiting in my opinion. I view WP rather as a framework with several plugins/layers built on top, but just like with other frameworks that can be handled.

    Something I do feel would improve this is the Convention over Configuration principle. WordPress doesn’t have as strict conventions as other frameworks do. (strict) MVC frameworks wont work without following the conventions, while in WP you can get away lumping functionality in themes, and a lot of WP developers don’t even use OO. Part of this is due to the amount of deprecated/legacy code and code design patterns in the core, while other frameworks can get away with a ‘rewrite’ pivot if they need to improve conventions (see CodeIgniter/Rails), I don’t think WP can do that.

    That’s my thoughts :) quite a mouthful, hope that helps!

    • …there are scenarios where specific types of apps are better suited to other frameworks.

      I think this is a valid point – especially about your “built for purpose,” comment.

      To me, the tension still remains that if a person doesn’t know a framework and then has to learn a new framework built for a given purpose, then is it worth the time and effort?

      I don’t really have an answer because I personally think it varies from problem to problem.

      But still, your point remains and it’s a good one.

      …while it was successful it was also very slow. I probably should have written it in node or ruby to handle the ajax calls better.

      Interesting! I’ve not actually read anything about WordPress Ajax benchmarks so it’s good to hear this.

      I’m wondering what made it so slow, though – was it the server-side querying or was it the processing of the data once it was retrieved from the database, or something else?

      Genuinely curious as I’ve done a lot of asynchronous work but it was always for very small pieces of data.

      Something I do feel would improve this is the Convention over Configuration principle.

      Yes – and I love this principle, though my biggest problem with it is when you’ve been working on an app for a year (or two) and a major release comes out that has complete pivoted and/or changed up the way the app layer works.

      You’re either tasked with a major rewrite or you’re left with having to stay on a legacy codebase which basically leaves us at a matter of time before we’d need to introduce some type of major change to make sure it’s up to standard with whatever the latest and greatest is.

      Either way, good thoughts – love what you had to share. Definitely lots to think about.

      • I’ve started to build a web app based on wordpress, all things fits, just that ajax handling is not perfect, it’s slow. As a wp plugin development suggestion, you sould use admin-ajax.php, which deals with all the wp functionalities, but it means almost all the wp resources loaded on request.
        There is a short init, which is quicker, but i realized then i loose on the other side: lack of wp functionality. As also suggested, I tried to load just what i need on short init, but on the end i had to load almost everything so back to where i start.
        But as I see, as others said, the app is a business goal too, keep development costs low, create a MVP, test the app as quick as possible, and i think it’s the wordpress way. If it works, there will be the chance to change the platform.

        • I think you make good points.

          Personally, I like the fact that there’s a “WordPress way” of doing Ajax both on the frontend and the backend. In order to keep things as light (or less as expensive) as possible, I typically try to make sure my request is only pulling back as little data as possible (in CSV, string, or JSON format if at all possible).

          There are also some optimizations that can be done like caching the Ajax library so it’s not quite as slow.

          Regardless, you bring up some valid points – glad to have the comment!

  3. I’ve developed (and recently launched) http://fanboom.net/ which uses wordpress multisite and a very carefully selected and tested suite of plugins from the likes of WPMUdev and other first rate dev shops. Theming is handled ably via Builder from iThemes and there’s been plenty of custom coding and bespoke plugin develop – e.g. for running the contests; but I’ve only had to resort to adapting core files in a couple of places (most notably wp-signup.php)

    FanBoom is now operating as a SaaS and in terms of speed and cost to develop, using WordPress has provided a definite advantage, although making sure the plugins play nicely together in a system such as this has still been a pretty sizeable task. Couple that with the fact that all plugins/themes have to play nicely within the confines of a Facebook tab and you’ve got a pretty complex system.

    Changes made to the backend dashboard have been minimal and more a case of stripping out unwanted elements than adding anything extra. This means that FanBoom retains its WordPress feel. I actually consider this a nice selling point. Countless people are used to using the WordPress dashboard for their blog/website updates, so its nice to be able to port that familiarity over to a system that people can use to create custom content for their Facebook pages.

    As to whether FanBoom ever evolves to the point where i would consider moving off WordPress remains to be seen, but everything is working pretty well to date.

    • Love hearing the story o this app, Stuart.

      Especially when it comes to making sure all of the plugins, themes, external APIs, and custom code works together.

      Best of luck to you, as well – would love to see this thing flourish!

      • Thanks Tom for the kind words, and here’s hoping…

        Looking at some of the other comments here… i’m by no means a programmer. Completely self taught and i’d never heard of WordPress a little over two years ago.

        But the fact that FanBoom has come so far – and i’d consider it a fairly advanced instance of using WordPress – is surely a great validation of the core wordpress platform and the rich tapestry of plugins surrounding it.

        I’ve bought in skills where needed and also run into my fair share of badly put together plugins (my own pet hate is where developers insist on creating their own interfaces rather than making use of native WP). But overall i’d say the WP economy is alive and kicking and a great place to be right now. I’m not aware of too many other applications that take a similar approach to FanBoom (edublogs.org and happytables.com are in a similar vein), but i’m sure there are more out there and no doubt there will be many more popping up over the next few years.

  4. Great post and I agree with it. I think the aspect that is often missed is the “developer profile.” It’s what I call the “invasion of the lightweights” and it’s easy to miss. We’ll jump to “they’re not real programmers” but there are lots of folks today coding up WP themes and plugins who have never heard of OO or finite state machines.

    Tomorrow will always turn the power user into a “developer” because of the tools that are available. WordPress may be a great platform for someone who doesn’t have the skills to use an alternate toolset.

    Know what I mean?

    • We’ll jump to “they’re not real programmers” but there are lots of folks today coding up WP themes and plugins who have never heard of OO or finite state machines.

      Straight up.

      Although I think there are advantages to having a background in programming or computer science, it’s not a full on pre-requisite.

      Besides, as you learn, it’ll eventually become your background, you know?

      Plenty of people have successfully pulled of careers teaching themselves, learning from other resources, and generally just refining their skill set.

      The thing about the WordPress world is that I think you can be a phenomenal theme developer and a poor plugin developer, and vice versa. They are both two different parts of the economy and one plays more towards front end design, the other towards more classical “software development” functionality.

      And I believe that this mirrors a lot of what we’re seeing in the industry.

      The thing is, I think that we’re at a point now where there’s a wider variety of developers, techniques, styles, and paradigms than there has ever been.

      Sure, many of the classical techniques and patterns persist – after all, they are proven solutions – but we’re seeing a lot of new, different ways that software can be written. And as long as that continues, we’re going to see all kinds of developers show up.

      It’s not enough simply to label oneself a developer – you gotta qualify that label.

      • The thing about the WordPress world is that I think you can be a phenomenal theme developer and a poor plugin developer, and vice versa.

        This is where I think we could gain a lot by a more enforced separation of functionality vs display code within WordPress themes. It’s very easy to sort of stumble into writing plugin code while you’re developing a theme, which can lead to a theme that tries to do far too much… I think beginning WordPress developers might be better-equipped to make the transition from themes to plugins and vice-versa gracefully if it was more obvious that they were different styles of coding and had their own separate set of conventions and rules.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.