My new website

This is my new website. It looks pretty much exactly the same as the previous, but it has a whole new tech stack and more room for content like blog posts.

I’ve been thinking of redesigning my website for a long time: there are some sketches for basically every year since I launched this design in 2014. In the end, though, I could never settle on a new design.

Nevertheless, I felt like a bit of an overhaul was necessary. I decided the design was okay for now. I’m still fond of it, and it can be changed at a later stage. The urgency for me was about content.

Why the new version?

The previous version was mostly set up as an informal online resume of sorts. It had a list of projects that I was proud of, and even a page dedicated to photography (a hobby I seem to have lost interest in the last few years).

Since the launch in 2014, a lot has changed on the web. The web has become less and less personal and more centralised. Somehow, online social contact and relationships feel less personal nowadays.

Many feel that the antidote to this is to make the web more personal: fewer templates and no more news feeds, but old-fashioned weird and quirky websites, personal newsletters, and I guess, shitposting on twitter, and I love it.

So understandably, I’ve been feeling that using my website purely as a form of resume is rather bland. I like the idea of an old-school home-page. This is something I want to work towards in the future.

I think a lot of my feelings regarding this have been expertly summed up by Laura Kalbag in her article It’s time to Get Personal in 2019’s 24 ways ¹. Most notably, I’ve felt a growing need to own my own content. This was also nicely described by my former colleague Roel, who has gone a similar route.

Finding a tech stack

Above all, I wanted to be able to just put a text or markdown file in a folder and have it create a new page on my website. This functionality has been part of many static site generators (like Hugo, Jekyll, 11ty, etc), but my then-current version of my website wasn’t built on one. It was just hand-coded HTML², which meant that I’d have to manually take care of syntax, formatting and image processing, which — although not terrible — is some extra work you have to do to get stuff out there. We can definitely do better nowadays.

Since I’m primarily doing Javascript development nowadays, I wanted to pick something that matched that stack. In the end, I considered two options, 11ty and Gatsby, both of which I tested. I didn’t want to use Wordpress⁴.

11ty

Basically like Hugo, but built with Javascript.

I really wanted this to work, and it was amazing to see how quickly it was possible to convert a folder structure of neatly organised markdown files into a complete site with an archive, RSS feed, and everything. It was fairly easy to set up collections for different types of content, which was great as well.

In the end, I didn’t pick 11ty. I’ll explain in the next part.

Gatsby

Gatsby (The Static Site Generator, not the fictional character) is a whole different beast. It does so many more things, and there are almost 2000 plugins for it at this point which allow you to do many things.

To be honest, Gatbsy drove me mad at first. 11ty can turn many things into a page without configuration, creating the page’s URL based on the filename and folder structure (unless you override any of the values in front matter). Gatsby does not do that.

For starters, it’s based on GraphQL, which is a really cool technology, but more often than not, I felt like it was in my way. The frustration was in little things, like having to restart the server for certain new fields to appear, or having to query explicitly for every single field you want to use. This makes sense for large APIs, but not for a bunch of articles and an object with layout data or social network URLs, for example.

With GraphQL you have to query through the plugin that loads a certain type of content (so either Markdown, static files, images, YAML, or JSON), and distinguishing between different categories of content (e.g. blog posts and work updates) requires a lot of work because everything is treated the same out of the box (i.e. markdown files).

That means that you end up having to write your own code to categorise content, create pages with different URLs based on the collection of content they belong to, and to filter through content to find the next and previous articles in a collection. There are documented ways of doing all of this, but it’s a hassle.

Overall, the amount of boilerplate code that I had to write with Gatsby made me quite demotivated, and I was close to dropping it a few times.

However, in the end, after I had all that boilerplate code sorted out, I did end up with something that worked for me and handled the different types of content properly.

The nice bits

Once over the boilerplate hurdle, I could start appreciating the nice things Gatsby does for you.

For starters, having an image pipeline is nice. On my previous website, I manually resized images, and created standard and 2x versions in both the original format and webp. With Gatsby, you get essential plugins like gatsby-image which take care of all of that; simultaneously creating generating those different versions for you, while also creating the markup necessary for browsers to pick the best size and format for the user. This also works for images in Markdown and in YAML Frontmatter, which is great ³.

Because the website is still basically my portfolio as a front-end web developer, it should still serve as a representation of my current skill and expertise, so even though the design is currently unchanged, building the website on a currently-familiar stack is a sound choice. Since Gatsby is built on React (which I love and use daily for work), this makes sense to me. 11ty supports a lot of different template languages, but React is not one of them yet (they’re working on it).

It would also allow me to add some more interactive or fancier frontend components when it makes sense (or just to show off a bit) in future iterations of the website. I’ve been playing around a lot with generative visuals and music the last few years, and I’m looking forward to adding some of that to my website in the future.

In the end, this would just not be that easy with 11ty, which is basically just a plain static site.

MDX

Then there’s MDX. Initially, the idea of putting React components in markdown seemed ridiculous to me, but being able to include a live example of my work by simply writing something like <FancyVisuals /> into a Markdown file that’s otherwise plain text sounds truly like the best of both worlds.

Additionally MDX gives you the ability to replace regular HTML tags with React components as well. I use it mostly to add some CSS classes to headers and lists in markdown files so that I don’t have to make special CSS rules for HTML tags in a markdown context (I can just use the utility classes I created for the previous version of the website, and not try to override existing styles).

Hosting

The website isn’t hosted on any fancy static site host, it’s just a folder on a Virtual Private Server running nginx. I push my changes via rsync.

Conclusion

In the end, I also used the occasion to update some of the website’s markup a bit by making the HTML a bit more semantically correct.

I also added Dependabot to the GitHub repository, because the Gatsby ecosystem moves very fast, and auto-updating all the different dependencies makes sense when there’s this many plugins.

I’m curious to see how this website will evolve. I have some plans for what I want to do design-wise, and I have more content that I want to put on it. I also want to write more, and as a start, I’ve created an RSS feed to the website so people can be updated with what I’m up to.

That said, one thing at a time. For now I’m happy to have the new stack ready for whatever I want to put on it. See you soon!