Gillius's Programming

Site Redesign With Jekyll

04 Aug 2025

Welcome to the newly redesigned gillius.org, built with Jekyll and CSS by hand, based on some CSS resets I found online.

This has been a long time coming – I last moved to Movable Type Open Source edition in 2011 and the last major CSS design I did in 2006. I’ve been working on this for some time and there’s still more updates I’d like to make, but it’s far past time to cutover at this point.

Some of my very old content has been removed such as C++ and Allegro tutorials and articles from the late 90s and early 2000s which is very out-of-date.

Keep reading for more details and my reasons in picking Jekyll.

The Issues

The Movable Type issue was the most pressing concern to deal with. The open source edition was discontinued in 2013, so it has been unsupported for a long time. I used .htaccess rules to completely block its usage to prevent any security issues, opening Apache-authenticated access only long enough to make an update. Since I didn’t post often in the past years, that hasn’t been as bad as it sounds, but now the code won’t even run anymore with the modern Perl configuration preventing even critical changes like updating my resume.

The other issue with the CSS and HTML layout from 2006 was showing its age and woefully inadequate for mobile viewing. Keep in mind the iPhone did not exist until 2007 so mobile web design wasn’t mainstream at the time.

The New Solution - Jekyll

To solve the problem with static site generation, I needed to find a new solution. I had the following requirements:

Nice-to-have:

Non-Requirements:

I searched for static site generators and quickly narrowed down to two options: Hugo and Jekyll. I kept flipping between the two for a while, even building a prototype in each, before I settled with Jekyll. So far, I’m quite happy with that decision.

Hugo is the most popular solution now, it’s known to be very fast, and it looks like it can do anything I’d want a static site generator could do, while Jekyll is more limited. Hugo also has a very active community and update cycle while Jekyll’s frequency of updates and community appears to be in decline. However, every time I tried to use Hugo I found it overly complex while I found Jekyll very easy to use and for my infrequently updated and simple site. I just couldn’t justify the investment in Hugo even though it is more capable. Additionally, Hugo’s speed didn’t matter in my case, as with Jekyll, my entire site generates in about 0.3 seconds. It also helps that I switched my primary desktop from Windows to Linux (a whole post coming on that soon), so Ruby was trivial to install.

Both solutions are better than Movable Type (MT) because they are not tied to a company with a paid / open source split. Unlike MT they don’t require any code running on server (MT written in CGI/Perl) or database (MT used MySQL). Since all code runs locally, even if the product is discontinued then at least I don’t have potential security issues from unmaintained CGI scripts.

Therefore, with Jekyll my biggest concern is what will the state of the project be in 2, 5, 10 years from now. Given that it is a completely local tool, I can safely run it even if it never gets an update again. Even if it does, as it’s used for the very popular GitHub Pages, I would suspect there would be ample tools to replicate Jekyll’s behavior or transition away.

In terms of “nice-to-have”, I was surprised that neither Hugo nor Jekyll worked well in IntelliJ. I was very surprised since it works well with all other frameworks I’ve tried. IntellJ is not a natural choice if all wants to do is HTML/CSS editing, but since I subscribe to it anyway for Java development, it’s still my primary IDE.

Lastly, my choice of Jekyll over Hugo also included one aesthetic advantage, which really bugged me. My URLs on gillius.org largely do not end with a slash except where I gave up fighting Movable Type on it (for example https://gillius.org/games and not https://gillius.org/games/). I get the trailing slash makes it easier to deploy a static site by having every file be index.html, but given that I am hosted on Apache I can configure content negotiation properly to serve games.html as /games and not break any existing links. Hugo fought me incredibly on this point, but it was much easier to get Jekyll to work this way including in its local development server.

Another nice site I found is Turndown, which turns HTML into Markdown. I used it to convert my “simple” HTML from static pages I hand-coded in HTML 20+ years ago into Markdown which let me edit them more easily.

For importing the old blog posts, I used the jekyll-import Movable Type importer. I didn’t want to import resources/pages, only blog posts so that worked fine. Resources and pages I brought over manually since I wanted to trim things down a lot.

For those interested, I used the following plugins:

The New CSS - “Vanilla”

During the same time I was deciding on what static site generator to use, I was also thinking about style frameworks as well. I didn’t have a strong desire to create a design from scratch, so I started looking through various Hugo themes. Again, I ran into the complication when I wanted to do anything my own way. I wanted to start simple. So then I shifted to, let’s just create a plain HTML and CSS in one file, so I can develop without worrying about framework. I thought I’d need something like Bootstrap. But again, I found myself fighting with getting it to be how I wanted. Frameworks like Tailwind are nice, but I didn’t want to introduce a build system and not having memorized Tailwind, but knowing CSS properties, I just felt like even Tailwind was more complicated than it was worth. If I did all-day, every-day frontend development, definitely these make sense, but as a part-time, it’s just another thing to learn on top of CSS.

Finally, I took the plunge to just start with plain CSS. I thought that would be crazy at first – “reinventing” the wheel. But it really fit the simple needs of my site. I was surprised at how little CSS I needed to get something reasonable. It also fit well with Jekyll’s philosophy since an HTML file is just a site and we don’t mix design and functionality together like a Hugo theme does. And, it’s also one less framework to worry about pivoting or disappearing in 10 years. With the nested selectors and CSS variables being part of the stock CSS spec now, I felt no need to use something like SASS even. I kept everything as simple as possible. For my simple site with 1 developer and low change frequency, it’s great.

Right now even with comments and whitespace the site’s CSS file is 7.6kb and 5.2kb for the “lightbulb” theme used by the syntax highlighter.

Now, I did start with some CSS resets. Actually, I had inspirations to draw from as a starting point:

Future Steps

There’s still plenty of work to be done:

Comparison to the Old Site

I left up a copy of the old front page at /old if you want to view it.

Laptop (1280x800) view before and after (click for full size):

Old website at 1280x800 New website at 1280x800

You can also see the issues with the mobile view on the old site as rendered by Firefox on a Pixel 9 Pro XL:

Old website mobile view New website mobile view

Desktop (1920x1080) view before and after (click for full size):

Old website at 1920x1080 New website at 1920x1080