This is a fantastic write up! Thanks @benjamin-kirkbride for your very thorough/thoughtful observations.

Just want to add 2 cents here and there (I may try for something more thorough at a later time):

Honestly not sure, broadly. @tataraba gave a talk about this, though I'm not sure if there is a video up for it.

He's referring to my talk at DjangoCon US 2022 titled Why I Didn't Start With Django. The short of it is:

A lot of the things that are initially intimidating about Django end up being a moot point, considering all the things you have to learn when embracing other "micro" frameworks. Some annoyances (opinionated decisions) are unavoidable, but the ecosystem/community of Django is undeniably awesome.

Takes longer to get started

Honestly, I actually went with a micro framework for the opposite reason most people do it. That is to say, I knew that if the "hello world" app could be built in 5 seconds, I would be spending a ton of time learning the "real world" skills to use the framework. But I actually wanted to know/learn how things were working from the ground up. I felt that Django, as powerful as it is, tends to obfuscate a lot of that with things like the ORM and/or class-based views.

I don't want to use a framework specific ORM

I ended up using MongoDB for my blog. I happen to like MongoDB, particularly with its dictionary-like structure. Plus, it comes with the upside of no migrations (sort of). Considering that you are defining your data structures in advance, I don't get as frustrated with "messy" database design. It takes a little bit more discipline. MongoDB in Django is... not great.

I don't want to use a framework specific templating language

I hardly have an opinion on this, but I wonder what it means for those who use other templating languages, such as Chameleon. (I haven't tried it myself, but know a handful of people who use it/like it.)

I don't like class based views

Interestingly enough, when I was re-factoring my blog (you know, for fun), I ended up building these classes... for my routes... that kind of look like... class-based ... views... Kind of.

It's opinionated

I think it's fine. I spoke to people at DjangoCon that were drawn to Django for the same reasons I was initially repelled by it. It's great that Django exists for the large group of people that use it and adopt it wholeheartedly.

In addition to things above, one thing that bugs me about Django is the settings.py file, and also the nomenclature around INSTALLED_APPS. But that's neither here nor there. Once you understand the Django patterns, you're in good hands.

As to using Django as default for PyHAT:

We have work to do if you want my above point to not be true.

I still think it's worth exploring this. I may revisit this in another post, but hopefully we can get a sense of what the community wants around this subject!

1 reply

Congratulations on the write-up @benjamin-kirkbride, these are interesting observations.

I had a couple of thoughts while reading this and going through django-htmx-patterns more thoroughly, to get a better grasp of the "What's the state of the template fragment technique", so I'll lay them down here. Behold, this is again going to be a mouthful of a comment! Hah.

Reactions to post

Symphony for instance [has] very mature and mainstream use of the Hotwire tooling to turn them into true HDA frameworks.

I wouldn't say this is true for Symfony, although I have limited view of the community since I'm quite new to it. I would say this — for Symfony, Turbo is front of the scene because it was chosen as part of the symfony-ux initiative. This initiative is fairly new (2020) and aimed at providing a unified and well-integrated set of tools for dealing with JavaScript enhancements in Symfony. It also includes integration for Stimulus as well as a Symfony-specific Webpack integration (Webpack Encore). But I don't know how "mainstream" all this is today for Symfony folks. The tooling is fairly mature though, yes!

Ruby (on Rails) seems to be the most ahead, but as you noted that is certainly linked to the commonality in people involved (DHH and team).

Django is not for SPA's

One extra reason (or synthesis of reasons) why I think Django might be better suited for HDAs than other microframeworks that allow displaying HTML, is exactly this — Django was made for displaying HTML.

Django was made at a time when all web apps did really was displaying HTML, and then people added the small enhancements here and there using jQuery and the likes, until the industry realized we started doing so many enhancements why don't we let JS render HTML, and there begins the "lost decade".

So, anyway, Django is really good at displaying HTML and providing all the tooling you need to build an HTML-centric web app.

On the other hand, as you noted, microframeworks focused on JSON APIs, so their tooling revolves around that and not HTML. Django itself can't do JSON APIs very handily, except with the REST Framework or something.

I don't like class based views

It doesn't seem like CBVs are a must-use with Django today, are they?

I'm sure you read it already, but there's a link in the django-htmx-patterns approach.rst to Django Views: The Right Way which I found very compelling on how CBVs should essentially be forgotten and people should go with function-based views for the most flexibility and durability.

Just mentioning this as a point that might get the soundness of "I don't like CBVs" a tad lower still!

I don't want to use a framework specific ORM
I don't want to use a framework specific templating language

One thing that struck me when comparing Symfony with Django is the design philosophy is quite different. Both are opinionated in different ways.

Django comes as a somewhat monolithic block, while Symfony has historically focused on modularity at the architectural level (not just "apps"). It's got Symfony Components which are "decoupled libraries for PHP applications".

For example, the Form component can be used in isolation to Symfony as it basically deals with validating dicts of data (that typically come from forms) and binding those to a PHP POJO. I'd say, sticking to django.forms.Form and forgetting about ModelForm would be the closest to working with the Symfony Form component.

Symfony Components are what allows it to be the basis for other frameworks, such as Drupal or Laravel which both use its HttpFoundation component (object-oriented HTTP abstraction layer, with Request and Response models) as well as its Routing component (HTTP routing layer, with binding of URLs to "controller classes" (classes with the equivalent of a __call__ method).

This puts the PHP ecosystem in a different position than Python. In Python, there's "Django with all things coupled into a tight and well-integrated pack" on one side, and "microframeworks perhaps with a modular framework as a shared base" on the other side (thinking of werkzeug + Flask for WSGI and Starlette + FastAPI for ASGI).

But there isn't a framework akin to Symfony that provides components so widely reused and yet is a full-featured framework in its own right.

The closest is Starlette, which was thought of as an "ASGI toolkit" and has highly reusable HTTP models and routing components effectively used as a basis by other frameworks (FastAPI is not the only one, many specialized microframeworks use Starlette as a toolkit). But Starlette stops there — it's an ASGI toolkit but not a full-featured framework with built-in components for forms etc (although Tom Christie initially aimed at developing a broader ecosystem, eg with typesystem or databases, at a time when async Python for the Web was just nascent).

Template fragments -- State-of-the-art htmx pattern, vs Turbo

Looking through django-htmx-patterns, the only thing that is recommended that doesn't come with Django stock is django-render-block, which wasn't even made for htmx/HDA's! The Django ecosystem had already built all the tools HDA's before HDA's were even a thing ( ‼️ ).

So I went through the django-htmx-patterns write-ups, and it seems the current state-of-the-art approach to "template fragments", with Locality of Behavior properties and all that, is something like this:

{# monsters/templates/list.html #}
{% extends "base.html" %}
{% block body %}
  <h1>List of monsters</h1>
  {% if page_obj.paginator.count == 0 %}
    <p>We have no monsters!</p>
  {% else %}
    {% block page-and-paging-controls %}
      {% for monster in page_obj %}
        <p class="card">{{ monster.name }}</p>
      {% endfor %}
      {% if page_obj.has_next %}
        <p id="paging-area">
          <a
            href="#"
            hx-get="?page={{ page_obj.next_page_number }}"
            hx-vals='{"use_block": "page-and-paging-controls"}'
            hx-target="#paging-area"
            hx-swap="outerHTML"
          >Load more</a>
        </p>
      {% else %}
        <p>That's all of them!</p>
      {% endif %}
    {% endblock %}
  {% endif %}
{% endblock %}

I initially wondered why there was so few "theory" explained Turbo. Its docs are very descriptive about "here's what Turbo can do for you", but they don't expose the same theoretical thinking than htmx does. I think it's because it embeds those principles without requiring the user to think about them much.

So for example, with Turbo plus a bit of tooling, you'd leverage Turbo Streams, and write something like this:

{# monsters/templates/list.html #}
{% extends "base.html" %}
{% block body %}
  <h1>List of monsters</h1>
  {% if page_obj.paginator.count == 0 %}
    <p>We have no monsters!</p>
  {% else %}
    {% block page-and-paging-controls %}
      {% for monster in page_obj %}
        <p class="card">{{ monster.name }}</p>
      {% endfor %}
      {% if page_obj.has_next %}
        <p id="paging-area">
          <form method="GET" action="?page={{ page_obj.next_page_number }}" data-turbo-stream>
            <input type="hidden" name="use_block" value="page-and-paging-controls" />
            <input type="hidden" name="stream.action" value="replace" />
            <input type="hidden" name="stream.target" value="paging-area />
            <button type="submit">Load more</button>
          </form>
        </p>
      {% else %}
        <p>That's all of them!</p>
      {% endif %}
    {% endblock %}
  {% endif %}
{% endblock %}

As you can see I'm using a button-triggered <form method="GET"> here. This results in more native behavior compared to a no-op <a> with hx-get. The browser won't display tooltips and behaviors associated with anchors such as "open in a new tab". Also, things would work even if Turbo is deactivated. This sticks to the progressivement enhancement philosophy, which htmx is a bit lacking at imo.

I had to decide where to put parameters we define in the template for LoB purposes: in the action or in hidden form fields? The first is less readable imo, the latter is a bit more verbose. Note that in any case, we'd be using native HTTP APIs. No need for an equivalent of hx-params!

In general Turbo seems to get out of the way a bit more and encourage us to use the existing platform. Incidentally, htmx was born out of a desire to revisit the browser as a hypermedia platform, so it's interesting that despite the theory it doesn't simarly encourage leveraging existing HTTP APIs more. Its reluctancy to use <form /> leads to reinveinting APIs which <form /> elements get us for free, such as hx-params.

Note: support for non-GET/POST form methods can still be achieved by sending an extra _method form parameter along with a POST request. It should be possible to have seamless integration on the server-side with a bit of integration in the frameworks' routing system, saying: "if there's a _method query param, treat it as the request.method". E.g. this could be a middleware. Symfony has this built-in with http_method_override.

Then we could have a similar decorator helper, so the view ends up like this...

@for_turbo_stream(use_from_params=True)
def list_monsters(request):
    page_obj = ...
    return TemplateResponse(
        request,
        "monsters/list.html",
        {"page_obj": page_obj},
    )

The @for_turbo_stream decorator would take care of:

1. Checking if "text/vnd.turbo-stream.html" in request.headers["Accept"] (can we render a stream, or was the request initiated without Turbo, e.g. the client doesn't have JS? --> Progressive enhancement)
2. If so, parse parameters from the request.GET/POST.turbo_stream_* parameters.
3. Set the response Content-Type to text/vnd.turbo-stream.html.
4. Edit the response.template_name with the template set to a file (which could be included in a "django-turbo lib" of sorts), looking like this:

<turbo-stream action="{{ action }}" target="{{ target }}"
  <template>
    {{ block_content|safe }}
  </template>
</turbo-stream>

I'm sure there are many more use cases requiring slight adjustments to this pattern, such as explicit use_template, use_block and **kwargs parameters on @for_turbo_stream for "manual mode" like @for_htmx.

But that would be the tooling I'd need to reproduce what we're currently doing on a PHP/Symfony/Turbo project at work.

It's interesting to note that if you look at the Turbo Streams docs, the approach shown there doens't have LoB properties. It uses a partial template with an if statement on the Accept header ("request format"). That's what you'd have to do without a @for_turbo_stream helper and that's precisely why such a helper might be useful. In Symfony there's not much more integration and you have to do the Accept jangling yourself, which is a bit of a pain since most of the streams look like the above, perhaps with several blocks instead of just one.

Anyway, the point I wanted to make here was: my conclusion is that Turbo is more "higher-level" in that it doesn't just allow you to send requests with some other parameters on how to deal with the response (hx-target, hx-params, hx-select, etc). Instead it gives 2 unique and more structured approaches:

1. Frames, which are an equivalent of hx-get="..." hx-select="frame-id" hx-swap="outerHTML"
2. Streams, which allow doing the rest of hx-swap actions, as well as more complete WebSocket streaming support

Actually this was reckonized by the htmx folks themselves. See this Reddit comment 2y ago:

htmx is going to be lower level than turbo: it should give you some additional flexibility at the cost of more explicitness.

so maybe:

• htmx if you want to stay as close to framework-less HTML as possible
• hotwire if you want stuff to "just work" and not get down into the details of your HTML so much

I don't quite agree with those claims, though. HTMX requires us to change the HTML quite dramatically, whereas as I've shown above, Turbo tends to be more transparent and help us leverage existing HTML APIs. For this exact reason, Turbo requires us to be precise and "expert" at the HTML we write, effectively getting down into the details as well.

So, in conclusion, I think that while htmx provides crucial theoretical background (see LoB which informed me to go further than the Turbo docs in the example above), Turbo's "lack of flexibility" is actually a strong asset — it went the extra step to provide polished APIs, whereas htmx gives a whole bunch of attributes and it might be hard to figure out what the proper patterns are.

And, as a meta-conclusion, I think this gives an extra reason that the "choice" of htmx over Turbo in the Django community is probably not so "informed", as it is "by chance". Turbo has been around for slightly more time and I don't think there's been as much "marketing" around it as htmx (the essays and memes etc helped a lot there).

I do think Turbo has all the required pieces to also be a helpful tool for Django / Python folks when going the HDA route, perhaps helping us solve the "best patterns" problem by construction — since it's figured those out into more structured APIs for us already.

1 reply

Why Did Django Go With htmx Over Hotwire?

I am actually not sure. Ruby on Rails went with Hotwire because the Ruby on Rails people built it with RoR in mind, so that is no mystery. PHP uses it because Symfony built integration with it. Perhaps the reason Django didn't go with it is simply because the Django project is agnostic about it? It also could be because https://github.com/spookylukey/django-htmx-patterns was written by a Django core dev (@spookylukey) and that was enough to move the needle.

My (unmeasured) guess is that htmx was already more popular than Hotwire in the Django community when I started making that guide. Other people like Adam Johnson were also helping to popularise it.

One factor in my choice is that Hotwire/Turbolinks comes from the Rails camp, and they tend to have a more "convention over configuration" / "magical-just-works" approach, while Python devs including myself tend to prefer "explicit over implicit". I was concerned that Hotwire would likely be a much better fit for Rails, while htmx was more framework agnostic. I remember seeing one tweet that backed that up, can't remember where now.

1 reply