You are right about changingsupport for niche but...
if the tool is easier to understand probably it is also less massive and easier to interact/find workarounds when needed than if you work on top of several layers + huge dependencies. At least that is my experience and why, in the face of choice and when it makes sense, I would choose htmx over React.
It is easy to understand and a thin layer you can figure out even what it is doing under the hood. I cannot say the same about React, which is much more complicated. Sure it has good use cases. But it is more difficult to understand and potentially drags a lot of deps inside.
I see every dependency on an app as introducing some risk: the more of them, the worse. They can break, they can go unmaintained, you can have a trnsitive dep that is compatible with one package but incompatible with another (this happened a lot to me with node) and that propagates recursively. It can be a hell to the point that making things work can get difficult.
So at the end, if you can do something with a couple of deps and some htmx/standard web stuff and a bit of hyperscript or similar here and there, chances that things will keep working for the years coming are higher. Also, if something gets outdated there is a tiny layer to replace you can do it more easily.
Yes, it's a tradeoff. Picking up a DSL is probably faster and easier than learning an entire new language. But knowledge about that DSL is also not as readily transferrable and it's much harder to hire for someone already familiar with a DSL than one of the most widely used languages. Of course in turn you probably want a much higher level of expertise in that language than would be necessary in a DSL you can learn (and, to some degree, master) in a fraction of the time.
if the tool is easier to understand probably it is also less massive and easier to interact/find workarounds when needed than if you work on top of several layers + huge dependencies. At least that is my experience and why, in the face of choice and when it makes sense, I would choose htmx over React.
It is easy to understand and a thin layer you can figure out even what it is doing under the hood. I cannot say the same about React, which is much more complicated. Sure it has good use cases. But it is more difficult to understand and potentially drags a lot of deps inside.
I see every dependency on an app as introducing some risk: the more of them, the worse. They can break, they can go unmaintained, you can have a trnsitive dep that is compatible with one package but incompatible with another (this happened a lot to me with node) and that propagates recursively. It can be a hell to the point that making things work can get difficult.
So at the end, if you can do something with a couple of deps and some htmx/standard web stuff and a bit of hyperscript or similar here and there, chances that things will keep working for the years coming are higher. Also, if something gets outdated there is a tiny layer to replace you can do it more easily.