Recently: Early September

Developer: the web isn't about you

The Web Isn't About You by Charlie Owen

I like to read stuff like this. I think there's a lot of it on the web these days, and I think it's only increasing as we come to rely more and more on Javascript-heavy web applications and people get more and more burnt out. Reading posts like this helps to make me feel like I'm not wrong for feeling burnt out and confused.

I make a lot of crap. I make a lot of inaccessible crap: sites that are hostile to users who navigate using the keyboard, or who can't use screens. Sites that barely load on anything less than a modern gigabit connection. I don't like that I do this, and I'm trying to stop. But it's hard.

It feels like there are two internets here, maybe in a way that hearkens back to Coyier's The Great Dividefrom a few years ago:

(1) The crap Internet that I work on. If you don't have Javascript enabled, it looks like this:

(2) The 'good' internet: accessible, lightweight, a little quirky. It looks like this, whether or not you have JS enabled:

The reason that it's hard for me to stop making type (1) websites is that the people who pay for me (& the company I work for) to make websites don't seem to care about type (2). They want Awwwards-ready websites; they want websites that utilise every last bit of juice that their 2020 MacBook Pro 16" with the 16 cores and the 32 GB of RAM can yield. They don't get out of bed for any less than a fully immersive web experience that drives their CPU temperature up into the triple digits.

I haven't been a dev for that long, but I can't figure out how...

This website can be used by people across the world on just about any device

...became such a harder sell than...

This website will gobble up as many resources as your computer will let it.

Which is why pieces like this mean a lot to me. I don't know Charlie Owen but she makes me feel a little less like I'm losing it, like I'm on the losing side of history, that we're all just going to go in for big web applications in future and that I'm not going to be able to run old secondhard hardware and I'm gonna have to drop £3,500 every two years for a shiny new Apple hunk of aluminum.

Now if you'll excuse me, I've got some accessibility work to do on Jernl.

Umami

I've previously made a stink about not having analytics on this site, but now I do.

Motivation here: I've never been very good at communicating online—but I want to be. Posting on Twitter, posting regularly on the blog. I guess I want to know if I'm… noticeable online, somehow. So I've installed some analytics.

I've installed Umami.is. It's hosted on my personal server and runs on my own database. I'm not going to share anyone's data with anyone, for any reason, ever. I know you hear that a lot.

If you don't want to be tracked, you can block stats.charlesharri.es—the domain that I'm serving the analytics from.

Lil utilities

Discovered xm this week: an interesting little compiler for HTML. Looks like it basically just stitches together different HTML templates to build a static website. And it has a markdown renderer built into it. I think it probably fills a niche for someone who wants to use some sort of component-based markup solution but doesn't need all of the bells and whistles.

I've got a bit of a soft spot for little utilities like this: small pieces of code that do one thing, and one thing well. Software like cat or top feel like well-made tools, a hammer that fits your hand or a pair of clamps that still clamp real good.

Not to bust the chops of bigger tools. I make my living on big web frameworks. But they feel less like individual tools so much as full toolchests, full of all sorts of things that I don't know if I'll ever need. Always pleased to find out that my framework of choice comes with a built-in solution to one or two of the thirty problems that show up every day, but I don't have the same intimate relationship with Nuxt serverMiddleware or Laravel's Eloquent mutators as I do with du, which always shows me exactly what's eating up all of the storage on the server.

Instagram user feed

I've been struggling on and off with getting an Instagram displaying reliably on one of our client's sites. Which is why this nice PHP package for fetching data from Instagram is changing the flippin game for me.

Instagram makes it particularly miserable to get data off of their platform—so much so that most "official" solutions just scrape a profile page for the window._sharedData that Instagram embeds. The engineers there must be aware of this, but I guess they're not so bothered about it.

One of the issues that you'll face if you use this strategy is that after a few requests, Instagram stops serving you the profile page that you want and starts serving you the login page. I guess if you're logged in, they trust that you're not scraping their site, but if you're just some anonymous bot, they'll slam dunk you to shadowban town.

This package neatly gets around this issue by logging you in in the background. It doesn't matter what account you use—a dummy account will do—Instagram just wants to see that session data in the request.

Gonna try using this on a couple of sites at work and report back with how well it works.

Application holotypes

Application holotypes by Jason Miller

For such a logical, category-oriented industry as software engineering, I'm sort of surprised that I haven't come across such a well-ordered taxonomy of web content before.

A couple of notes here: I'm surprised by how many of the holotypes' ideal implementations are single-page apps. Maybe that's a reflection of the modern ecosystem; maybe it's a result of so many of the holotypes focusing more on interactivity than content delivery.

(In fact, really only the content websites holotype is a content delivery website; the rest are what you might term 'apps'.)

It makes me realise how few of the sites that I build these days are really apps. We tend to do a lot of content sites, along with a few storefronts. Makes me really want to work on a social media application or a media player.

Actually dovetails sort of nicely with the above, viz. the move on the web from a collection of interrelated, hyperlinked documents to an Javascript-powered application experience. I think my angst comes from building what is effectively a collection of hyperlinked documents (i.e. simple content sites) with full application frameworks (and the full application JS bundle that entails).

Recently: Early September