Should I go static? An argument for switching to a static site generator.

March 17th, 2019 - Blogging, Tech, Dev, Viewpoint & Static Site

I’m planning to write a little guide on how you can host a static site effectively, but it got me thinking that first I might wanna write about WHY you’d want to use a static site in the first place. Here goes!

So, why bother with static? Isn’t WordPress amazeballs?

SURE it is, half the internet runs on it, but that doesn’t mean it’s the best option for a lot of blogging use-cases. A few reasons I think that WordPress is usually overkill for blogging:

It requires a database. This means you need to start caring about database backups (you don’t wanna lose all your content one day do you?), which means either paying for automated tools to do this, or figuring it out yourself. And sure, there are fully managed WordPress services these days, but this leads to both more expense, lock-in and less flexibility.
It requires more computing power (both RAM & CPU). Whilst most micro virtual private servers (VPSs) can handle WordPress to some extent, it’s unlikely to be super-performant on the smallest servers.
Which leads into scaling: Making your site able to handle a large number of page-views is going to be a LOT more expensive with a dynamic solution like WordPress than a static one. Realistically you’re going to start thinking about how you can cache things which also ends up leading to a more complex setup.
Security: a simple Nginx install that only serves flat HTML is orders of magnitude more secure than a dynamic program that does lots of complicated stuff with user input (WordPress has historically had issues in this areas, but this applies to any dynamic application to be honest). Heck, you could even put the files on something dumb like S3 and host it from there. This way the security of your site is essentially as secure as your hosting platform (and things like AWS are pretty good at security these days).
Maintenance: If you’re running on a VPS, you’ll still need to think about OS upgrades, but gone are the language/library upgrade issues (like upgrading to the new version of PHP that breaks your theme). Much simpler to keep things technically healthy.
Site speed: both in the time it takes to get all your content to your users, as well as the time it takes their browser to churn it into what they see. Static sites will respond with their content way faster than dynamic ones, and the normal plugin-generated WordPress solution is usually WAY more bloated than a simpler purpose-crafted approach *.

But I don’t care about any of that stuff, and WordPress seems easier.

So, WordPress is definitely easier to get setup. But as I just explained, it’s definitely not easier to operate. Also, is it better for your readers? They’re likely far more interested in a pleasant and fast reading experience than waiting for your slow-as-hell blog to load. If you’re interested in having happy readers who want to come back, then you really want to care about the experience they’re having on your blog.

This is one reason I think static sites are better for readers. But I also think they’re better for writers.

I mean what is blogging all about? As I see it, it’s writing content (probably quite a lot of it relatively often) for easy consumption by a large number of people.

Writing your words in a WYSIWYG editor in your web-browser is easy to get started with, but it often becomes frustrating in no time at all, especially if you’re doing a lot of it. Think about some of the things that anyone who has written web-content via their browser has had to suffer through:

Because browsers now use a millionty gigabytes of RAM, it randomly crashes out when swithing between tabs, losing all the words you wrote since you last saved.
The weird characters that you just copy/pasted in from word (where you probably do the real writing because you don’t trust chrome) look super weird once you’ve published it, but you can’t figure out how to make them normal in the WYSIWYG.
That link that you’re trying to add ended up being an underlined space character but it was fine before you published it and now you don’t know why.
You have time to kill on the commute and you’re trying to write a post on the trian. And it looks like it’s worked, but your connection just dropped when you hit publish and, once more, you end up having to re-write half of it.

These are some of the problems that markdown-based static-sites solve. You can write it with a phone app, an app on your laptop or just with a plain text editor on your machine. It’s simple, it’s clear, it’s offline. And, as the normal approach is to stick your static-site content in a version-control system like Git, then it’s also rock-solidly backed up. You’re not going to lose it to some weird hosting error that happened one sunday night because the provider you chose for cheapness (because performance issues remember) decided losing your database wasn’t a big deal when they updated something.

After moving to a MarkDown-based writing setup a while back, I find it a million times more writer-friendly than CMS WYSIWYGs. And the upside of this is that a good writing experience is likely to lead to you writing more. Which means more blog content. Can’t be bad right?

Ok, so I’m keen, I think a static site makes sense but why do I need a static-site generator?

Static sites CAN be as simple as some html/javascript/css that you modify manually and stick in some hosting somewhere. I mean we did it that way in the 90’s and nothing went wrong right? And if your site is something super-simple like a portfolio with 1 or 2 pages then this is very likely the right way to go.

However, if you’re aiming for something like a blog with quite a bit of content, then it’s going to start getting very tedious very quickly. You need to edit all your content in HTML for a start. This’ll make it hard to migrate in the future as well as being far more laborious than normal text or markdown. You’re also going to need to think of something like server-side includes to be able to reuse bits of HTML like headers, footers, sidebars etc. And every time you add a new post you need to remember all the places it needs to go: index page, any sort of blog-roll, category pages, sitemaps, and the list goes on.

When you think about it, the ball-ache involved is going to get you quickly looking into how you can automate all these annoyances. This automation is exactly what static-site generators are for. Problem solved :D

Caveats

* This doesn’t mean that ALL static sites are better than ALL WordPress sites, or even that a WordPress site can’t be configured to be almost as performant as a static-site alternative. I’m just pointing out the average output of both these two tools, and it’s generally a LOT easier to get instant performance out of a static site than it is a WordPress one.