Introductions

[benjamin-kirkbride]

Do you maintain a library in this space? Have you shipped a project with HTMX and Python? We want to hear from you!

Introduce yourselves below. Things to include:

• What got you interested in HTMX/Hypermedia driven applications
• What projects you work on (with links if appropriate)
• What you would like to see/get out of the PyHAT initiative
• If interested, how you would see yourself assisting with this initiative (see Welcome to the Project! #1 for ideas and more context)

[benjamin-kirkbride]

Hello everyone, my name is Benjamin Kirkbride. I started this initiative with @tataraba at PyCon 2023. I really love the ideas that Carson posits in the various HTMX essays, and really resented being forced to use JS to make a web application that is even remotely modern feeling.

What I am hoping to get out of this, is firstly to establish common terminology and patterns for making hypermedia driven applications in Python, and secondly to reduce the amount of churn/duplication of efforts that is happening in this space.

I hope to help facilitate the growth of this initiative, both in mindshare and in participation, but I am very open to other people getting involved.

For now the best way to reach me is probably either by posting on here, or my email: benjamin@kirkbride.email

[florimondmanca]

Hey there,

As prompted via florimondmanca/asgi-htmx#7, let me introduce myself, as well as provide an (extensive) testimony. I always told myself — "I need to blog about this stuff", but never did, ha! So...

My name is Florimond. I've spent most of my open source time since 2018 around the Python async ecosystem, in particular ASGI. I contributed to projects like Starlette, Uvicorn, or HTTPX. I maintain awesome-asgi which lists libraries, tools and resources around ASGI. I also have a semi-maintained package djangorestframework-api-keys that I built because the API key package at that time went semi-maintained itself :-).

I've spent time trying to keep the ASGI framework-agnostic approach alive and kicking. This involves regularly providing ASGI-level implementations of various functionality. Related to the topic at hand, I experimented with asgi-htmx which was inspired by django-htmx.

What got you interested in HTMX/Hypermedia driven applications

End of 2021, then into 2022, I discovered the Hypermedia approach, mostly by chance. I hadn't worked on Web apps for 2 years at the time, so JS fatigue was there but not urgent.

I need to highlight that my focus at the time was (and still is) environmental sustainability. This actually made me shift carrier plans quite a bit and a few other things in my life. I was exploring what this meant for Tech and the digital infrastructure at large. I learned that one driver for environmental impacts of Tech was the continuous renewal of end-user devices (~1 bn per year), and that a significant fraction of this was driven not by loss, breakage, or aging (digital tech doesn't age much in absolute terms), but by devices starting to feel slow. And this was because us, developers, were pushing more and more resource-intensive things to these devices.

I still hold as a hypothesis that the switch from server-optimized MPAs to device-"distributed" (duplicated) computation via SPAs was (and still is) a part of the issue, and an extra explanation factor of why electricity consumption of datacenters have remained stable over the past 10 years, instead of increasing steadily (other factors including efficiency and architecture improvements in datacenters themselves).

So the journey really began when I stumbled upon the Modest JS handbook. I was struck by the idea that the now-classical "DB, backend, API-for-frontend, JS frontend" stack most likely made things way much more complicated and less efficient than they could be in 80% to 90% of the cases.

Later on, I found about about Turbo. Then about htmx. I tweeted an opinion thread (in French) about these realizations. I tried django + htmx and tweeted again how enthusiastic I was about this stuff. I spent some time around the htmx Discord server. I read Carson's htmx essays, as well as the Hypermedia Systems handbook. I got a firm grasp of why so-called "REST" APIs are actually JSON APIs that are not "REST-ful", e.g. because they lack controls embedding, unlike HTML. Overall, this was and still is fantastic theory stuff. (I think we should link to all of this stuff on a list like this, or perhaps link back to the corresponding section in awesome-htmx.)

I started talking about this approach with colleagues. I faced reactions like: "Isn't it like these old Drupal includes?", "Isn't it like Edge Side Includes (ESI)?", "Let we not forget why Angular.js was born in the first place!", "Alpine.js is fine, but it quickly becomes a mess!", "But what about SSR?", etc.

But seeing the frontend community come back to HTML through the "SSR" and "hydration" and other concepts made me seriously think: hold on, why don't we just cut the BS and revisit HTML?

Also, the business I work at since 2021 had an internal custom ERP/CRM built with Node / NestJS and Svelte / Sapper. It's useful to us, but we have little time to maintain it. So seeing Sapper become SvelteKit, then SvelteKit undergoing more major breaking changes around 1.0 meant that this project built in 2020-2021 was effectively very legacy just 3 years later, in 2023. This was kind of a shock for me. What kind of development tooling makes software so minimally durable? OTOH, Django is backwards compatible for years. Sure, Sapper was "edge tech" so we should have known what we went with. But on top of this, we had ongoing issues and more breakage with dependencies. Requiring days worth of effort every month just to maintain a small/medium size system like this one alive didn't seem acceptable to me. Overall, the "mindset" of the JS community ("Move fast and break things" with lots of small unfederated projects) was also part of the fatigue.

I then found about Alex Russell's work and writings, which strongly resonated with all this on another theoretical level. Russell's work basically summarizes to: we lost a decade in Web development" (2022 thread) by following the illusion of DX over UX (2018 blog post), and this resulted in growing inequalities among users (Performance Inequality Gap Reports). I must say some of his political views echo with mine too (The Markets for Lemons), and I'm not opposed to politicizing tech, quite the contrary (why do we do what we do, who or what does it affect positively, negatively, and overall how do we engineers take environmental and social responsibility in the systems we design and build?), so there's that too.

I may also link to The Spicy Web, a blog mostly focused on frontend, which features posts such as The Rise (and Fall) and Rise Again of HTML Frameworks, and The Great Gaslighting of the JavaScript Era — both are great pieces. (Also features a ~controversal piece, Why Tailwind Isn't For Me... 😉)

So that's how I got convinced something was happening in the industry and I was not that crazy to think the "SPA all the things" frenzy could and had to end. That something was basically: let's revisit MPAs, hypermedia and the Web stack, but learn from the industry's record of the past 10 years: add JS for the 10% cases where it's needed, and leverage what browsers do best, aka handle HTML for the 90%. Crucially, this doesn't mean throwing away frontend expertise that have developed over the past 10 years (like accessibility, progressive enhancement, semantic HTML, etc) nor the entirety of JS tooling, but choosing the pieces whenever seems fit, rather than keep following the "SPA all the things!" frenzy — inevitably lagging behind.

What projects you work on (with links if appropriate)

Professionally, I worked on a FastAPI / "clean architecture" / SvelteKit project from november 2021 to ~november 2022. It followed the "traditional" DB / backend / API / JS frontend. I was the sole dev on the project at first, then we were two. My conclusion was: this kind of stack is way too much work and plumbery for a small dev team. There ought to be a simpler way.

Since november 2022, I work on a PHP / Symfony project for the French administration (dialog.beta.gouv.fr) with a fellow coworker. When discussing technologies, my coworker and I shared the JS fatigue syndrome so we looked for something else. So instead of using Symfony to build an API, and then have a JS frontend on top "as usual", we went back to "MPA first is OK", knowing we'd use something like htmx to turn that into an HDA. This was made easier by the fact that symfony-ux landed which brought Turbo + Stimulus integration into Symfony (so we used that instead of htmx + hyperscript). We documented our reasoning in a decision doc (in French).

Today, my colleague and I are happy and productive with PHP, Symfony and Turbo for the 90%, and Stimulus for the 10% (perhaps less) of occasional sprinkles of JS for client-side interactions. The project is still young, but the performance metrics from Lighthouse look excellent, and we get an A-grade EcoIndex without much effort — mainly thanks to a very reduced bundle size (300 kB) and number of HTTP requests (no XHR requests to get data and populate the DOM). We're still discovering best practices — e.g. it occurred to me we don't quite use the "render partials" pattern yet, instead we have various partial template files and {% include %} in page template files. But things are nice and playful.

I'm happy to see this wave extend to Python and I hope I'll be able to come back to Python in the future and use the existing tooling (e.g. Django) to its full extent, not just as an API-for-frontend framework.

[benjamin-kirkbride]

Wow... what a read, thank you so much for sharing your experience and insight. I spent the better part of the afternoon reading through many of the sources you linked to. And I thought I was passionate about this.... haha 😅

I would love it if you would host the above comment somewhere else, tweaked for a broader audience. I would love to post a link to it on the awesome list.

[florimondmanca]

Happy to! I agree that a lot of this could be proper blog post material — as I wrote in the beginning of my comment, I’ve been deferring that for some time!

[tataraba]

Hi all!

My name is Mario Munoz (@tataraba ) and I am the co-conspirator of this repo, along with @benjamin-kirkbride.

I'm a relative newcomer to web dev, but have always dabbled with HTML and CSS here and there (mostly as a hobby). I didn't start learning Python until approximately 4 years ago, and a bit later, I gravitated toward web tooling (Flask/FastAPI/Django). However, I did not have the desire or mental bandwidth to dive into JavaScript, so I tried my best to keep my applications within the Python/Template/HTML/CSS stack.

I was quite excited when I discovered htmx, since that meant that I now had access to many web features I didn't think were possible, such as fun/tricky UI behaviors, or content switching without a full page reload.

As a result, I have been trying to get the word out to as many people as possible!

I taught a tutorial at PyCon 2023 titled: Tutorials: Web Development With A Python-backed Frontend: Featuring HTMX and Tailwind -- and subsequently had several conversations with enthusiastic PyCon attendees who had either already embraced htmx fully, or were curious enough to try.

I also hosted an open space where I met @benjamin-kirkbride and others who were interested in pushing things further.

Almost everywhere I turn, I notice that there is considerable interest in embracing the PyHAT stack, but so far, it seems like there is a lot of experimentation/fragmentation in the space, and I think having a consolidated viewpoint/approach will help get the word out to as many Python devs as possible.

As @benjamin-kirkbride noted, I am also invested in participating/growing this collective initiative, but am also happy to see others get involved.

You can reach me here or by email: pythonbynight@gmail.com

[davidbrochart]

Hello, my name is David Brochart and I am a Jupyter developer.

@florimondmanca set the bar pretty high, it's going to be difficult to do the same!
In a way, it's reassuring that people who have extensive experience with JS frameworks think that htmx can compete. I almost have no experience in frontend design, but because I work in the Jupyter ecosystem, I have a great example of a web app with JupyterLab. It really is a complex application, it just happens to run in the browser.
With JupySpace I want to create a web app that allows to manage conda-forge environments and run JupyterLab in them, all in the browser. It would have been tempting to create this web app using JupyterLab components (JupyterLab is also a framework for creating web applications), but it would probably have been overkill. And since I didn't enter the JS framework hell yet, I thought I would give htmx a try.
So my approach is more of a feeling that if frontend developers with JS fatigue turn to htmx, there must be a reason. I'm happy to stick to this simpler and healthier stack than spending time to catch up with all the latest JS technology, which seems overwhelming.
I've quickly gone through PyHAT's contents, and I already learned a lot. Since I use FastAPI, my interest is to see how this framework can leverage htmx the best. For now I only use Jinja templates, but I heard that the Django community has a better integration with htmx, for instance in django-components (although it's not specific to htmx).

[tataraba]

Welcome @davidbrochart!

I just added a section to the Readme that includes two demos (as of now). They are both written in FastAPI. The Music Binder repo uses the jinja2-fragments library to handle rendering partial content from a template. But either way, whether using Django/Flask/FastAPI, there are lots of options!

Hopefully there are enough resources here to fit into what you want to do!

[benjamin-kirkbride]

@davidbrochart thanks for introducing yourself! My recommendation is to look through https://github.com/spookylukey/django-htmx-patterns. Despite the name, the concepts and patterns are very general and IMO should be considered required reading for anyone looking to make a Python web app with htmx.

[davidbrochart]

Thanks @tataraba and @benjamin-kirkbride !
Also, let me ping @frankie567 here, as I know he's been using htmx for Fief and his feedback would be valuable.

[yaakovLowenstein]

Hi, my name is Yaakov Lowenstein and I am a python/Django developer.

I use Django at work and when I was introduced to the framework I fell in love with it. It gives you so much out of the box and makes some things really easy (Django forms etc).

I was introduced to HTMX by someone at work, but we don't use it there and I only briefly played around with it. Not so long after, I started working on a personal project on my own time using Django. I decided to try incorporating HTMX just for the heck of it, I was like 'why not'. But, immediately I hated the way you had to handle it in the views and the way you had to deal with partials.

That led me to develop https://github.com/yaakovLowenstein/hx-requests. In my humble opinion, it's a game changer for HTMX with Django. It offloads everything from the view to these things I call HXRequests. It's simple to setup an HXRequest and it does so much of the boilerplate code for you. ( can read more about it here https://hx-requests.readthedocs.io/en/latest/#). The package isn't fully developed but it's close (a couple of bug fixes I need to take care of, plus I would love to add handling for formsets in it)

Now I look back at other Django projects that are not using HTMX and it makes me frustrated that it's not asynchronous. And the parts that are, have to resort to messy JavaScript.

I love the initiative. I agree with @benjamin-kirkbride that it's great for normalizing the terminology and also having collaboration from many people with the same goal.

It would be great if the initiative takes off so that we can all gain from each other's effort in the space.

[yaakovLowenstein]

I can send a link to my website where I use HTMX + Django (and the hx-requests package I developed), but I wasn't sure what convention was about posting external websites..

[tataraba]

Thanks so much for stopping by. I don't think we have a formal way of contributing so far, but would love to see more examples of how people are using the stack.

I think for now, the logical place for these would be in the Readme under "Projects Using PyHAT (or similar)"

If you want, you can open an issue and link to your website with a brief blurb (similar to what is already in the Readme) and we can get it added.

[frankie567]

Thank you @davidbrochart for the ping and @benjamin-kirkbride for the project, really interesting 🙏

As David mentioned, I build Fief, an open-source authentication platform similar to Auth0 or Cognito. It comes with an admin dashboard where developers can manage their users and finely tune the authentication experience. It's mainly a CRUD app to list, create and update data.

I'm quite used to build SaaS apps, so I started to implement the frontend in React, mostly by habit and because "this is the way". Personally, I've always disliked the JS ecosystem, its complexities and its "always outdated" feeling. I also work on projects using Next.js, a framework that becomes more and more complex, with breaking changes every six months (did you know that, depending on the context, your code can be run either on a NodeJS runtime or a proprietary engine, with different standard libraries? That's crazy! 🤪).

I got tired of all this. I already heard about HTMX so I thought I would give it a try. After a few hours, it became crystal clear to me that it was the way to go. I re-discovered the pleasure of building templates like we did with good-old frameworks like Django or Symfony, while still getting the interactivity we like about SPA.

So I rewrote the whole React frontend with Jinja, WTForms, HTMX, Hyperscript and Tailwind! The codebase is easier to maintain, easier to work with and easier to test. It's in production for a few months now without any problem 😄

---

Regarding PyHAT, it would be great if we could coordinate efforts to build tooling to manage the JS part of the stack, in particular the Tailwind build and, optionally, some JS modules. Typically, in Fief, I had to create a Rollup configuration which I call before running the Python server to build the required CSS and JS. It would be great if this could be abstracted by Python tools, similar to what Symfony does with Encore.

Of course, I will be happy to participate in conversations and give insights based on my experience 😄

[florimondmanca]

"always outdated" feeling

Yup to that. That's also a major point I got fed up with the JS fuzz. Like, has stability become overrated?

I found relief when I realized we might have collectively been gaslit by the React frenzy folks into thinking their way was The Way. Except the burden is not on us to prove that's total bollocks, because obviously it is -- as any individual experience reported here and elsewhere shows. Instead, it's on them to prove that's actually (still?) The Way. That's a core message from the post I just linked that I really adhere too now.

[tataraba]

Regarding PyHAT, it would be great if we could coordinate efforts to build tooling to manage the JS part of the stack, in particular the Tailwind build...

Have you used pytailwindcss? It is a python wrapper of the standalone Tailwind CLI. You pip install it like any other python package and run pytailwindcss init (I think, going from memory here) and it creates your tailwind config file. Then you can run Tailwind commands without the npm or npx part. Not sure if that's what you meant in your statement, though. If the question is around the build command, that shouldn't be too hard. In the Music Binder app, the build command is run on app startup automatically (using subprocess, but there may be better options out there as well).

The only limitations here are the same ones for running the standalone Tailwind CLI, which means no access to existing JS extensions, but that is okay for most use cases, I believe.

[frankie567]

Thanks for the pointer, @tataraba 👍 Unfortunately, the Tailwind CLI is limited if we want to use SCSS to overload some directives or if we want to include CSS coming from other libraries (like combobox or calendar libs).

The same goes if we need to bundle JS. Some libraries don't provide a full JS script that can be loaded through a CDN, like CodeMirror which requires to be bundled.

[benjamin-kirkbride]

@frankie567 something like this: https://www.forgepackages.com/docs/forge-importmap/ ?

[frankie567]

Yes, definitely 👍

[bensi94]

Hi!

Thank you @benjamin-kirkbride and @tataraba for the project it's really exciting.

My name is Benedikt Óskarsson and I am a Python developer. I have a lot of experience with Django, FastAPI, and Flask, and I currently use Django where I work. We however only use Django for our APIs and have a SPA application (Vue) for the front end.

A few years ago I was working at a company where we used Django as a full-stack framework, and we used good old jQuery to partial page updates, how I wished that we had HTMX back then, it would have changed my life 😁

But using Django now again, but only for API development without a Django UI, I really missed the Django Debug Toolbar, especially the part that monitors the SQL queries. That's why I decided to build Django Requests Tracker which is a convenient Django development tool aimed towards rest API development. It collects and displays information on requests, responses, SQL queries, headers, Django settings, and more.

I wanted the package to be very lightweight and usable in any Django project, and easily extendable by creating your own fork of it. HTMX was a fantastic way to fulfill that and still give it that modern feeling. Requiring the whole JS ecosystem and knowledge of complicated JS framework would have been much worse.

After creating this I can honestly say that I can't wait to use HTMX more, it just feels so simple and has little overhead compared to working with the bigger JS frameworks.

In this short clip, you can see Django Requests Tracker in action using HTMX for all updates like search, sorting, and filtering.

To my knowledge, the project is currently only used by me and my team at work, but I think it has good potential and could be very beneficial for many people.

If you're interested in trying it out but you don't want to try it out on your own project just yet (or don't have one), the project also includes an example project that you can run. The instructions are in the Example project README.

[tataraba]

This is very cool! Thanks for sharing.

[Edit] - Realized that we have this listed already in our Readme. This is a great example of how to leverage htmx effectively. I love the idea behind this.

[justmars]

Hi, my name is Mars, a lawyer/consultant based in the Philippines. Just finished initial draft of this very stack start-django.fly.dev Just lacking the asgi part but Django seems already prepared for it. Also recently made django-fragments which helps wrap some html into idiomatic local-first pieces, think <svg> icons with the theme switcher, and <input> groups with htmx inline validation.

[tataraba]

Welcome! Thanks for stopping by.

Just checked out the start-django boilerplate! Very cool. I like the idea of bringing people closer to this paradigm as quickly as possible and drawing attention to locality of behavior.

Noticed that for start-django, the unpacking step involves using npm dependency for tailwind. Are you using any additional JS plugins for tailwind? If not, have you considered using pytailwindcss to give access to the tailwind CLI without the npm dependency?

Either way, really cool project!

[justmars]

Thanks for taking a look! Might consider pytailwindcss for the starter project since it seems like it makes it easier to run without the npm dependency. I remember it took me sometime to grok... so I can understand how this can appear daunting. Nowadays I like having the independent npm as a learning experience (just so I don't forget how to get it to a state of utility outside the python ecosystem).

[laker-93]

Hey all. My name is Luke. I'm working on an app that allows music lovers/DJs to stream their personal audio collection and be able to import/export to their DJ software. I'm also hoping to extend this app to provide a platform for independent music producers to share their music. The service is still in beta at the moment but the entire landing page front end has been built with htmx and fast api! Looking to connect with other Python developers making their way in to the front end world one div at a time :)
You can check out sub-box here: https://www.sub-box.net/

[tataraba]

Welcome Luke! I'm glad you've stopped by and hopefully you've found some good resources here. I took a quick look at your landing page and looks good so far!

[besil]

Hi everyone,

My name is Silvio, I'm a computer scientist and entrepreneur/CTO from Italy.

I'm a long time python fan and Django lover, I built tons of products during the years with these technologies.

I felt for years JS fatigue and discovering HTMX was like the first drop of water after a marathon in the desert. I advocate it a lot and I'm going to blog my experience with it.

In particular, I built my last SaaS startup all-in with HTMX and the product was really good (both for end users and dev experience, rock solid and it looks like a SPA).

I'm working on a "template app" with Django, HTMX and some goodies from my humble work experience, I'm going to open source it in a few weeks.

Awesome repository BTW

[tataraba]

Hi Silvio, welcome! Thanks for stopping by. I'm looking forward to reading your blog about your experience. It's encouraging to hear a lot of "real case" stories of how htmx is being used. Let us know when your template app is ready!