Blog post
The Future of Frontend Is Generative
Generative UI flips the old assumption: the model assembles the interface from your component library at runtime.
For the past few weeks I have been digging into a framework called Hashbrown (https://hashbrown.dev/). I have read their source code, gone through the official samples line by line, and we use it in our own production app. Here is the thing that has been circling in my head for days: my belief is that this kind of tool is about to change the way frontends are built entirely.
Over the years, no matter how we built frontends (from jQuery to React to signals), one thing never changed: the developer decides up front what the user will see. Every screen, every form, every flow is drawn by our hands. A user has a thousand different needs, but the UI is one fixed path for everyone. On a settings page with 40 options, finding the one the user needs is the user’s job.
Generative UI flips that assumption. The screen is not drawn in advance. The user states their need, and the model assembles the right UI for that exact moment, picked from your component library. Whoever wants a chart gets a chart. Whoever needs a small form gets just that form. The interface is then no longer a fixed artifact: it is a response assembled at runtime.
Hearing this, you might think the frontend developer’s job is over. To me it looks like the exact opposite: the work is moving up a level. Notice: the model does not build any UI itself, it is not even allowed to write arbitrary HTML. It assembles from our built, tested, accessible components. So component libraries and design systems are not losing value: their worth is multiplying several times over. Because components are now your app’s vocabulary, and the model will build its sentences out of those words.
And the nature of the work changes like this: I used to think “what goes on this page?” Now I think “what can my app do, and how do I declare those capabilities to the model?” Every component needs a description, every input needs a typed schema, every tool needs a contract. Writing those is now the design work. Schema design, capability boundaries, deciding how much power to hand the model and how much to keep in deterministic client logic: that judgment is the new skill.
The most interesting thing that stuck from Hashbrown’s samples: one of their demo apps does not even have a router. The model decides which screen to show when (the system prompt effectively is the routing table). We do not need to go that extreme everywhere, but the direction is clear.