What an experience. It’s satisfying to see my words thrown up onto the internet in a slick web page. However, at the same time I’m reminded at every turn how much I despise web dev.

How I Feel About the Tech Stack

I don’t do a whole lot of web dev, and I’ve had to touch a lot of different technologies for this. Some of them are familiar, some brand new.

There’s been a bit of Javascript, which sucks. I mean it works, but I hate it. You want justification? Well, what do you think this does?

document.getElementsByClassName("foo").forEach(e => console.log(e));

I’ll tell you what it doesn’t do: work. Imagine not having a concept of iterable.

HTML and CSS… are okay, actually. Sure, sometimes you’re pulling out your hair wondering why that thing is off by one pixel, but that’s just the nature of layout. Layout is a tough problem to solve, and HTML and CSS do a pretty good job of it.

The site’s running on GitHub Pages, which runs on Jekyll, which runs on Ruby. Ruby sucks. I have to type end every time I want to close a block and I hate it.

Templating languages are disgusting. Jekyll uses something called Liquid, which is some kind of funky low-powered templating language. You really can’t do a whole lot in it aside from string manipulation. I’ve had to do a bunch of silly work in Javascript because it simply can’t be done serverside. Normally, you could use Ruby to write custom Jekyll plugins to do all manner of fancy things, provided you’re willing to actually write Ruby. But it turns out that GitHub Pages don’t support running arbitrary plugins, so that’s not an option.

Jekyll is actually pretty okay. The documentation could be a bit more detailed as far as plugin writing goes, but seeing as I can’t use custom plugins I suppose I can ignore that.

Why’d I Make This Blog Anyways?

You know, I didn’t set out to write a blog. I was just trying to figure out image hosting for SVGs only to learn it doesn’t exist, so I figured I’d just spin up a lightweight GitHub Pages repo, sprinkle some sort of Javascript on top to get the SVGs zoomable and pannable, and be done with it. Then things spiraled out of control and it turned into a dang blog, simply because Jekyll seemed cool and I wanted to play with it.

I’ve thought in the past that a blog could be useful and sort of looked side-eyed at Medium, but they’ve got some weird monetization stuff going on PLUS I can’t very well do a zoomable pannable SVG there which was the whole point. So here we are in build-it-myself town. It’s been a chore, but at least it’s interesting and I come out of it with full control over my own HTML if I need it. Plus I get to write this in Markdown. I freaking love Markdown.

Now all I need is something to write about… eh, that’s a problem for my future self.

Challenges

It’s been a non-stop series of issues, but I think I’ve finally gotten the base blog laid out in a way I’m okay with.

SVG Nightmare

As I mentioned, I couldn’t find anyone that does SVG hosting. Plus, I wanted zooming and panning. I’ve got infinite resolution and by god I want people to be able to see it. Apparently the svg-pan-zoom library is the main thing that does this. After a lot of fiddling around with the page’s onload event happening before the SVGs had actually loaded in, I eventually just hooked up an onload trigger to each individual SVG and that solved that issue. The next issue is that svg-pan-zoom has a known issue where scroll-zooming doesn’t disable page scrolling. The good news is there’s already a PR up that fixes it. The bad news is that PR has been open for over two years now. So yeah, I guess I get to self-host my own svg-pan-zoom with the fix patched in. You know what’s funny? In the end I just disabled the scroll-to-zoom because it turns out to be a usability nightmare when you’re scrolling down the page.

Jekyll, and Jekyll Themes

Jekyll has been surprisingly good. The first order of business was getting a dark theme, which incredibly GitHub doesn’t have available as one of their presets. After some hair pulling I figured out that I can use a completely custom theme, and I ended up using minima, which has a nice dark theme available.

The next order of business was fixing the content width. Apparently blog designers have some sick fascination with making their whole page 800 pixels wide. Unfortunately, that’s not an exaggeration. I was not okay with 68% of my browser window just being dead space. Especially as I had some landscape-style SVGs to display. Bumping the content width up was easy, as minima has a nice variable where you can just set it to whatever you desire. What was tough was getting the SVGs wider than the content box they live inside. There’s probably some fancy HTML hack you can do to make this possible, but I figured I’d just flip the model around. Originally the container provided the margin and the content stretched to fill it. Now, the container is the full page width and the content itself picks its own margins. This means every <p>, every <h2>, etc is setting its own margins. And the SVGs are the only outlier with a way smaller margin. Is this bad? Beats me. Does it work? Yep.

Search Engine Stuff

Okay, I’ve got a blog, I can render my images, and I’ve written a post. The next problem is clearly finding someone to read my post. Being in Google would be nice. I don’t give a damn about SEO hanky-panky, I just want to be in the results somewhere. Luckily, the Google Search Console exists. It’s got a bunch of stuff that it does, but all I care about is it lets you summon the GoogleBot to crawl your page. A quick change to add a meta tag to my page’s head and I’m verified and good to go.

Analytics

Okay, in theory people will be able to find my blog now. It’d be nice to know if I have nonzero traffic. It turns out minima actually has built-in support for Google Analytics, so that was a super simple process to get working. Fun fact: Firefox blocks Google Analytics by default, which is pretty funny as I can’t even track myself. Guess I’ll only be tracking Google Chrome users, then. You know Google’s not going to block their own analytics in the browser they created.

Categories

Okay, I have one page. Time to sort all the pages I have. (I’m a genius, I know). Jekyll has this built-in categories feature. After playing with that a while I learned that it changes the path to a page when you change the categories. By default you’ve got something like https://blog.com/2022/01/01/my-silly-post/. If you add foo and bar categories to it then suddenly it’s https://blog.com/foo/bar/my-silly-post/. This is awful, because it means you can’t change categories without completely breaking links to your post. This is awful for search engines, and awful for anyone direct-linking to your post. So categories are clearly a no-go. What I really need is tags.

Tags

Oh hey, despite the documentation being way more up-front about categories, Jekyll also supports tags. By default it doesn’t do anything with them except aggregating them for you. You’ve got to handle displaying them on your own. Remember how I’m very limited by not having custom plugins? Yeah, this is the part where that started to hurt. There’s already a Jekyll plugin that does tagging stuff, but GitHub Pages doesn’t support it. So my only option is to make a tags page that enumerates all the tags and lists them, like this. What I really wanted was a page per-tag. Something like this. But I can’t generate distinct pages without a plugin, so it’s impossible… or is it? I mean, obviously it’s possible because I just linked to it. What’s going on there is it’s actually the same page and Javascript is just examining the anchor link and hiding everything that you shouldn’t be seeing client-side. It’s disgusting as it’d be so cheap to just do this server-side and cache it, but it’s my only option.

In Conclusion

I’ve made a useless blog. Useless because I don’t write enough to merit one, and the things I do write aren’t interesting enough to merit reading. But hey, it was sorta fun to make.