Why I have moved from WordPress to using my custom Static Site Generator?

Short Answer, control. The longer one is this blog.
By Apan Trikha at Wed Feb 03 2021


Those of you who either know me or my work before 2018, I created a WordPress website as an attempt to blog and provide my insight on Gaming Industry and Linux gaming which inevitably failed because:

As I'm in a situation where I have some insight in the tech world about things that aren't as often discussed which includes:

I can contribute to some discourses in the tech community so blogging can be a thing, even on a side. But these can be done with a WordPress blog too, so why I'm moving from WordPress to my own Static Site Generator?

First, let's address why I built a static site generator anyways as to some this sounds like something hipsters will do.

Why build a static site generator?

This is where I will elaborate this blog's description as the word "control" means different from person to person. In my opinion, a you have control over a piece of software if you know

These reasons are also why I use Linux over Windows as my main OS since I can create my workflow based on my Linux knowledge and make modifications whenever I feel like without fearing about any legal ramification as opposed to Windows, which is convenient but the scope of modifying the OS without violating the EULA (End User's License Agreement) is infinitely limited.

There are many open-source, libre licenced static site generators in the market but the licensing doesn't change the fact that some of these static site generators have a huge code base at times like Hugo and Jekyll. This isn't a deal breaker at all as learning how a piece of software works isn't something that'll hurt me, I planned to contribute adding AWS support to Godot Engine's GDScript but has been shelved due to not having money to run and test it on AWS. But the time I'll take to learn how to modify these huge static site generators will be still more than learning a new programming language along with a framework like NextJS and implement it.

For the record, I started building my static site generator on 1st February 2021 and I'm writing this blog in 3rd February 2021. Despite my lack of proficiency in JavaScript, NextJS and Web Development in general, I was able to learn how to create a static site generator without all the unnecessary stuff that will taint the reading experience.

If I compare this with using a pre-built static site generator, I need to strip everything out first the build what's needed. This doesn't exist when using web app frameworks like NextJS, Gatsby, Vue, etc. I can implement when I want and need to.

Why moving from WordPress?

JAM Stack

This sounds like a cool and hip thing to you but trust me, it's vastly more practical. But what do these "stacks" mean? In software development, the stack means the collection of technologies used to build an architecture of a software or a service.

What WordPress uses is what we call a LAMP stack comprising of Linux, Apache, MySQL, PHP. To make it work, the pages are rendered from an Apache Server using Linux as the OS, taking content from a MySQL database and all combined into a web page through server side logic written in PHP. This is great if you're creating a website that can change content on the fly. But this is an overkill for a basic blogging site as it over engineers the architecture which could easily be replaced by a static HTML file.

If that's the case, then why not just write everything in HTML? And that's not the practical option, some may prefer I don't. I used to detest dealing with it when back when I got introduced to it in middle school and I still detest it, I want to write it once and be done with it. Fortunately, I'm not the only one who doesn't like dealing with HTML and I thank John Gruber and Aaron Swartz to create Markdown, a markup language that is made for humans not to have seizures while reading or writing. Initially this was done through a Perl script to convert it to HTML but now every major language has a Markdown parser and can be transferred to other markup languages like LaTeX. I used markdown to write my final year presentations and used pandoc to convert it into a beamer presentation. No powerpoint baby! Just write a markdown file and parse it. No need to format everything like a troglodyte and focus only on the content. If you find markdown interesting and want to know, check this guide out.

I know different programming languages but this time I choose to learn a completely alien language, JavaScript. There are two reasons for this:

As about the second point, I'm surprised how fast JavaScript is! This language is insanely fast even on a cheap ultrabook, the pages render almost instantly in my local server. This proved how much developers these days neglect software optimization until we're dealing with the big-tech, because in no way I can believe that this language can create slow software now that I've used it myself.

I also want to extend it with micro services with APIs whenever I want to and JavaScript does that pretty well due to its prominence in the web development industry. So if I want to extend it, I do not need to pivot the project later.

As you're reading, there are 3 most prominent technologies I've touched on: JavaScript, API and Markup language. These 3 form the JAM stack which is now a new trend for simpler websites with more manageable and decentralised architecture.

Those who want to know more about the JAM Stack, you can check their web page.

Faster Page Renditions

Since I have built an application that creates an HTML page using JavaScript by

The pages won't render on the server but one the client's system that is the web browser. After all, the requests are made solely for HTML pages and pruned a redundant process of creating one from the server. It's neither rocket science nor music theory that this process will be faster as the server is not doing any additional computation for the request.

Simple, De-centralised and Portable Architecture

Since these are HTML pages, web crawlers have an easy time finding my website so from a marketing standpoint, this is a plus. Along with that, I don't have worry about the script kiddies trying to get into my site. It's a text file with other protocols divided between the owners of each micro service.

The main content is in Markdown and I have a static site generator that merely converts it to HTML, the core info can be converted into various formats ranging from an article to a website. In case if I want to completely pivot my SSG architecture (which is the worst case), the APIs and content can be easily migrated from one SSG to another, this includes my Content Delivery Network (CDN). Right now, this website is hosted on Vercel, if I want to shift it to GitHub Pages, Netify or Gitlab Pages, I do not need to shell out a lot of money or take a lot of time to rebuild/migrate my website.