The post is a 2023 design note from the Misago forum project explaining why it started removing React.js from a Django-based codebase and replacing those parts with HTMX. The key motivation was not a grand anti-JavaScript manifesto. It was maintenance pain. Misago had ended up implementing parts of the UI twice, once as Django templates and again as React components, which made even routine changes expensive. The author’s claim is that forum software is mostly server-rendered content with some interactive edges, so HTMX can deliver partial page updates and live behavior without carrying a full client framework everywhere.
That framing landed with a lot of people. The strongest consensus was that forums are almost the ideal HTMX use case. Threads, posts, pagination, notifications, and lightweight actions map naturally to server-rendered HTML fragments. Several people extended that beyond forums to the broad class of
CRUD-heavy apps where the interaction model is forms, tables, filters, and navigation rather than sustained client-side state. In that world, replacing a second frontend stack with HTML partials looks less like nostalgia and more like deleting an entire category of complexity.
The discussion got more interesting when people moved past the easy case. A concrete example from a faceted product listing showed the boundary pretty clearly. HTMX worked fine while the page behaved like simple search plus results. It got clumsy once the filter form itself became dynamic, with options enabling and disabling based on current selections and with large result cards making each response heavy. The eventual solution was a split model. Keep server-rendered HTML for results, but use a small reactive component for the filter form so not every interaction requires re-sending and re-computing the whole UI. That example became the practical line many readers converged on. HTMX is strong when the server remains the obvious source of truth and each interaction maps cleanly to swapping a fragment. It starts fighting you when the browser needs to own meaningful local state, preserve fine-grained UI continuity, or manage high-frequency interactions.
That broader point also shaped the React defense. The pro-React case here was not really about
SPA fashion or avoiding full page loads. It was about keeping one rendering model for initial render and updates, doing granular DOM reconciliation, and handling complex client state without bolting on more escape hatches. Critics of HTMX argued that once an app grows richer, attribute-driven requests plus scattered bits of JavaScript can turn back into the same old mess people were trying to escape. Supporters pushed back that this is exactly the wrong mental model for HTMX. If you are managing substantial client state, you already crossed into a different problem class and should use a different tool. Put more bluntly, HTMX is not a universal frontend replacement. It is a way to simplify the large category of apps that never needed a client app runtime in the first place.
The mood was positive toward Misago’s decision, but not starry-eyed about HTMX itself. People liked the move because the target application is boring in the best possible way. They were much less convinced by sweeping claims that modern React-style frameworks are obsolete. The practical takeaway from the comments was narrower and more useful: match the architecture to the state model. If the state mostly lives on the server, HTMX can delete a lot of accidental complexity. If the browser has to think hard, reach for a frontend framework before the escape hatches pile up.
misago-project.org