In 2015, Guillermo Rauch published Pure UI. Its thesis, that the UI of an application should be a pure function of its state, has become a cliché of modern design. But a decade later, I don't think the key lesson in the essay is the formula itself. It's the map that accompanies it: the map of every state that an interface can exist in, which has become a tool for designers and developers to share.
In the years since Rauch's essay, the idea of Pure UI has become so entrenched that it's hard to imagine the problem being solved any other way. Before React, when writing a pure function for an interface was alien to most programmers, we described how an application leaves one screen and arrives at another: a spinner appears while a request is in flight and the button disappears; when the request completes, the button returns; if the request fails, an error is appended and then eventually removed. Event handlers on buttons and other controls change the screen a step at a time, so its behavior and appearance depend on the sequence in which the handlers run.
Rauch's key insight is that you can stop describing these transitions and start describing the resulting state of the interface: a pure function that takes a state and returns the screen that corresponds to it, then is called again whenever the state changes.
Describing how the UI should work as a series of screens was already intuitive to designers. Creating artboards for desktops, tablets, and phones is analogous to calling the same pure function with different inputs. Instead of a collection of screens, a style guide like GitHub's Primer describes components with parameters, like passing a class to get its variant. React gave developers a model designers had long been using.
What has aged best
The most compelling moment in the essay is an admission. Rauch wrote that “underestimating the size of the state space is actually very easy.” The video player seems like a single screen, but it turns out to need states for a video still converting on the backend, a video removed after a copyright claim, a connection or server error, an age gate, a stream that stalls mid-playback, and a user hovering the progress bar. They are all obvious once he's stated them, but none were obvious when he started.
Rauch writes that an incomplete state space leads to poor estimates. You can't predict how much work a project is going to be if you don't have a list of all the states it will include. This is a much better explanation for inaccurate estimates than most I've heard, which blame bad math. The problem isn't the math; people are bad at making lists.
For a remedy that would help with estimates, Rauch proposed breaking an interface into small functions, giving a complete list of what each accepts as input, and rendering all combinations that are worth showing. The list of states becomes a negotiated deliverable between designers and developers; if a designer lists twenty states and we render ten, we know we're halfway there.
We've all absorbed this practice. Component workshops show every variant of a single component on one page. Tools like Figma introduced variants and properties to allow designers to build all states into a single component. Visual regression suites capture and compare all states on every commit. The state map has become a tab in the toolbar.
Where purity leaked
The function stayed pure, but the context around it did not. With jQuery, you only see a payment form's failure path if you force the payment to fail. A pure render can show the form in its success and failure states at the same time. But the pure function only describes the on-screen frame. The hard work is not in the screens but the actions between them: requests that time out after retries, responses that arrive after a form has already been submitted, and double submissions.
A pure function can render a “network error,” but it can't describe how the application got there or how to get out again. The state map is a roster of the rooms, not the hallways where the bugs live. For a decade, data-fetching libraries, effect systems, and server components have tried to bring the hallways under the same discipline as the rooms.
This is also where the argument about estimates gets harder. Listing states is tractable, but listing sequences of states is combinatorial. A team that shows all twenty checkout screens could still have a bug that only happens after a certain sequence of four steps. The state map describes what a screen can look like, but it needs a complement that explores the ways users get there.
What the map is for today
The complement that I'm most excited about is property-based and model-based testing, which generates sequences of actions and verifies that every reachable state meets a desired property. These approaches shrink a test failure down to the shortest path that triggers it. Where the state map was a gallery of the rooms a designer listed, a property-based suite turns it into a territory. Instead of rendering only the twenty rooms on the designer's list, it explores the rooms a user can actually reach and reports the ones nobody listed.
Rauch measured the completeness of a state map by comparing a designer's list with the implementation. Property-based testing compares both with reality.
There's another reason the state map is important. A growing share of interface code starts as a prompt to an AI model. A prompt like “build a video player” generates a single screen. The same prompt with a list of states like “converting,” “removed,” “age gate,” and “error” comes closer to the product. A list of state names is the most valuable specification an AI agent can receive. It is also the most valuable specification a developer can receive, because it moves discovery to the early stage where it's the most efficient.
The legacy of Pure UI
Pure UI has become known for advocating a programming model. I think it was advocating a practice: before you start to build a new interface, list every state it can be in and keep that list visible for everyone. React made that practice practical, and that practice made the work easier to estimate, review, and share.
The formula showed how to display a state. The map described which states actually exist. A decade later, the formula is infrastructure. The map is the component that every project neglects.