The End of the Loading Spinner

There's a UX pattern so ubiquitous we've stopped questioning it: the loading spinner. You click something, a spinner appears, you wait 200-800 milliseconds, the content appears. This has been the rhythm of web software for twenty years.

I want to argue that the loading spinner is not a design decision — it's an apology. It's the interface's way of saying "I'm sorry, your request had to travel thousands of miles and wait in a queue and we're doing our best." The spinner is evidence of a broken assumption embedded in the architecture.

The assumption: software runs on remote servers. The result: every interaction includes network latency. The apology: the spinner.

Local-first software eliminates this assumption. And when you eliminate the assumption, you eliminate the apology.

What Latency Actually Costs#

I want to be specific about the cost of latency, because I think it's systematically underestimated.

There's research going back to 1982 — the Doherty Threshold — showing that when response time drops below 400ms, human-computer interaction enters a qualitatively different mode. Users try more things. They explore rather than plan. They develop intuition faster. The tool feels like an extension of thought rather than an obstacle between thought and action.

Above 400ms, users shift into a planning mode. They batch their queries. They think before they click because the cost of a wrong click is 400ms wasted. They develop habits that minimize interactions because interactions are expensive.

This sounds subtle but the effects accumulate. I've watched experienced Salesforce users work. They have specific, refined workflows — exactly the sequence of clicks that gets them what they need with minimum redundant actions. These workflows are optimization artifacts. They exist because the software is slow, and slow software teaches you to be efficient with your clicks.

When software is instant, you stop needing these optimized workflows. You just try things. You ask questions you wouldn't have bothered asking if the answer cost 800ms. You check in on data you wouldn't have checked if loading it required patience.

This is why performance isn't just a technical metric. It changes what users do with the software.

A Query That Costs 3ms vs. 300ms#

Let me be concrete. In DenchClaw, querying "all contacts who haven't been reached out to in 30 days" takes about 3ms. This is a DuckDB analytical query against a local file — disk I/O, in-process computation, result serialization.

The equivalent query in a cloud CRM: 300-600ms. This is a network round-trip to a server in a data center, possibly a read query against a shared database under load, result serialization, network return.

3ms vs. 300ms isn't 100x faster in a way that "only engineers care about." It's the difference between asking a question and getting an instant answer, versus asking a question and waiting for someone to look it up. The latter breaks the conversational flow that makes interaction natural.

When I first built the local DuckDB query layer and ran this in a terminal, my first reaction was disorientation. I kept thinking the result was cached. It couldn't really be that fast. But it was. That's just what happens when data and compute are on the same machine.

The Spinner as Competitive Advantage (Temporarily)#

Here's the counterintuitive thing about the loading spinner era: it was briefly a competitive advantage to have a fast spinner rather than no spinner.

In the early 2000s, cloud software that loaded in 500ms was dramatically faster than desktop software installed from CD-ROMs. The cloud spinner was an improvement, not an apology. Users chose cloud software partly because it was faster to set up and partly because the upgrade cycle was faster.

But that window closed around 2015. By then, web software was so common and so similar in performance characteristics that the spinner was just the expected cost of doing business. Everyone had one. Nobody was faster. The competitive advantage evaporated.

What's happening now is the next phase: local-first software can be genuinely faster than cloud software — not incrementally faster, but categorically faster. The spinner disappears. The question is whether users notice and value this.

My experience building DenchClaw: they do. Within a week of using a sub-10ms CRM interface, cloud CRM latency becomes viscerally noticeable. You've recalibrated to instant. Anything else feels broken.

What the End of Latency Enables#

When you remove latency from an interactive application, some things become possible that weren't before.

Real-time filtering. As you type in a search box, results filter with every keystroke. No debouncing, no "wait until they stop typing." The query runs on every character. At 3ms per query, this is fine. At 300ms per query, it's not.

Exploratory analytics. "Show me deals by stage" → "break that down by rep" → "filter to Q1" → "show only deals over $50K" — this kind of exploratory pivot happens fluidly when each query is instant. It requires patience when each query takes a second.

Conversational interaction. When you say something to the DenchClaw agent and it responds in 100ms, the interaction feels conversational. When it takes 2 seconds, it feels like waiting for a form to submit. The conversational quality of AI interaction depends partly on the latency of the underlying operations.

No loading states. The entire complexity class of "show old data while loading new data," "optimistic updates," "skeleton screens," "progressive loading" — all of this exists to manage the user experience during latency. Remove the latency; remove the complexity.

Undo. When operations are instant and local, undo becomes trivial — just reverse the last operation against the local store. When operations require network synchronization, undo becomes complex state management across distributed systems.

The Design Implications#

The end of the loading spinner isn't just a performance story. It changes how you design interfaces.

When responses are instant, you design for exploration. When responses are slow, you design for efficiency. These are different products.

An instant interface can afford to be playful — let users try things, show them the result, let them adjust. A slow interface needs to be precise — help users get to the right state with minimum clicks.

An instant interface can show richer information by default — more columns, more context, more data points. A slow interface has to be careful about what it loads because each additional data point costs latency.

An instant interface can update continuously — live counts, streaming data, real-time updates. A slow interface has to batch updates and decide when to refresh.

DenchClaw's design is built around instant interaction. The views update as the agent modifies records. The search filters as you type. The pipeline metrics are always current. This isn't aggressive engineering — it's the natural consequence of removing the network from the critical path.

Frequently Asked Questions#

Doesn't caching make cloud software effectively as fast as local?#

Caching helps for data that doesn't change, but CRM data changes constantly. Aggressive caching for frequently-read data can bring read latency down, but invalidation is expensive and cache misses are common for personalized queries. Local storage doesn't have cache miss problems.

Will WebAssembly or edge computing solve the latency problem for cloud apps?#

Edge computing reduces latency by moving servers physically closer to users. WebAssembly enables running code in the browser. These help, but they're in the direction of "local-first" — moving compute to the edge. The logical conclusion of edge compute is the device itself.

Is there a meaningful difference between 100ms and 3ms for users?#

Below ~100ms, differences are mostly imperceptible in isolation. The difference matters when you're doing many sequential operations — each one 3ms vs. each one 100ms compounds significantly. And the psychological difference between "instant" and "fast" is real even when the absolute difference is small.

What about first load performance? Local apps still need to load.#

First load for DenchClaw: npx denchclaw runs in about 30 seconds. Subsequent loads (after npm cache is warm): 2-3 seconds for the process to start. This is comparable to cloud apps for first load; subsequent loads are similar or faster.

Does local-first mean offline-first?#

Local-first implies the software works offline, but offline is not the primary goal — performance and ownership are. The fact that it works offline is a beneficial side effect of not depending on a network connection for core functionality.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →