Veit's Blog

Going Static

I have been doing a lot of web development in the past three years. I am a backend-centric fullstack developer, which means that if you hold me at gunpoint I can probably come up with a website that doesn't suck, but I would be much more comfortable building your API.

Nonetheless, I have worked with with a few brilliant frontend developers who greatly influenced the way I look at the Web. In hindsight, I did everything wrong when my website first launched a few years back. That is a blatant overstatement, of course, but my convictions have changed dramatically, and I cannot help but look back at it with contempt. All of the personal websites I've built lately—click us for examples—have been much more minimalistic than what I would have built a few years ago. I'm deliberately excluding corporate websites here, because they are very different in terms of what they should look and feel like. I would like to explore why my views have changed and how I approach building these websites, both with and without a backend.

A caveat & an introduction

I alluded to it earlier: I am not a frontend developer. While I have worked in web development in at least some capacity for most of my professional life, I am not especially productive when confronted with stylesheets. I have a good grasp on JavaScript and have used React and Angular to build pretty large web applications in minimal time. Styling those websites, however, takes ages if you let me do it.

This is especially true in a corporate context. And I don't think that it is because I have no taste or don't know CSS. The problem runs deeper. I have come to believe that I have a hard time thinking in a corporate design box.

Kindly regard anything that follows as a description of what pleases my eyes and, quite possibly, my eyes only.

I against the world

I. I embrace minimalism. It caters to my artistic and æsthetic principles. I don't mean bogus minimalism à la material design, which try to invent a visual language that a) looks appealing and b) works in a corporate context. In fact, I think every effort to make anything corporate look good is doomed. I don't think it is impossible a priori, but I do think it is hard—especially so if it has to fulfill a purpose (think Customer Resource Management software or sales portals).

II. I believe minimalism and function are naturally at odds. Professional life is always about selling things, in one or another. It has to serve a purpose, it has to fulfill its function. Thus, looking back at the first sentence of this paragraph, we can conclude that minimalism and professional life are at odds.

III. I need to earn money. I like to do so doing things that please me. At the beginning of my career I was intimidated by the websites of people who were good at what they were doing. That was especially true if they built software, just as I aspired to do. I did the natural thing. I copied their style. Most of these websites were made by talented people and still, they looked bad. In hindsight it is obvious that my website was also destined to look bad.

IV. I have gained a lot of experience since then, working on all sorts of projects, trying to make the best of things, good and bad. Now I can follow my own æsthetic intuition.

How I build websites

When working on projects for myself or people who aren't paying me to work, I take my time. I have come to think that that is key to me being able to build a website I don't completely despise. This is especially true because my resources for work that is not my domain are expertise are somewhat limited. Of course there are good and bad days at work as well, but if I have less of an idea of what I am doing, those good days really are my only hope. The variance is just bigger.

I like static, small, and fast pages, best without a backend. I prefer if I don't have to optimize, minify, audit, double-audit, harden the database, or, God forbid, build a fully-fledged development pipeline using my current development tools of choice—at the moment Gulp and foremux. There's something in the air if it is just me, Vim, and the browser. Some of my personal projects do require a backend. Some are only backends. If that is the case, I try to tackle these problems separately, tricking myself into thinking these are in fact two separate, unrelated projects. Otherwise, both of them are tainted; the backend would often like the frontend to change and vice versa. Most of the time, especially in small projects, it is better not to bend under the pressure, and find a way to deal with a non-conforming party gracefully, not unlike in a conversation. I find that makes both components prettier, if you don't give into the desire to find hacky workarounds—and if the other party is not objectively at fault. Once again, this is a wholly personal take on the adaptability of components in a system. If you disagree, you probably have great reasons.

What to make of this

I'm not really sure what to make of all of this. I am still in the process of finding out what I want my work to be and I am unsure whether I will ever have a definite answer. I do, however, have a firm grasp on what I currently think and why I think so. And, in my eyes, that is much more important.