---
title: "Hypermedia Systems and the complexity budget you can't split"
description: "The complexity budget behind htmx holds up until a team keeps React for half the app and spends it twice."
url: "https://michael.zazon.us/notes/hypermedia-systems-and-the-complexity-budget-you-cant-split"
published: "2026-02-04T12:00:00-05:00"
kind: "book-notes"
subject: "architecture"
tags: ["media","team-design"]
---
I find myself more interested in the argument of [Hypermedia Systems](https://hypermedia.systems/) than the tool they're selling. The book (by Carson Gross, Adam Stepinski, and Deniz Akşimşek) is available online for free, and makes the case that we should be sending HTML over the wire, doing all the thinking on the server, and keeping the browser thin and mostly responsible for rendering the response.

The underlying idea is older, and (to me) the best part: Gross talks about a [complexity budget](https://htmx.org/essays/complexity-budget/) in this essay, the idea that every project spends its complexity somewhere, so you should spend it where the application earns its keep. This is an idea that stands on its own, independent of htmx, and I think it would survive even if htmx itself disappeared tomorrow.

Imagine an internal admin tool owned by a back-end team, full of forms and tables and a search box. The budget argument is strongest here: keep the complexity on the familiar server, keep the front end thin and un-needy.

The book is candid that this approach isn't for everyone. It concedes that some highly interactive applications may require a single-page framework, and offers Alpine.js and hyperscript as scripting add-ons for extra browser behavior. That's a fair concession, but it enables my biggest worry: a hybrid setup where a team keeps React for the dashboard but uses htmx for settings pages.

The complexity budget argument goes out the window, because even if the subsection of the app is theoretically simpler than it could be in React, the overhead of switching in between two frameworks in the same project is just going to wipe out any gains you make from making one half simpler.

So instead of saving your budget by only having to spend it once, you've spent it twice because you have two mental models and two sets of conventions to keep straight. I suspect most teams that try htmx will end up in this half-and-half state, which means that the best idea in the book is the one that's hardest to actually benefit from where people are testing it out, since teams rarely start with a blank slate.. React is usually already there.

React is the incumbent, HTMX is the upstart. When you're the upstart, you need to offer some really compelling reason to switch away from React.

But the complexity budget itself raises a question: is "simpler" by itself reason enough to leave React? Or does htmx, despite its good ideas, only really win when there was no React to replace in the first place?