Why Over-Engineering Is Fine - Building eric.film
Posted: June 7, 2020
Updated: February 16, 2021
Every two years or so, I redo my website. This year during COVID-19, I had some time and started developing the third version - with a couple of goals in mind:
- Make it super mega fast
- Mobile first
- Learn as much as possible
It's safe to say this project was completely over-engineered. This is mostly because it's the first time I've built eric.film all by myself, without relying on a HTML/Wordpress template. It's nice because I can do whatever I want and it's bad because I can do whatever I want.
It's no secret that slow websites make users quit and business people sad. Although visually, a lot has changed since eric.film v2, the most notable improvements happened under the hood. Me and Wordpress finally got divorced. Knowing almost nothing about PHP, I switched to the Jamstack and got in bed with the coolest kid on the block - React. Together with Next.js - a framework for both SSR and static site generation - eric.film is now a whole lot faster. Vercel's CDN, HTTP2 and solid code-splitting are the main reasons for this.
During development, Google's Lighthouse tool became a very good friend of mine, and even though we often argued, it provided me with valuable insights about what can be improved on eric.film. In order to have some kind of benchmark, I set myself the goal of getting a green Lighthouse report. With some little tweaks, this was possible for most pages on eric.film!
Here's what the the Lighthouse score (generated on the web UI) looked like before:
And for the current version (beta)
It's important to note that these reports depend on so many distinct variables like current bandwidth, the device you're using, and so on. Always look at these results with a grain of salt and know where to stop. And use the Node CLI for a little more consistent results.
Let's get to the visual part! The most challenging aspect in terms of design was making sure all pages conform to a persistent and layout and feel. As a hobby photographer, I wanted to showcase videos, photos, tables and text - different media that should somehow be displayed in a consistent form. The galleries should be an eye catcher on both mobile and desktop, but it's no secret that big images conflict with page speed.
eric.film was developed mobile first because I expect most traffic to come from social links. Sure, eric.film is and will always be a small site with maybe 10-50 visits a month, but whoever takes the time to come here should be rewarded with a somewhat pleasant experience. So if you're reading this, thank you so much for stopping by!
Per default, this website makes use of a dark theme, with many colors codes and concepts shamelessly stolen from Material Design. Although I'm a dark theme lover, I was not sure whether people like reading long texts on a dark surface. That's why a Theme Switcher was implemented, so whoever reads a blog post can toggle between a white and dark mode. Go up again to try!
The main reason I spent hours on this project was that I wanted to learn as much as possible. In my current role in digital project management @Blick (Ringier AG), I'm confronted with challenges of modern web development on a daily basis.
Do we put the commenting section above or below the recommended articles? What fetch interval and caching strategy is best for live sport data? Where and how do we let users customize their experience?
With this personal project, I had an opportunity to better understand some these questions. eric.film is obviously way simpler than the Blick project but some challenges remain the same. My belief is that people who understand how their product works on a technical level manage it better. I intentionally over-engineered a simple website in order to learn. And I think that is completely fine.
For the curious ones: eric.film is completely "open source". Check it out on Github.
By the way, you can take a look back and check out the previous versions of eric.film here:
Preview picture by @anniespratt on unsplash.