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
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 Chuniversiteit.nl.
Languages, frameworks and libraries
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.
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!
Chuniversiteit.nl 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 Chuniversiteit.nl 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.
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 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!