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.