Alexander Gerund, Co-Founder okay bueno Alexander Gerund
Back home

Redoing my website and falling back in love with HTML

For the past few years I've neglected my website. To be honest, I wasn't even sure why I had one, besides securing my name as a domain. In fact, I neglected it so much that I didn't even bother setting up my SSL certificate, so it got unlisted from the Google Search Index. Kinda embarrassing for someone running a Digital Product Studio, but what the heck, who cares? I surely didn't.

But things change. Over the past months I’ve gotten rid of most of my private social media channels. Publishing on Medium feels like shouting into the void. Twitter is constantly on the brink of collapse and engagement is minimal, or at least that’s what it feels to me. Instagram is random stories and ads. Facebook? I barely know her. And LinkedIn... sure. I use it. I run a business. Do I enjoy it? No.

At the same time I started getting into journaling. Writing for myself, mainly as a reflection of my projects, daily doings, and state of mind. I’ve used a bunch of different apps, but ultimately what works best for me is sitting down at my desk and really focusing on writing. The physical environment matters to me, the digital environment not so much.

How I got started in web development in the first place

I really hated web development when I was studying. I was so focused on audiovisual design, that I couldn't even be bothered with development. That changed quite a bit over the years, and by the time I’m writing this I have had months at okay bueno when I spent far more time on frontend development than on strategy and design. And actually, I quite enjoy it. I’ve always been a generalist, wanting to know just enough to be able to do what I want to, but not with the mindset of mastery or to achieve excellence in a narrow field, but rather play the broader field profoundly. That's the same mindset I use as a north star for my new website.

Leading principles

Another thing I got pretty vary of is the environmental impact of digital products. The amount of data stored and transmitted. The amount of electricity used. A lot of times I check the network tab on a website and I get dozens of MB transferred. Then I look at the screen and I don’t get it.

The complexity of building websites is another interesting phenomena for me. Don’t get me wrong, I see the beauty in no-code tools like Framer Sites or Webflow, and I fully am amazed by modern frameworks, preprocessors, bundlers, and build tools. I use both approaches for internal and client production work depending on the requirements and expectations. But both approaches fundamentally feel wrong to me.

So with these ideas in mind I wanted to approach my website differently. Manually, actually. As semantic as possible, as reduced as possible.

To make sure I stay on the right track, I imposed a few constraints on myself, because I believe that restrictions help guide a project. Here’s the rule set I used for creating my own website:

Development rules

  1. No build tools
  2. No JavaScript
  3. No CSS pre-processing
  4. No custom fonts
  5. No analytics / third party scripts
  6. Respect system settings and user choices
  7. Initial load must be 100kb or less
  8. Accessibility first and as semantic as possible

My approach

People that have worked with me know that I’m quite impatient. It’s one of the reasons I couldn't really stick around in big companies for too long, the pace just isn’t satisfying to me. Moving fast is natural to me, I think mainly because I work intuitively, not by following steps or processes.

So when I start the process of redoing my website, I do it mostly in mind head. Then I sketch out some key ideas in Figma, but never actually finalize the UI design, if you can even call it that, but rather start writing the markup and css and finish the design directly in the browser.

The limitations

By not using any complex set-ups, I’m forcing myself to write well-structured, dry code. But there are limitations I can't deny. Here are some of them and how I approached them:

Image Handling

Well, I don’t use an image server or resizing service. I simply have a few Figma art boards I copy and paste images into and export them at 1x/2x/3x/4x, run them through tinypng and then serve them via img srcset. I’ve used respimagelint, my favorite booklet ever, to lint the image sizes and adjust the attributes to ensure I serve images in appropriate sizes.

Lazyloading

I’m well aware that biggest payload of the site will be images, so lazy loading is an important aspect. I thought about integrating lazysizes.js or writing my own minimal, Intersection Observer based solution for handling image loading on scroll, but that would violate rule number 2: no JavaScript.

In the end I decided to stick to the rules that I imposed on myself by using the native HTML loading attribute, which is supported for images in most up-to-date browsers.

Routing

Well, it’s just HTML and CSS. There’s nothing that helps maintain my routing structure. Except there is. My IDE. If you spend a lot of your time refactoring code, you get so used to using your IDE as a Content Management System, editing tool, that it felt smart to me to actually leverage the IDE to help me keep track of my routes.

Outlook

I’m never gonna be excited about anything I do, I’ve already come to terms with that, but I’m at least kinda happy with the outcome. I’m sure I’m going to redo it again at some point, and if only to break my self-imposed rules.

It actually took me longer to write about it, than to build it – I spent two afternoons before pushing it live. That also tells you how hard it still is for me to write about what I do. I hope it becomes more natural over time. We shall see.

One of the next things I want to integrate is a RSS feed for my website. RSS ain't dead just yet.