I want to be upfront about something before getting into this: most of what gets written about "the future of frontend" right now is confident to the point of being dishonest. This post tries to be different β honest about what's actually happening, honest about what's genuinely unknown, and honest about where my own view might be wrong.
Some of what I say here may age badly. I'm writing it anyway, because the alternative β the kind of post that declares the death of React and the birth of AGI-rendered holographic interfaces β is worse. Not because it's wrong. Because it's unfalsifiable, and unfalsifiable predictions are how people in this industry avoid accountability for their opinions.
Two Very Different Futures, One Overloaded Term
Generative UI is being used to describe two fundamentally different things.
The first is already here: AI generates the code or component structure that produces an interface. The second is much more ambitious: the interface itself is generated dynamically at runtime in response to the user's state, intent, or data.
Those are not the same technology, and the engineering constraints between them are enormous. Most of the discourse about "generative UI" conflates them β often unconsciously, because the second one sounds more futuristic and gets more engagement. This post is about what happens when you take that distinction seriously.
What Is Actually Happening Right Now
Generative UI, in the form that actually exists today, is not a browser rendering UI dynamically from an LLM in real-time. That remains a largely unsolved engineering problem in production contexts, for reasons we'll get into. What's actually happening is something more specific and more interesting: AI tools are getting dramatically better at writing the code that produces UI.
If you've used tools like v0.dev, you've seen this. You describe what you want β "a dashboard card with a chart and three KPI numbers" β and get back a working React component. It's not always what you had in mind. The accessibility is often poor. The design system integration usually needs work. But it ships something real in seconds that would have taken a developer twenty minutes.
That is genuinely significant. Not because it's magic, but because it changes the economics of prototyping, of iteration, of the early-stage decision about whether an idea is worth pursuing. The cost of "let's see what this looks like" has dropped close to zero. That changes how products get built.
But there is a very large gap between "AI writes UI code" and "AI renders UI at runtime in the browser." Keeping that distinction clear is what this post is about.
The Latency Problem That Doesn't Get Solved by Handwaving
Human perception also puts real constraints on interactive UI. Around 100ms feels instantaneous; around 1 second is roughly the point at which users begin to notice that their flow has been interrupted. Beyond that, the interface needs to communicate progress rather than simply appear frozen.
Even with fast inference and small models, end-to-end latency for LLM-driven UI generation can easily exceed the response times users expect from direct interactions β especially once network, context processing, tool calls, and generation are included. For a simple button click, that gap is already meaningful. For unconstrained runtime generation of something as complex as a new UI panel, end-to-end latency can easily move into seconds rather than the tens-of-milliseconds range expected from direct UI interaction.
This is not a constraint that faster hardware alone will resolve. It reflects a fundamental tension between the statistical nature of LLM inference and the deterministic, near-instant expectations of UI interaction. The two don't fit together cleanly.
There are approaches to address this β pre-generation, caching, speculative rendering, running small models on-device. Some of these are promising. Apple's on-device intelligence work is relevant here; they've specifically made the architectural choice to run models locally to get acceptable latency. But these are engineering solutions to a hard problem, not demonstrations that the problem doesn't exist. Claims that runtime AI rendering will become straightforward often leave the state, latency, testing, and authorization problems unspecified. Those problems are real and unlikely to disappear quickly.
The State Problem Nobody Wants to Explain
Here is a specific technical problem with runtime generative UI that I haven't seen discussed honestly anywhere.
Most interactive UIs have state. A form where the user has filled in three of five fields. A shopping cart. A multi-step wizard. A filtered table view. This state belongs to the user β it represents their work in progress. In a traditional UI, that state lives in the component tree and persists through re-renders via controlled components and state management libraries.
In a runtime-generated UI, what happens when you regenerate the UI? If the model produces slightly different HTML β different element IDs, different structure, different order of fields β what happens to the half-filled form? How does focus behave? How do you reconcile "the user was on step 3 of the wizard" with a freshly generated UI that has no memory of step 3?
This is a real engineering problem. The component model popularized by React exists partly because it gives applications a deterministic representation of UI identity and state across updates β the reconciliation algorithm knows how to update only what changed while preserving component identity and state. Replacing it with LLM generation at runtime means either giving up this property or rebuilding it from scratch on top of generative output. Neither is trivial.
One promising direction is to separate generation from execution: let the model generate a UI description or component tree once, then let deterministic application code own state, events, and subsequent interactions. That reduces the problem substantially β but it also changes what "generative UI" actually means. You're no longer regenerating UI on every interaction; you're using generation as a one-time authoring step. That's a meaningful architecture, and arguably the right one β but it's different from the runtime vision most of the hype describes.
The Design System Tension Nobody Is Talking About
Large enterprises may face a particularly interesting version of the generative UI problem because they've spent years β sometimes decades β building design systems. Consistent typography, color palettes, spacing systems, component libraries that encode accessibility requirements and brand guidelines into reusable primitives. This work is expensive and intentional. It exists because consistency, at scale, across many teams and many products, doesn't happen by accident.
Generative UI, in its current form, actively works against this. Ask an LLM to generate a button and it will produce something that looks reasonable but doesn't match your design system. Ask it to generate a form and the spacing will be slightly off, the font weight slightly wrong, the focus states not quite compliant with your accessibility guidelines. Every generated element is a micro-deviation that accumulates into inconsistency.
The solution most teams reach for is constraining the model β giving it the design tokens, the component library, the style guide. This works, imperfectly. The model still hallucinates occasionally, using a spacing value that doesn't exist in your system or a color that's close but not quite right. And the more you constrain it, the more the "generative" part becomes narrow β you're essentially asking it to assemble existing components in new configurations, which is useful but different from the open-ended generation the hype suggests.
I don't know how this gets fully resolved. It might not get resolved β it might just be the ongoing tension design teams have to manage. But the current narrative treats generative UI as something that will simplify frontend development. For teams with serious design systems, it may just add a new kind of complexity.
The Testing Problem That Emerges at Runtime
Frontend testing has a complicated history, but the industry has developed a reasonable set of tools and practices: unit tests for logic, component tests for rendering, integration tests for user flows. These work because the output is deterministic β the same code, the same inputs, produce the same UI.
Generative UI breaks that assumption. If a component's structure is generated at runtime by a model, how do you write a test for it? You can't test against specific element selectors that might not exist in the next generation. You can't snapshot test a generated output that varies. You can't easily assert "this rendered correctly" when "correct" is defined by a probabilistic model.
The approaches that make sense β testing against semantic content rather than structure, behavioral testing rather than structural testing, using smaller constrained models that produce predictable output within bounds β exist but require rethinking how frontend testing is done. This problem largely disappears when generation produces a constrained schema that is then deterministically rendered: the nondeterminism belongs at the generation boundary, not in the UI runtime. That architectural separation is one of the strongest arguments for the constrained-schema approach covered later. Where that separation isn't present, the testing tooling and practices aren't ready yet.
The Security Concern That Is Actually Real
Prompt injection into UI is a real concern, and it's worth understanding concretely rather than abstractly.
Imagine a help-desk application where an AI reads the user's submitted ticket and generates a UI for the support agent β showing relevant information, suggested responses, action buttons. The ticket content is user-controlled. A sophisticated attacker submits a ticket designed to influence the model's behavior. The dangerous case isn't merely that the model generates a malicious-looking button. It's when untrusted content can influence the model's decision about which privileged UI actions or tools become available β and those actions are then executed without an independent authorization boundary.
This isn't a theoretical concern. It's structurally identical to prompt injection attacks that have already been demonstrated against LLM-based systems in research settings. The specific vector β using user-controlled content to influence which UI actions or tools are exposed β is a particularly important application of the broader prompt-injection problem, and one that deserves first-class attention in any system where user content drives UI generation.
The mitigations are real but imperfect: strict Content Security Policy, sandboxed rendering environments, output validation against schemas, separate models for untrusted content, and β most importantly β independent authorization checks that don't rely on the model's judgment about what a user should be allowed to do. None of these are complete solutions. Any team building generative UI that renders based on user-controlled content should be treating this as a first-class security concern, not an afterthought.
What the Discourse Gets Wrong About the DOM
You'll occasionally read that the DOM is dying β that WebGPU and canvas-based rendering will replace it. This is an old prediction that keeps getting recycled, and it's worth addressing directly.
The DOM is more than a rendering mechanism. It provides the semantic document structure that browsers can expose to accessibility technologies, scripting, navigation, extensions, and other parts of the web platform. You can render to canvas and get a visually identical result, but you lose the entire ecosystem that makes the web accessible and interoperable.
Figma is a useful example of the tradeoff. Its canvas rendering doesn't automatically provide the accessibility semantics that traditional HTML and the browser's accessibility tree provide, so Figma has had to build a separate accessibility layer β including a Mirror DOM β to expose that information to assistive technologies. Games and specialized graphics applications render to canvas or WebGPU and that's appropriate for them. For general-purpose application interfaces that need to work for everyone, the DOM's overhead buys you things that matter.
This doesn't mean the DOM is perfect or that nothing will change. It means claims about the DOM's death usually come from people thinking about rendering performance in isolation, without accounting for the full set of constraints that make the web work for actual human beings.
The Part Everyone Keeps Missing: The Model Probably Shouldn't Own the UI
The most technically interesting direction for runtime generative UI isn't what most of the hype describes β an LLM continuously regenerating HTML in response to every user action. That path runs into all of the problems above simultaneously.
The more promising architecture separates concerns: intent β model β constrained UI schema or component graph β deterministic renderer β application state. The model generates the interface description once; ordinary application code handles state, events, and subsequent interactions. This reduces the latency problem, the state problem, and the testing problem substantially. It also changes what "generative" means β but it changes it in a direction that's actually deployable.
Runtime generative UI doesn't necessarily mean regenerating the DOM after every click. It might mean generating a durable component structure from user intent, then handing that structure to a conventional rendering system that behaves predictably. That's a real architectural pattern, and it's the kind of thing that might actually ship in production systems β as opposed to the open-ended vision that makes for better conference talks.
What I Think Actually Changes for Frontend Developers
Here is my honest assessment.
The part that's already changing: the economics of first-draft UI production. Generating a component from a description, generating a layout from a wireframe, generating a form from a data schema β these are genuinely getting faster and more reliable. The bottleneck is shifting from "write the code" to "evaluate and refine the output." This is a real skill change. Knowing whether generated output is correct, accessible, and consistent with your design system becomes more important than knowing how to produce it from scratch.
The part that will take longer than people expect: AI driving meaningful runtime UI decisions in production applications. The latency, state, testing, and security problems are real. They will get partially solved over time, but "partially solved" in an engineering context often means "manageable under specific controlled conditions," not "general solution that works everywhere."
The part that isn't changing as much as claimed: the underlying skills that make someone good at frontend. Understanding how browsers work, why layout behaves the way it does, what accessibility requires, how state should flow through an application β these remain as valuable as ever, and arguably more valuable because you need them to evaluate generated output. The person who never learned these things can't tell the difference between good generated UI and plausible-looking bad generated UI. That difference matters.
The Honest Prediction
In ten years, frontend development will look significantly different from today. Some of the specific changes I've described will probably be wrong. But the direction β toward more generation, more evaluation-as-skill, more tension between design systems and generative flexibility, more novel security concerns β feels right to me, with the appropriate uncertainty.
What I'm confident about: the hype cycle around generative UI is generating a lot of predictions that are technically underspecified and unfalsifiable. The most confident claims often leave the engineering constraints unspecified. That's not necessarily malice β it's the normal shape of technology discourse. But the missing details matter.
Frontend development is not dying. I don't expect the DOM to be broadly replaced by WebGPU rendering this decade for general-purpose applications. React is not irrelevant. But the set of skills that matter, the set of problems that are hard, and the set of things worth understanding are genuinely shifting β more slowly than the hype suggests, more significantly than the dismissers suggest.
That's the most honest assessment I can give. I reserve the right to be wrong about the details.
If you work in frontend and see this differently β especially if you're working on the runtime generation problem directly β the conversation is worth having.