Why Great Systems Use Approximations That Feel Like Lies

Jun 20, 2026

9 min read

2 views

68%

The number is wrong, and that is the point

A can of soda tells a small but revealing lie. If you do the arithmetic by hand, the sugar seems to imply one calorie count, while the label gives you another. At first glance, that looks like a mistake. But the deeper truth is more interesting: useful systems are often built on approximations that are intentionally not exact.

That idea is easy to miss because we are trained to treat numbers as if they are moral facts. A calorie count, a page load time, a pricing formula, a design pattern, a performance benchmark, all appear to promise certainty. But in practice, the best systems are rarely exact. They are usefully approximate. They trade purity for speed, simplicity, and human comprehension.

That is where the strange kinship between nutrition labels and HTMX begins. One is a way of simplifying how bodies consume energy. The other is a way of simplifying how browsers talk to servers. In both cases, the goal is not perfect representation. The goal is a model that works well enough to guide action without overwhelming the user.

The best systems do not tell the whole truth. They tell the smallest truthful version that still lets people act well.

Approximation is not a flaw. It is the interface

We tend to think of approximation as a compromise made when reality is too messy. But it is more accurate to say that approximation is the place where reality becomes usable. A nutrition label does not describe the chemistry of every bite of sugar molecule by molecule. It compresses a complicated biological process into a number that is good enough for decision making.

That same logic appears in web development. A traditional full page reload is conceptually clean, but it is often a terrible interface for human attention. HTMX makes a different wager: instead of requiring the browser to behave like a miniature application runtime, it treats the server as the source of truth and lets HTML fragments update the page in place. It is not the most theoretically complete model. It is the model that reduces friction.

This is the hidden pattern connecting the two ideas: the right abstraction is not the most exact one, but the one that collapses complexity into something the user can safely ignore.

Think of a restaurant menu. It does not list the molecular composition of each meal. It gives names, descriptions, and prices. That simplification is not deception. It is the interface through which choice becomes possible. If the menu tried to be chemically exact, it would become unusable. The same is true of calorie labels and browser interactions. Exactness can destroy usefulness.

In that sense, approximation is not the enemy of truth. It is the translation layer that allows truth to be acted upon.

Why exactness often makes systems worse

There is a seductive assumption in modern design, software, and even public policy: if a little is good, more precision must be better. But precision comes with costs. It can increase cognitive load, inflate implementation complexity, and create false confidence in distinctions that do not matter in practice.

Take nutrition. The body does not experience calories as a spreadsheet. It experiences satiety, digestion, metabolism, and context. The difference between a labeled 139 calories and a back-of-the-envelope 151 calories is not proof that one number is true and the other false. It is proof that energy accounting in living systems is inherently messy, and that different formulas are used depending on which tradeoffs matter most.

The same principle appears in user interfaces. A page that reloads completely after every interaction may be technically straightforward, but it introduces latency and interrupts flow. A very elaborate client-side app can feel more responsive, but it often hides state inside layers of JavaScript, making behavior harder to understand, debug, and maintain. HTMX occupies a different point on the spectrum: it chooses partial updates over total abstraction, letting the browser remain a browser while still making the experience feel immediate.

This is a powerful lesson: the pursuit of exactness can become a way of losing the plot. Systems can become so precise that they stop serving the people who use them.

Consider weather forecasts. The forecast is not wrong because it says 60 percent chance of rain and it ends up dry. It is useful because it changes behavior at the right level of confidence. You bring an umbrella. You reschedule the picnic. You do not need meteorological perfection to make a better decision. Likewise, a calorie label does not need biochemical exactitude to help someone compare options. A web interaction does not need a massive client framework to feel fluid. In both cases, what matters is whether the approximation is aligned with the decision at hand.

The deeper design principle: make the invisible cheaper

If we connect the two ideas more carefully, a stronger principle emerges: good systems reduce the cost of the invisible parts of reality.

For nutrition, the invisible part is metabolic complexity. No consumer can, or should, reconstruct digestive chemistry every time they read a label. The label exists to make an invisible process legible enough to influence behavior.

For web development, the invisible part is the machinery of request, response, and state change. Users do not care about the round trip itself. They care that a button works, a cart updates, a form submits, and the page stays responsive. HTMX is compelling because it takes something usually hidden inside JavaScript frameworks and makes it simpler by leaning on the semantics of HTML and the server.

This gives us a useful mental model: every system has a hidden engine and a visible interface. The quality of the system depends less on how sophisticated the engine is and more on how honestly and efficiently the interface maps to the outcomes people need.

A spreadsheet of calories is not meant to reveal the full physiology of food. A DOM fragment swap is not meant to reveal the full complexity of front end state management. Both are compressed representations of a much larger machine. The challenge is not eliminating compression. The challenge is designing compression that preserves the right distinctions.

That is why some approximations feel trustworthy and others feel sketchy. A trustworthy approximation tells you what matters and omits what does not. A sketchy one hides uncertainty while pretending to be exact.

Precision is valuable only when it improves judgment. Otherwise it is just decorative complexity.

A framework for choosing the right level of detail

The easiest mistake in system design is to ask, “How accurate can this be?” The better question is, “What decision will this number or interaction support?” Once you ask that, approximation becomes a design tool rather than a defect.

Here is a practical framework for thinking about it.

1. Identify the decision

What action is the user trying to take? Compare foods, navigate a page, submit a form, estimate effort, avoid an error. The smaller and more concrete the decision, the less detail you usually need.

2. Find the cost of error

Not all inaccuracy is equal. A rough calorie estimate is usually acceptable because it informs a broad choice. A medical dosage is not. A partial page update is fine if the state is simple and the feedback is clear. It is dangerous if hidden side effects are complex.

3. Compress only the variables that do not change the decision

A nutrition label ignores many aspects of food because they are not useful to the typical shopper at the moment of choice. HTMX ignores much of the client side state machine because it is not necessary for many interactions. The test is simple: if removing detail does not change the decision, remove it.

4. Preserve a path back to truth

Approximations should be honest about their limits. A label can be a label, not a lab report. A server rendered fragment can be a fragment, not an entire application architecture. The system should let you drill down when needed, without forcing everyone to pay that cost all the time.

This framework matters because many failures come from confusing an approximation for the thing itself. A calorie number is not your metabolism. A snappy UI is not a simple architecture. The approximation is a tool for action, not a replacement for understanding.

The real elegance of HTMX and calorie labels is humility

There is a cultural temptation to romanticize complexity. We assume that if something is sophisticated, it must be better. But the more mature design instinct is often the opposite. It asks: what is the smallest thing that still works? What can be delegated to a simpler layer? What can remain conventional, readable, and boring?

This is why both nutrition labels and HTMX feel refreshing. They reject the idea that every problem needs maximal machinery. A nutrition label does not demand that consumers become biochemists. HTMX does not demand that every site become a sprawling client application. Both say, in effect, the system should meet people where they are.

That is a kind of humility. It acknowledges that users do not need the whole universe, just enough of it to move forward. It also acknowledges that engineering teams do not win by impressing each other with complexity. They win by building things that are easier to use, easier to reason about, and easier to maintain.

The irony is that these seemingly simpler systems are often the result of deeper thought, not less. It takes real discipline to decide what to leave out. It takes experience to know when a general rule is good enough. It takes confidence to reject the illusion that every edge case must be handled in the primary path.

That is why the phrase “good enough” should be treated carefully. In sloppy hands, it means lazy. In skilled hands, it means optimized for the right layer of reality.

Key Takeaways

Do not ask whether a number or interface is perfectly accurate. Ask whether it helps people make better decisions.
Treat approximation as a design choice, not a technical failure. The best abstractions compress complexity without hiding the important parts.
Match precision to consequence. High stakes require more detail, but most everyday decisions benefit from simpler, legible models.
Prefer systems that make invisible complexity cheaper. Good labels, good APIs, and good UI patterns reduce cognitive friction.
Be suspicious of sophistication that does not improve judgment. If extra precision or abstraction does not help the user, it is probably noise.

Conclusion: the most honest systems are not the most exact ones

We often equate honesty with completeness. But in practice, the most honest systems are the ones that clearly reveal their purpose and limits. A nutrition label is honest because it gives a usable estimate, not because it captures every molecular nuance. A lightweight server driven interaction can be honest because it keeps behavior understandable, not because it maximizes architectural novelty.

The deeper lesson is that truth in design is relational. It depends on who is using the system, what decision they are making, and how much complexity they can tolerate without losing the thread. The right answer is rarely full fidelity. It is the smallest model that still produces good judgment.

That is a lesson worth remembering far beyond food labels and web tools. In a world obsessed with precision, the real advantage belongs to those who know when to simplify without lying, when to compress without distorting, and when to trust that a well chosen approximation can be more truthful than an exacting mess.