Comment by kareemm | Hacker News Reader

Comment by kareemm | Hacker News Reader

Parent Full thread

We use HTMX at Savio (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.

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

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!

Can you elaborate on the render fragment on GET/POST part? That sounds interesting!

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

The examples give a fleshed-out version: 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.

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

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/

there are other newer libraries that exhibit this characteristic as well: tailwinds and alpine.js for example

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!

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.

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

You're just casually glossing over the fact that the server-rendered + jquery approach was already a distributed system, just with less explicit boundaries and more ad-hoc patterns for managing and updating that state.

It all just depends on the product though, if the client-side interactions are minimal enough than I agree the server-rendered approach can be better. I was just saying I don't see this as the inherently better way, there are pros and cons to each approach.

> Another advantage is there are some cool no-code solutions where you can build internal admin tooling on top of your API

Which tools are you thinking of? I know of react-admin, are there others?

Retool is one of them https://retool.com/

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?

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.

I've been wanting to do this switch too and have the same concern. One option worth investigating is Shoelace - 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.

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.

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.

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.

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

You dont'?

It's handled for your with a library like react-router.

That is precisely the point. You have to add more stuff on top.

That’s like complaining that Python doesn’t include routing.

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.

Who said you had to bring Django’s baggage to a React project?

I don't think you are getting it, at all.

So explain it then. A React-based framework is too complex so we went with Django because we get routing and back button functionality for free, even though you get routing and back button functionality for free with React-based frameworks.

Reply on news.ycombinator.com