New blog software

I've started this blog in 2009 with a Wordpress installation. Then in 2014 I re-implemented the blog based on the static site generator Jekyll. This was a great experience back then and I'm still a big fan of static site generators and the way you are creating content with them. However, recently I wasn't that satisfied with Jekyll anymore, and so I started to work on a re-write of the blog system again.

Since roughly start of 2019, this blog is now using Gatsby.js under the hood. Gatsby is also a static site generator that lets me write articles with Markdown files like before. Like jekyll it then creates a bunch of HTML, JavaScript and CSS files that I can upload to my webserver. In the past few months I was also rewriting the website for the Java User Group Görlitz which was also using Jekyll in the past and now uses Gatsby.js too.

In this blog post I will write down some thoughts of why I switched the blogging tool, what I've learned on the way, what is still missing compared to Jekyll and what I'm planning for the future.

Ruby on Windows

Jekyll is a cool tool and I had much fun working with it in the past few years. However, one aspect that was always a pain is the Windows support. Jekyll is developed with Ruby as programming language and my experience with Ruby software is that it's nearly impossible to get it running on Windows - at least not without much more effort compared to other programming languages. I'm not a fan of windows, and I try to get around it as much as I can and so the problems with Jekyll were not that big for me personally as I'm a happy user of linux anyway and Jekyll runs OK on linux.

However, at work I'm either using a windows laptop or a macbook and even on macOS I had some troubles getting Jekyll to work. And also on Linux I had troubles from time to time when I haven't touched the code for a longer period of time and newer versions of Jekyll weren't compatible with installed versions of some libraries. So from time to time I had to completely reinstall Ruby on my machine to get Jekyll to work again. And in contrast to my personal blog the website of the Java User Group Görlitz is edited by other users too and not all of them are using Linux.

For active Ruby developers it might be a totally different story because they know their tools - but I don't. Gatsby on the other hand is implemented with JavaScript and NodeJS. And while this platform also don't have the best reputation when it comes to compatibility of libraries and other aspects, for me personally it's working great. I'm developing software with JavaScript for more than 12 years, and I'm used to the platform and it's tools. And based on the experience from the new JUG Görlitz website which was migrated to gatsby in summer 2018, we have nearly no problems at all with this NodeJS setup.

React

The second argument for using Gatsby was that it is based on React for it's rendering. This gives me the chance to create much more sophisticated UIs and features compared to Jekyll. At the moment this isn't really needed for this blog but during the work on the JUG Görlitz page and also the work on another page for the Digitale Oberlausitz e.V., another non-profit society I'm working for in a voluntary capacity, this was a major benefit because it allows me to reuse components for repeating UIs on the website.

And it allows me to implement new features that were not possible before. And besides this, for me personally React is the best UI library/framework available today and I'm happy to use it where ever it's possible and makes sense.

JavaScript for custom logic

Jekyll is based on Ruby and therefore also extensions are developed with Ruby. This is not a bad thing per se but for me personal this means that I'm not able to create own extensions. Of course, I could try to learn Ruby but I have not that much interest in this language and it would mean a lot of effort just to be able to tweak my website. An example of extensions that I was using is the generation of RSS feeds. I was using a ruby script that I found somewhere on the internet without really knowing what it does. I was able to understand it basic steps but I wouldn't be able to adjust the behaviour if needed.

With Gatsby.js it a whole new story: With Gatsby, everything is build with JavaScript, GraphQL and React - technologies I'm familiar with. And so I was creating my new feed generation by myself in a rather short amount of time (There is an RSS plugin for Gatsby but it wasn't really working the way I'd like it to). This is a totally subjective opinion and again: This argument wouldn't apply to experienced Ruby developers.

Complex content management

Jekyll has a clear opinion of how content has to look like. By default, it takes markdown files or plain HTML as input. You can use plugins to add support for different markup languages but it still has a rather strong emphasis on blogging. Markdown files in the _posts directory will be handled as blog articles. This is cool if all you need is a simple blog and you don't like to adjust things to much. However, if you like to build little more complex content management you will be stretched to Jekyll's limits. This was the case for the JUG website where we have "talks" that actually where posts in Jekyll's terms. But there are other entities like "speaker" and "location" that we haven't modelled explicitly in the old page but had copy+pasted the speaker biography and location description in the normal text of the talk. With Gatsby I'm able to define as many content folders as I want. In the new page we have explicit locations, speaker profiles and only link to them in the talk markdown file. This way the system kind of knows the relation between talks, speakers and locations and you can now see other talks from the same speaker or get a list of all speakers with the number of their talks.

Of course this is still not a professional content management system that stores content in a database. The relation between content types is not enforced by the system itself. It's just a field in the frontmatter of the markdown file and it's the job of my implementation to use this to get additional content. It's not a relational database that enforces integrity of the data. But for our use case it looks like a both flexible and pragmatic approach.

For this blog I also have introduced an additional entity besides blog articles. There is now an explicit notion of "projects" which allows me to link blog articles to their belonging projects. In the future I might add other kinds of content like tech talks I gave or articles in print magazines.

Keep URLs alive

In the old setup I was using a URL schema "/year/month/day/title" which was a bad idea from the beginning. Such a schema may be useful for blogs that post more than one article every day but for me, it's needlessly complex. In the new Gatsby setup I'm simply using "/year/title". However, Cool URIs don't change, and so I wanted to make the existing articles available under the old and new URI. This is done within Gatsby itself so that a client-side redirect is done if an old link is used in an article. Additionally, I've generated a config file for NGinx (my webserver) with mappings from old to new URIs so that external links using the old URI will be redirected to the new URI with a http 301 permanent redirect.

What is planned?

I'm very happy with Gatsby at the moment but of course there are still things to be improved. At the moment both my personal blog and the website of the JUG Görlitz (whose source code you can see on github by the way) are done with pure JavaScript. In the meantime I'm using TypeScript for all my newer projects and I'm loving it so one of the things on my list is to migrate the JavaScript code to TypeScript in the future. I'm not sure if this is even possible with Gatsby as Gatsby.js itself is written in JavaScript and to use TypeScript you need to adjust the build setup of Gatsby but at least there is a TypeScript page in the docs so obviously someone has already thought about this topic.

Another thing is the way my content entities are linked to each other. As described above it's not a real link but just an interpretation of data that is done in my own page implementation. Gatsby itself has no notion of this link at all. However, in the meantime there were some features (1, 2) added to Gatsby that I will take a closer look into.

In the future I will most likely write more articles related to Gatsby.js to explore some of my insights in more detail.