As efficient as WordPress is nowadays, it's not always a silver bullet to every blog kind website or at least for me. For the past week I found myself thinking, why am I using WordPress for a very unique project.
These are my thoughts on WordPress and why I wanted my other co-workers to abandon it for those kinds of websites.
I feel like this post should have been named "When not to use WordPress"
But first, let's look at the powers of WordPress and why you might need to use it.
The Pros of WordPress
- User-friendly CMS: A feature that made WordPress popular are it's CMS capabilities. Editing pages, uploading new content, a nice editor for bloggers. WordPress makes it so easy to organise content without much knowledge needed.
- Plugins: WordPress has been used for far too long and people have been making all sorts of plugins to make it easy for developers to extend WordPress functionality.
- SEO: With all the SEO plugins available like Yoast, it's very easy to optimise your website without any knowledge.
- Less administrative tasks (On the Server-Side): With WordPress, you don't need to worry about upgrading your stack versions. You just click a button and everything is done for you.
Now, knowing all those pros of WordPress, are there any legitimate reasons not to use it?. Let's find out!.
Keep in mind, if your project is sorely for blogging, then keep WordPress, there's no other better system. But if you want more, then I advise you to build a custom thing
- What made me rethink my stack
- WordPress REST API limitations
- Speed & Page Size Considerations
- Flexibility in terms of code organisation, and functionality
- Doing too much for me
WordPress REST API Limitation
I'm currently building a zero-rated news aggregator that happens to also contain a marketplace. The news aggregator and marketplace also have to have an android mobile application, so the REST API is an important piece of the project.
In fact, the mobile application is the most important piece of the website and so the REST API plays e.an important role
WordPress REST API is opinionated, it assumes a blogging intent and therefore all the endpoints are already built for you, however, it's rarely the case where you need all the data that WP REST API returns and that gives your server an unnecessary strain of serializing the data that you don't need.
The other case is when you want more custom fields that are not returned by WordPress, this means that you have to extend WordPress and inject those fields manually and thus giving an additional unnecessary strain on the server.
Imagine if your REST API endpoints can only return the exact data that you need. And you can control the serialization and deserialization of your data. I imagined this would give a huge speed to the server.
Speed & Page Size Considerations
As WordPress assumes a blogging intent, it comes with unnecessary generic code. Even though you can customize the site and remove the code you don't need, WP codebase is soo dependent on each other, if you remove jQuery, for example, that means the comments reply function is broken, and if you remove wp_head() from your header then every other plugin you install won't work as perfect. This is just an example but I imagine there are many such interdependencies in the WP codebase.
If page size and speed are soo important for the project, isn't it a good idea to just build a custom system bottom up with size and speed in mind?.
Flexibility in terms of code organisation, and functionality.
While WP can be customised, it's very hard, for me, to organise my code and functions in the way I want. One can argue, that WordPress's code organisation is the best, as in tried and tested. I find it limiting. It boxes you and retards creativity.
Doing too much for me
From offering a ready to use REST API to suggesting my code organisation, WordPress does so much and does not allow the developer to go outside the box and experiment. It removes the developer from the need to inspect every aspect of the application. This is an advantage, but not when you have many constraints in mind, like page size, caching, speed, and general efficiency.
Note: This might be biased because of my love for total control and therefore love for less opinionated frameworks.