Why AI Hates Modern Frameworks (and Loves Web Standards)

A developer argues that modern JavaScript frameworks like Angular and React impose a token cost on large language models (LLMs) when generating code, making simpler, standards-based architectures more efficient. The post highlights that frameworks optimized for human coordination create friction for AI, which processes code token by token, increasing latency and cost. The author advocates for flat architectures built on web standards, such as the Inglorious Web approach, to reduce generative context and improve AI performance.

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 https://angular.dev/ , React https://react.dev/ with its whole ecosystem, Nx https://nx.dev/ 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. 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: .ts , .html , .css files @Component with all its metadata NgModule or a standalone-components config 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: js 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 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 https://inglorious.dev/web is built on the three core principles of Redux https://redux.js.org/understanding/thinking-in-redux/three-principles single source of truth, read-only state, changes through pure functions and is fully compatible with Redux DevTools https://github.com/reduxjs/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 https://dev.to/iceonfire/entity-centric-architecture-a-different-way-to-think-about-web-uis-4mkd — but the short version is: predictable state flow is a property that benefits both the model generating code and the human debugging it afterward. 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 https://lit.dev/docs/libraries/standalone-templates/ 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. 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.