I attended the first Bleeding Edge Web meetup here in Austin. It was the first in a long time, but exemplary of how great Austin meetups can be. Video of the meetup is now up here. Slides for this one here under February 2024. The slides of interest here, however take just a little bit more work. They are embedded in this GitHub repository which is not just simply slides, but the subject of the presentation. Thus you can follow the instructions on this repository and launch a web server to see the slides, which are an HTMX example.
I found this very interesting despite not being a front-end developer. I usually tell people “front-end to me is back-end to you.” That is to say that my development experience is more about system software, middleware and such. The closest thing to front-end that I do is either writing command-line utilities for developers or IT admins, or playing with things like TiddlyWiki in an attempt to make more magical documentation. What is really missing without the video of this presentation, however, is the guided tour and commentary that Ted gave while demonstrating HTMX to us.
First, HTMX looks to be just dead simple. Ted commented, “after about an hour your average 13-year-old could be dangerously productive.” I pretty much know some basic HTML from the old days. Add several decades of general hacking in lots of different languages (I dabbled in customized open source builds and spent a decade of being a production build engineer that had to, among other things, often determine if build breaks were a problem in our build environment or something introduced by a development team). And I’ve done just enough JavaScript hacking and playing with TiddlyWiki to be mildly dangerous but definitely not respectable.
I looked at all of this and felt like I was transported back to the old pre-web HyperCard days. Lots of promise, and a bunch of crazy things that were just simple to do, but now instead of being trapped in this little Mac based application, this could be added to a modern web server and with some other basic web skills turned into a powerful yet simple way to produce web content that seemed only accessible to those who live among all of the JavaScript frameworks I have avoided my whole career (TiddlyWiki being the primary exception).
However, being a long enough regular attender of this meetup (I joined and kept coming because I could tell this was a successfully run meetup, and as a junior meetup organizer myself, I stayed to learn those organizing skills), it was also clear to me the demonstration of how much HTMX promises to reduce front-end code bases. Add a couple attributes to your HTML, write your back-end to feed little snippets of partial HTML, and you have just replaced a whole pile of compiled JavaScript framework code… Awesome!
Anyway, a couple days later I run into this gem of a talk called Quit Simplifying by Florian Haas. Slides for that are here and it also importantly refers to this blog post by Mike Hadlow called The Configuration Complexity Clock As I listened to this, I thought about Ted’s talk, and a bunch of other things. I also though about AI, which is also is something Ted is also engaged with at the moment.
I suppose I can also throw in this other talk as well, which seems to me to be somewhat relevant to all of this. These other two talks were shared in a thread in the #_hangops channel of the hangops Slack (introduced to me by the Austin DevOps meetup community) where people were sharing some of their favorite conference talks.
So, now I will list some partially random thoughts related to all of this. I lack a good tool to chart all of the connections and ideas, and connect them to deeper explanations of the ideas I am connecting together, but hopefully this will make some sense to a reader who want to try to piece together the bread crumbs I am leaving here.
In a real sense capability and complexity are interrelated. However, complexity does not always imply capability. Further there are arguably different forms of complexity. It is not unusual for complexities and simplicities to have a trade off economy. That is that we trade certain forms of complexity for other forms of simplicity. At times these trade offs are made for somewhat subjective reasons.
As Ted explained in his talk, HTMX was chosen as part of an attempt to minimize the work required to get certain functionality that was not at the core of what the team needed to accomplish. It also potentially allows the project to remain free of more extensive language and framework dependencies.
If you confine yourself to a certain set of rules then it is very hard to escape the complexity clock Florian presents. However, eventually projects die. One could argue that death is an ultimate form of simplicity. With death there is some hope that in a larger scope unnecessary complexity is eventually weeded out. At the same time the desire for more capability seems to demand complexity. At some point one might also ask the question, “in which context are certain capabilities also unnecessary?”
When you look at complex biological systems you see that there are multiple layers of cycles, and for complex living organisms there are multiple cycles of genesis, life, and death. At the cellular level complex organism grow new cells throughout most of life. These cells live, and eventually die. We shed the materials of dead cells every day. As organisms we also are born, live and die. But beyond that, whole species emerge, live and die out. And growth happens within each of these levels of life. Individual cells work, and divide and even die to accomplish a number of necessary things for the organism. Organisms live and grow, mature, and eventually die. Those processes in the organism also serve a variety of purposes in the lifespan and evolution of a species. Arguably, the evolution of species, their emergence and eventual collapse also seem to generally serve the purpose of propagating life in a resilient and adaptive manner.
I wonder if we view our software through this kind of bigger picture lens if it might change how we feel and think about some of these things. I think that if software is going to become more pervasive and even ubiquitous, then more complexity is necessary, and an evolved ability for us to cope with that complexity as well. I think at some level this is really what the broader DevOps movement in its cultural form is really pointing us towards. However, I also think that the movements tendencies: ever faster cycles, relentlessly building encapsulating and abstracting at the top of the stack, pushing everything to the left, and subjugating everything to automation, these all have their limits. And at some point I believe they will have to moderate back.
Some things will need to die. They might cost too much, they might not serve as well for a broader audience. It might be that the relentless fast pace of progress becomes something people don’t want in certain places. And among other things humans value agency and artistry which are at least in tension with most automation. In fact if you are paying attention, much of the software that is produced dies pretty quickly. Perhaps the death rate is also symptomatic of our pacing. If you have been in the industry as long as I have (almost 30 years for me now), how much of the software you have worked on is still in regular use? That probably varies for many of us, but I can assure you that for many of us much of what we have worked on is already defunct and replaced, though perhaps not without some heritage.
DC - 20240229 - 20240301