Starting is rarely my problem. Instead, it’s sticking with, especially since I tend to start more often than I finish. The end result is a lot of half-finished things lying around me at any one time. I’m doing slightly better in terms of organizing myself, so I can only hope that I’ll be able to slowly chip away at the pile over time. Whether I’ve succeeded will be pretty clear from this blog.

Anyway, this is supposed to be a development-focused blog, not my personal one! So I thought I’d mention a bit about how I put my personal site together and why I did it the way that I did. This also gets into my more general approach to web-based development, which can be summed up in one word: simplicity.

There’s two aspects to this, but plenty of overlap between them. I generally think in terms of simplicity of code and simplicity of visuals.

Visuals⌗

This comes down to user experience. Too many web developers think about what looks cool versus what’s pleasant to use. This isn’t to say that a given web site (or any program, for that matter) has to be boring, but it also means that any visual flourishes need to be out of the user’s way as much as possible. It’s a trade-off. But, for example, I see tons of blog templates where the home page is just like four links to other parts of the site and nothing else. Why are you making the user have to do more work just to get to the actual content?

This applies equally to intro animations, where a bunch of stuff goes flying around the screen before the user can actually do anything. It’s obnoxious most of the time, and the best-case scenario is that it’s interesting the first time someone visits your site, but becomes more annoying every subsequent visit.

Animations too are fine; quick transitions between pages, or to make loading periods more interesting (even if those occur more often than they need to) can help make the user experience better. I have a quick “typing” effect on my main tilde page, which I think fits with the overall aesthetic, makes the page slightly more interesting to use, but doesn’t expect the user to sit there while I show off all the fancy animation tricks I happen to know.

To be clear, this isn’t about avoiding modern web technologies. Do your site all in webGL if you want! This portfolio site does just that, but notice what else he does. The first thing you see is a group of signs you can click to go straight to specific parts of the site if you’re looking for one particular thing. If you’re not, you can zoom around and explore, and he’s put in a lot of really nice details that make the whole thing more interesting, even if I had to eye-roll a bit at the Tesla logo on the back. Note that I’m also not addressing the possible accessibility concerns that can arise with this kind of thing, since there are ways to do both.

There’s absolutely a degree of subjectivity here, which of course makes it that much more difficult to find the right balance. And context matters too: I’m more forgiving of, say, a web designer’s portfolio being a little more ostentatious than some company’s website. But even then, it doesn’t take long for the user experience to get unpleasant quickly; I’d rather a site be a little boring than to be a chore to actually use.

Code⌗

This translates over into how a site is coded. I admit this may come across (or genuinely be) a simple case of “old man yells at clouds,” but there are legitimate criticisms here nonetheless.

Briefly, I dislike NodeJS’s ecosystem, embodied in npm. Yes it makes add-ons easier, but that’s kind of the problem. If you install a module from there, you’re also installing every module that it depends on, and every module all of them depend on, off into infinity. I’ve heard of simple web apps with close to 100 dependencies(!), and it can get far worse as complexity increases. On the one hand, I get it: why re-invent the wheel? But the problem is that it’s very easy to pull in additional code that you don’t actually need for whatever it is you’re doing, which at best just adds size and complexity to your site. At worst, it creates an attack service that can become massive.

Security threats are very real, and they don’t even have to be malicious (but sometimes are). Back at the beginning of this year, the developer of a couple wildly popular NodeJS libraries was angered by what he saw as corporate greed, namely that billion-dollar companies rely on open source software without giving anything back. His response was to release corrupted versions of the libraries he maintained. These simply broke their functionality, either creating an infinite loop in the code or making them produce garbage output. But even then, it hindered the functionality of a lot of large websites, because these modules were used by React, a massively popular web development framework. The issues were eventually solved by GitHub putting the code back up without the author’s permission, which is a subject for another time.

This case was an inconvenience, and doubtless lost some income for some businesses, it’s hard to say that it was outright malicious. The same cannot be said for the most recent episode, which came to light within the last couple days (as of the date of this post). The developer of another widely-used NodeJS module called node-ipc decided to engage in some protest against the Russian invasion of Ukraine. His method was to have this module delete every file on the computer if it determined that it was being run on a machine within either Russia or Belarus. For users in the rest of the world, it created a file on their desktop with an anti-war message.

This is obviously a much bigger deal, and could involve serious data loss for people who have nothing to do with their government’s policies. In fact, an allegation was posted to GitHub (which hosts the code) by someone claiming to be from an American NGO, saying that they had lost tens of thousands of messages from people inside Russia and Ukraine about war crimes and the like as a result of this action. It’s difficult to understand what the developer’s thinking for this was, especially since he has not gone to any efforts to cover his tracks or hide his identity. Anyone who wants to find his real identity can do so easily. But anyway, I use this as an example of how much access NodeJS and its ecosystem gives random developers to the system running it. The malicious code I just mentioned apparently ended up getting folded into Vue.js, another popular web framework, as well as the Hub app that comes with Unity (a program for making 3D games that is extremely popular).

Thus for all the convenience of using npm, there is a massive trust and security problem. It’s frankly amazing that things like this don’t happen more often (that we know of), and it would be trivial for a large actor like a major corporation or nation-state to inject malicious code into an npm package that would be difficult to detect. There are examples out there of various approaches that could compromise security easily, especially if the developers aren’t paying enough attention (or are themselves up to something).

Just Do It⌗

Returning to my own approach, it’s beyond clear to me that the risks outweigh the benefits. I don’t need hundreds of kilobytes of JavaScript to display some text in a way that looks nice, and that does exactly what I need it to do. There are myriad ways to avoid these kinds of vulnerabilities and resource usage by simply thinking more about what we want to do, what we gain from doing it, and whether we need some overstuffed third-party library (which is basically a black box) to do it.

My main site on tilde.team weighs in at a whopping 16KB, plus an additional 25KB for the embedded font. It is three files: one for HTML, one for CSS, and one for JavaScript, all of which are completely human-legible. It will work without JavaScript all, since that code is purely for visuals (the flickering effect on the header and the “typing” effect on the quick menu). You can ignore the font embed and it will still display properly.

From a design standpoint, in addition to being simple and easy to read, I’m (obviously) a sucker for retro computing aesthetics. I love ASCII art, text-based interfaces, the works. But I also didn’t want to totally copy every other terminal-like theme out there, even if I was totally okay with that for this blog specifically. I’m a DOS kid at the end of the day, so decided to go with that for my primary basis, even if I used a darker and less box-focused color scheme than was common in DOS programs back in the day. For a good example of what I mean, you can check out the source for the font I used, which very much embodies a more “authentic” design. There are also ideas like BOOTSTRA/386 which go further, but violate both the principles I’ve talked about here. The text display animation is slow and obnoxious, and the code is massive compared to what it really needs to be (over 400K for the most recent “official” version!). The default also doesn’t use a good font choice, in that the proportions are off when rendered to the web, something the font pack I linked to has dealt with already.

Another note on font embedding: there is 0 reason to use Google Fonts. They have enough data on us as it is, and I for one am not willing to subject every visitor to my site to harvesting. There are better hosts for that, to say nothing of just hosting it yourself. I realize the latter isn’t always an option depending on what you’re doing, but there’s no excuse in my opinion for embedding code from an actor that we know cannot be trusted.

With all this in mind, it was thus pretty simple to come up with a simple box-designed layout with a nice dark color scheme (basically an almost-black background, an almost-white foreground, and a green I like for accent). Figuring out what to actually put in there content-wise was much harder, but ultimately I went with my backup plan for writing: just say what’s in your head.