In case you didn't spot this part:
> Some reasons why TwinSpark exists despite HTMx and Unpoly (those are similar in approach):
>
> It’s really small (8KB .min.gz).
> There is no attribute inheritance — keeps surprises away.
> Batching - very useful if you want to use HTTP caching effectively, while maintaining some personalisation for your users.
> Bundled - a lot of practical stuff packed in, like actions, or non-traditional event triggers, or morphing.
> Extensibility - you can easily register new directives the same way those in core are registered.
I think a bigger difference is that TwinSpark seems to have some integrated DOM manipulation, so it's a bit bigger in scope and less opinionated?
HTMX on its own is great as long as you stay within its philosophy of rendering things on the server.
But most UIs I write need - as in it's optimal for UX and performance or out of necessity because it's talking to a third party - at least _some_ parts to be fully client side rendered.
I personally found that combining HTMX with something like lit-html is kind of the sweet spot for a lot of projects assuming full-stack development. These are very small/light libs that cover a ton of ground with minimal surprises and very good performance per default. The _only_ downside is that you don't get isomorphic rendering code but I happily pay that relatively small cost for having such a simple dependency graph.
Why do you "need to"? Use what works for you. Glance over new stuff and dig deeper if some aspect of it appeals to you. And if the churn stresses you out then don't.