Rebuilding my personal web site with a focus on web standards - Part 1
Every time I rebuild my website, I think that I've found the perfect solution to show off my portfolio, write and share my blog, and create a corner of the web that I can truly call my own.
Yet, my last website (which was custom-built from React tools) made me realize that a website's architecture can prevent its content from being accessible for all users…
In this series, I will walk through the steps (and tools) it took to…
- Research a tech stack that made it easy to comply to web standards (this post)
- Get Hugo up and running and styling the home page
- Migrate my blog from Medium and my portfolio from my old site
- Style the blog and portfolio using SCSS
- Design and build out the portfolio browsing experience
- Migrate the only dynamic content on my site, the “I am…” page
- Deploy to netlify, set up DNS and redirect rules
- (Cross-)Post content on others’ sites and get feedback on drafts
The problem: React is too flexible, yet some of its tooling is way too opinionated
As a Product Designer, a proponent of semantic HTML and a lean software zealot, it gave me a bit of heartburn to see how bloated my website had become. What started as a fun side project to teach myself React eventually morphed into a custom markdown rendering pipeline that required an always-running node server and a Redis cache!
At first, I strayed away from all-in-one frameworks like Gatsby to avoid bloat and boilerplate in the code I had to write. Yet, when I found myself fighting against what Next.js's opinion of a static site should be, I realized that the amount of configuration required to customize the look and feel of my website made it hard to focus on one thing at a time…
Want a sticky header? Install
helmet. Need a loading bar for dynamic content? Guess I'll grab
nprogress for that. Want to write markdown for your content?
react-markdown feels like a good choice.
Each one of these tools had its own API and learning curve and I still for the life of me could not figure out to do CSS Animations!
Eventually, I grabbed Material-UI to reduce the number of choices I had to make. But if I wanted to customize anything to look different, I had to read pages of documentation just to update some nested element's border radius.
The pivot: focus on the content
So I took a step back and asked myself. What was I spending so much time on? Why was I so obsessed with all these little things when my site was essentially just…
- A front page (including a bio and a list of honors)
- A link to a blog (hosted on Medium)
- A portfolio home page and its children portoflio posts
- The “I am…” page (which shows my Last.fm and Wallabag feeds)
I steeled myself against sunk cost fallacy and asked, “what is the bare minimum that I need to display this content and make writing new content easier?
The hero: the static site generator
Although Next.js has static site generation built-in, the way I was rendering the markdown made it very difficult to be flexible in my posts. What if I wanted to embed an iframe? Welp! Gotta write a new function for
react-markdown for that!
There had to be some other tool that had solved the markdown parsing problem for me… A bit of ducking led me to the following options:
- Jekyll (Ruby, an oldie but a goodie)
- Hugo (Golang, and therefore FAST)
I spent a lot of time reading the docs for each of these (along with a various other SSGs that didn't make this top 3 list). I had used them all on projects in the past but this time I brought my own designer/content-first lens to the table.
So let's get started…
- Install a full Ruby development environment.
- Install Jekyll and bundler gems.
Yikes. This is a lot of setup for something that claims to be “just your content.”
11ty (Getting Started)
Eleventy is available on npm and requires version 8 of Node.js or higher
Congratulations—you made something with Eleventy! Now put it to work with templating syntax, front matter, and data files.
This was pretty straightforward but also makes me nervous. Coming from a site with too much flexibility, the “start from scratch” nature of 11ty's setup make nervous.
Hugo is for people that prefer writing in a text editor over a browser.
Hugo is for people who want to hand code their own website without worrying about setting up complicated runtimes, dependencies and databases.
Hugo is for people building a blog, a company site, a portfolio site, documentation, a single landing page, or a website with thousands of pages.
This ethos really spoke to me as a designer and hugo's technical choices “walked the walk” here. Rather than starting from scratch and needing “version 8 of Node.js or higher” (like 11ty) or requiring me to “Install a full Ruby development environment” (like Jekyll), Hugo is just a binary file (see Installation).
As someone who switches computers (and operating systems) frequently, a zero-dependency tool with a focus on speed of setup and content authoring (👋 LiveReload) hooked me with its simplicity.
Next up: my kingdom for a theme!
In my next post, I'll cover why I chose to setup Hugo with a blank theme and add my own layers of paint… Spoiler alert: Designers are picky!
Content Warning: If it's been a while since you wrote plain HTML/CSS, the simplicity of the next few posts may scare you (and possibly cause you to swear off ever writing client-side rendered websites again).