@User I recently swapped several pages over to HTMX. In just a few minutes had live search working, basically just copying the example on the HTMX site. Also have page that uses load-polling and a HX-Trigger-After-Settle header. All very easy, highly recommend. I did use the django-htmx extension to make detecting the requests easy

Nice I'll test it out and give feedbacks too

It also has an example app with a couple of patterns!

It's a good post, just beware it predates hx-headers, which is an easier way of setting the CSRF token - https://github.com/adamchainz/django-htmx/blob/main/example/example/templates/csrf-demo.html

I've just started using htmx in a, supposed medium size, Django app. So far, 3 screens in and 1 form down, seems a breeze to work with.

Yep, mixing HTMX into my django projects has simplified so much that I didn't realize was frustrating me to begin with. I really cannot say enough good things about this combo. I have cut out significant chunks of jquery and js that I wasn't super comfortable with, and get the same functionality with a few hx-attributes on my html elements. There are a bunch of good examples and articles on HTMX here (https://github.com/rajasegar/awesome-htmx) - several of which are django-specific or are easily adapted to django.

Just watched this video last night and thought it was distantly related to the ideas of htmx. This library is called HashQL, basically what is does is that create a single endpoint on the server (like GraphQL) but it lets you write full SQL queries on the client. Then at build time it will replace your client side queries with a hash representation of every query and store them on the server. That way the client code is safe from modification and your queries are somewhat protected since just a hash is exposed on the client. This video goes into a little more detail, worth the time.

The nice thing about HTML (and APIs like REST) is that you have some idea from the path what is expected to happen and maybe what is expected to be returned. This makes the api somewhat transparent and open (something that in many cases, but maybe not all, is a really good thing). Having a single endpoint and passing in a bunch of hashes seems like a weird direction for the web. Is the point "security through obscurity"? Either way, pretty interesting project. I'm just not sure the ideal use-cases for it, but the author seems enthusiastic and there's probably just something I'm missing.

Hope that doesn't sound overly-negative. It's not for me, but I'm sure someone more knowledgeable than me will find good uses for it.

I think the idea of the project is to offer an alternative to GraphQL. Which has it's own query language that you can use on the client. What I think is interesting that in general having a powerful query language on the client is a good thing. It basically admits that most SPAs end up not having REST backend but a collection of custom made endpoints to optimize every view/screen of an SPA or mobile app. I like this project in particular because it actually recognizes that most SPA/mobile app backend don't actually have standard REST APIs and require constant development on the backend. This is just more direct: "here, just use SQL". Also the approach of producing hashes for the client side is interesting because in theory you could change the query on the backend that corresponds to a hash in order to optimize if necessary. An important point is that this kind of approach might require row level security which is not very common. Security is not a feature, in fact, I think that the main question for this approach is if it can be made secure and if security vulns can be easily introduced by accident.

Yeah, the security considerations of GraphQL make my mind melt. I had a hacker news fight with a guy from Facebook about it back in the day and wrote a blog post on it: https://intercoolerjs.org/2016/02/17/api-churn-vs-security.html

These ideas are pretty much the concept of BFFs (Backend for Frondend).

yup, but I have never seen an approach for real SQL on the client side, it’s a cool idea and simplifies a lot of aspects about SPA developmet

does htmx have a common way to handle debounce/throttle?

I can do this with Alpine, but just wondering if there's something in htmx

@User you mean, on a field: https://htmx.org/examples/active-search/

oh great "keyup changed delay:500ms"

yep

delay is the option you want

perfect thanks

\> tfw the easy and correct fix for a bug would require you rewrite all your tests

😑

@User bringing the lumber

c'mon zuck fite him

I am already nervous: My htmx talk at DjangoCon EU: https://cfp.2021.djangocon.eu/2021/talk/PZ3KWB/

Good luck

Good luck! I spoke with the django talk podcast folks yesterday and it sounds like there is a lot of excitement around django/htmx so you should have a friendly audience!

I was just looking at the DjangoCon site and saw this. Came here to say congrats! 😁 I am hoping to submit a proposal to DjangoCon US in a similar vein (though if you're planning to do the same I wouldn't want to step on your toes)