I am working on a awesome-python-htmx, seeking your feedback

[benjamin-kirkbride]

A few of us at PyCon this year got together and brainstormed a new Web Stack that we are calling PyHAT (Python, htmx, ASGI, TailwindCSS). The first thing we set out to do is create awesome-python-htmx; a collection of active tools/libraries/projects in that space.

I like the look of your project, specifically I like that it is trying to be more general (most other projects in this space are build specifically for one framework), but it seems development may have stalled?

In addition to that, if you could also participate in PyHAT-stack/awesome-python-htmx#1 that would be greatly appreciated!

[florimondmanca]

Hi @benjamin-kirkbride

Thanks for the heads up!

I haven't given this much extra functionality since the last pass, indeed.

This is basically because I didn't get the chance to have a use case off of which to work on.

Professionally, I've been brought to the PHP world lately. It's a fun detour. We did go the "HTML on whatever you like" ("HOWL stack") route on one project, although with Turbo instead, as Symfony provided out of the box integration with that.

From initial experiments, I anticipate there's not much that can be done with Turbo that can't be done with htmx.

We do like the opinionated aspect to Turbo, though. Because we don't do SPA or JS as much doesn't mean we should be able to do anything we like and break expected behaviors or spec expectations. Experiments have hinted me that it's easier to do broken things with htmx. And I'm not sure alleviating our JS fatigue with broken experience for some users is a net positive.

E.g. from an a11y perspective, there's things to do if you decide to treat a <div /> like a link or like a button — like setting an appropriate role, ensuring there's an appropriate visible name, adding aria-controls for the region of the screen it will update, etc. Yet I didn't see this considered by htmx much, if at all. Turbo doesn't really tackle a11y either, sadly, but the needs there are less urgent because it relies on the built-in <a /> and <form />, which are easy to make accessible when used correctly. So, once you strip the "I can hx-get on whatever element" bit and stick to <a /> and <form /> + <button type-"submit" />, I'm not sure there's much in htmx that's not in Turbo. So yeah, that's how we went.

That being said, I enjoy seeing the Python community expand and structure its "but HTML over the wire was nice" faction. :)

Like most of my asgi-* packages, the aim was indeed to keep a framework-agnostic approach and provide an htmx integration with ASGI the spec.

I believe this is more relevant in some cases than others. In the case of htmx, the need for language-specific integration seems fairly reduced, doesn't it?

I tend to agree with the comment here, even with "Turbo" replaced with "htmx" and "Django" with "ASGI / whichever framework": hotwire-django/turbo-django#78 (comment)

The vast majority of Turbo's benefits can be realized without an additional library. And what we need even more at the moment is a library of patterns with demos on how to best implement Turbo in a Django project.

[benjamin-kirkbride]

@florimondmanca thanks so much for your well thought out response.

This is basically because I didn't get the chance to have a use case off of which to work on.

A lot of projects in this space have suffered a similar fate, so I'm not surprised to hear this.

From initial experiments, I anticipate there's not much that can be done with Turbo that can't be done with htmx.

I think this is true as well :) though it seems like (understandably) on the Python Side, htmx has more mindshare, for better or worse.

We do like the opinionated aspect to Turbo, though. Because we don't do SPA or JS as much doesn't mean we should be able to do anything we like and break expected behaviors or spec expectations

This is part of what I hope to address with this initiative. There are projects out there building solutions that help address this, as well as people creating reusable patterns, but the efforts are very disparate at this time. Projects like https://www.forgepackages.com/docs/forge-htmx/ encourage sane, standards compliant behavior.

from an a11y perspective...

This is a great point, and something I don't see discussed much at all. Probably should carve out a section to discuss this. Unfortunately I don't think I'm qualified to discuss it intelligently, so I will either need to find someone who can (wink wink nudge nudge) or spend some time figuring it out.

I enjoy seeing the Python community expand and structure its "but HTML over the wire was nice" faction

Yes, PHP is way ahead of Python on this train, but we are getting there!

Like most of my asgi-* packages, the aim was indeed to keep a framework-agnostic approach and provide an htmx integration with ASGI the spec.

Do you happen to know if it works with Django? My understanding is Django can run on ASGI, but my guess is there are too many asterisks to have this work out of the box.

In the case of htmx, the need for language-specific integration seems fairly reduced, doesn't it?

Depends on what you want. See forge-htmx above for instance. Another example is most Python templating engines don't support partial rendering by default, so unless you are okay with a million template fragment files, you need some tooling.

It's not really about htmx per-se, really more general to HOWL not being a pattern anyone is thinking about when building frameworks.

---

Again thanks so much for your detailed response. I realize you are not working on PyHAT-type projects right now, but you certainly have a lot of insight into general HOWL principles, and I would really love if you were involved in the initiative, even if just to keep us noobs to the architecture in check ;)

Discussion to introduce yourself: PyHAT-stack/awesome-python-htmx#2

Discussion calling people to action and laying out our needs: PyHAT-stack/awesome-python-htmx#1

[benjamin-kirkbride]

I agree with this approach, broadly: https://github.com/spookylukey/django-htmx-patterns/blob/master/approach.rst

But I think that not every developer needs to go through the same "step 2 at least 3 or 4 times" for someone (us) to come up with some helper libs/meta frameworks.