The React Monolith & HTMX (?!) Captain's Log: Part 2

What if you could render HTML in a more expressive language (say, perhaps JavaScript?) but still have it yield semantic UI elements that render in any browser?

That was the original value proposition of React. Over 10 years later and I'm still writing React code, so I'd say it delivered pretty well on this aspirational concept. People don't use Handlebars because React did it better. Solid.js at it's core leans on this strength, and largely takes nothing away, only adding a better and more modern internal engine for handling this highly dynamic UI capability.

After working primarily with React for so long, and then pivoting to HTMX recently for Meet Near Me , I finally hit my first speed bump where I wanted something that React made easy, but is not very straightforward or intuitive with HTMX.

I think it's so common in user interfaces these days to have these big monolithic interfaces that do a million things. A really common example would be a "settings" admin interface.

What I've seen in the past is a tendency to just jam this all into one monolithic state machine that has a UI representation which is deeply nested and reflects this complex object representation of valid configurations.

I was working on something more along the lines of a multi-step wizard UI. To some degree, the principle of HATEOAS (hypertext as the engine of application state) holds up well in this use case, returning the next step in the flow in response to an hx-post from HTMX, assuming the previous was successful.

But what about going backwards in the flow? What about updating the step indicator in the wizard?

This was the first time I pondered to myself "Do I need React after all?!" ... when you're a hammer, everything is a nail of course.

I think I have a solution but I want to talk about something different.

The ability to have everything represented in a clean way because it's all in a single JavaScript file is misleading. Just because you can create a big complex state machine and represent many permutations of UI, doesn't mean you should.

I'd go even further and say that this allure has been leading people away from the importance of making a trip to the server periodically to break up your gigantic UI state machine into reasonably chunked commits.

If you're able to represent a thousand UI permutations without a server interaction and validation on the server and you don't need to distribute that complexity among smaller micro UIs (something I've seen a lot of, and been guilty of), you ultimately end up with a failure in terms of separation of concerns.

Sure, there's a line of reasoning to say that this whole thing generates a single object that represents the potential states of the user settings. The API may even accept your massive user settings objects. But there's something important being overlooked here, just because you can define a concept as a bucket for something, doesn't mean it serves as a good unit for delineation.

In other words, if your user settings admin UI is an object with 500 nodes nested 4 deep, you need to find some other way of bucketing that conceptually so that you don't end up with a gigantic Java class that does everything.

And when you split that out in a way that makes the number of items in the collection a bit more manageable, you end up with micro UIs that don't necessarily need that level of complex abstraction that React tends to lead to.

That's the HTMX captains log for today, anyway. Who knows where we're headed next!