Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx Is Composable?

timkellogg.me

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Htmx Is Composable?

#41

Post by BiteCode_dev »

lucasyvas wrote: post #37
BiteCode_dev wrote: post #33

Earlier quoted context omitted.

HTMX users just use existing JS components. It's not an XOR proposition.

But you should be able to distribute bundled backend and frontend logic given its paradigm. There is no guidance on what it would take to do this, or what the interface for the components should be to enable it, or how you should build and share it. Without both, I don't see the point because then you need to potentially mix multiple frontend frameworks unless you are strictly using WebComponents. It's not XOR, but i…

No, that's not the purpose nor the scope of HTMX. This is thinking in term of other types of web framework, but it's not the design of this tool.

Since it's neutral to the backend or scripting tech you chose to use, it cannot, and should not, step into that realm.

It provides a more simple, basic service.

You may be tempted provide a django template + view + htmx reusable component.

Or a rail enpoint + htmx reusable component.

But that would not be universal, it would be super specific. Maybe useful in your company, across team, but that's it.

Re: Htmx Is Composable?

#42

Post by lucasyvas »

BiteCode_dev wrote: post #41
lucasyvas wrote: post #37

Earlier quoted context omitted.

But you should be able to distribute bundled backend and frontend logic given its paradigm. There is no guidance on what it would take to do this, or what the interface for the components should be to enable it, or how you should build and share it. Without both, I don't see the point because then you need to potentially mix multiple frontend frameworks unless you are strictly using WebComponents. It's not XOR, but i…

No, that's not the purpose nor the scope of HTMX. This is thinking in term of other types of web framework, but it's not the design of this tool. Since it's neutral to the backend or scripting tech you chose to use, it cannot, and should not, step into that realm. It provides a more simple, basic service. You may be tempted provide a django template + view + htmx reusable component. Or a rail enpoint + htmx reusable…

That's OK - but then I'd say I'm not interested in it based on its project scope.

I have enjoyed it for small demos but I wouldn't pitch it to my company to use in the real world based on its philosophy.

Re: Htmx Is Composable?

#43

Post by Terretta »

Feedback to author:

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:

https://fossil-scm.org/home/doc/trunk/www/index.wiki

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

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:

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

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:

> With fossil plugins, it’s become straightforward to work on any part of the stack:

- UI elements — write verbatim HTML or Jinja templates, packaged into a plugin

- API endpoints — register them via a decorator API

- DB tables — Create them during plugin initialization

- AI algorithms — register them via the API

- fossil

> That’s neat. The whole stack.

I'd edit three things:

+ "...social media client for Mastodon I call ‘Fossil’ that displays my feed..."

+ "With plugins for my Fossil app..."

+ "- fossil mobile app"

Re: Htmx Is Composable?

#45

Post by recursivedoubts »

lucasyvas wrote: post #30

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". This is definitely possible, but unless you are using WASM or something you would have component libraries specifically built for a backend language or…

my position is that components for htmx are simply components for HTML: they should integrate with the DOM in the standard manner: attributes, input values and standard JavaScript events.

It doesn’t make sense to talk about “htmx components”, there are only html components that should play well with anything that respects the core web platform: unpoly, Hotwire, twinspark, data star, alpine Ajax or, heaven forbid, a vanilla HTML form.

I recognize this may hinder htmx adoption.

Re: Htmx Is Composable?

#46

Post by BiteCode_dev »

lucasyvas wrote: post #42
BiteCode_dev wrote: post #41

Earlier quoted context omitted.

No, that's not the purpose nor the scope of HTMX. This is thinking in term of other types of web framework, but it's not the design of this tool. Since it's neutral to the backend or scripting tech you chose to use, it cannot, and should not, step into that realm. It provides a more simple, basic service. You may be tempted provide a django template + view + htmx reusable component. Or a rail enpoint + htmx reusable…

That's OK - but then I'd say I'm not interested in it based on its project scope. I have enjoyed it for small demos but I wouldn't pitch it to my company to use in the real world based on its philosophy.

That's how engineering is supposed to work: you get to decide what to use based on your problems and the nature of the solutions.

Beyond the memes, this one Montana guy is very reasonable.

Re: Htmx Is Composable?

#47

Post by wg0 »

thomassharoon wrote: post #29
wg0 wrote: post #21

Earlier quoted context omitted.

>not everything needs the window url to be updated. The user needs it to be. It is the single most important handle of information for a layman. Of copying and pasting URL to someone else so that's kinda should be non negotiable for any pro user developer/engineer. I find React to be too convoluted through its evolution multiple times over (plus the virtual DOM and horrendous ergonomics of hooks) but at the time, I'm…

> But honestly, torn towards htmx but undecided. We are in the middle of migrating from our monster react application into server rendered pages (with jinja2). The velocity at which we are able to ship and the reduction of complexity has been great so far. Managing client side state for simple things like (is the dropdown open/closed), listening to keyboard events and such can be done with something like alpine-js [1…

I have not prototyped anything but I think that alpine-js + htmx can go long way for such apps. Especially, this is pretty interesting idea [0]

React... might be good but I am too weak to handle all that comes with it.

[0]. https://devdojo.com/pines

Re: Htmx Is Composable?

#48

Post by recursivedoubts »

lucasyvas wrote: post #42
BiteCode_dev wrote: post #41

Earlier quoted context omitted.

No, that's not the purpose nor the scope of HTMX. This is thinking in term of other types of web framework, but it's not the design of this tool. Since it's neutral to the backend or scripting tech you chose to use, it cannot, and should not, step into that realm. It provides a more simple, basic service. You may be tempted provide a django template + view + htmx reusable component. Or a rail enpoint + htmx reusable…

That's OK - but then I'd say I'm not interested in it based on its project scope. I have enjoyed it for small demos but I wouldn't pitch it to my company to use in the real world based on its philosophy.

And yet, and yet:

https://htmx.org/essays/a-real-world-react-to-htmx-port/

Re: Htmx Is Composable?

#49

Post by sesm »

betenoire wrote: post #44

Something about this feels really at odds with all the "locality of behavior" virtue the creator/maintainer often promotes.

Yep, and as soon as you need non-local updates, the whole concept of HTML-over-the-wire starts breaking down. I really like this HN comment on this topic: https://news.ycombinator.com/item?id=38081174

Re: Htmx Is Composable?

#50

Post by zaphod420 »

mejutoco wrote: post #12
larve wrote: post #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 t…

I think the key feature of htmx that often people overlook is that you can update several elements with one html response The attribute is the following: https://htmx.org/attributes/hx-swap-oob/

Oh, I was wondering how to do this with HTMX! I wish the documentation was more verbose, and had some examples. It's a little hard to understand how to use with how minimal the docs are.

edit: just found the example. https://htmx.org/examples/update-other-content/

Post reply on HN