Moving From React to htmx

It is all well and good talking about REST & HATEOAS in theory or describing the Hypermedia-Driven Application architecture, but, at the end of the day, what matters in software is practical: Does it work? Does it improve things?

We can say for sure that htmx works, since we use it in our own software. But it is hard to say that it would be an improvement over other approaches, since we haven't had an apples-to-apples comparison of how htmx might compare with, say, react.

Until now.

David Guillot at Contexte has given what we are calling "The Mother of All htmx Demos" at DjangoCon 2022:

From React to htmx on a real-world SaaS product: we did it, and it's awesome!

We took the plunge and replaced the 2-year-of-work React UI of our SaaS product with simple Django templates and htmx in a couple of months. We’d like to share our experience with you, with concrete indicators on various aspects, and convince your CTO!


You can (should!) watch the entire presentation here:

Executive Summary


These are eye-popping numbers, and they reflect the fact that the Contexte application is extremely amenable to hypermedia: it is a content-focused application that shows lots of text and images. We would not expect every web application to see these sorts of numbers.

However, we would expect many applications to see dramatic improvements by adopting the hypermedia/htmx approach, at least for part of their system.

Dev Team Makeup

One easy-to-overlook aspect of the port is the effect it had on the team's structure. When Contexte was using react, there was a hard split between back-end and front-end, with two developers being entirely back-end, one developer being entirely front-end, and one developer being "full stack".

("Full stack" here means they are comfortable doing work on both the front-end and back-end, and, thus are able to develop features entirely independently across the whole "stack".)

After the port to htmx, the entire team became "full stack" developers. This means that each team member is more effective and able to contribute more value. It also makes development more fun, since developers can own an entire feature. Finally, it can lead to better optimized software, since the developer can make optimizations anywhere in the stack without needing to coordinate with other developers.


The slides for the presentation can be found here (be sure to check the excellent speakers notes!)