From Dynamic to Static

Tech Talks

This journal has been inactive for a long time. Too many things happened, too little time to sit down and write. So the usual “Life Happened™” is basically the main reason. Also the convenience of byte size conversation on Twitter is making writing more than 140 (soon to be 280) characters looks like a Herculean task.

I am not about to abandon this journal, I was tempted to write on Medium but again, time is not being the best of friend nowadays. This journal is an artifact of my life, a part of personal evolution so it will be a shame to just abandon it and let it bites the digital dust.

Problem with CMS

While I called this place as a journal, it is in a technical sense, just another blog. As a blog, it relies on CMS to maintain and make it works. Wordpress has been the engine of choice for this journal’s CMS and it has been working out great for some years now. The problem with CMS is it is a system. A system needs some moving parts to function properly and moving parts mean maintenance. While CMS like Wordpress is easy to setup and use, it needs constant maintenance as in updates, checking for vulnerabilities and so on. For a dormant or at least seldomly updated blog like mine, it was a pain to updates things just for the sake of being safe. Would it be wonderful to just take the content out of the system aka. stop being created dynamically by a CMS and make the content static[1]? Of course!

Here comes SSG

SSG or Static Site Generator has been on fire for some years now. I am a bit late to jump on the wagon here but I am happy I made the jump and learning so much while doing it. Basically SSG is a piece of application that compiles all the content, which organized specifically for that SSG, and creates a fully working static website. In the world full of JavaScript wonder, “static” does not mean it just sit there do nothing except rendered the content to browser, it could have some interaction too but runs on client-side aka. user’s browsers.

It does not mean SSG will replace CMS though, both have their own quirks and perks. I found out SSG works best with documentation websites, online books and seldomly updated blog like mine. Put it in other words, content that once set or written, it will rarely change. However, updates are still possible.

Which SSG?

There are many SSG in the wild nowadays, the most popular one is Jekyll which popular among developer because its close relation with GitHub. It is the engine behind GitHub Pages[2]. It also run on ruby, which is one of my favorite language. It is also very easy to implement, not to mention the availability of Wordpress to Jekyll importer plug-in. Everything was awesome until build time… I have 600+ entries and the compile time was in minutes, not too bad if I am already production cycle but since I also want to change the looks and else, I want faster compiling time. Then there is Hexo which run on Node. Sounds interesting, but as much as I like and utilize Node at work, I always find setting the right environment for Node is not a simple task - especially since I run multiple environments (macOS, Windows and Linux) right now. Now before anyone pointed out I can easily utilize Docker to make it work between environments, but I want something that run natively in all environments (In the end I did utilize Docker to make my setup work in Windows, go figure)

Then Ariya mentioned Hugo which run on Go, something I never have a chance to learn/try, but running as a binary which mean I do not need to setup the right environment for it. Sounds good. It also said to compile fast and that actually was an understatement, Hugo is blazingly super fast. So yes, Hugo is the Go.

From WordPress to Hugo

I will write longer entry about the migration, it was not as rosy as some articles mentioned but it manageable. Turned out if you are already using [Markdown](https://daringfireball.net/projects/markdown/ "Markdown) for half of the content, the exporter could freak out. Some tweaks were needed here and there but as I said, it manageable.

I also plan to write about workflow. The usual step on using WordPress is very simple: login, write something then post. With SSG (Hugo in my case), it is different if not a bit techy. Thankfully, I already know about source control, in this case Git, so the learning curve is not too steep. I also learn a lot about Continuous Integration which is not a requirement to utilize Hugo but will make the workflow easier. Especially since I use Firebase as hosting right now (I used Google Cloud to host my WordPress blog previously, running the Bitname WordPress. Since I have a very low traffic - thanks to the lack of content, the monthly billing was miniscule).

Those are the plans. I might write them soon if I can find time or not writing them at all. We’ll see.

Epilogue

I achieved my goal with this migration. I created a whole static website that I could easily copy and move around without setting up database or any of those things. This journal is a perfect project to experiment with. Along the way, I also learned about SSG, Go (Go Template specifically), CI (Continuous Integration) and other various cool things. The journey was worth it.

  1. Static in this sense is plain HTML with some CSS and JavaScript for looks and interaction. In general, it will only have front-end elements and not relied on back-end to generate and manage the content. ↩︎

  2. GitHub Pages is a free hosting provided by GitHub. It’s free as long as the content is static and the source codes are available publicly on GitHub. It also have some space and bandwidth limitation (It’s free! What do you expect?) ↩︎