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:
- Site template / output format completely under my control; generates code with zero dependencies back to the framework
- Generation of listing and detail pages
- Ability to generate static pages
- Support generation of pages at well-known links (full control of URLs)
- Generation of Atom feed
- A solution that will still work 10+ years from now – I don’t want a repeat of the Movable Type discontinuation
- Minimal lock-in / easier to move to a different static site generator
- Syntax highlighting
Nice-to-have:
- CSS/JS Resource minification / bundling
- hash busting
- Easy to understand and flexible templating language
- Plugins / extensions built in a language that I know
- IDE support for IntelliJ
Non-Requirements:
- Dynamic content such as comments / trackbacks / search
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:
- Josh’s Custom CSS Reset was the base
- I took some things from Vanilla CSS
- Lastly, I used Modern Font Stacks to select a
font-family
that works in multiple environments.
Future Steps
There’s still plenty of work to be done:
- The mobile styling I would consider as minimum viable product (MVP) and needs improvement; possibly a dropdown navigation, but that would require some JS and today my site works even with JS disabled.
- I’d like to consider a sidebar on wide screens with the post/page’s headings for navigation with a “scroll spy”.
- I want to pre-compress files such as HTML, CSS, SVG so Apache can serve them when
Accept-Encoding
is gzip, maybe also support zstd. - Consider minifying/combining the CSS files. However, even before minify and compression the CSS is under 13kb.
- Create a dark theme variant.
- Support client-side searching with Pagefind.
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):
You can also see the issues with the mobile view on the old site as rendered by Firefox on a Pixel 9 Pro XL:
Desktop (1920x1080) view before and after (click for full size):