Consider adopting HTMX

[smcalilly]

Background

HTMX is a framework for building interactive webpages. It uses HTML and a backend to serve up new data/content on specific parts of a webpage based on user interactions. Rather than reloading the entire webpage, it updates the html that you target.

It looks simple and I'm curious to try it, as it could be a good alternative when React might be too heavy for a project — like searching/filtering a table or interactive forms. I don't think it would fully replace JavaScript or React, but it seems promising for some of our common use cases. I like the approach to use HTML whenever possible and only use JS when absolutely necessary.

It grew out of intercooler.js. It's similar to the new Rails hotwire pattern, but less magic (aka more explicit/following the zen of python).

There's a django-htmx package for integrating within Django.

See:

• https://htmx.org/
• https://pypi.org/project/django-htmx/
• https://www.mattlayman.com/blog/2021/how-to-htmx-django/
• https://djangochat.com/episodes/htmx-carson-gross-ep95-replay

Proposal

I want to see how well it would work and whether it's as good as advertised/folks talking it up. What's good and bad? What is promising? What are the limitations? What parts of our apps could this replace (table filtering, interactive forms, maps, etc)? Does it work well with JavaScript if a feature needs JS (like for a map)? Does it create maintainable code? Does it make sense? Do we like it?

These questions will be viewed with skepticism so we don't hurry to adopt this week's hottest new JavaScript framework.

Deliverables

I'll use HTMX to re-implement the search/filter table in the IL NWSS app. I'll do this outside of the project in investment time, that way we don't buy-in to a new framework for a project.

I'll implement it with the django-htmx plugin, and depending on how that goes, might also try to use the htmx library itself.

Timeline

This will take 1-2 investment days. I need to finish #272 first and then can work on this.

If anybody else has the bandwidth to try this before I do, please do!

[smcalilly]

leaving this here to refer to later: https://htmx.org/essays/a-real-world-react-to-htmx-port/

[smcalilly]

might be worth a read: https://hypermedia.systems/book/contents/

[smcalilly]

more htmx content, django specific: https://fly.io/blog/a-no-js-solution-for-dynamic-search-in-django/

[smcalilly]

another django link. this is a good example for how htmx naturally fits django patterns https://www.photondesigner.com/articles/submit-async-django-form-with-htmx

and here's a cool use case, real time notifications: https://www.youtube.com/watch?v=MziqE_2Euss

and a typeahead database search example, would be cool to do this with elasticsearch typeahead: https://www.photondesigner.com/articles/database-search-django-htmx

[xmedr]

I've been reading and messing with some htmx for a couple investment days and followed a django-htmx task list tutorial and pushed up my finished product here. Here are some initial thoughts

TL;DR

HTMX applies functionality through attributes on html elements to determine what actions trigger which reactions and what pieces of the html get swapped out, added to, removed, etc.

It’s definitely nice if you need quick ajax functionality. I do think because of it's nature and it's ease of use, it can be used in some projects to handle small forms or to get some functionality up and running quickly. However, it might be inflexible when working for different frontends, so I'm hesitant to suggest it for large components.

Pros

• Ease of use. Since it’s all based off adding attributes to html, there's less of a need to deal with js on the frontend. I didn't need to worry about selecting and updating pieces of the dom. Also most of my time working on that task list was spent on the backend instead of the front. If anything, it helped get my hands dirty with django views a bit more.
• Locality of behavior. This is the concept that all the behavior of a component can be determined by looking directly at that component's code, as opposed to looking back and forth between multiple locations. In this case, it may be a bit easier to look at just the html and determine what it does.
• Reloading just portions of the page with ajax requests is the default behavior. Writing a separate fetch request isn't wholly necessary.
• There's a good bit of resources available for learning htmx, and the developer seems active on places like reddit, helping answer questions.

Cons

• No separation of concerns. This is the opposite of locality of behavior. Because of the nature of using htmx, the components would house both presentation and function.
• Some articles site that if you need the same back end to work for different front-ends, then that would pose an issue. I could see what they mean by this. It does initially seem like you must provide pretty specific responses, since every response is html snippets. But is that, that much different than specifying a template to render?
• I’ve read that security might be a concern, but I’m unsure of how much more of a concern it is here than in other frameworks

Maybes

• A selling point for htmx is that it can use more http methods than just GET and POST. Maybe it’s because I’m still learning, but for this project, it’s been more trouble than it’s worth when using class based views.
  • Example: following the tutorial, I was using hx-delete in order to make a DELETE request to the appropriate view. So because of this, I was overriding the view's delete method and using that to delete the task. It worked, but django complained about that with a warning. So for that in particular I used a POST request anyway.

Questions

• What is promising?
  • It really is easy to implement on the frontend. Because of this, I do feel like I got more practice in dealing with class based views. So a side effect of its ease could be its effectiveness as a prototyping and learning tool.
• What are the limitations?
  • The fact that the responses are just straight html could limit the backend's flexibility towards different front ends.
• What parts of our apps could this replace (table filtering, interactive forms, maps, etc)?
  • I could see small repeatable bits of apps using htmx. So searching/filtering as you type, or small forms could benefit. For example, I'd be curious to see how htmx would've helped getting multiple mostly identical forms on a page in this previous ccfp issue: Phase and funding forms on one page fpdcc/ccfp-asset-dashboard#156
• Does it work well with JavaScript if a feature needs JS (like for a map)?
  • I don't have much experience with maps so I think I might have to revisit that in time, but generally I can't imagine it would be outstandingly difficult to incorporate js into htmx elements.
• Does it create maintainable code?
  • I believe that it would, mostly because of the fact that you can see what the htmx is trying to do on the html element.
• Does it make sense?
  • I think it does! It was simple to pick up and the docs are extensive enough that if you needed some functionality you weren't sure how to do, it wouldn't be too hard to find out how htmx takes care of it.
• Do we like it?
  • Personally, I'd want to use this for a side project and play around with it some more.

[smcalilly]

Some more HTML propaganda: https://html-first.com/