Hacker News Reader

Hacker News

Comment by andybak | Hacker News Reader

Parent Full thread

andybak

That was the first thig I wondered too.

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.

View on HN

Most of these also apply to HTMX it seems.

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 feel the need to use lit-html? Just interested in the use-case.

I am not the original poster, but I use lit-html to make the interactive elements on the page like tabs and modals. Then I use HTMX to load the contents of those elements when the tab or trigger is clicked.

That's one of the reasons TwinSpark got actions, you still need little bits of client-side interactivity.

I find things like actions is great for conditionally showing and hiding form fields or small things like that, but if you want to have accessible tabs and modals it is best to bundle it up in a component. Here is an example of a lit components I use, https://codepen.io/megaman821/pen/GRXmzZb and https://codepen.io/megaman821/pen/dydvxBE

This doesn't answer the question "why not bring this inside htmx or unpoly", and now as a developer I need to again check if I need to port over a new framework or not

Two reasons really: I wrote it before htmx appeared, so it already existed and a few projects were using it in production. And second one - I really hate attribute inheritance, and it’s everywhere in htmx…

The blog post hints at the first point, but I didn't know about the latter, so thanks for the details !

> now as a developer I need to again check if I need to port over a new framework or not

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.

Reply on news.ycombinator.com