The Project Aisle

Website: The Next.js Generation

All the things you didn’t need to know about the current incarnation of my personal website.

The USS Enterprise’s captain Jean-Luc Picard gives an order
Baldly going where no one has gone before

Nowadays I only work on software that you can’t see, but I actually started my career as a UX research intern. Somehow I transitioned from that to full stack development to pure backend development in just five years. Ah well. At least I still have this website, which I rebuild from scratch every few years because I keep learning new front-end stuff (and also simply because I can). This article describes the 2020 version, which is what you are looking at right now!

Why I rebuilt my website

The previous version of this website was built using Jekyll and some handwritten Gulp scripts to process images and Sass files. It suffered from a number of maintainability issues, most of which were related to Ruby (which seems to break every time I run brew upgrade), horribly outdated NPM dependencies, and the fact that its string-based templating engine makes it very easy to make dumb mistakes that go unnoticed until you’re rebuilding the whole thing two years later.

Screenshot of the old front page
Chances are that you’ve never seen the previous version of this website, so here’s a screenshot of the old front page.

For its successor I wanted to use a more modern, JavaScript-based stack that’ll last at least and lets me do whatever I want without having to worry too much about external dependencies.

How I rebuilt my website

When it comes to frameworks and libraries there were essentially two major contenders: Next.js with React and Sapper with Svelte. Because I had some trouble deciding between the two I simply built prototypes for both frameworks in parallel until one of the two emerged victorious.

Both frameworks have their own strong and weak points, but I eventually ended up picking Next.js with . While the Svelte-based version definitely loads and reloads a lot faster than the React-based version, its ecosystem is a bit of a disappointment; many things (like documentation) are either less mature in the Svelte world or don’t exist at all.

Since there are many more framework and tooling choices that I’ve made along the way, I’ve compiled a list of all the tools, frameworks, libraries, and services that were used to build the 2020 version of

Languages, frameworks and libraries

Most of the code for this website is written using JavaScript. I’m normally more of a TypeScript person, but in this case I wanted to keep things as simple and uncluttered as possible. The code also comes with a very minimal set of tests and I’ve used a .vscode configuration to hide all the I don’t care about.

I already mentioned Next.js and React above, but I’ll mention them here again. Both frameworks are very popular in industry, so picking these was mostly a no-brainer. What I didn’t mention though is that I’m not actually using React, but Preact, a lightweight alternative to React.

The difference between React and Preact is fairly negligible from a developer’s perspective, but there are some subtle differences that can lead to some very unsubtle annoyances.

One of my other libraries that does not like Preact very much is styled-components, which I use to make this website look Chuniversiteit-y.

It technically works fine with Preact, but styled-components will pollute your console with false warnings for every component on the page, because Preact’s implementation differs from that of React. This makes it much harder to spot actual warning messages that actually matter.

Other than that and some minor issues with specificity, styled-components works very well for me. I’ve played around with , but this seems to be the only one that lets me write CSS with JavaScript variables without weird, arbitrary limitations.

Articles (like the one you are currently reading) are written in MDX, which combines the simplicity of Markdown with the power of React components. I kind of like it, but .

I don’t use MDX directly, but via the next-mdx-remote package that allows me to decouple the routes you see in your address bar from the physical location of my MDX files on the server’s filesystem. It seems to make single pages render more slowly during development, but I think that’s a small price to pay!

Hosting is currently hosted on a cheap shared hosting plan. While I consider this to be more of a bug than a feature, this does shield it from my Linux and Kubernetes ops-periments, which have the annoying tendency to break things once in a while.

Speaking of shields, I’ve put Cloudflare in front on the website, because it speeds things up a bit and gives me some insight into the number of visits – for free!

Oh, and in case you were wondering: I don’t use a CI/CD service for right now. My deployment tool is a simple Bash script that builds a static version of the website, copies it to the server, and points a symlink to the newly deployed build.

I’m planning on migrating the website to a Kubernetes/OpenShift instance or Amazon S3 in the future, with GitHub Actions as CI/CD service because that’s what ReAl EnGiNeErS™ do. It’s not particularly high on my list of priorities though.

Desktop applications

Visual Studio Code is my main text editor for projects, but I open single files using a registered copy of Sublime Text so I don’t clutter my Code workspace with random files.

I’ve configured of my applications to use a light theme, because I’m a psychopath (and also because I spend a lot of time reading scientific papers with very white and bright backgrounds, which completely negate any benefits of dark mode user interfaces).

Most of my interactions with Git are done using GitHub Desktop. I’m not a great fan of Git’s command-line interface and Desktop does the job well enough, especially for single-person projects.

Almost every illustration on this website was created using Microsoft PowerPoint and rasterised by making a screenshot of slides in presentation mode. Like I said, I’m a psychopath (and very good at PowerPoint presentations).

The result

The result of all that work is the website you see before you now. Feel free to look around and don’t hesitate to contact me via Twitter if you have any questions!