There's a paradox nobody wants to say out loud: the same frameworks companies pick because they're "enterprise-ready," "scalable," and "industry standard" are, for an LLM writing code, a minefield.
Angular, React with its whole ecosystem, Nx with its monorepos: these are powerful tools, built by humans to coordinate teams of humans on massive codebases. And for that purpose, they're often the right choice — if your primary constraint is coordinating hundreds of engineers over a decade, the conventions and tooling of an established framework earn their keep.
But there's a second actor in the room now. When the one writing the code is an AI, the very traits that make these frameworks "robust" turn into pure friction. The argument I'm making isn't "Angular and React are obsolete." It's narrower: we've historically optimized software architecture for human cognition, and LLMs introduce a different cost model that may favor simpler, more deterministic architectures — at least in some domains. Let's break down why, in three points.
1. The Token Tax (and the Cognitive Bottleneck)
An LLM doesn't "understand" code the way we do — it processes it token by token, and every token costs something: money, latency, and context window that could otherwise be spent reasoning about the actual problem.
Try asking an AI to generate a simple input form in a typical Angular/Nx context. To do it "properly" it has to:
- create the component (separate
.ts,.html,.cssfiles) - declare the
@Componentwith all its metadata - import and wire up the right modules
- possibly touch an
NgModuleor a standalone-components config - navigate 4-5 folder levels inside a typical Nx structure (
apps/,libs/,feature-x/,data-access/,ui/...)
All of this before writing a single line of actual logic. That's architectural complexity that, for a human, pays for itself over time thanks to tooling, autocomplete, and internalized conventions. For an LLM generating text sequentially, it's a tax paid on every single request.
My thesis: modern architectural complexity isn't just a cognitive cost for developers — it's a direct economic and latency tax on AI. More files, more boilerplate, more layers of indirection means more tokens, which means more time and more cost for every single generative interaction. Yes, context windows are growing and agents are getting smarter at navigating large repositories. But fewer tokens is still fewer tokens, at any scale — cheaper and faster doesn't stop being an advantage just because the baseline improves.
The alternative is a flat architecture, built on native web standards, where logic is deterministic and localized. In Inglorious Web, for instance, a component is an object with handlers and a render function:
const ContactForm = {
render(entity, api) {
return html`
<input @input=${(e) => api.notify("#contactForm:fieldChange", {
path: "email", value: e.target.value
})} />
`
},
}
No decorators, no modules to register, no folders to traverse. One file, one unit of meaning. For an LLM, that translates into a drastically smaller generative context — and in practice, a near-instant response instead of a whole reasoning pass spent figuring out where and how each piece fits.
"But what about Svelte or Solid?" — fair question, and the one a skeptical reader is probably already forming. Yes, both are lighter than Angular or React. But they don't fully solve the problem, for one fundamental reason: they both require a build step. Svelte compiles its template syntax into vanilla JavaScript before anything reaches the browser. Yes, human developers also reason about Svelte semantics rather than generated output — but they rely on compiler guarantees that have been tested and documented over time. An LLM has fewer opportunities to verify that the source it generates behaves as intended once that transformation step is applied. It introduces another semantic layer between what the model writes and what the runtime ultimately executes. SolidJS is closer to the metal, but its fine-grained reactivity — signals that automatically track dependencies at runtime — introduces a different kind of implicit magic: the LLM has to predict what the runtime will track, not just what the code says. These aren't fatal problems, but they are additional sources of unpredictability that a no-build, standards-native approach simply doesn't have.
2. Boilerplate-Induced Hallucinations
The more speculative code a codebase has — patterns added "just in case," preemptive abstraction layers, optional configurations — the more surface area an LLM has to get confused on.
If an AI has to navigate Signals, RxJS, a couple of custom stores, and maybe a different state-management library per feature (the jungle you've probably already run into in some Angular or React project that grew badly), it has more opportunities to hallucinate. It'll invent a method that doesn't exist, mix two incompatible patterns, break the app on the first refactor because it "guessed" a convention that wasn't actually the one the project used.
Generative AI excels when working close to platform-native abstractions: HTML, CSS, modern JavaScript. That's where it has seen the most examples, the most consistency, the least variance from one project to another. Every architectural "house of cards" we build on top of the native platform is one more dialect the model has to learn to recognize — and statistically, one it will get wrong more often.
A framework with a single state pattern (everything lives in the entity, never in component closures) and a single rule for changing it (api.notify(), always) eliminates entire branches of ambiguity. There's no choosing between useState, a signal, or a Redux selector: there's one way, always the same way. Fewer arbitrary choices to make means fewer chances to get it wrong.
And when something does go wrong — because it will — you're not left debugging magic. Inglorious Web is built on the three core principles of Redux (single source of truth, read-only state, changes through pure functions) and is fully compatible with Redux DevTools. This means you get time-travel debugging out of the box: you can replay every state transition, inspect exactly what changed and when, and pinpoint the moment the AI-generated code produced an unexpected result. The same determinism that makes the architecture legible to an LLM makes it legible to a developer with DevTools open. If you want to go deeper on this, I've covered the Redux principles and how Inglorious Web applies them in earlier articles — but the short version is: predictable state flow is a property that benefits both the model generating code and the human debugging it afterward.
3. "Just-In-Time UI" Is Already a Real Use Case — Even If It Stays Niche
I'm not going to claim that the 400-screen enterprise app is dead, or that users are about to stop wanting the button to always be in the same place. Consistency, auditability, accessibility — these are real constraints that keep pre-built UIs relevant, especially in regulated industries. Generative UI may never become the dominant paradigm, and it would be naive to predict otherwise.
But here's the thing: it doesn't need to be dominant to expose a genuine limitation in today's frameworks.
There are already real use cases where generating UI components on demand makes sense — data exploration tools, internal dashboards, custom reports. In these contexts, an AI receives a dataset and produces the visual layer needed to interact with it, just for that moment. Niche? Probably, yes. Nonexistent? Absolutely not.
And for this to work at all — even in a narrow niche — the rendering has to be fast. To be fair, both React and Angular have evolved significantly here: server components, partial hydration, and streaming have addressed many of the performance complaints that were valid a few years ago. But even in their modern form, they carry runtime overhead and initialization costs that are hard to shed entirely — because they were designed for complex, stateful applications, not for components assembled on the fly and discarded moments later.
What on-demand UI requires is a rendering engine with no intermediate compilers and no heavy runtime to initialize: re-render the whole tree on every state change and let a library like lit-html handle template reconciliation — efficiently updating only the DOM nodes that actually changed, without a virtual DOM layer in between. No zone.js to wake up, no signal graph to trace. Just: state changes → re-render → the browser applies the diff.
Whether this pattern will expand beyond its current niche is genuinely unknown. But the frameworks that make it technically impossible aren't even in the conversation.
When I Designed Inglorious Web
I'm not going to tell you "so go use my framework." But there's one thought I want to leave you with.
When I designed Inglorious Web, I did it to get back to the simplicity of web standards. Today I realize that same simplicity isn't just there to keep us humans sane — it's the only way to let AI generate interfaces that are fast, cheap, and stable.
The software of the future may end up looking surprisingly lightweight — not because humans demanded it, but because LLMs reward it.
Top comments (9)
Nice article thanks it quite resonates with my personal experience: I used to build everything fe with vanilla js on top of lit-html as the renderer; thing is I almost always was the only dev to touch the project, and building without any llm meant having everything “mapped” in my mind (documenting everything wasn’t an option due to time constrains). Then I moved to a less lone wolf situation, having to deal with more devs contributing to the code base, and have found that a more structured setup was indeed more helpful to onboard new teammates. TBH though we now use a nx monorepo with vue as the view layer, pinia for shared state and vue-query for data handling: project started to be written manually, ai assistants were introduced after the foundation was laid down. with a proper Claude.md/agent.md and tons of (llm generated /human reviewed )documentation Claude rarely misses the point (yes, always read and review the code also in person) or reach the token limits of a max sub.
Will for sure take a look to inglorious web as I really enjoy that “single source of truth thing” that could be the solution to my own drifting away from lit and vanilla.
Really enjoyed the reading🙏🏽
Thank you so much for your feedback! That's what I was thinking halfway through your comment: "Maybe he could have added a good state manager on top of his lit-html renderers and he wouldn't have drifted away". Notice that this is exactly how Inglorious Web was born: I combined Inglorious Store and lit-html, and voila!
Interesting perspective. I don't think it's that AI hates modern frameworks, but I do agree that convention heavy ecosystems increase the amount of context an LLM has to reason about.
I've noticed the same thing when switching between projects. A simple, opinionated architecture with one clear way of doing things usually leads to more reliable AI-generated code than a project with several competing patterns.
Thank you for your perspective! Don't mind the clickbaity title, I 100% agree with you.
Interesting perspective — especially the framing of framework complexity as a token and reasoning tax for LLM-driven code generation.
I agree that deeply layered architectures (Nx monorepos, multi-pattern state systems, mixed reactivity models) increase ambiguity both for humans and models. In practice, most AI-assisted code failures I’ve seen don’t come from “lack of capability,” but from inconsistent conventions and too many valid ways to express the same intent.
Where I’d push back slightly is on the idea that build steps or reactivity systems inherently reduce AI reliability. In well-structured codebases with strict boundaries and consistent patterns, even complex frameworks can be highly predictable for LLMs. The real variable is not framework depth, but consistency of abstraction.
That said, the argument for standards-native, low-abstraction UI layers in “just-in-time UI” and AI-generated interfaces is compelling — especially where determinism and speed matter more than long-term team-scale architecture.
Strong read overall.
Thank you Luis! You're right, a complex framework can be as predictable as a simple one if managed correctly. But what I noticed is that it burns way more tokens, with the risk of LLMs losing a bit of context over time.
This is a great point! I've wondered
Thank you Frank! Glad it resonated with you. If you ever plan to give Inglorious Web a try, let me know what you think about it!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.