Lately I’ve been concerned about static site generators. After using Jekyll and then Hugo extensively for a combined 2.5 years, I’m seeing things in new light.
First though, going from WordPress to Jekyll and Hugo is really popular. Here are the upsides of a static content generator:
- It’s cheaper. You can host on GitHub pages, which is free.
- It’s safer. A site that is nothing but
.htmlfiles can’t be hacked, unless permissions are wonky.
- It’s geekier. There’s a higher barrier to entry because it takes more knowledge than running a WordPress site. The exclusivity appeals to nerds with an ego. If we’re honest with ourselves, few of us who write software for a living are immune to this appeal.
- It’s faster. There’s nothing faster than running a static HTML site.
- It gives you version control via git. If you have a deploy process set up, pushing to your master branch is how you deploy a new blog post, which means git is a core part of your workflow.
But! But. There are downsides too. They’re a bit less tangible but they wear on you after a while. Let’s look at them.
- Architecturally, database-driven design is superior to file-driven design. Marco Arment argued this point on the ATP show a while back. I disagreed with him at the time, but as I’ve gotten more experience and understand the nuances of the two systems, I’ve come to realize he’s right. Chris Pearson recently confirmed this during a Periscope episode. He argued for the superiority of a WordPress theme system being database-driven instead of file-driven. Thesis was built atop the database paradigm. It requires a different way of thinking, but it’s better for a few reasons.
- Database-driven design gives you better flexibility. If you want to change the date structure or permalink structure of a static site’s posts, or if you want to introduce a new property to a post type, it’s a huge headache. You either have to be a regex ninja or make a lot of manual per-post changes or introduce confusing conditional logic in the render template. All of this is easier in a database-driven design. Same goes for complex things like search and per-month archive pages. Those things are a pain in static site generators compared to WordPress, and sometimes simply impossible given the constraints.
- Similarly, database-driven design ensures maximum repeatability, whereas file-driven systems contain an innate amount of redundancy. If you’re having to repeat yourself a lot in a database-driven architecture, you’re doing something wrong; whereas in a file-driven architecture, you often don’t have much choice. For example, you often have to loop through a global list of posts and manually cherry-pick the ones you’re after for a given view, rather than just start out with the correct data like you could with a MySQL query.
- Every time you do a new deploy in a file-driven system, you have to rebuild the entire website. That gets incrementally slower as you introduce more and more posts. Hugo is about 10x faster than Jekyll since it’s built in a compiled language (Go) rather than a scripting language (Ruby). Still, there’s a cognitive overhead in knowing that you’re slowing down the system with every new post you create. Database-driven designs are immune to this. Yes, there’s a slight performance cost to increasing the number of rows in the
wp_poststable, but it’s infinitesimal compared to increasing the file count in a file-driven system.
- Related, every time you write a new post in Hugo, you’re creating a new file in a flat directory. Pretty soon you have hundreds or thousands of files. This just feels wrong compared to having them elegantly tucked away in a paginated database table. Feelings matter.
- WordPress has 28% of the global market. How much does Jekyll have? How much does Hugo have? A lot less than that. I’m not worried that Jekyll and Hugo will go away tomorrow. But they’re always going to be a fringe technology in the grand scheme of things. Building an empire on a fringe technology is a bad idea. I’ve seen it go awry too many times. And if I had to guess, WordPress will outlast these static content generators, ultimately, from a sheer numbers and sustainability standpoint. I want to use a platform that’s going to be around in 40 years.
- In a similar vein, setup and configuration with a static file generator has a lot more pitfalls and obscure dependencies. It’s harder to get Go compiled and running than PHP and MySQL, simply because PHP and MySQL are more popular. You also have to support a deployment pipeline with a static site. I’ve personally found that the ongoing maintenance of a regularly-deployed static site is higher than the ongoing maintenance of a WordPress site. That is something I would not have expected. Live and learn.
- Getting your content from WordPress is a lot easier than from Jekyll or Hugo. That’s because it’s easier to get importable data out of a database than it is from a collection of markdown files. I like systems that are easily exportable. Because of this, switching to a file-driven system seems like a step backwards in time, not forwards.
- Bonus round: using a file-driven system means you don’t get to use Mars Edit to write your stuff. You’re stuck in Terminal and VSCode, which wouldn’t be a problem except that you’re in there 8+ hours per day already. Never underestimate the appeal of using a different set of equally elegant tools. It provides a mental break. That’s incredibly important. The most enjoyable tools are those dedicated to the job at hand.
On the whole, the cons of a static file generator seem less tangible than the pros. But I’ve been giving a lot of hard thought to this over the past few months. Intangibles matter. As a result, I’m seriously thinking about switching from Hugo to WordPress. Googling around, I’m not sure anyone’s done this yet. If I pull the trigger on the switch, I’ll be pioneering new ground and documenting the process as I go. Stay tuned. 😎