Software and the monopoly of the recent #

Every now and then, I end up revisiting the ideas of Ivan Illich’s Tools for Conviviality and thinking about they might apply to computers. For a book that doesn’t mention the word “computer,” (that I can recall, at least) and was written well before the personal computing revolution, it’s surprisingly compatible the early ideal of computing as an empowering medium for thought. Think Alan Kay or the ideals of the free software movement.

For Illich, the idea of “conviviality” as it relates to tools is a balance between personal autonomy and freedom from dominiation by the majority. To quote:

A convivial society should be designed to allow all its members the most autonomous action by means of tools least controlled by others.

So it was nice to stumble on the Hope in Source podcast interview with Stephen Kell, which talks a lot about conviviality and computing. What struck me most in the conversation was the idea that Kell called “the monopoly of the recent,” namely that the tech world is too obsessed with newness, often to our detriment and to the exclusion of others. Drawing on Illich’s ideas of a radical monopoly, Kell says:

It definitely spoke to me when I read it in Tools for Conviviality. And he talked about how in the sort of seventies United States, there was a radical monopoly of the car, in that society was designed so that you had to use a car to get around and it was kind of impractical to survive without one. You could do it, but you confined yourself to the fringes. You weren’t a full participant.

So I thought what’s the equivalent in software. And what I came up with was this idea of change, right. Always working with the latest thing. That’s that’s to me the most equivalent concept in software, because it’s like the monopoly of the recent. If you want to use some old piece of software that you happen to know does what you want. And maybe it’s simpler or performs better than some newer version. Yeah, you can do that, but you’re confining yourself to the fringes, right? Because suddenly you need to install the old versions of a dozen other things, and suddenly you’ve got security problems to contend with maybe. Because everything is so interconnected, you’ve confined yourself to not being a Real participant in the software community anymore.

Today’s “monopoly of the car” is the smartphone. It’s increasingly more difficult to get by in society without one.

There are some connections to make here with the permacomputing movement, to be sure.

Thoughts inspired by "A Child's Plaything" #

Read A Child’s Plaything by Toby Ord. Such a brilliant short story that says so much about modern life with so little.

And they would understand that the people of our time are so wealthy, so powerful, that every one of them has access to machines with thousands of parts working in concert, and that it is less effort to build such a wondrous machine than to simply paint a doll’s eyebrows in their right places.

I immediately think of software (because that’s always where my mind goes), where amazing capabilities have become rapidly commoditized, but where high levels of quality and craft remain scarce. With templates and boilerplate and starter packs and generative AI we can more easily spin-up complicated working systems than ever before—including tools with an astonishing simulacrum of intelligence—but to build something of beauty still requires ingredients that remain in short supply: time, attention, and care.

Controversial thoughts on networked note-taking #

Like Casey Newton, I’ve found networked note-taking to be a practice that mostly overpromises and under-delivers.

As someone infatuated with the idea of tools for thought, I’ve tried a multitude of different note-taking applications, both of the networked and non-networked variety. Everything from Roam to Workflowy to Obsidian to Bear to Apple Notes to vim and vimwiki to Simplenote to Evernote and so on and so forth. Presently, I use Obsidian, but I don’t really need it.

Despite best intentions to create a Zettelkasten for myself over the years, I’ve repeatedly found the marginal increase in value—or insights-delivered-to-hours-spent ratio—not nearly worth the effort. My hunch is that digital Luhmann-ism really only provides dividends for a small population of academics and writers of non-fiction who need to cite references or make connections across disparate texts.

For the rest of us, just writing down notes is all that really matters. Any tool that allows you to compose and save text will do. It is the act of writing, not the act of linking or reading or revisiting, that clarifies thought and leads to insight. The rest is all superfluous.

Some early impressions of HTMX #

I’m bullish on HTML-first, JavaScript-light frameworks and libraries gaining more developer mindshare over the coming years. We’re seeing more and more developers starting to realize that maybe JavaScript-heavy SPAs are not the best way to build many applications.

There are two HTML-first frameworks I’m particularly excited about and have been using in personal projects: Enhance and HTMX. This note is about my early experiences with HTMX, a hypermedia-based approach to application architecture. (Hypothetically, you could use Enhance and HTMX together, but I haven’t tried that.) Take all this with a grain of salt, I’ve only been using it a few weeks.

A few nice things about HTMX:

  • It’s just markup! You write HTML, sprinkle in a few special attributes on any element, and you get a large portion of the AJAX-based dynamic behavior you get in a JavaScript-heavy SPA without all the JavaScript. It’s easy, simple, and feels kind of magical the first time you use it.
  • The API is pretty damn simple and uniform—just use HTML attributes for specifying nearly all behavior. (You can also use custom response headers on the server side to invoke client-side behavior from the server when you need it.)
  • Server-side rendering is the default. Your server needs to respond to HTTP requests with HTML rather than JSON. Admittedly, this is probably better for newer projects that don’t have pre-existing JSON APIs. (Though there are extensions to HTMX that allow you to use client-side rendering if you must use JSON). But for me, this way of working feels natural anyway, and harkens back to the days of 2007-2010 or so, when I was writing a lot of Ruby on Rails.

A few challenges I encountered:

  • How you handle pure client-side behavior is left as an exercise to the reader. For instance, how do you handle animated modal dialogs and overlays? A server-side rendered modal can be injected on-demand, but there remains a need for client-side scripting to handle transitions, canceling, hiding or removing the dialog, etc. HTMX supports the new ViewTransition API, but alas, Firefox does not. Additionally, there are myriad ways of handling pure client-side behavior, some more compatible than others to the HTMX style and ethos. Alpine.js perhaps, or maybe Cami.js? Both are lightweight libraries that do just enough. Personally, I’ve landed on client-side enhanced web components (really just custom elements that are defined in JavaScript but are server-side rendered), and that has been working pretty well so far.
  • Sometimes you do want some client-side state, and pure HATEOS feels limiting. For example, handling client-side state based on the current route is not-so-straightforward. If a user clicks a navigation bar, you may wish to both highlight the current location on the navigation bar and re-render section of the page to show the application contents corresponding to that location. In an SPA framework, a client-side router would allow reactive rendering behavior based on the current route. Unfortunately, browsers don’t make it easy to observe URL location changes despite the existence of the History API (the newer Navigation API may solve this problem). One solution has been to rely on HTMX events like htmx:afterSettle as triggers to check for location changes and handle accordingly.

I’m sure I’m doing some things “wrong.” That’s OK—it’s been fun to just dig in and try.

On eschewing devices and living well #

From The Stuff of (a Well-Lived) Life, where L.M. Sacasas reflects on the furor around the recent iPad ad:

A good life is supported by a diverse array of focal things and practices, which tend to reward us with deeper, more meaningful experiences; a gratifying measure of bodily skill and competence; and possibly even a stronger fabric of relationships. Alternatively, a life characterized merely by the consumption of virtual goods mediated through devices, and the subsequent dependence and isolation such a life necessarily entails, will not be conducive to our well-being.

iPads embody a device-centric paradigm towards computing, which is exactly why my wife and I have been extremely cautious in how and when we allow our children to use them. Their device-centric nature isn’t so much an artifact of the table form factor as it is of how Apple markets it and tailors the associated user experience towards consumption over creativity. The recent ad, which attempts to counter this perception—”look, your iPad can be your piano!”—instead fails miserably and only reinforces this hidden bias. We don’t want our devices to subsume those focal objects that make an embodied, creative life so fulfilling—if anything we want devices to remain in the periphery, to complement them instead.

I fully believe there could be an alternate universe where tablet devices excel at empowering creativity by complementing other tools and instruments without trying to supplant them. But, that’s clearly not the universe we inhabit today.