99% Of Devs Are Quietly Using The Wrong UI. This Actually Changes Everything.
**Sarah Chen** — Full-stack developer and educator. Writes about web development and programming craft.
> **Bottom line:** A new React component library called "Performative-UI" hit the top of Hacker News this week by institutionalizing the web's worst design tropes—meaningless loading spinners, fake skeleton states, and un-closable popups.
While developers are laughing at the satire, the library exposes a deeply uncomfortable truth: we've stopped designing for users and started designing to appease engagement metrics and our own technical egos.
If your application relies on artificial friction to mask slow queries, you aren't building a product; you're building a performance.
I spent three weeks last month optimizing a React application's loading states, meticulously crafting staggered skeleton screens and micro-interactions.
It wasn't until I watched a user aggressively tap their screen, waiting for my beautifully animated skeletons to finally yield the data, that I realized my "clean UI" was actively hostile.
I had spent 120 hours building a theatrical performance to hide the fact that our backend was unacceptably slow.
When the **Performative-UI component library rocketed to the top of Hacker News** this week with a massive 915 points, it hit me right in the chest.
The repository is a masterclass in satire, offering ready-to-use components like `
It's hilarious right up until the moment you realize **you've shipped variations of these exact components to production**.
We all have. And it's costing us the trust of the very people we claim to be building for.
The Era of Theatrical Engineering
There is a growing obsession in frontend development with making things *feel* complex so the user believes value is being generated.
We have traded raw speed and utility for a highly choreographed digital theater.
If an AI prompt executes in 200 milliseconds, product managers will often demand we artificially slow it down to 3 seconds.
**They argue users won't trust an answer that generates too quickly.** We add blinking cursors, "analyzing data..." text, and simulated thinking states.
We justify this manipulation as "managing user psychology." But in reality, we are conditioning our users to expect friction as a proxy for quality.
This isn't just an AI problem. Look at modern e-commerce checkouts or SaaS onboarding flows. We've normalized the practice of holding users hostage in our beautifully designed waiting rooms.
**Performative-UI is just saying the quiet part out loud:** we are intentionally degrading the user experience to serve internal metrics and our own egos.
Stop Designing for Dribbble
The conventional wisdom in modern web development is that friction is the enemy, and we must build elegant states to smooth over that friction. I disagree completely.
**Elegant loading states don't reduce friction; they institutionalize it.**
When you build a perfect skeleton loader, you remove the urgency to fix the underlying performance issue.
Everyone looks at the smooth, pulsing gray boxes and decides the 4-second database query is suddenly acceptable.
We need to stop designing interfaces that look good in a portfolio and start designing interfaces that respect the user's time.
A blank screen that resolves in 50 milliseconds is infinitely superior to a buttery-smooth skeleton screen that takes 3 seconds.
By wrapping our architectural failures in beautiful UI, **we are lying to our users and we are lying to ourselves.** Performative-UI forces us to look in the mirror and see the dark patterns we've accepted as "industry standard." We aren't crafting experiences; we're applying lipstick to technical debt.
The Friction Facade Framework
To understand how deep this rot goes, we need a way to identify when we are building actual value versus when we are just performing. I call this the **Friction Facade Framework**.
There are three distinct layers where performative design infects our applications, usually right under the guise of "best practices."
1. The Processing Illusion
This is the most common performative trope. It's the `
Whether it's a travel site "searching 400 airlines" or an AI tool "synthesizing data," **we are injecting fake latency into systems that are inherently fast.** We treat the user's time as a disposable resource to be burned in exchange for perceived product value.
This is a profound breach of trust.
2. The Hostage Checkpoint
These are the UI elements designed purely to prevent the user from doing what they want. Think of the `
We dress these up as "retention strategies" or "churn reduction features," but they are explicitly hostile.
**When you make a destructive action intentionally difficult, you are building a hostage situation, not a product.** You are extracting a few extra dollars at the expense of lifelong brand resentment.
3. The Decorative Apology
This happens when our architecture fails, and instead of fixing the root cause, we build elaborate UI to apologize for it.
This is the over-engineered empty state, the cute 404 page, and the aforementioned skeleton screen.
**We spend more engineering hours designing the failure state than we would have spent fixing the underlying performance bottleneck.** The decorative apology allows us to feel good about our craftsmanship while ignoring the fact that the user didn't get what they came for.
What This Means for Your Next Sprint
If you are a mid-level frontend engineer, Performative-UI shouldn't just be a joke you share in Slack; it should be a wake-up call. **The industry is reaching peak frustration with theatrical design.**
As we head deeper into 2026, the novelty of complex, animated interfaces is wearing off. Users are becoming hyper-aware of when they are being manipulated. They can spot artificial latency.
They know when a progress bar is fake.
**In the next 18 months, raw, unapologetic speed will become the ultimate premium feature.**
The products that win won't be the ones with the most elaborate loading animations. They will be the ones that load so fast they don't need animations at all.
When you sit down for your next sprint planning, look at the UI tasks on the board. Are you building a feature that provides value, or are you building a decorative apology for a slow API?
If it's the latter, push back. Demand time to fix the query instead of building the skeleton. **Your job is to deliver data to the user, not to entertain them while they wait for it.**
The Illusion of Control
At its core, the obsession with performative UI stems from our own anxiety as developers. The web is chaotic. Networks drop, databases stall, and third-party APIs fail.
By building elaborate, choreographed states for every possible outcome, **we create an illusion of control over a fundamentally unpredictable medium.** We want to believe that if we just design the perfect error state, the error itself won't matter.
But users don't care about our error states. They just want the thing they clicked on.
Performative-UI is a brilliant piece of satire because it strips away our professional justifications and shows us exactly what we're doing: wasting everyone's time on purpose.
It forces us to ask whether our complex, modern web stacks are actually serving the user, or if they are just serving our need to feel like serious software engineers.
Have you caught yourself building performative UI recently to cover up a deeper architectural flaw, or is it just me? Let's talk in the comments.
---
