Ripping Out React Takes Years, Even When htmx Is Right

A December 2023 roadmap post from Misago, the Django-based forum platform, hit the Hacker News front page again this week: the project is removing React.js and rebuilding its interactivity on htmx. The predictable framework flame war followed. But read in mid-2026, the post is interesting for a different reason than it was when it was written. The decision has aged well. The timeline hasn't. Two and a half years in, stable Misago is still on 0.39.x, and the release that completes the migration — 0.40 — has yet to ship.

Both halves of that matter, and they point in opposite directions.

How a forum ends up with 1.4 MB of JavaScript

Misago's React adoption made sense when it happened. In the mid-2010s, Discourse had redefined what forum software should feel like — no full page reloads, live updates, app-like polish — by going all-in on an Ember single-page app. Every ambitious forum project chased that bar, and Misago chased it with React on top of a Django API.

The trap was structural, and it's one every server-framework shop that bolted on a SPA will recognize. Django can't server-render React components — there's no Node runtime in the stack — so any page that needed to work for search crawlers, no-JS clients, or fast first paint got implemented twice: once as a Django template, once as a React component that mounts over it. Rafał Pitoń, Misago's maintainer, tallied the cost in the roadmap post: duplicate page implementations, duplicate translation catalogs, and a client bundle that had grown to roughly 1.4 MB across three files — 679 KB of vendor code, 615 KB of app code, 102 KB of translations — about 363 KB gzipped, for software whose core job is displaying threaded text.

React's meta-frameworks solved this exact problem by owning the server. But adopting Next.js means demoting Django to a JSON API and rewriting every template, which is a bigger surgery than the disease. The honest alternatives for a Django app are two: complete the SPA transition and eat the rewrite, or move interactivity back to the server. Misago picked the second, and htmx — a ~14 KB library that swaps fragments of server-rendered HTML into the page on interaction — is the natural tool for it.

Why forums are htmx's home turf

Forums are close to the ideal case for this architecture, and it's worth being precise about why rather than treating it as a vibe. The interactivity in a forum is islands: voting, watching a thread, moderation menus, marking notifications read. Everything between the islands is cacheable, crawlable, server-owned document content. Old-guard software like phpBB proved for two decades that the model works; what it lacked — partial updates without a full reload — is exactly the gap htmx fills. Change the category filter on a thread list and Django returns just the new list HTML; the navbar never re-renders.

There's a second payoff that got less attention on HN but is arguably the bigger one for self-hosted software: extensibility. Misago 0.39 shipped a plugin system alongside the first React removals, and that pairing is not a coincidence. Server-rendered templates give plugins an obvious integration surface — override a template, inject a fragment — the model that made WordPress's ecosystem possible. A compiled React bundle gives them almost none; Discourse's plugin ecosystem is famously constrained by the need to ship JavaScript into the core app's build. For software whose users are admins customizing their own installs, template-level extensibility is a feature that outranks client-side polish.

The results so far back the thesis. Removing React from the categories page, account settings, and a ground-up rewrite of the thread lists cut the app bundle from 615 KB to 530 KB (124 KB to 99 KB gzipped) — with most of the app still unmigrated.

The part that should give you pause

Now the other half. This "incremental" migration was announced in December 2023 with work planned "throughout 2024." As of July 2026, the latest stable release is 0.39.6, and 0.40 — the version that actually delivers htmx-based interactivity, the new permissions system, and plugins — remains unreleased. Misago is largely a one-maintainer project, and the migration is entangled with rewriting permissions and parsing, so this isn't a controlled experiment in framework swap costs. But that's precisely the point: real migrations never are. The framework change rides along with every other overdue rewrite, and the payoff arrives only when the last React page dies, because until then you're maintaining three stacks — templates, React, and htmx — not two.

The HN skeptics land one real punch, too: htmx doesn't answer rich client state. A post composer with drafts and previews, live notification counts, embedded media pickers — Misago will still need hand-written JavaScript for those, and the roadmap concedes some interactions keep custom AJAX. htmx shrinks your JavaScript; it doesn't absolve you of it.

The actual decision rubric

So what should you take from this, concretely? If you're greenfielding on Django, Rails, or Laravel and your app is document-shaped with interaction islands — forums, dashboards, admin tools, CRUD — server-driven UI with htmx (or Hotwire, or Unpoly) should now be the default, and reaching for React is the choice that needs justifying. The django-htmx integration is mature, and you skip the double-implementation tax entirely by never incurring it.

If you have an existing React frontend, the bar is much higher. Rip it out only if you're paying Misago's specific tax — duplicated server and client implementations of the same pages. If your React app is a genuine client (real-time collaboration, heavy optimistic state, offline), htmx is the wrong hammer, and a migration measured in years will burn the time you should spend on product. Misago's case study is genuinely persuasive about the destination. It's even more persuasive, if unintentionally, about the price of the journey — budget for it in years, not sprints, and only start if the duplication is bleeding you today.