Wordpress Vs Static Websites

I watched a lecture from “Clean Coding” author, Robert C. Martin (Uncle Bob), recently. He was talking about making a website with his son that used flat text files as storage, instead of a database. At the same time I was moving this website from WordPress to GatsbyJs, i.e. from a database to flat markdown files. Uncle Bob’s conclusion was that for his project with his son, text files were just as good, if not better than a database. The difference in using flat files or a database really shows the differences between WordPress and static websites.

My Coding History

I have history with using text files where a database would typically be used. In the early naughties (around 2002/3, I believe) I was helping someone redesign their website. They needed a guestbook or simple comment system on some pages. At the time, we discussed whether to use a database or not, and we decided that using flat text files was the best solution for the comments.

• We liked the simplicity of it, we didn’t have to set up a MySQL database and make sure it was secure.
• We liked the fact that it seemed like the alternative, non-standard way of doing things.
• We liked the portability of having the entire site in file form.

WordPress

WordPress is the #1 way that websites are delivered on the web. Something like a third of all websites use WordPress. While it may have started out as an easy way for techy people to publish websites, these days anyone can have their own WordPress site either through WordPress.com or with the easy setup wizards many hosting companies have.

All you do is create a database with a user and WordPress does the rest. Pretty much everything is stored in the database. As long as the WordPress blog can speak to the database you can post, and the website will work normally. You are also able to use any number of plugins that are written for WordPress, which will typically also have access to the database too.

This is all wonderful so far. But, as time has gone on the WordPress ecosystem has become bloated. It is no longer something for techy people to use HTML tags in their posts, the post editor gets less and less techy with each new release. As more and more features get added to make everyone’s life easier the codebase gets bigger and bigger. The more popular a blog becomes the bigger the database will get from all the posts and other activity.

All this can make a WordPress blog quite slow, even with PHP version 7. The next major release of PHP, PHP8, may be even quicker, but I do not know how much quicker it will be for a WordPress blog accessing a MySQL database.

Modern Standards: Need for Speed

We all want to be the best, or at least be average, or above average. But, when we look at our large WordPress websites on Google’s Lighthouse we see that it is very slow. The more we post, and the more effort we make the slower it gets.

For anyone wanting to rank highly on Google they will immediately become downhearted on seeing the very first gauge, performance, of Lighthouse.

There are things you can do to improve this: get better hosting, a better database, optimize, caching, etc but there is only so far a mere mortal can go with this. Exactly how much website performance matters to Google, I do not know, but anyone striving for perfection is going to be disappointed.

Static Websites

The solution to having to spending time accessing the database on each page load is to have all the pages pre-built and on the server waiting.

When everyone learns HTML for the first time you get your text editor, and you make your first HTML page, then you make another page and link the two together. This is great, but the more pages you get the harder it is to create a system that links all the pages together nicely. And, what happens if you ever want to change the styling of the website? You either have to use something built in to your text editor or IDE, like Dreamweaver templates, or you’re in for a hard time.

This problem is originally why people used PHP templates and databases, but now the modern solution is a static website. Similar to a backend website, the static website can have a template and knows where all it’s pages are and so can join them all together. But, unlike a PHP website the static website does all the hard work on the developer’s machine and by the time it is uploaded to the webserver every page is already pre-formed.

This website is built with GatsbyJs so instead of using HTML tags we’re using a shorthand in the form of Markdown. This means that we don’t have to type out all the tags, but even creating a post in markdown involves knowledge of markdown code, unless there is a text editor that generates markdown from WYSIWYG. Markdown is not hard to learn, but it is different to Microsoft Word so that might be a barrier to entry.

The beauty with GatsbyJs or VueJs is that they are built with the language that most people learn right after HTML so that they can breathe a bit more life into their websites: javascript. While you do not have a backend, you still have all the frontend functionality that javascript brings.

And, even then, you do really have a kind of backend functionality on your development machine, but that backend processing is exported into a frontend-only version that you deploy.

Modern Development

These days everyone knows that they shouldn’t be re-inventing the wheel: it is not efficient. As such, most websites are not just a heap of code sitting on a server, they use different APIs for different functionality. This is perfect for static websites because it means if we need the user to be able to interact with our website we can add that functionality with an API. For example, this website uses an API for the contact form.

This means that the website is completely static and does not need any backend functionality whatsoever, therefore we don’t need a fully functioning webserver that needs updating constantly. A WordPress blog can live on the cheapest AWS EC2 hosting (AWS Lightsail) which is a few dollars per month whereas a static website can live on AWS S3 which is much cheaper, and almost free. Amazon get their money in other ways, so the deal is not quite as good as it looks from the hosting alone. But even so, the net result is that you’re potentially saving money, do not have to worry about security as much and have a lightening fast website.

The static website is also perfect for using Git and portability because absolutely everything is in a text file and can be stored on Git. You may have sensitive information like API keys that you don’t want in Git so you can still use an .env file or equivalent. And, you probably don’t want to store a lot of images in Git, so there are different considerations with images and other media.

From what I’ve seen so far deployment of static websites tends to be with the commandline. If markdown is one barrier to entry, this is probably another.

Conclusion

All this talk of text files, APIs, Git and deployment reminds us the selling point of WordPress: anyone can use it to start publishing to the web. Once set up, WordPress has a user-friendly admin area you login to to post and check out the comments. As soon as we start talking about text files and static websites, we’ve gone to the other end of the spectrum, and we’re publishing our thoughts with something that will take anyone a while to get used to. So, static websites may not be for everyone. Maybe they’ll evolve, just like WordPress has, and there will be non-techy flavours of static websites that anyone can use, if they do not already exist.

Update: 24th July 2021

The compromise to having either a static website or a dynamic WordPress website would be to combine the two. If you use the WordPress admin area for a backend then export the posts via GraphQL you are able to import posts into a Gatsby front end.