Htmx always sounded nice and I always wanted to give it a try - yet, paradoxically, I always had my reservations about it on the conceptual level.
With something like Elm, I'm basically thinking of the frontend as a state machine (composed of smaller state machines). I always know what's [supposed to be] going on exactly, and assuming that all the underlying machinery is working as expected and that I haven't messed up anywhere, I can be sure that everything is consistent. Basically, things are data-driven.
Htmx feels like a step back in this regard. Let's say https://htmx.org/examples/delete-row/ - something back in my mind yells at me that I don't really know what I'm presenting in that table. The state is in DOM, all "inverted" as the frontend is not really aware what it's displaying (it can figure it out by introspecting the DOM, but that's exactly what feels off). I'm just concerned that it'll end up like my ancient Delphi or Visual Basic projects, where it was impossible to understand what's going on, because everything got tangled up in a ball. This is opposite of data-driven approach that I don't really know a name for... "shape-driven"?
I look at examples like https://htmx.org/examples/sortable/ and I just can't shrug off the feeling that with such design the frontend has no idea about what's going on, and while it's fine if all I ever need is a small sorted list (that I can pull back from DOM - which acts like a weird pseudo-database), if it grows it becomes error-prone, difficult to comprehend and maintain.
I suspect this is because HTML was always about documents, and never about interactive applications, so there's this fundamental impedance mismatch when one tries to build an application in a browser. I thought the solution was to build a new abstraction replacing HTML - with things like React being intermediate steps, still using HTML/CSS for rendering, and canvas-based GUIs being the way to go, unburdened by the document-based foundations anymore. In other words, I'm not really convinced that Hypermedia is a suitable foundation for a lot of the things people actually build online.
Htmx surely has appeal in simplicity, but doesn't this simplicity brings back all the complexity people tried to get rid of all this time? Is there something I'm missing? Should I possibly think of the frontend as a terminal-like system that can run small programs but is not an application so it's never aware of what's going on? Or is it something else?
My apologies for the confusion, or if I wrote something weird (I sure babbled a lot). I'm just trying to keep up with the world and understand it.
(And, of course, no doubt, one can write crappy incomprehensible mess of a codebase using any technology. Maybe all my issues is that I have no idea how to write good Htmx code that wouldn't bloat and rot over time?)
> Should I possibly think of the frontend as a terminal-like system that can run small programs but is not an application so it's never aware of what's going on?
Kinda? Where HTMX sits in my head is on a different evolutionary path starting from server rendered pages back in the 1990's. Instead of doing full page renders, HTMX lets us update discrete portions of the DOM from server rendered content... and that's all. It's like heavy client JS apps never existed. IMO, the key here is that the browser is assumed to be mostly just for display, and the backend is still expected to be inside the user interaction loop.
The last time I tried to do anything with HTMX, the technology practically resisted any attempt to add any substantial state management on the client-side (which is kinda/sorta by design). As you mention, complex controls that do this like fully-featured tables, are a poor fit. It's possible, but not elegant or easy. Meanwhile, fetching an updated fragment from the server to do those kinds of jobs on user input, is trivial. It's super inefficient for bandwith, but way easier to code and maintain (IMO). To me, that's the core tradeoff here.
The server-rendered web app (without htmx, think crusty PHP router admin panel) is actually very similar to the Elm architecture.
The database is the Model.
The server is the update function.
The HTML template is the view function.
HTTP requests are the Msg.
Database/API calls are the Cmd.
The problem with this model is that recreating the whole UI every time is slow and clunky.
Elm and most JS frameworks fix this by running the `Model` and `update` function on the user device and doing tree diffing. This is reasonably performant if you do it well, but it's also hard to do well (see: every website ever these days) and introduces complexity, particularly because the client-side `Model` almost always needs to be synchronized with a database or some other "canonical" model.
As pragme_x touched on in a sibling comment, what htmx does is not an iteration on the framework model; it's an alternate solution to the original problem. What it does to avoid the clunkiness is let the server to return `Delta HTML` instead of `HTML`, and for the slowness, it leaves the vanilla-JS escape hatch open for things that can be done without altering the Model (database). This model also has its flaws, especially if you need to use that escape hatch a lot, but it's also a lot simpler conceptually and keeps the `Model` and `update` function in a trusted computer, meaning you don't need to marshal and validate stuff between two models.
> how to write good Htmx code that wouldn't bloat and rot over time?
- Don't try to perform fine-grained updates if you don't have to. It's fine to replace a little more than you absolutely need to, and htmx takes care of some of the things you might worry about like preserving focus. For example, in the "delete row" example, it might be more robust to replace the whole table.
- Use htmx for anything "side-effecty", i.e. anything where a network request is compulsory. Relegate JavaScript to "micro-interactions". I consider a code smell in an htmx application any time I need to add new elements to the DOM via JavaScript, most of it should be manipulating classes, attributes and styles.
- For those micro-interactions, the "component" model heralded by the big three JS frameworks doesn't work as well here, since components have their own state, which is another "shadow-Model". Instead, try the RSJS methodology (https://rstacruz.github.io/rsjs/) with "behaviors".
- To wire up that JS to your app, reach for custom events. The `hx-trigger` attribute is the "port" that translates JS-based interactions to Msg.
> I suspect this is because HTML was always about documents, and never about interactive applications
This is a really common refrain and it peeves me, but I don't have a good rebuttal to it yet so I won't weaken my comment by trying to make one. I don't have good explanations for a lot of things about htmx and hypermedia, actually. The code of htmx is mostly complete, but the theory is still WIP.
With something like Elm, I'm basically thinking of the frontend as a state machine (composed of smaller state machines). I always know what's [supposed to be] going on exactly, and assuming that all the underlying machinery is working as expected and that I haven't messed up anywhere, I can be sure that everything is consistent. Basically, things are data-driven.
Htmx feels like a step back in this regard. Let's say https://htmx.org/examples/delete-row/ - something back in my mind yells at me that I don't really know what I'm presenting in that table. The state is in DOM, all "inverted" as the frontend is not really aware what it's displaying (it can figure it out by introspecting the DOM, but that's exactly what feels off). I'm just concerned that it'll end up like my ancient Delphi or Visual Basic projects, where it was impossible to understand what's going on, because everything got tangled up in a ball. This is opposite of data-driven approach that I don't really know a name for... "shape-driven"?
I look at examples like https://htmx.org/examples/sortable/ and I just can't shrug off the feeling that with such design the frontend has no idea about what's going on, and while it's fine if all I ever need is a small sorted list (that I can pull back from DOM - which acts like a weird pseudo-database), if it grows it becomes error-prone, difficult to comprehend and maintain.
I suspect this is because HTML was always about documents, and never about interactive applications, so there's this fundamental impedance mismatch when one tries to build an application in a browser. I thought the solution was to build a new abstraction replacing HTML - with things like React being intermediate steps, still using HTML/CSS for rendering, and canvas-based GUIs being the way to go, unburdened by the document-based foundations anymore. In other words, I'm not really convinced that Hypermedia is a suitable foundation for a lot of the things people actually build online.
Htmx surely has appeal in simplicity, but doesn't this simplicity brings back all the complexity people tried to get rid of all this time? Is there something I'm missing? Should I possibly think of the frontend as a terminal-like system that can run small programs but is not an application so it's never aware of what's going on? Or is it something else?
My apologies for the confusion, or if I wrote something weird (I sure babbled a lot). I'm just trying to keep up with the world and understand it.
(And, of course, no doubt, one can write crappy incomprehensible mess of a codebase using any technology. Maybe all my issues is that I have no idea how to write good Htmx code that wouldn't bloat and rot over time?)