6 ms·

We use HTMX at Savio (https://www.savio.io https://www.savio.io), which started as a pure Django app. Our operating theory was that using a JS FE framework was

We use HTMX at Savio (https://www.savio.io https://www.savio.io), which started as a pure Django app. Our operating theory was that using a JS FE framework was overkill for a CRUD app. So we went with stock Django and server-rendered HTML. It became clear that parts of our UX would benefit greatly from client-side interactivity, which is what we eventually expected to happen. We sprinkled in HTMX (on top of our Jquery) on certain pages and it's been a breath of fresh air. We even built a nice Kanban board w/ HTMX and a Jquery plugin. Key benefits include: 1. When you're looking at a template the HTMX syntax makes it obvious what happens 2. HTML is rendered server-side in templates (imho where it should be) and is sent down the wire 3. We get a lot of stuff for free from Django (routing, back button handling, etc) that we don't need to build with a FE framework Even though we're devs we believe the best code is no code (in the literal sense, not the de rigeur "No Code" sense). Maintenance costs are important to us. Getting stuff for free is important to us. Building for a specific use case is incredibly important to us. With that in mind, the Django + sprinkled HTMX experiment has been pretty successful thus far.

dopeboy 5y ago
We use django + react. I've long been curious about HTMX but one thing has been holding me back that I'm trying to get others' opinion on: the npm ecosystem is incredibly rich. I'm thinking of drop in components like maps, UI libs, etc. Don't I need to spend a lot more effort using their original JS incantations and integrating that w/HTMX?
- kareemm 5y ago
  It obvs depends on what you're trying to do. In general we aim to use well documented, well maintained, and popular dependencies if we take them on at all. We haven't run into any issues where it felt like we were doing more work than necessary to get HTMX up and running.
- brtkdotse 5y ago
  By pulling in React you're now on the hook for another tooling+build pipeline for JavaScript. HTMX is a single JavaScript import meaning you can forgo the whole js tooling, which in my book is a _massive_ win.
- felipeccastro 5y ago
  I've been wanting to do this switch too and have the same concern. One option worth investigating is Shoelace - https://shoelace.style/ https://shoelace.style/, a library of nice looking web components that you can just add to your page without setting up a whole build pipeline.
  - digisign 5y ago
    Not certain, but should be easy to make a new folder, fire up the django tutorial, and drop in htmx and shoelace from their cdn links into the main template to start experimenting. Looks feasible.
- tomwojcik 5y ago
  I agree npm is wonderful and if you need npm just stick to React but you mentioned UI libraries. I use Django + HTMX stack in side projects. I've been using Material UI with React before, but I don't see a need for something similar in Django + HTMX stack. Just add some css like bulma and you're done.
theptip 5y ago
I've only prototyped adding HTMX to my Django app (currently using React & DRF), but there seems to be a great alignment between Django and HTMX. HTMX wants you to send back a partial HTML tree for the node being updated, and Django's template inheritance machinery lets you very cleanly separate the "parent page" from "partial sub-tree" (since you can just say `{% include "foo_table_fragment.html" %}` in the parent page template, and then render the "foo_table_fragment.html" template directly on the GET/POST with HTMX headers). It's all very easy to wire in to a normal Django page to gradually add interactivity (say, partial updates to filter/sort a table to instead of full-page reload).
- number6 5y ago
  Can you elaborate on the render fragment on GET/POST part? That sounds interesting!
  - brylie 5y ago
    See the following video tutorial starting at 9:18 for an example of rendering a template fragment in a Django view that gets returned to HTMX https://youtu.be/H_m1g8XOtHY https://youtu.be/H_m1g8XOtHY
  - theptip 5y ago
    If you use django-htmx, it's pretty simple to get the "this HTTP request came from HTMX" flag and branch accordingly in your view. The docs give a simple example of the logic here: https://django-htmx.readthedocs.io/en/latest/middleware.html#django_htmx.middleware.HtmxDetails https://django-htmx.readthedocs.io/en/latest/middleware.html... The examples give a fleshed-out version: https://github.com/adamchainz/django-htmx/blob/main/example/example/core/views.py#L107-L127 https://github.com/adamchainz/django-htmx/blob/main/example/... Though that's very slightly different than how I described it above, but it's basically the same idea; in this case you commonize the `main` block between the two contexts.
- speg 5y ago
  This is what I do (not Django but same idea). Works lovely. Between that and a 900+ package npm install for a simple demo code I’ve given up on “modern JS frameworks”. Or maybe I just got old!
recursivedoubts 5y ago
very glad you are finding htmx useful :) regarding point 1: 1. When you're looking at a template the HTMX syntax makes it obvious what happens I am trying to codify this design principle under the term "Locality of Behavior". I have written an essay on this idea here: https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/ there are other newer libraries that exhibit this characteristic as well: tailwinds and alpine.js for example
- kareemm 5y ago
  Hah. My co-founder uses your phrase “locality of behaviour” all the time. I was trying to remember it when I wrote that first item in the list but couldn’t. I very much appreciate you using it in htmx - makes understanding code so much easier. Thank you!
robertoandred 5y ago
You don't need to build routing or back button handling with FE frameworks.
- xcubic 5y ago
  You dont'?
  - qudat 5y ago
    It's handled for your with a library like react-router.
    - xcubic 5y ago
      That is precisely the point. You have to add more stuff on top.
      - robertoandred 5y ago
        That’s like complaining that Python doesn’t include routing.
        selcuka 5y ago
        Not really. Django already has routing and (obviously) back button functionality. By introducing react you first break it, then you add another library to fix it again. The point is HTMX doesn't break it in the first place. Not that I'm saying HTMX is better (or worse) than react, but that's what is being discussed here.
        robertoandred 5y ago
        Who said you had to bring Django’s baggage to a React project?
        xcubic 5y ago
cactus2093 5y ago
That's an interesting perspective, although I definitely have a negative gut reaction to that "where it should be" comment. It's so nice having a separation of concerns where that the backend doesn't deal with any view/presentation/styling concerns and only exposes an API, and then the clients consume that API (doesn't matter if those clients are FE web apps or iOS or Android apps or 3rd party developers accessing your API). Another advantage is there are some cool no-code solutions where you can build internal admin tooling on top of your API, which kind of gets you some similar benefits to the django admin interface system. I haven't really used this approach in production but it makes a lot of sense. But in some cases this can definitely come with more overhead than a quick Rails or Django app, and if you have a very read-heavy traditional website and no other clients then that overhead might not make sense. Sounds like you've found a platform that works well for your use case.
- CraigJPerry 5y ago
  >> It's so nice having a separation of concerns where that the backend doesn't deal with any view/presentation/styling concerns and only exposes an API You’re just casually glossing over the fact that now you’ve created a distributed system - state still exists server side but now there’s a distributed eventually consistent subset of state living in the user’s browser (i don’t mean trivial UI state like is the dark theme enabled, i mean application state). And you’ve opened this can of worms only for the trade off that you get to move view templating from the server side to the client side. There’s one case where there’s obvious clear benefits of choosing the client side rendering trade off and it’s if you’re building a client side app. Something that should be an intensive desktop app but you choose to deploy via browser instead. Maybe a music mixing or live DJ’ing app or a photo or video editor. Delivering these apps via web has some neat benefits in app distribution and cross platform accommodations. It wouldn’t be possible to build them without client side rendering so it’s a clear win. Most web apps are not that though. Most are like you describe, a UI to some APIs. The state really lives server side - my bank account UI, my blog posts, my … etc etc For these cases, you can reduce complexity by ditching the client side rendering.
  - cactus2093 5y ago

dopeboy 5y ago

We use django + react. I've long been curious about HTMX but one thing has been holding me back that I'm trying to get others' opinion on: the npm ecosystem is incredibly rich. I'm thinking of drop in components like maps, UI libs, etc. Don't I need to spend a lot more effort using their original JS incantations and integrating that w/HTMX?

kareemm 5y ago
It obvs depends on what you're trying to do. In general we aim to use well documented, well maintained, and popular dependencies if we take them on at all. We haven't run into any issues where it felt like we were doing more work than necessary to get HTMX up and running.
brtkdotse 5y ago
By pulling in React you're now on the hook for another tooling+build pipeline for JavaScript. HTMX is a single JavaScript import meaning you can forgo the whole js tooling, which in my book is a _massive_ win.
felipeccastro 5y ago
I've been wanting to do this switch too and have the same concern. One option worth investigating is Shoelace - https://shoelace.style/ https://shoelace.style/, a library of nice looking web components that you can just add to your page without setting up a whole build pipeline.
- digisign 5y ago
  Not certain, but should be easy to make a new folder, fire up the django tutorial, and drop in htmx and shoelace from their cdn links into the main template to start experimenting. Looks feasible.
tomwojcik 5y ago
I agree npm is wonderful and if you need npm just stick to React but you mentioned UI libraries. I use Django + HTMX stack in side projects. I've been using Material UI with React before, but I don't see a need for something similar in Django + HTMX stack. Just add some css like bulma and you're done.

theptip 5y ago

I've only prototyped adding HTMX to my Django app (currently using React & DRF), but there seems to be a great alignment between Django and HTMX. HTMX wants you to send back a partial HTML tree for the node being updated, and Django's template inheritance machinery lets you very cleanly separate the "parent page" from "partial sub-tree" (since you can just say `{% include "foo_table_fragment.html" %}` in the parent page template, and then render the "foo_table_fragment.html" template directly on the GET/POST with HTMX headers). It's all very easy to wire in to a normal Django page to gradually add interactivity (say, partial updates to filter/sort a table to instead of full-page reload).

number6 5y ago
Can you elaborate on the render fragment on GET/POST part? That sounds interesting!
- brylie 5y ago
  See the following video tutorial starting at 9:18 for an example of rendering a template fragment in a Django view that gets returned to HTMX https://youtu.be/H_m1g8XOtHY https://youtu.be/H_m1g8XOtHY
- theptip 5y ago
  If you use django-htmx, it's pretty simple to get the "this HTTP request came from HTMX" flag and branch accordingly in your view. The docs give a simple example of the logic here: https://django-htmx.readthedocs.io/en/latest/middleware.html#django_htmx.middleware.HtmxDetails https://django-htmx.readthedocs.io/en/latest/middleware.html... The examples give a fleshed-out version: https://github.com/adamchainz/django-htmx/blob/main/example/example/core/views.py#L107-L127 https://github.com/adamchainz/django-htmx/blob/main/example/... Though that's very slightly different than how I described it above, but it's basically the same idea; in this case you commonize the `main` block between the two contexts.
speg 5y ago
This is what I do (not Django but same idea). Works lovely. Between that and a 900+ package npm install for a simple demo code I’ve given up on “modern JS frameworks”. Or maybe I just got old!

recursivedoubts 5y ago

very glad you are finding htmx useful :) regarding point 1: 1. When you're looking at a template the HTMX syntax makes it obvious what happens I am trying to codify this design principle under the term "Locality of Behavior". I have written an essay on this idea here: https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/ there are other newer libraries that exhibit this characteristic as well: tailwinds and alpine.js for example

kareemm 5y ago
Hah. My co-founder uses your phrase “locality of behaviour” all the time. I was trying to remember it when I wrote that first item in the list but couldn’t. I very much appreciate you using it in htmx - makes understanding code so much easier. Thank you!

robertoandred 5y ago

You don't need to build routing or back button handling with FE frameworks.

xcubic 5y ago
You dont'?
- qudat 5y ago
  It's handled for your with a library like react-router.
  - xcubic 5y ago
    That is precisely the point. You have to add more stuff on top.
    - robertoandred 5y ago
      That’s like complaining that Python doesn’t include routing.
      - selcuka 5y ago
        Not really. Django already has routing and (obviously) back button functionality. By introducing react you first break it, then you add another library to fix it again. The point is HTMX doesn't break it in the first place. Not that I'm saying HTMX is better (or worse) than react, but that's what is being discussed here.
        robertoandred 5y ago
        Who said you had to bring Django’s baggage to a React project?
        xcubic 5y ago

cactus2093 5y ago

That's an interesting perspective, although I definitely have a negative gut reaction to that "where it should be" comment. It's so nice having a separation of concerns where that the backend doesn't deal with any view/presentation/styling concerns and only exposes an API, and then the clients consume that API (doesn't matter if those clients are FE web apps or iOS or Android apps or 3rd party developers accessing your API). Another advantage is there are some cool no-code solutions where you can build internal admin tooling on top of your API, which kind of gets you some similar benefits to the django admin interface system. I haven't really used this approach in production but it makes a lot of sense. But in some cases this can definitely come with more overhead than a quick Rails or Django app, and if you have a very read-heavy traditional website and no other clients then that overhead might not make sense. Sounds like you've found a platform that works well for your use case.

CraigJPerry 5y ago
>> It's so nice having a separation of concerns where that the backend doesn't deal with any view/presentation/styling concerns and only exposes an API You’re just casually glossing over the fact that now you’ve created a distributed system - state still exists server side but now there’s a distributed eventually consistent subset of state living in the user’s browser (i don’t mean trivial UI state like is the dark theme enabled, i mean application state). And you’ve opened this can of worms only for the trade off that you get to move view templating from the server side to the client side. There’s one case where there’s obvious clear benefits of choosing the client side rendering trade off and it’s if you’re building a client side app. Something that should be an intensive desktop app but you choose to deploy via browser instead. Maybe a music mixing or live DJ’ing app or a photo or video editor. Delivering these apps via web has some neat benefits in app distribution and cross platform accommodations. It wouldn’t be possible to build them without client side rendering so it’s a clear win. Most web apps are not that though. Most are like you describe, a UI to some APIs. The state really lives server side - my bank account UI, my blog posts, my … etc etc For these cases, you can reduce complexity by ditching the client side rendering.
- cactus2093 5y ago