tl;dr Living with annoying technological constraints might be less costly than maintaining the sophisticated workarounds we create to avoid them.
I really enjoyed this well-reasoned article explaining why htmx, the open-source hypermedia JS framework, does not have a build step.
I liked that the premise – “we don’t have a build step” — is not presented as a universal truth for its readers — “therefore you shouldn’t have a build step”.
Instead, the author outlines the benefits and tradeoffs of their approach. The article is not, “This is what everyone should do”, but rather, “This is what we do for this project for these reasons and with these trade-offs, which fits our context. Perhaps you might be in a similar situation.”
The htmx DX is very simple—your browser loads a single file, which in every environment is the exact same file you wrote. The tradeoffs required to maintain that experience are real, but they’re tradeoffs that make sense for this project.
Granted, the power to cheat entropy by writing code as it will be run comes with a cost — and that cost is often paid by you the programmer. Perhaps that is why we have so much “innovation” in the DX space: to make our lives easier (but not necessarily our websites better).
In fact, it almost makes you wonder if all the innovation in DX and web tech has a parallel to those startups which solve trivial problems that only address the superficial annoyances of our lives, like being able to order any food at any hour and have it delivered directly into your lap. Or a machine to squeeze juice out of a bag. Living without those is annoying to my laziness, but in lived experience it’s not that big of a deal.
I love the pragmatism here. “While not being able to use shiny new thing is incredibly annoying, in practice it’s not that big of a deal.”
And I haven’t even got to the “no build step” part yet!
There’s a cost to writing code that must be transformed before it can be run, and (as Rich said) I think people are in denial about the costs toolchains impose on them — or maybe even unaware of them.
Maintenance is a cost paid for with labor, and open-source codebases are the projects that can least afford to pay it
As the author notes, a big reason we’re (willingly or unknowingly) blind to the costs of our toolchains is because we hold this unspoken belief in technology that change, any change, constitutes progress.
the tendency of software engineers to view progress as a teleology of capability rather than choices with tradeoffs sometimes blinds them
But that blinds us to so many of our own ailments — “Doctor it hurts when I touch here / then don’t touch there!” For example, sometimes we are so willing to pickup and use the gateway building blocks to complexity in order to avoid the slightest bit of annoyance.
Modules are really useful.
Sometimes, however, you want to solve simple problems, or at least relatively simple problems. In those cases, it can be helpful not to use the building blocks of more complex software, lest you emulate their complexity without creating commensurate value.
Perhaps a little constraint could go a long way. As Devine said, “I don't think we've even begun to scratch the surface with what can be done with little.” Especially at the cost of a little annoyance to ourselves.