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.
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.
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.
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.
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?
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.