After my recent dismissal of WordPress, I wanted to elaborate a bit on why I think it’s unfortunate that a tech-savvy person should prefer it as their content management system. The summary is this: if you’re comfortable in command line, there are much better tools for the job. In saying this, it’s not just WordPress that I’m criticizing. I’m also criticizing Drupal and Moveable Type and probably most PHP frameworks. I’m targeting WordPress in particular, however, because it’s the most popular one in use today and it’s the one I’m the most familiar with. I’ve spent thousands of hours writing in WordPress, developing WordPress themes for individuals as well as for the commercial marketplace, and even developing one open source plugin. In other words, I know the platform pretty thoroughly - not as much as a core contributor would - but well enough to build anything I want. And with that expertise comes an opinion. I could write on this subject in lengthy technical detail but for now I want to keep this discussion as high level and brief as possible.
As a way of illustration, WordPress is similar to a fast food meal in its value proposition. It delivers way more calories than you need, it’s very affordable, it’s fast to work with, it’s very popular, and it’s despised by the elite. In the same way that people who have the time, knowledge, and money to home cook their meals despise fast food, the people who have the time and knowledge to use a customized content platform despise WordPress.
The thing is this. If you aren’t a good cook and have no interest in learning how, and you don’t mind being obese and dying of a heart attack, then fast food is actually a really great option. The food is gross but if that’s all you’ve ever known, then you won’t feel the burn. Translated into WordPress terms, this means that I still recommend the platform to anyone who isn’t tech savvy and just wants to be able to publish content on the web easily. WordPress is great at that. There are just too many tradeoffs compared to better tools that I don’t recommend it if you have the technological ability to use something else.
WordPress is very complex and it aims to be even more complex in the future, which means you shouldn’t use it for simple projects. Using WordPress to power a simple blog is overkill. WordPress is usually the wrong solution to complex projects too, because you likely have the wherewithal to spin up a custom solution that’s better tailored to your complex needs than WordPress’ kitchen sink.
Then there are the subjective reasons I don’t use WordPress.
- I really don’t like how Matt Mullenweg treats the WordPress community and his philosophy that software should be open source. I disagree with his bullying tactics and I disagree with his philosophy in general. He’s an irksome person, and I don’t like using stuff that’s run by irksome people.
- Working on a statically generated site just feels better. I get to write everything in my code editor. And then when I’m done, I don’t select and copy and paste that into a different application. It’s already where it belongs - in a file. The job is done. I just commit and push. It’s lightweight and fast and it’s perfectly suited to the Micro format. If I’m writing something super short I’ll sometimes even use Vim within Terminal. I put a new piece of content on the web without ever leaving Terminal. You just can’t easily do that with a bloated system like WordPress.
- If given the choice of configuring things via form elements such as checkboxes and dropdowns versus doing it in a file via Yaml syntax, I will choose Yaml every time.1 Everything in WordPress is form based, and everything in a static engine like Jekyll is Yaml based. Yaml is cleaner and faster. You can search it quickly. You can copy and past it and share it with a friend. It doesn’t have the weird bugs that inevitably crop up in forms at some point or another. With WordPress, every time you want to specify whether a post is a Micro or a Macro for example, you have to interact with a form element. It’s much more beautiful when that occurs in a static Jekyll posts’s front matter via a single line of Yaml.
Are there drawbacks to a static site over WordPress? Let’s look at the common complaints:
- Static sites take longer to publish. I’ll admit this is true. It might be a few minutes from the time you commit and push a static site’s change to the time that it’s viewable online. It depends on how many articles your site is and how complex your build process is. Maybe this is a problem for some people but it’s not for me. A couple minutes’ delay is fine. If what I’m wanting to publish is so important that it has to be instant, I need to consider using a different technology stack entirely from either of these two. Something more like Twitter, with web socket integration.
- Static sites aren’t as customizable. Take a look at Drinking Caffeine and tell me that that’s really true. I’m doing a lot of custom stuff on here - stuff that would take time for a WordPress developer to mimic, in fact. If you think static sites aren’t customizable, what you’re really saying is that you haven’t taken the time to learn how. Now I will grant you that you can do more with WordPress than you can with a static site but it’s rare that you see WordPress taken to those limits. The overwhelming majority of people who are afraid a static site wouldn’t fit their needs would be pleasantly surprised.
- Static sites aren’t as consumable. It’s true that we’re seemingly moving towards a world where every site should conceivably be consumable as a service, but right now the one and only actual real life need of a content site in this realm is RSS, and a static site’s RSS is just as good as a WordPress site’s RSS. It’s true that if you required, say, some paginated results in JSON of a static site’s posts that this would get tricky. But I really don’t ever see this being a realistic resource for a content site to need to offer. Maybe I’m wrong, but I just don’t see this happening.
If heretofore you’ve been using WordPress and you’re okay with using command line, go check out Jekyll. I think you’ll be blown away by how refreshingly different it is, and I don’t think you’ll ever want to go back.
- It’s an aside but this is why I like the IDE settings in VSCode and Sublime over the IDE settings in PHPStorm. The latter is based on GUI form elements, while the former are based on JSON objects. ↩︎