Live data from Hacker News

Htmx Is Composable?

timkellogg.me

1–10 of 69 posts

Re: Htmx Is Composable?

#2
> 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.

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.:

services.AddTransient();

services.AddScoped();

services.AddSingleton();

// etc for many lines

This is definitely no worse than XML.

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.

Re: Htmx Is Composable?

#3
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.

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.

Re: Htmx Is Composable?

#4
This reminded me that one thing I miss from WPF is the "free" render-time polymorphism.

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.

Re: Htmx Is Composable?

#5

> 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. In .NET anyway, this was replaced by use an Inversion of Control container with configuration as code. Because it's more flexible if you…

I also don't think it's out of style if you have a .Net monolith. It's already there; there's no need to include or install anything. So people use it. It's a little too much magic for my taste, but people like magic.

Re: Htmx Is Composable?

#6
post #5

> 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. In .NET anyway, this was replaced by use an Inversion of Control container with configuration as code. Because it's more flexible if you…

I also don't think it's out of style if you have a .Net monolith. It's already there; there's no need to include or install anything. So people use it. It's a little too much magic for my taste, but people like magic.

In my experience in .NET recently, Inversion of Control containers are as popular as ever; typically just using the one that's "already there".

But it's the "config as a XML file" that is right out of style, in favour of config as code, for the reasons given.

Re: Htmx Is Composable?

#9

The author of the article needs to read this https://youryoure.com/?its

Sometimes people are just in a rush or just a bit careless, much like you were here: https://news.ycombinator.com/item?id=38879565 . It really isn't the end of the world.

Glass houses, and all that.

Post reply on HN