HTMX is neutral to composability, since it's limited to connecting and orchestrating parts of a system that may or may not chose to provide components.<p>Does your backend has components? Does your scripting toolkit has components?<p>HTMX doesn't care either way, and will use whatever you give it.<p>You can pick reusable django forms, alpine js, some manually created boundaries, a jquery module... You can even drop react on a single page because there is a widget you like and it's not loaded often.<p>People may be tempted to talk about HTMX using irrelevant points of references.<p>It's not providing an SPA with a component architecture, that's the point.<p>The readers that are very used to modern JS stacks and never had to deal with the web before 2010 may want to read:<p><a href="https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1" rel="nofollow">https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1</a><p>This will give a better idea of how to think in HTMX, which is just a new trick for an old dog.<p>It's better to use this tool for what it is, with its limits and strengths rather than trying to make it into something it's not.<p>The reason HTMX can't do many things react is good at is because it's by nature the opposite of react.
One thing I see lacking with HTMX is that, eventually, someone will want to package and distribute a third party component. You say "but it's meant for small things not requiring much scripting" and I say "I don't believe you - once it's in it will grow indefinitely".<p>This is definitely possible, but unless you are using WASM or something you would have component libraries specifically built for a backend language or framework which doesn't leave us much better off.<p>To be fair, I have not seen this stated as a goal or concern of HTMX anywhere. But, it's a concern of mine - I'm not going to build all my components from scratch all the time and this kills HTMX for me.<p>I guess what this would look like is an encapsulated backend module with internal templating and properties that allow controlling certain behaviours or routes. Definitely doable, not thought out at all.
I am confused about htmx because if it is about AJAX, they don't replace the window URL as user clicks about and around unless you explicitly tell HTMX to do so.<p>And if you step into that realm of keeping the window URL in sync with where exactly the user is in the app, then you're almost already into realm of SPAs but without having the full set of tools that go with SPA.<p>Any open source project done in HTMX that has gone beyond TODO/LLM front ends etc could be interesting to look at
> Years ago, in .NET and Java, it was popular to use an Inversion of Control container with XML configuration that declared and configured different classes and objects. I think it largely went out of style because it’s complicated, or at least more complicated than it needed to be.<p>In .NET anyway, this was replaced by use an Inversion of Control container with configuration as code. Because it's more flexible if you need that. And if you don't, it's just a boring (in the good sense) list of e.g.:<p>services.AddTransient<IFoo, FooService>();<p>services.AddScoped<IBar, BarService>();<p>services.AddSingleton<SomeType>();<p>// etc for many lines<p>This is definitely no worse than XML.<p>It's now as simple or as complicated as you want it to be. Using the same tools as the rest of the app code rather than a different syntax.
I'm not sure I fully understand the composable part. To me this seems like server-side rendered HTML on the one end (which indeed makes it easier to debug), and a react version on the other end. React would instead of passing the object directly to the renderer (as one can do when doing it all in one process), have some fetching mechanism.<p>In terms of composability, react seems more composable to me. I can delegate the distributed and state aspect to something like redux / redux query, and fully concentrate on the composable component system. The added benefit is of course to separate backend and frontend concerns, which might or might not be to your like or useful within a certain project's scope.
This reminded me that one thing I miss from WPF is the "free" render-time polymorphism.<p>If you had an interface, say ICard, and a few xaml data templates for how to render the concrete types, all you had to do was bind to a collection of ICards and it would automatically do what I guess we'd now call pattern matching on the concrete type of each element to render it without needing to mix the presentation with the plain old c# objects.
For the folks who have been writing these inline HTML views and been wishing to have a more composable way of generating HTMX like in this blogpost try <a href="https://github.com/maxpert/htmxido">https://github.com/maxpert/htmxido</a>
I couldn't get it to work with single-spa, which is what our company's UI framework uses to compose components built by different teams.<p>It seems like the two approaches are at odds with each other anyway, so perhaps this won't ever be possible.
> HTMX as Configuration<p>Bam, there you are, can't make programs with just configuration, that's a wet dream.<p>The article also mentions IoC configuration, which is a horrible way to program, another thing that is only good on paper.
Feedback to author:<p>The diagram and explanation took a beat longer than normal to scan, since this buries a bit that it's not about the beautiful source control system called fossil shipped as a composition of modules:<p><a href="https://fossil-scm.org/home/doc/trunk/www/index.wiki" rel="nofollow">https://fossil-scm.org/home/doc/trunk/www/index.wiki</a><p>Great diagrams, so of course that's the first thing a reader will skim. Reader thinks people build things based on git all the time, the diagram looks like it's based on fossil, cool, scan more...<p>Making it take a bit longer when scanning upwards from the diagram, the Mastodon client is introduced without naming it until an aside at the end of the paragraph:<p>> <i>Before the New Year I decided to hack on an idea. I wanted a social media client for Mastodon that displays my feed in a way that suits me ... I call it Fossil.</i><p>If you missed that at the end and scan back down to the arch section, it mentions fossil without really saying it's the social media app:<p>> <i>With fossil plugins, it’s become straightforward to work on any part of the stack:</i><p><i>- UI elements — write verbatim HTML or Jinja templates, packaged into a plugin</i><p><i>- API endpoints — register them via a decorator API</i><p><i>- DB tables — Create them during plugin initialization</i><p><i>- AI algorithms — register them via the API</i><p><i>- fossil</i><p>> <i>That’s neat. The whole stack.</i><p>I'd edit three things:<p>+ "...social media client for Mastodon I call ‘Fossil’ that displays my feed..."<p>+ "With plugins for my Fossil app..."<p>+ "- fossil mobile app"
The author of the article needs to read this
<a href="https://youryoure.com/?its" rel="nofollow">https://youryoure.com/?its</a>