We recently completed a couple of large web application projects where the deliverables did not include any CMS functionality. That is, they were purely a functionality based web application.
I’ve been reflecting on both of these projects, and how we approached each one for a few reasons:
- Did we make the right choice with the underlying framework?
- Could we have completed the project faster/better/smarter if we did it another way?
- Should The Code Company be working on non WordPress projects
- And if we do work on non WordPress projects, will we end up doing 100 different frameworks in an average manner, rather than doing one framework really well?
WordPress is without questions our preferred framework. However, our team have also worked with CodeIgniter and Laravel. I won’t delve into the detail of these frameworks too much here. Instead, I’m more interested in exploring in evaluating the suitability of WordPress as a framework based on its current offerings.
READ MORE: Digital publishers: if you’re not using WordPress, you’re missing out
When is WordPress the right framework?
I believe WordPress is more than a blogging platform, and more than a CMS, I think it’s a “Content Framework”.
WordPress offers a bunch of flexible constructs that allow you to store, group, link, and work with content until your heart’s content. Being able to rapidly create data sets with taxonomies in the backend of WordPress, with tools like Advanced Custom Fields to allow administrators to modify data in an incredibly short amount of time is a real plus for WordPress.
Not many software packages can let you do this so rapidly. This is one of the things I’ve loved with WordPress from day one. Being able to rapidly get the “grunt work” (boring, repetitive tasks like building admin layouts) out of the way so quickly, and getting to work on the customised functionality of the project. This custom engineering is where the bulk of our projects lie.
Advanced Custom Fields has made this process even faster, being able to build custom admin UI for managing data, and having things like photo uploads or repeaters running so effortlessly is again, a major win.
Limitations of WordPress as a framework
One of the common complaints from both WordPress and Non-WordPress developers, is how tightly connected certain things are. Instead of starting with a blank canvas and building up, you get something half built, and if you don’t want it, you need to actively remove it. Removing things in WordPress or WordPress admin can also be disheartening when you end up using CSS and jQuery hacks to hide elements. It feels like an amateurish and hacky solution, because it is.
At WordCamp San Fransisco last year, Matt Mullenweg spoke to the WordPress as a Framework push, and showed the following slide.
What the above says (to me) is that WordPress is a bunch of low-level functions and code, that you then plugin in on top of that a CMS, a blog, or ecommerce, etc. Meaning you can pick and choose the bits that you need for a certain project. The majority of users picking three or four of the above ‘blocks’.
However, as of today, these building blocks are so closely tied together, so “WordPress” aka the standard WordPress software package comes like this:
So what’s WordPress bad at? It’s bad at only being a framework. It’s bad at just being a CMS. It’s bad at just doing one thing and building on top of.
In the project mentioned above, a lot of horrible code was required in order to get the application to do what we wanted to do.
Here’s an few of the conversations you may have heard among our team:
- Don’t want this here? Oh just use CSS to hide it.
- Don’t want that shown? Just use this line of jQuery to hide it because there is no css to identify it.
- Want that link hidden? Use a filter to intercept the array and yank the item out by doing a string match.
All of these kind of approaches make me feel as if I’ve failed as a developer, and that I’m just as bad as the newbie developer googling for snippets on Stack Overflow to build something. Def
The disappointing part is that these hacky approaches are often the only approach with edge cases in WordPress application development.
How do you choose the right framework?
Which horse do you bet on? This is the hard part.
Do you go with WordPress because it’ll deliver a massive head start on the project and get you up and moving with real data quickly? You’ll be able to have editors / admins / clients inside the admin area very quickly and working away. Sure there’ll be a couple of hacks to get the admin UI going but such is life.
Or, do you go with a more traditional framework, like Laravel, Symphony, CodeIgniter, and so on? Do you spend a bit of extra time building your CRUD interfaces (Create, Read, Update, Delete) but make up the time with greater flexibility because you’re now using your own data constructs and methodologies?
Here is an overview of how I go about it and the questions the team chat through to work it out:
- Can we use ACF and WordPress to save us a considerable amount of time in grunt work?
- Looking forward, and if we use WordPress and ACF for data storage, what might not work? For example, can we query data backwards efficiently?
- Are we going to have to undo more of the WordPress admin than we’ll actually use?
- Are we going to write our own URL routing for all the UI, skipping WordPress admin & front-end theme altogether? (This is a pretty significant one).
How to choose the right agency to build your web application
Thinking through this post, it’s the logical question to ask of someone:
- Are you a web development company that specialises in WordPress development? OR
- Are you a specialist WordPress development company?
If you’re the later, then you really should pass up projects that don’t suit WordPress.
If you’re the former, the risk is that you end up having to support a big list of software packages built on different frameworks, which is a cost your business has to absorb and try pass on to the customer.
For me, I’ve always loved CodeIgniter, and recently one of the team completed a project in Laravel. I really enjoyed it and would be interested in completing another project or two in the same framework. Laravel, from my understanding, is basically where all the CodeIgniter people live, because it’s so much better.
Use the best tool for the job
A mantra of mine is “use the best tool for the job.”
The fact remains that 90% of The Code Company’s businesses “development” revenue is WordPress. Other frameworks, or legacy systems play a very minor part. That is really all it comes down to. I don’t want to build an application in WordPress just because our team are good at it, and it’s technically possible. The best platform should be evaluated without bias and moving forward.
This is tough subject to discuss without sounding like you’re WordPress-bashing, which seems to be a popular sport.
There are a heap of good reasons why WordPress isn’t a framework like Laravel or Symphony. In my view, WordPress do a good job of trying to strike a balance, and over the last decade, their team have taken leaps and bounds in this field.