Website: The Next.js Generation

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!

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.

For its successor I wanted to use a more modern, JavaScript-based stack that’ll last at least five years or until I have published 500 articles (side note: Whichever comes first!) and lets me do whatever I want without having to worry too much about external dependencies.

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

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 files and directories (side note: This includes things like .babelrc, node_modules, .next, and… .vscode.) I don’t care about.

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 in its current state it definitely isn’t for everyone (side note: See also MDX: The good, the bad, and the ugly).

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!

I spent a lot of time trying out various CSS-in-JS solutions (side note: If you’re exploring different alternatives I can heartily recommend Edmund Reed’s excellent blog on CSS-in-JS.) and ended up choosing styled-components. It lets me write SCSS-like CSS that is scoped to my components and allows me to use JavaScript variables from a global configuration file. It’s far from perfect though: I’ve had some minor issues with specificity that were specific to styled-components, and sometimes it would occasionally mess up class names in the production build.

The source code, Markdown files, and illustrations are all stored in a single private repository on GitHub. The website is deployed both periodically and manually using a GitHub Action, which creates the production build, optimises any newly committed illustrations, and deploys the whole thing to GitHub Pages.

Content is served via Cloudflare, which lets me view some basic (side note: And wildly inaccurate) visitor and bandwidth stats.

I currently don’t pay for anything.

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 virtually all (side note: *raises fist at Spotify*) 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!