Recently: January

On blogging

I've been mostly posting movie reviews lately. I like to watch movies and I like to think critically about them, but I don't have the filmic chops to write consistently insightful reviews of films, nor do I have any interest in being a, like, movie thought leader.

But I've always wanted this to be a place where I can write down my polished thoughts about tech & the Internet. And I don't know that I've done that, consistently.

The reason that stands out to me most is: I feel as though my opinions on code are still, like, nascent. Mucus-covered and mushy. I have a colleague who has worked with code for like 15, 20 years. He's seen whole ecosystems rise & fall. I wasn't even around when React was getting big. I don't know how to compete with that sort of longevity.

I'm a good programmer. I have cogent thoughts about the ecosystem. I just don't write them down.

Maybe I'm too fussy. Maybe I think that I need 1,000 words before I can post something online. That sort of rule did me a lot of good back when I was writing Everything You Have Heard Is True. 1,000 words, every Monday morning: what happened since last Monday? Then again, a lot more was happening, both in my life and in the world in general, back then.

What's the blog for?

I want to do two things with the blog:

• Experiment with web technologies. I've done a bad job of this so far. The blog's pretty bog-standard at the moment; maybe the most interesting thing I've got going on it is a custom <Image>component for rendering images at custom sizes through my self-hosted image proxy (running Will Norris's imageproxy) service on my $5 DigitalOcean box.
• Take deliberate notes. I spent a lot of 2020 trying to figure out a good way to pass off the daily brain load to my computer. I think I've got a lot of it down—but not quite all of it just yet.

Sometime in the future I'd like to come up with a solution to finding the deliberate notes that I've written. Some kind of search or filtering. Haven't thought up the right paradigm though. :/

On template builders

A little while ago, I wrote about a small utility called xm that compiles HTML templates. I think this solves a problem that a lot of people face: they just want to write HTML files. No frameworks, no libraries or servers. They just want a set of HTML files and then they want to put those files on a server somewhere & be done with it.

BUT: I don't know that micro-utilities like XM is a good fit. As I see it, there's a sort of spectrum of template builders:

Templating languages -> CLI utilities -> Frameworks

Templating languages are things like Nunjucks or Mustache. They're just a syntax. They're agnostic of the context or language you're using them in. They leave it up to whatever environment they're being used in to determine how to pass in data. They wind up getting embedded in places like CraftCMS or Eleventy.

CLI utilities encompass most static site generators. They do one thing: take a bunch of non-HTML files, maybe with a thin data layer (like markdown or a JSON object) and turn those files into HTML files. Maybe they come with a watcher so that you can run it in development. Simple input/output.

Frameworks are the dominant category here. I'm not just talking full-featured static generators (think Gatsby), but things like Nuxt as well, where static generation is one option among many. These compile your HTML templates but they also handle some other neat stuff, like image transforms or client-side routing and hydration. Some of them come bundled with a server as well, so you can run them non-statically as well (although we seem to be moving away from this).

There's always going to be a place for template languages, since they're so flexible (even if they can't really live on their own). And so long as there are smart people on the web we'll have frameworks for abstracting away repetitive tasks. But I'm not so sure about these HTML compiler utilities that we find in the middle. Eleventy is great because it lets you bring your own templating language and it's got a cool way to populate data. Jekyll is obviously still in use all over the place, though I'm not sure if it's just because it's the established player in the space. Hugo also gets a lot of talk, probably because its compiler (written in Go) is uber-fast. These last two are also the only conventional options for SSG in Ruby and Go, respectively—and both langauges have huge numbers of devs behind them. So it makes sense.

But a JS-driven static site generator? Something you have to download, or run with npx? It feels like another player that no one asked for, in an already-crowded space. If you're going to learn to use some tool to compile HTML for you, why not learn Eleventy instead of, say, Saber?

(Nothing against Saber, I plucked it out of a hat.)

Learning SVG animation

You probably saw Cassie Evans's animated avatar on her site earlier this year (scroll to the bottom of the page at the link above). It made me smile and scratch my head but I sort of filed it among web experiments that were more than I could chew on. It was only this past week that I went back and read her excellent walkthrough of how she made the avatar.

SVG animation, like service workers and Three.js, has always sort of seemed... above me, somehow. Technical in a way that I can't easily conceptualise. Cassie's walkthrough, however, broke it down into familiar bits. "How do you eat an elephant? A bite at a time." This felt very much bite-at-a-time. And you'll notice that I have my very own SVG animation on my landing page now.

Supabase

Supabase bills itself as an open-source alternative to Firebase, focusing on Firebase's main product: databases and auth.

It's surprisingly easy to get set up and started with Supabase. It's punching at paid-SaaS level though at the momen it looks like it's just being funded by Y Combinator and Mozilla. Onboarding is slick, the UI is uncluttered (bordering on sparse, actually), everything comes to hand without too much fuss. I never felt lost or like I didn't know what to do next. Though I would have liked a quick pointer towards the documentation.

Speaking of documentation, the sparseness is probably felt most keenly there. It's not that it's lacking—it's just not as explicit as I'd like. Doesn't keep me from building stuff, and I can be pretty thick when it comes to reading docs.

From a developer perspective I doesn't quite feel as polished as Firebase does. But Firebase has Google's clout behind it and Supabase is still in beta—and for a beta product it is more than capable. I also really like that it uses Postgres under the hood rather than whatever ambiguous NoSQL stuff Firebase is using. I've always sort of thought that you should use relational databases until you have a good reason not to, and Firebase isn't a good enough reason not to.

I haven't tried out Supabase's auth stuff but it looks generally the same as Firebase's; ditto for the realtime DB stuff. But I'm not concerned. I've got some ideas in store.