DEV Community: Matteo Antony Mistretta

Why AI Hates Modern Frameworks (and Loves Web Standards)

Matteo Antony Mistretta — Tue, 30 Jun 2026 12:30:16 +0000

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, .css files)
declare the @Component with all its metadata
import and wire up the right modules
possibly touch an NgModule or 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.

The Code AI Won't Write

Matteo Antony Mistretta — Tue, 16 Jun 2026 12:30:05 +0000

I use a form validation problem as a technical interview question. It's deceptively simple — and the solutions people reach for reveal a lot about how they think.

Then I tried it on Claude, ChatGPT, and Gemini. The results were illuminating, but not for the reasons I expected.

The Problem

Many form libraries share a common convention: form data is represented as a plain nested object, and the validation function returns an object of the same shape containing the errors. You'll find this pattern in Formik and React Final Form in React, and — full disclosure — in Inglorious Web, my own framework, which ships form handling built in without any extra dependencies.

const values = {
  productName: 'VR Visor',
  quantity: 1,
  homeAddress: { street: 'Long St', zip: '00666' },
  shippingAddress: { street: 'Short St', zip: '00777', co: 'Inglorious Coderz' },
  billingAddress: { street: 'Wide Plaza', zip: '00888', vat: '1142042' },
}

The validation function should return an object containing all errors found. A starting example:

function validate(values) {
  const errors = {}

  if (!values.productName) {
    errors.productName = 'required'
  }

  return errors
}

The ask: extend this to validate every field.

Notice that the three address types aren't identical. shippingAddress requires a co field. billingAddress requires a vat. These differences matter — and how you handle them reveals a lot.

Four Solutions, Four Instincts

1. The Flag — the average human

The most common approach I see in interviews is a single validateAddress function with a type parameter:

function validateAddress(values = {}, type) {
  const errors = {}

  if (!values.street) errors.street = 'required'
  if (!values.zip) errors.zip = 'required'

  if (type === 'shipping' && !values.co) errors.co = 'required'
  if (type === 'billing' && !values.vat) errors.vat = 'required'

  return errors
}

It works. But every new address type, every new special rule, becomes another branch inside the same function. The differences between types are hidden rather than expressed.

2. Recursion without a schema — the clever human (and the AIs' first attempt)

The cleverest answer I ever received in an interview was this:

function validate(values) {
  function validateNode(values = {}) {
    const errors = {}

    for (const [key, value] of Object.entries(values)) {
      if (value && typeof value === 'object' && !Array.isArray(value)) {
        const nestedErrors = validateNode(value)
        if (Object.keys(nestedErrors).length) {
          errors[key] = nestedErrors
        }
      } else if (!value) {
        errors[key] = 'required'
      }
    }

    return errors
  }

  return validateNode(values)
}

No schema, no flags — just a recursive walk of the data shape itself. Elegant, clever, a bit too complex for my taste maybe, but genuinely impressive.

But it has a silent flaw: it only validates fields that are present in values. If billingAddress arrives without a vat key entirely, the error is never registered. The function doesn't know what it doesn't see.

To be clear: the problem here isn't recursion itself. It's that the implementation has no source of truth about what fields are expected. A recursive validator can work perfectly — if it's driven by something that knows the shape of the domain.

Interestingly, this was also the first instinct of all three AIs — Claude, ChatGPT, and Gemini independently reached for this same structure. When I pointed out the missing-key problem, they all reached for the same fix.

3. Schema + recursion — the AI that wants to cover everything

Once the missing-key flaw is on the table, the natural repair is to drive the iteration from a schema rather than from the data:

const schema = {
  productName: true,
  quantity: true,
  homeAddress: { street: true, zip: true },
  shippingAddress: { street: true, zip: true, co: true },
  billingAddress: { street: true, zip: true, vat: true },
}

function validate(values) {
  function validateNode(schema, values = {}) {
    const errors = {}

    for (const [key, rule] of Object.entries(schema)) {
      const value = values[key]

      if (rule === true) {
        if (!value) errors[key] = 'required'
      } else {
        const nestedErrors = validateNode(rule, value)
        if (Object.keys(nestedErrors).length) {
          errors[key] = nestedErrors
        }
      }
    }

    return errors
  }

  return validateNode(schema, values)
}

This is technically sound. It handles missing keys, it scales, it's data-driven. All three AIs converged on this pattern independently — and honestly, it's not wrong. If address types were configured at runtime via metadata rather than hardcoded in the codebase, this approach would be the right one. When variability lives in data, a data-driven solution wins.

But here, the schema is just a mirror of the data shape, with true where values should be. It's a solution to a problem — missing keys — that the composition approach never has in the first place.

4. Function composition — knowing the right tool

function validate(values) {
  const errors = {}

  if (!values.productName) errors.productName = 'required'
  if (!values.quantity) errors.quantity = 'required'

  errors.homeAddress = validateAddress(values.homeAddress)
  errors.shippingAddress = validateShippingAddress(values.shippingAddress)
  errors.billingAddress = validateBillingAddress(values.billingAddress)

  return errors
}

function validateAddress(values = {}) {
  const errors = {}
  if (!values.street) errors.street = 'required'
  if (!values.zip) errors.zip = 'required'
  return errors
}

function validateShippingAddress(values = {}) {
  const errors = validateAddress(values)
  if (!values.co) errors.co = 'required'
  return errors
}

function validateBillingAddress(values = {}) {
  const errors = validateAddress(values)
  if (!values.vat) errors.vat = 'required'
  return errors
}

No schema. No recursion. No flags. Each address type is its own function, and the shared logic is composed in.

The missing-key problem doesn't exist here — validateBillingAddress always checks for vat, regardless of what arrives. But the reason isn't just simplicity: it's that validateBillingAddress exists because a billing address is a distinct business concept, not because it saves lines of code. The structure of the code reflects the structure of the domain.

When a new address type appears, you introduce a new validator rather than extending a growing set of conditional rules. Modification doesn't disappear — it becomes localized.

Why Is This the Hardest Solution to Find?

The flag, the recursion, and the schema all share the same instinct: find the common pattern and centralize the logic. It's what we're taught. It's what most production code looks like. It's a sound instinct — and sometimes the right one.

The composition approach asks a different question first: where does the variability actually live? If address types are stable domain concepts that belong in code, then composition wins — each type gets its own function, and differences are expressed rather than parameterized. If address types are dynamic, configurable, and driven by external data, then the schema wins.

The problem with the flag, the recursion, and the schema is not that they're wrong — it's that they all assume the answer to that question without asking it.

What's striking is that the cleverest human in the room and three AI models all converged on the same solution independently. In hindsight, this isn't surprising. Programming education spends years teaching us to eliminate duplication and generalize patterns. Large language models are trained on the output of that culture, so they inherit many of the same instincts. This isn't a story about what AI can't do — it's a reflection on what software engineering culture taught both AI and us to reach for by default.

AI can write the composition solution. It just rarely chooses to.

The simplest solution isn't the one that requires the least typing. It's the one that most honestly reflects what the domain is actually telling you.

Next time you find yourself reaching for a flag or a schema, ask: is this variability in my code, or in my data?

The answer changes everything.

Stop Blaming Re-renders. You're Optimizing the Wrong Thing.

Matteo Antony Mistretta — Tue, 09 Jun 2026 12:30:00 +0000

This post is part of a series about Inglorious Web. Start here if you haven't already, or go back one post to see why global state is pretty much always acceptable.

After the benchmarks post, I got a question that comes up every time I talk about Inglorious Web's rendering model:

"If the whole tree re-renders on every state change, wouldn't it be better if you memoized render functions the way React does with React.memo?"

It's a reasonable question. It's also solving the wrong problem.

What memoization actually costs

Memoization isn't free. A cache lookup happens on every call — whether or not the cached value is stale. In a busy UI, that's constant overhead, paid regardless of whether the memo ever saves you anything.

And it saves you less than you'd think, because lit-html already does its own caching at the template level. It tracks which parts of a template changed between renders and only patches those DOM nodes. Adding a JS-side memo layer on top means you're diffing twice: once in your cache, then again in lit-html. The second diff doesn't know what the first already handled.

So memoizing render functions in Inglorious Web would mean: always paying a cache lookup cost, sometimes saving a function call, while lit-html does its own DOM diffing regardless. The math doesn't work out.

What signals actually cost

The usual counter-proposal is: "fine, skip memoization, but use signals instead. Only update the parts of the tree that depend on what changed."

Signals are magic. Not in the fun sense — in the sense described in the first post of this series. Each reactive primitive maintains its own list of subscribers, built and updated at runtime, invisible to you as you write code. When a signal changes, it pushes to that list. Fine-grained reactivity works by having many small signals, each with its own observer registry, each encoding a piece of a dependency graph you didn't write and can't read.

That's memory. Multiple signals means multiple registries. And those registries encode a dependency graph that's implicit, assembled at runtime, and opaque by design. You can't grep for it, you can't draw it statically, and when it behaves unexpectedly — a component updates that shouldn't, or doesn't when it should — you're debugging something that doesn't exist as readable code anywhere.

In Inglorious Web, the only observer of state is the root render function. One observer, no registries, no hidden graph.

The actual benchmark

I've measured the worst case for full-tree rendering: a tree 8 levels deep, 3 children per node, one random node firing an event 3 times per second, over 10 seconds.

Compared to React, Vue, and Svelte — which all use different levels of fine-grained reactivity to update only the affected node — Inglorious Web walks the whole tree every time.

The result: ~100ms of extra scripting time over 10 seconds. 1% of wall-clock time, on a workload specifically designed to be as punishing as possible for full-tree rendering. All four frameworks hold 120 FPS throughout.

The profiler can measure it. No user would notice it. And it comes with a tradeoff in the other direction: Inglorious Web's JS heap runs substantially lower than Svelte's in this scenario. Full-tree rendering trades a small, bounded CPU cost for lower memory pressure and no observer registries to maintain.

The right distinction

Here's the thing that often gets missed: the concern about "wasting renders" is almost never really about render functions being called. It's about expensive work happening inside render functions.

Those are different problems with different solutions.

If your render function runs something expensive — a sort, a filter, a derived calculation — that work should be lifted out into compute(). Not because it makes the render faster to call, but because that computation doesn't belong in a render function in the first place. Render functions should describe structure. Structure is cheap.

compute() works exactly like Redux's createSelector: you pass it an array of input selectors, and a function that receives their results:

import { compute } from "@inglorious/web";

const items = (state) => state.taskList.items;
const filter = (state) => state.taskList.filter;

const visibleItems = compute(
  (items, filter) => items.filter((item) => item.status === filter),
  [items, filter]
);

visibleItems is now a memoized selector. It only reruns when items or filter actually change. Everything else — every render caused by unrelated state changes — skips the computation entirely and returns the cached result.

You use it in render like any other selector:

const TaskList = {
  render(entity, api) {
    const items = api.select(visibleItems);
    return html`
      <ul>
        ${items.map((item) => html`<li>${item.text}</li>`)}
      </ul>
    `;
  },
};

compute() memoizes the calculation, not the render. The render function stays a pure, cheap description of structure. lit-html handles the DOM delta. Everyone does their job.

Memoizing the render function itself would be treating the symptom — "this function is called too often" — rather than the cause — "this function is doing too much." And it would do so at the cost of a cache layer that's always present, always paying its overhead, for a benefit that only materializes in specific circumstances lit-html already handles at a lower level.

The caching tradeoff, plainly stated

Signals waste memory to save CPU time. Full-tree rendering wastes a little CPU time to save memory. Both are fine choices. Neither is the absence of a tradeoff.

The difference is that full-tree rendering is explicit and measurable. You can run the benchmark. You can read the profiler output. You know exactly what you're trading and why.

A hidden dependency graph built at runtime by a reactive system is harder to audit. It's magic in exactly the sense this series has been pushing against: invisible machinery doing things on your behalf, breaking in ways you didn't anticipate, in places you didn't author.

I'll take the 100ms.

Docs · Repo

You Just Need Entities That Can Die

Matteo Antony Mistretta — Tue, 07 Apr 2026 13:18:44 +0000

This post is part of a series about Inglorious Web. It stands alone, but the examples make more sense if you've read the architecture post first, and maybe the post about why it's better to stick with global state.

Forms are one of those relevant cases where the Single Source of Truth principle goes to die.

Not because the principle is wrong — it isn't. But because forms are volatile. They change on every keystroke. They're submitted and discarded. They have validation state, touched state, dirty state, error state — a whole parallel universe of UI concerns that has nothing to do with your application's domain state. Putting all of that in a Redux store felt principled at the time and turned out to be a mistake.

Redux-form was that mistake, made by Erik Rasmussen — enthusiastically, alongside the rest of us who were in love with Redux at the time. The redux-form homepage now reads: "Do not begin a project with Redux Form." Rasmussen learned the same lesson the rest of us did, and built React Final Form instead. The lesson it taught the ecosystem shaped every form library that followed.

The real axis here isn't global vs local. It's alive vs dead. Form state can be global — accessible, debuggable, consistent with the rest of your application state. But it should only exist for as long as the form exists. The problem with redux-form wasn't putting form state in the store. It was never taking it out.

In Redux-form, you reset forms. In Formik, you isolate them. In Inglorious Web, you destroy them.

Redux-Form: When the Principle Became the Problem

The idea was coherent: if all state is global and managed by Redux, form state should be too. Redux-form put your form's field values, validation errors, touched fields, and submission state all into the Redux store.

The problems were practical. Form state that entered the store on mount stayed there after submission — bloating the state tree with stale data from forms the user had already completed. Worse, if you submitted a form and opened it again, you'd retrieve the previous submission's values by default unless you explicitly reset. The store was supposed to be the single source of truth, but the truth it was telling was wrong.

And then there was performance. Every keystroke in a form field dispatched an action to the Redux store. Every action triggered a re-render of every connected component. For a long form with many fields, typing felt sluggish.

Formik and React Final Form: Escaping the Store

The ecosystem's answer was to accept that form state doesn't belong in Redux. Formik managed form state locally in a React component using useRef and useState internally, keeping Redux out of it entirely. Clean, practical, and widely adopted.

React Final Form — also by Erik Rasmussen, who had learned from redux-form — took a similar approach but with a more sophisticated subscription model. Instead of re-rendering the entire form on every change, it let individual fields subscribe to only the state they needed. The clever part was FormSpy: a component that could subscribe to specific slices of form state and re-render independently, minimizing the rendering surface area.

<FormSpy subscription={{ values: true }}>
  {({ values }) => (
    <pre>{JSON.stringify(values, null, 2)}</pre>
  )}
</FormSpy>

FormSpy is genuinely clever engineering. It exists because React's rendering model means that any state change in a parent re-renders all children — so you need an explicit mechanism to opt out of those re-renders for performance. The solution is a subscription system layered on top of React's component model.

Both libraries solved the redux-form problems correctly. But notice what they're solving: performance issues and stale state problems that arise from a specific architectural context — React's component-centric rendering model and the mismatch between volatile form state and persistent application state.

Inglorious Web: Forms as Entities

In Inglorious Web, a form is an entity. You compose the built-in Form primitive with your own type, add a submit handler, and declare the entity in the store with its initial values:

import { Form } from '@inglorious/web/form'
import { html } from '@inglorious/web'

const ContactForm = {
  ...Form,

  create(entity) {
    entity.values = { name: '', email: '' }
  },

  submit(entity, _, api) {
    api.notify('contactFormSubmit', entity.values)
    api.notify('remove', entity.id) // optional — destroy the entity on submit
  },

  render(entity, api) {
    return html`
      <form @submit=${() => api.notify(`#${entity.id}:submit`)}>
        <input
          .value=${entity.values.name}
          @input=${(e) => api.notify(`#${entity.id}:fieldChange`, {
            path: 'name',
            value: e.target.value,
          })}
        />
        <input
          .value=${entity.values.email}
          @input=${(e) => api.notify(`#${entity.id}:fieldChange`, {
            path: 'email',
            value: e.target.value,
          })}
        />
        <button type="submit">Send</button>
      </form>
    `
  },
}

const store = createStore({
  types: { ContactForm },
  autoCreateEntities: true
})

The form's field values, validation state, and touched state all live in the store as part of the entity. When the user submits, you handle it in the submit handler. And if you want the form to disappear after submission — for a modal form, a one-time wizard step, a transient data entry panel — you notify remove:

api.notify('remove', entity.id)

That's it. The entity is destroyed, its state is removed from the store, and because render is bound to the entity, the form disappears from the UI automatically. No stale data. No manual cleanup. No reset call.

There's a less obvious benefit worth naming: forms become first-class, inspectable runtime objects. While the form is alive, its full state — field values, validation errors, touched fields — is visible in Redux DevTools, time-travelable, and accessible to any other entity via api.getEntity(). A confirmation dialog that needs to know whether the form is dirty before letting the user navigate away can just read the entity. No callbacks, no context, no prop drilling.

For persistent forms — a settings page, a profile editor — you simply don't call remove. The entity stays in the store, and its state reflects whatever the user last entered.

Of course, this pushes more responsibility onto lifecycle design — you have to decide when something should die. That's a real cost. But it's an explicit, visible cost, not a hidden one.

Multi-step forms are up to the developer. If each step has its own distinct lifecycle — you want to destroy step 1 before moving to step 2, or allow independent abandonment — you model them as separate entities. If the steps share a flat state (name on step 1, address on step 2), a single entity works just as well: the render method shows the relevant fields based on a currentStep property, and the entity is destroyed only when the whole flow completes. Either way, the store stays flat and normalized.

The FormSpy Problem Is Less Acute

React Final Form's FormSpy is the solution to a rendering problem: in React, form state changes trigger re-renders up the component tree, so you need a subscription mechanism to contain them.

In Inglorious Web, full-tree re-rendering with lit-html's surgical DOM updates changes the cost significantly. When a field value changes, lit-html walks the template and touches only the DOM nodes that actually changed — the input's value attribute — skipping everything else. There's no virtual DOM reconciliation, no subscription system to configure, no FormSpy equivalent to learn.

This doesn't mean re-renders are free — it means the cost is low enough that it stops being a design constraint for the vast majority of forms. React can also optimize with memoization and signals, and those tools are worth using when you need them. The difference is that in Inglorious Web you don't need them by default. The benchmarks post has the full picture.

The Pattern Again

Redux-form was right about the principle and wrong about the lifecycle. Formik and React Final Form solved the symptom by relocating form state rather than rethinking its lifetime. The tension was never resolved — only hidden.

Inglorious Web makes lifetime explicit. Entities are created when needed and destroyed when done. The single source of truth principle turns out to be fine for forms.

You just need entities that can die.

What Comes Next

There's not much more to say. One main concern I received so far is: isn't full tree re-rendering too expensive to be taken seriously? Wouldn't it be better if I memoized the render functions at least? Short answer: no.

Docs · Repo

There's No Such Thing As Local State

Matteo Antony Mistretta — Tue, 31 Mar 2026 12:30:13 +0000

This post is part of a series of corollaries to the Inglorious Web series. It stands alone, but the examples make more sense if you've read the architecture post first. Or you can just go back to a time when we were just having fun creating videogames.

There's a decision every frontend developer makes early in a project, usually without realizing it's a decision: where does state live?

It feels like a technical question. It's actually an architectural one. Most frameworks default to local state and make global state expensive. Inglorious Web flips the default: state is global unless you intentionally isolate it.

The difference looks like this:

Every mainstream approach has a point where the model strains. The strain always comes from the same place — state that was supposed to stay contained, didn't. Here are three projects, three frameworks, and three different versions of why that matters.

Fattutto: Context API Hits Its Limits

In 2018 I was hired as lead front-end architect on Fattutto, an invoicing application. We were a small team — two front-enders, two back-enders — working intensively for two months. Redux existed but RTK didn't, and plain Redux felt too verbose for what we thought would be a modest amount of global state. Context API was a reasonable choice.

And it was fine — for a while. The problem with Context API isn't that it's wrong for global state. The problem is performance: every consumer re-renders whenever that context's value changes, unless you split your contexts as finely as possible. As features accumulated, each new concern that needed to be shared got its own provider. By the time the app was mature, the root looked like this:

<ThemeContext.Provider value={...}>
  <UserContext.Provider value={...}>
    <LicenceContext.Provider value={...}>
      <IdsToRemoveContext.Provider value={...}>
        <SelectionContext.Provider value={...}>
          <PageViewsContext.Provider value={...}>
            <PreferencesContext.Provider value={...}>
              <SidebarsContext.Provider value={...}>
                <Enhanced {...props} />
              </SidebarsContext.Provider>
            </PreferencesContext.Provider>
          </PageViewsContext.Provider>
        </SelectionContext.Provider>
      </IdsToRemoveContext.Provider>
    </LicenceContext.Provider>
  </UserContext.Provider>
</ThemeContext.Provider>

Eight nested providers. The team that took over after me eventually reduced that number — proving Context is malleable enough to refactor, and that it wasn't a bad choice in the first place. But the growth happened, and reversing it required deliberate effort. That's the limit of the model.

Tetra Pak: The Right Tool, Right from the Start

In 2020 I was hired as lead front-end architect at Tetra Pak for an industrial HMI — a four-year project building the interface for factory control systems. I'd internalized the Fattutto lesson: even if the initial state seemed small, I went full RTK from day zero. That looked like overkill at first. By the end of the project, the store had grown to this:

export default configureStore({
  reducer: {
    auth, config, dashboard, drawer, changePwdModal, deleteModal,
    alarms, alarmsHistory, kits, lineStatus, maneuverItems, recipes,
    // ... 30+ slices in total
  },
})

Not overkill. The architecture was right, and I'm proud of it. The problem was ergonomic: creating a new RTK slice required enough ceremony that junior developers consistently reached for useState instead. In React with RTK, that's sometimes the correct call — creating a slice for a dropdown's open/closed state is genuine overhead, and useState is the right tool for truly isolated UI state. The problem is that "truly isolated" is a bet, and the bet doesn't always pay off.

The concrete example: a list of maneuver items, each rendered as an accordion. The user clicks a header to expand it, edits settings in the form inside, and clicks save. Saving should trigger multiple effects across different parts of the app: the accordion collapses, a recipe bar appears asking "do you want to save this change to the recipe too?", and potentially other reactions elsewhere.

With local state, the first instinct looks like this:

function ManeuverItem({ item }) {
  const [isOpen, setIsOpen] = useState(false)

  return (
    <div>
      <button onClick={() => setIsOpen(!isOpen)}>{item.name}</button>
      {isOpen && (
        <ManeuverForm
          item={item}
          onSubmit={(saved) => {
            saveItem(saved)
            setIsOpen(false)
            // but how do we tell the recipe bar to appear?
            // and collapse all other items?
            // and trigger anything else that cares?
          }}
        />
      )}
    </div>
  )
}

The comment is the problem. onSubmit doesn't know about the recipe bar. It can't reach the other accordion items. Every effect that needs to happen requires either prop drilling, a callback passed from above, or a new RTK slice. The state that felt local at definition time turned out to be needed in five other places.

A state manager that's too painful to use correctly is almost as bad as no state manager at all.

Heineken: Multiple Sources of Truth

More recently I was brought in on an Angular project for Heineken. This isn't an Angular problem specifically — almost every framework implicitly accepts multiple sources of truth as a normal condition. Forms manage their own state. Routing state lives in the URL. Filters live in a service. Default configuration lives somewhere else. The ecosystem treats this as pragmatic.

Until it isn't. In one case, navigating to a URL was supposed to apply a default workcenter to the query string. Other parameters were added on top. But something kept removing the workcenter — a race between the URL history, the filter state, the default configuration, each one writing to the query string independently, each one unaware of the others. Days of debugging, because there was no single place to ask "what is the current routing state?"

This isn't unusual. It's the norm. And it's worth naming, because it means the single source of truth principle isn't just a Redux dogma — it's the thing that makes routing state debuggable.

Three different stacks, three different teams, the same failure mode: state escaping the place it was supposed to live.

Inglorious Web: Global by Default, Free of Charge

All three stories share a root cause: state that someone decided was local, wasn't. The fix in each case required effort — refactoring contexts, adding slices, untangling sources of truth — because the architecture didn't make global state cheap enough to reach for from the start.

Before addressing the obvious objection ("you don't need a global store, you need signals"), let me show what the Inglorious Web version looks like. Then I'll come back to it.

Here's the maneuver accordion:

const ManeuverItem = {
  create(entity) {
    entity.isOpen = false
  },

  toggle(entity, _, api) {
    if (!entity.isOpen) {
      api.notify('maneuverItem:collapse') // enqueued first — collapses all
      api.notify(`#${entity.id}:open`)    // enqueued second — opens this one
    } else {
      entity.isOpen = false
    }
  },

  open(entity) {
    entity.isOpen = true
  },

  collapse(entity) {
    entity.isOpen = false
  },

  save(entity, payload, api) {
    saveItem(payload)
    entity.isOpen = false
    api.notify('maneuverItemSave', payload) // broadcast — anyone who cares reacts
  },

  render(entity, api) {
    return html`
      <div class="maneuver-item">
        <button @click=${() => api.notify(`#${entity.id}:toggle`)}>
          ${entity.name}
        </button>
        ${entity.isOpen ? html`
          <maneuver-form
            .item=${entity}
            @submit=${(e) => api.notify(`#${entity.id}:save`, e.detail)}
          ></maneuver-form>
        ` : ''}
      </div>
    `
  },
}

The event queue is what makes toggle work correctly. api.notify() enqueues events rather than firing them immediately — so maneuverItem:collapse hits all entities first, then #maneuver1:open fires, leaving exactly one item open. The order is deterministic and explicit.

And elsewhere in the app, the recipe bar simply listens:

const RecipeBar = {
  maneuverItemSave(entity, payload) {
    entity.pendingChange = payload
    entity.isVisible = true
  },
}

No callbacks. No prop drilling. No knowledge of the component tree. maneuverItemSave is a broadcast — every entity with that handler reacts independently. Adding a new reaction means adding a handler to a new type, nothing else.

This looks like classes with methods. It isn't. The type object holds no state — create() fires when the entity is added to the store and initializes its state there. toggle(), open(), collapse(), save() are reducers. Everything lives in the store, accessible to any other entity, debuggable, and testable by calling a function.

Multiple instances are declared explicitly or created at runtime:

// Static
const entities = {
  maneuver1: { type: 'ManeuverItem', name: 'Approach' },
  maneuver2: { type: 'ManeuverItem', name: 'Lift' },
  maneuver3: { type: 'ManeuverItem', name: 'Deposit' },
}

// Or dynamically as data arrives
maneuverItems.forEach((mi) =>
  store.notify('add', { id: mi.id, type: 'ManeuverItem', name: mi.name })
)

Each instance gets its own independent state in the store. Adding a new maneuver item type means writing another type object — same shape, same cost, no additional infrastructure.

The router follows the same principle — web history and store state kept in sync as a single entity, with every navigation visible as an event in Redux DevTools:

const { route, path, params } = api.getEntity('router')

api.notify('#router:navigate', '/workcenter/42?filter=active')

The Heineken race condition — multiple services writing to the query string independently — would have been visible immediately. One entity, one source of truth, every change traceable.

When state changes, Inglorious Web re-renders the whole tree and lets lit-html handle the DOM diff surgically. No useEffect firing unexpectedly, no stale closures. The form saves, the event broadcasts, the store updates, the tree re-renders, the accordion closes, the recipe bar appears. Every step is explicit and traceable. The benchmarks post has the full numbers — the short version is 120 FPS on dashboards without any optimization work.

"But You Don't Need a Store — You Need Signals"

The objection is fair, and it's worth addressing directly: signals solve re-render granularity without a store. A signal for isOpen on each accordion item would work. Fine-grained reactivity would update only the affected DOM node.

The problem isn't the re-renders — as the benchmarks show, full-tree rendering with lit-html is fast enough that the difference is imperceptible in practice. The problem is the dependency graph. Signals are implicit: the runtime tracks which signals were read during rendering, and re-runs when they change. That graph is invisible, lives in the framework's memory, and doesn't show up in your DevTools. When something updates unexpectedly — or fails to update — you're debugging a system you can't inspect.

The event model is explicit: every state transition is a named event you can grep, every handler is a function you can call in a test, every change is visible in Redux DevTools. That's the tradeoff. For the full argument, it's in the first post of the series.

The Decision You're Actually Making

When you reach for useState, you're making a bet: that this state will never need to be shared. In React, that bet sometimes pays off — a dropdown that genuinely never coordinates with anything else is a fine use of local state, and creating a Redux slice for it is real overhead. The friction isn't imaginary.

But the asymmetry is brutal in one direction: keeping state local when it should be global is cheap to write and expensive to undo. The Fattutto pyramid, the Tetra Pak accordion, the Heineken routing race — all of them started as decisions that felt small.

In Inglorious Web the asymmetry disappears. Global state looks like local state — a create() handler reads almost like a useState initializer, a type object reads almost like a component. The difference is that everything ends up in the store, accessible to everything else, at no extra cost. You're not choosing between local convenience and global power. You just write the type, and the store takes care of the rest.

The decision still exists. But now the safe choice is also the easy one.

What Comes Next

If the state is better global, then what about edge cases like forms? Turns out, you don't need local state for those. You just need entities that can die.

Docs · Repo

Suspense Is A Symptom

Matteo Antony Mistretta — Tue, 24 Mar 2026 13:32:00 +0000

This post is part of a series on Inglorious Web. You can start from the beginning, go back one post to see another problem that simply vanishes when you reframe the context, or read it standalone — the argument here is self-contained.

Inglorious Web didn't start as a React alternative. It started as a game engine.

I wanted to build a cool JavaScript game engine — something that could handle hundreds of entities updating at 60 frames per second, with clean state management, deterministic event handling, and no magic. The state manager that emerged from that work was general enough that I started using it for web apps too. And once it was powering web UIs, the React rendering layer started feeling like the wrong tool: too heavy, too coupled, too opinionated about who owns state. I replaced it with lit-html and followed the logic all the way through.

Game engines have been solving high-frequency state updates with heterogeneous objects for decades — under far stricter performance constraints than any web UI. They never needed a component hierarchy. They never needed to fire REST requests from inside a render function. And they never needed <Suspense>.

That last point is the one I want to pull on.

What Suspense Actually Does

<Suspense> was introduced by React and has since been adopted by SolidJS, and more recently Vue. The premise is elegant: wrap a part of your component tree in a boundary, declare a fallback, and the framework shows the fallback until all async resources inside the boundary have resolved. No cascading spinners, no layout shifts, no manual coordination of loading states across components.

Here's the SolidJS version, straight from their docs:

const MyComponent = () => {
  const [profile] = createResource(async () => { /* fetch */ })

  return (
    <Suspense fallback={<div>Loading...</div>}>
      <div>{profile()?.name}</div>
      <div>{profile()?.email}</div>
    </Suspense>
  )
}

The key detail: createResource reads data inside the component, inside the render function. The component itself initiates the fetch. Suspense catches the pending state at the nearest boundary and holds back the DOM until the resource resolves — pre-rendering nodes speculatively so there's less work to do when data arrives.

It's genuinely clever engineering. But notice what it's engineering around.

The Problem Suspense Solves — And Where It Comes From

The coordination problem Suspense solves exists because of a specific architectural choice: data fetching is coupled to rendering. The component declares what it needs, initiates the fetch, and renders based on the result — all in one place. When multiple components do this independently, you get cascading loading states that need a boundary mechanism to coordinate.

Game engines don't have this problem. Not because they don't fetch data asynchronously — they do it constantly. Loading screens stream level geometry. Multiplayer games make network calls every frame. Asset pipelines fetch textures and audio in the background. But the loading state is just state. A loading screen is an entity. The transition from loading to loaded is an event. The render function reads whatever state the entity currently holds.

Game engines solve this differently. Loading screens, asset streaming systems, scene readiness checks — these all exist, and they handle async coordination constantly. But they do it by reading state that reflects loading progress, not by letting the rendering layer initiate the loading itself. The render function reads whatever the entity currently holds. The loading logic lives elsewhere.

This is the same architectural instinct that Inglorious Web carries into web UI development.

How Inglorious Web Handles It

In Inglorious Web, fetching data and rendering data are two separate concerns handled by two separate mechanisms. handleAsync manages the fetch lifecycle:

import { handleAsync } from '@inglorious/store'

const Profile = {
  ...handleAsync('fetchProfile', {
    start(entity) { entity.status = 'loading' },
    async run(id) {
      const res = await fetch(`/api/profiles/${id}`)
      return res.json()
    },
    success(entity, data) {
      entity.data = data
      entity.status = 'success'
    },
    error(entity, err) {
      entity.status = 'error'
      entity.error = err.message
    },
  }),
}

The render function reads state:

render(entity) {
  if (entity.status === 'loading') return html`<div>Loading...</div>`
  if (entity.status === 'error') return html`<div>Error: ${entity.error}</div>`
  return html`<div>${entity.data.name}</div>`
}

There is no <Suspense> boundary. There is no resource being read inside the render function. The fetch is triggered by an event — store.notify('profile:fetchProfile', userId) — and the result lands in the store. The render function is a pure function of whatever state the entity currently holds. It doesn't know or care how that state got there.

This isn't a workaround for the absence of Suspense. It's a different model where the coordination problem doesn't arise.

Suspense Is a Symptom

The spread of Suspense across frameworks — React, then SolidJS, now Vue — tells you something. Frameworks that allow async resources to be read inside the reactive graph tend to require Suspense-like coordination to manage the consequences. Not all signal-based frameworks go this route — Svelte notably doesn't — but the pattern is clear enough: when data fetching becomes part of the reactive rendering graph, a boundary mechanism follows.

This is the pattern that recurs across the whole series. TanStack Query exists because component-local state creates a data fragmentation problem. Suspense exists because reactive rendering creates a loading coordination problem. Each tool is a genuine solution to a real problem — but the problem is architectural, not universal. Change the architecture, and the problem disappears.

Game engines figured this out not by being clever, but by being constrained. When you're updating thousands of entities at 60 frames per second, you can't afford to let the rendering layer own business logic. State is state. Rendering is rendering. The separation isn't a best practice — it's a survival requirement.

Web UIs operate under far looser constraints, which is probably why the coupling was allowed to creep in. Components that fetch their own data are convenient. Reactive resources that update automatically are ergonomic. Suspense boundaries that coordinate loading states are elegant. Each step feels like an improvement. But the complexity accumulates, and each layer of machinery exists to manage the consequences of the previous one.

Inglorious Web went the other way — not because I planned it, but because the game engine origin forced the separation from the start. The state manager didn't know anything about rendering. The renderer didn't know anything about data fetching. When I applied that architecture to web UIs, there was nothing left for Suspense to do.

When You Might Still Want Suspense

Being honest here matters. If you're using a framework where data fetching is coupled to rendering — which describes most of the mainstream options — Suspense is the right tool. It's a well-designed solution to a real problem in that context.

And there's one scenario where even an entity-based architecture needs something like Suspense: lazy-loaded entity types. If your app loads type definitions on demand — for route-based code splitting, plugin systems, or large config-driven UIs — you need a way to signal "this type isn't ready yet, show a fallback."

Inglorious Web's router already handles this. Here's what the app-level render function looks like when supporting lazy-loaded routes:

export const App = {
  render(entity, api) {
    const router = api.getEntity("router")

    return html`
      <main>
        ${when(router.error, () =>
          html`<div>Route not found: ${router.path}</div>`
        )}
        ${when(router.isLoading, () => html`<div>Loading...</div>`)}
        ${when(!router.error && !router.isLoading, () =>
          api.render(router.route)
        )}
      </main>
    `
  },
}

And the lazy type itself is just a plain type definition loaded on demand:

// lazy-type.js
export const LazyType = {
  render() {
    return html`
      <h1>Lazy Loaded Route</h1>
      <p>Check your network panel: this route was loaded on demand!</p>
    `
  },
}

Notice what's happening: router.isLoading is just state on an entity. The fallback is just a conditional in the render function. The lazy type loads when the route is navigated to, and the transition from loading to loaded is an event. There's no boundary mechanism catching a thrown promise — the app-level render function is the boundary, and it's explicit rather than implicit.

This is a legitimate use case for Suspense-like coordination, and Inglorious Web handles it natively through the same mechanisms it uses for everything else. The difference is that you can see exactly what triggers the loading state, exactly what the fallback is, and exactly when the transition happens. Nothing is implicit.

The Pattern

Every post in this series has landed on the same observation from a different angle: the tools we reach for most often exist to manage consequences of architectural choices, not to solve fundamental problems. Remove the choice, and the tool becomes unnecessary.

REST didn't build a better session cache — it eliminated the need for one. The entity store doesn't build a better query cache — it makes the fragmentation that requires one impossible. And Inglorious Web doesn't need a better Suspense — because when data fetching lives in the store and rendering is a pure function of state, there's nothing to suspend.

The game engine didn't solve this problem. It never had it — because the constraint of rendering thousands of entities at 60 frames per second made the coupling between fetching and rendering unthinkable from the start. The separation wasn't a design principle. It was a survival requirement.

Web UIs operate under far looser constraints, which is probably why the coupling was allowed to develop. But looser constraints don't mean the coupling is free. It just means the cost shows up later, in the form of tools like Suspense that exist to manage consequences rather than prevent them.

What Comes Next

If you're curious about how Inglorious Web was born, you can check its origin story here. Otherwise I can tell you why giving state and behavior to components is usually a bad idea.

Docs · Repo

How a Game Engine Accidentally Became a Web Framework

Matteo Antony Mistretta — Tue, 17 Mar 2026 13:30:03 +0000

This post is the origin story behind Inglorious Web. You can read it standalone, or as a prologue to the series that followed. Or just go back to the previous post in the series, who am I to judge.

This is not a post about a framework. It's a post about why I needed to build one — and why it took three years, a conference that almost nobody was supposed to attend, and the worst year of my life to get there.

Summer 2022: The Idea

I love Redux. Not in the abstract — I mean the specific intellectual pleasure of the three principles: single source of truth, immutable state, pure functions. The kind of architecture where you can look at any state transition and reason about it completely. Where testing is just calling a function.

I'd been using it professionally for years, and at some point I started wondering: what if you applied those same principles to a game engine? Games have to manage hundreds of entities updating every frame. They have to be deterministic, debuggable, and fast. Redux had proved those properties in web apps — could they survive the pressure of a game loop?

On July 30, 2022, I started finding out. The core idea was simple: model the game loop as a pure function.

const gameLoop = (state, action) => {
  const nextState = reducer(state, action);
  render(nextState);
  return nextState;
};

This was my first attempt. It didn't last long. Redux itself turned out to be the wrong fit — slices and reducers weren't designed for entities that need independent state and behavior. So I threw it out and designed my own store: an entity-based model where each entity has a type, and each type defines its behavior as event handlers.

const types = {
  Player: {
    move(entity, direction) {
      add(entity.position, direction);
    },
  },
};

const entities = {
  player1: { type: 'Player', position: [0, 0] },
};

That felt right. By August 2022, the entity store worked. At the time I thought I was building a game engine. In hindsight, I was building a state architecture that accidentally had to do with games. And then — like most side projects — life got in the way, and I set it down.

2023: Game AI and the Canvas

A year later, a book on game AI algorithms reignited the project. I wanted to implement pathfinding, behavior trees, and decision systems in a functional style rather than the object-oriented approach most game development books assume. The entity architecture made it elegant — an enemy entity checking distance to a player entity, notifying an event, the store processing it in order. Deterministic, testable, no magic.

I added a 2D canvas rendering layer. React had been powering the visuals, but there's only so much the DOM can do at 60 frames per second. More importantly, I wanted the engine to be render-agnostic — the store shouldn't care whether it's rendering to a canvas, a DOM, or nothing at all.

By late 2023, the engine had a working canvas renderer, an AI system, and a clean separation between state, behavior, and rendering. Then I hit collision detection, and the motivation drained again. Collision detection is one of those problems that starts simple (two rectangles, check the overlap) and reveals an abyss the moment you look closely. I'd also just gotten married. The engine went back in the drawer.

2025: Coding Is Coping

Right after my wedding, things went south quickly. My mother was diagnosed with cancer. She died in March 2025.

In the same period, LLMs arrived and started threatening the thing I'd built my professional identity around. The combination — personal grief, professional anxiety, the general sense that the ground was shifting — produced a burnout I didn't fully recognize until I was already deep in it.

What pulled me out, eventually, was coding. Not productively at first. Just tinkering, reading old code, seeing if things still made sense. LLMs helped in a way I didn't expect: not by writing the code for me, but by giving me a thinking partner when I needed to reason through a design decision at 11pm with nobody else around. The engine, sitting untouched for months, started to feel interesting again.

I know this sounds like I'm romanticizing it. But there's something specific about working on a system that behaves exactly the way you tell it to — that has no opinion about your grief, no awareness of your anxiety, that just processes events in order and gives you back a new state. It was the right kind of boring.

July 2025: The Conference

My friend Savino Carlone organizes a small conference in Turin for .NET developers — Torino .NET. He needed a speaker for a mid-August online slot and asked if I could fill it. I said I had nothing to talk about. He said: "Don't worry, nobody's going to listen anyway. Everyone's on vacation."

That was enough. I said yes, pulled up the engine code, and started re-reading it to prepare slides.

What happened next surprised me. Re-reading code you wrote in a different state of mind is a strange experience. Some of it was embarrassing. Some of it was better than I remembered. And somewhere in the process of preparing examples and building a demo — a particle system, a few simple game prototypes — I realized that I'd built something genuinely interesting without fully noticing.

The attendance was better than expected. I opened with a hook for the .NET crowd: certain problems can be solved through the decorator pattern in object-oriented programming — and then I showed how, in functional programming, the decorator pattern becomes function composition. That part landed. When I moved deeper into the FP principles behind the engine, I lost most of them technically, but something still came through. They appreciated it. I left with my passion back, which was the only thing that mattered.

The Coding Spree

After the conference, I couldn't stop. And here I want to say something about LLMs that I don't see said often enough.

Nobody else cared about this project. Not in the way that matters when you're deep in a design decision at 11pm and need to think out loud. LLMs gave me something I hadn't had in a long time: a partner with encyclopedic knowledge who was genuinely willing to engage — not just say "well done," but push back, suggest alternatives, catch mistakes, and sustain a real technical conversation for as long as I needed. They also gave me the ability to move fast on the parts of the codebase I found tedious, so I could spend my energy on the parts I found interesting.

Yes, LLMs had threatened my sense of professional relevance. They also saved the project. Both things are true.

I added a scaffolding tool, sound support, touch support, an entity pool for performance-critical scenarios. I even created a JavaScript superset — IngloriousScript — that adds native vector operations to the language, because I kept writing add(position, scale(velocity, dt)) when I wanted to write position + velocity * dt.

And then, sometime in October 2025, I noticed something.

The state manager at the heart of the engine — the entity store I'd built in 2022 — was completely decoupled from the game loop and the rendering layer. It just managed state. It processed events. It was predictable and testable and deterministic.

It could power a web app.

Not Only Games

I'd spent years building React architectures for complex, data-heavy applications — config-driven dashboards at Irion, industrial HMI interfaces as lead front-end architect at Tetra Pak. I was proud of that work. But I could also see exactly where it would age. The complexity of RTK made junior developers reach for useState() when they shouldn't. Cascading renders made behavior unpredictable at times. Business logic drifted into components because that's where the framework pulled it. The kind of system that works until it doesn't, and then debugging it requires holding the entire tree in your head.

The entity store solved those problems structurally — not by being clever, but by keeping concerns separate from the start: state in the store, behavior in types, rendering as a pure function of state. A couple of years after my collaboration with Tetra Pak ended, I went back to propose migrating to Inglorious Store and Inglorious Web. The reception was warm. The migration never started. So the experiments my team and I are doing remain in-house for now — which is fine. The framework exists either way.

Then I kept pulling the thread. If all the logic lives in the store, what is React actually doing? Providing lifecycle hooks? Not needed — there are no component-level lifecycles in an entity model. Diffing the virtual DOM? Overkill when the render function is already pure and lit-html can handle surgical DOM updates at 3.24kB total.

By November 2025, React was gone. Inglorious Web was born.

What It Became

The framework now ships with a router, form handling, table, select, virtualized list, declarative SVG charts, an animation library, a design system, and SSG with HMR and file-based routing. It's Redux DevTools compatible, works with any web component, and renders to the real DOM — no virtual DOM, no compiler, no proxy-based reactivity.

The bundle is 16KB. The mental model is a one-time cost. Testing is just calling functions.

I wrote a series of posts about the architecture and the benchmarks — why I made the choices I made, where the framework fits, and where it honestly doesn't. If you want the technical argument, start there.

This post is just about how it got here: a Redux idea applied to games, a drawer it sat in for too long, a grief that made coding feel necessary, a conference in Turin that reignited everything, and a thread I kept pulling until something new came out the other end.

In May 2026 I'll be speaking about all of this at JsTek in Chicago — hoping it finds a slightly larger audience than a mid-August .NET meetup. If you're going to be there, come say hello.

EDIT (June 2026): The conference is over, and boy, what an experience. I was flown out to the US with travel and accommodation paid to give two speeches... only for fewer people to show up than at that mid-August online meetup! To top it off, someone literally stole my audience by staging an improvised talk in the room next door and inviting everyone to join. I don’t think I’ve ever felt quite so betrayed and humiliated in my professional life.

But the universe has a strange sense of irony. Right after returning to Italy, I attended a local .NET meetup where the scheduled speaker's train was delayed by 200 minutes. I offered to step in and give an impromptu talk to fill the gap. It was a massive success. They were incredibly grateful for saving the evening, the energy was electric, and I finally got the engaged audience I was looking for. Turns out, this framework just thrives when things get weird.

What Comes Next

Videogames taught me one thing, that is common to dashboards and pretty much any complex piece of software: there's no such thing as local state. Come find out why.

Docs · Repo

You Might Not Need TanStack Query

Matteo Antony Mistretta — Tue, 10 Mar 2026 13:30:03 +0000

When I teach web development, I always spend time on one of the most elegant moves in the history of software architecture: the shift from Web 1.0 application servers to REST.

Early application servers needed to share session state across machines — a genuinely hard distributed systems problem. People built clever solutions: sticky sessions, shared databases, distributed caches. Then REST came along and didn't solve the problem at all. It eliminated it. By making each request self-contained, stateless by design, the need for shared session state simply vanished. The solution was a reframing.

I think about that move a lot when I look at how modern frontend frameworks handle server state — because I think the same thing is happening again, and most people are still on the "build a better session cache" side of it.

TanStack Query is excellent. If you're using React with component-local state or context, you should probably use it. But understanding why it exists reveals something interesting: the problems it solves are architectural, not universal.

If your app is built around a centralized, entity-based store, you may already have everything TanStack Query gives you. And the only missing piece might be a single helper function.

What TanStack Query Actually Solves

Before dismissing any tool, it's worth being precise about the problem it's solving.

In a typical React app, server state lives in components. Two components that need the same data will independently useEffect their way to it, each triggering its own fetch. There's no shared cache, no way to say "this data is already in flight — don't fetch it again." The result is duplicate requests, inconsistent UI states, and a lot of hand-rolled loading/error handling boilerplate.

TanStack Query solves this with a query cache: a centralized store keyed by query keys, where identical keys share a single fetch lifecycle. It adds background refetching, stale-time configuration, request deduplication, and a clean { data, isLoading, error } API on top.

It's solving, essentially, the absence of a single source of truth for server state.

The Entity Store Already Has One

In Inglorious Store, state lives in a store as entities. An entity is just a plain object with an id and a type. Its behavior — how it responds to events — is defined by its type.

When you need to fetch some data, you model it as an entity:

const entities = {
  posts: {
    type: 'Posts',
    status: 'idle', // 'loading' | 'success' | 'error'
    items: [],
    error: null,
  },
}

This entity lives in the store. It's not local to a component. Every component that needs posts reads the same posts entity.

That's deduplication. Not as a feature you opted into — as a consequence of the architecture.

The `handleAsync` Helper Is All You Need

The remaining question is how to manage the fetch lifecycle: fire the request, set loading state, handle success, handle error. Without a helper, that's repetitive. With one, it collapses to this:

import { handleAsync } from '@inglorious/store'

const Posts = {
  ...handleAsync('fetchPosts', {
    start(entity) {
      entity.status = 'loading'
    },
    async run() {
      const res = await fetch('/api/posts')
      return res.json()
    },
    success(entity, posts) {
      entity.items = posts
      entity.status = 'success'
    },
    error(entity, err) {
      entity.error = err.message
      entity.status = 'error'
    },
  }),
}

handleAsync expands into a set of event handlers — fetchPosts, fetchPostsStart, fetchPostsRun, fetchPostsSuccess, fetchPostsError — that you can trigger, test, and extend like any other store behavior.

To trigger a fetch, you notify the store:

store.notify('Posts:fetchPosts')

To read the data, you read the entity. In a React component:

function PostList() {
  const posts = useEntity('posts')

  if (posts.status === 'loading') return <p>Loading...</p>
  if (posts.status === 'error') return <p>Error: {posts.error}</p>
  return <ul>{posts.items.map(p => <li key={p.id}>{p.title}</li>)}</ul>
}

The Comparison Side by Side

Here's the same scenario in TanStack Query:

function PostList() {
  const { data, isLoading, error } = useQuery({
    queryKey: ['posts'],
    queryFn: () => fetch('/api/posts').then(r => r.json()),
  })

  if (isLoading) return <p>Loading...</p>
  if (error) return <p>Error: {error.message}</p>
  return <ul>{data.map(p => <li key={p.id}>{p.title}</li>)}</ul>
}

This is clean, and TanStack deserves credit for how ergonomic it is. But notice what it's doing: it's creating an implicit cache (keyed by ['posts']) to compensate for the fact that there's no shared store. If two PostList components mount, TanStack Query deduplicates the fetch via that cache.

In the entity-based version, there's no need for a cache layer at all. The store is the cache. posts is a single entity. Two components reading from it are just reading the same thing.

This Isn't a New Idea

It's worth stepping back, because the entity store isn't the only architecture that sidesteps this problem.

Angular has always had services — injectable classes that live outside components and centralize logic. An Angular developer who designs their services well, using RxJS's shareReplay(1) to multicast a single HTTP request to multiple subscribers, largely doesn't feel the pain TanStack Query solves. The Angular ecosystem has a TanStack Query adapter, but experienced Angular developers often don't reach for it because their tooling already pushes them toward centralization. The architectural instinct was there from the beginning.

Redux centralizes state, just like the entity store. So why does RTK Query exist?

This is worth being precise about, because it's a genuine objection to the argument. Redux solves the shared state problem — there's one store, one source of truth — but it says nothing about how data gets into that store. You still write thunks or sagas to fire requests, and you still manually dispatch loading, success, and error actions. That boilerplate is real, and RTK Query eliminates it by auto-generating everything from an endpoint definition.

So RTK Query isn't solving the same problem as TanStack Query. TanStack Query compensates for the absence of a shared store. RTK Query eliminates lifecycle boilerplate on top of a store that already exists. These are different problems.

handleAsync is Inglorious Store's answer to that same boilerplate problem. The difference is that RTK Query goes further — it adds cache lifetime management, automatically removing data from the store when no component is subscribed to it anymore. handleAsync doesn't do that. For most applications it doesn't matter, but it's an honest gap.

The broader point is that this pattern — centralize state, reduce fetching to a lifecycle concern — has precedent across frameworks and decades. The entity store is a particularly clean expression of it, but the instinct is not new.

What You'd Still Want

Being precise here matters. There are features TanStack Query provides that handleAsync doesn't out of the box:

Refetch on window focus. When the user tabs back to the app, TanStack Query can silently refetch stale data. You could replicate this with a visibilitychange listener that notifies the store, but it's not automatic.

Stale time and cache invalidation. TanStack lets you say "consider this data stale after 30 seconds." In an entity store, you'd add a fetchedAt field to the entity and check it before deciding whether to fetch. A small utility could wrap that pattern.

Pagination and infinite queries. TanStack has first-class support for these. In an entity store, you'd model paginated state explicitly — page, hasMore, items — which is more verbose but also more transparent.

These are real gaps. But they're gaps you'd fill with a few conventions and perhaps a small utility, not a 40KB library with its own cache, observer system, and devtools.

When You Should Use TanStack Query

If you're building a React app without a centralized store, TanStack Query is the right answer. It provides the shared cache you're missing, with a polished API and a huge ecosystem.

If you're already on Redux Toolkit, RTK Query is worth looking at — it integrates the same ideas directly into the Redux store.

And honestly, even in an entity-based architecture, if your data-fetching needs become complex enough — lots of pagination, optimistic updates, real-time invalidation — reaching for TanStack Query as an explicit caching layer isn't wrong. It just solves a problem you don't have yet.

The Takeaway

Remember REST. It didn't build a better session cache — it reframed the problem until the cache wasn't needed.

The entity store does something similar on the client side. TanStack Query exists because component-local state creates a fragmentation problem: multiple components, multiple fetches, no shared truth. Its query cache is a sophisticated solution to that problem. But the entity store reframes it: state is centralized by design, so the fragmentation never happens. There's no cache to build because there's no incoherence to resolve.

The irony is that REST solved distributed state by embracing statelessness on the server. The entity store solves the client-side version of the same problem by doing the opposite — embracing a single, explicit, stateful store. Same intellectual move (reframe the problem), opposite mechanism.

If your state lives in components, you need TanStack Query. If your state lives in a centralized entity store, you already have deduplication and a single source of truth for free. All you need on top is a clean way to manage the async lifecycle — and handleAsync is that.

The next time you evaluate a library, it's worth asking: what problem is this solving, and do I have that problem? Sometimes the answer is no, and the simpler path is already in front of you.

You Probably Don't Need to Think About UI Optimization: Honest Benchmarks

Matteo Antony Mistretta — Tue, 03 Mar 2026 13:30:03 +0000

This is the third post in a series. Start with the first post if you haven't already, or read the architecture post for the full mental model.

Framework posts love benchmarks. They also love cherry-picking them. I want to be upfront about what these benchmarks measure, what they don't, and what the numbers actually mean for your daily work.

All benchmarks are in the public repo. Run them yourself on your hardware.

If you find a flaw in the benchmark methodology, please open an issue or PR. I'd rather fix the benchmark than win an argument.

Executive Summary

Here's the honest version, up front, instead of buried at the end: Inglorious Web usually doesn't beat Vue or Svelte, and it doesn't beat Solid at all. What it offers instead is comparable performance in these workloads — close enough that users are unlikely to perceive a difference in normal interaction — with a simpler programming model and a testing story that the others don't match. That's the actual pitch of this post. Everything below is the evidence for it, including the parts where Inglorious Web loses.

Three findings, briefly:

On high-frequency bulk updates (dashboards, tickers, live data grids), Inglorious Web matches Vue and Svelte's frame rates without any optimization work, in a 4–5x smaller bundle than React. Solid is faster still — its compiler gives it a real, measured scripting-time advantage here.
On sparse, deeply nested updates (the shape of spreadsheets, conditional forms, dependency chains), fine-grained frameworks — Vue's proxies, Svelte's runes, Solid's signals — all converge on doing almost nothing, while Inglorious Web's full-tree walk costs more. Under realistic usage, that cost is a few milliseconds per update and isn't something a user would notice; under a sustained synthetic stress test, it adds up to something a profiler can see.
On developer experience, Inglorious Web's event-handler model tests without a runtime, a store, or mocking — call the handler, assert the result. That's the thing none of the other frameworks give you in the same form, and it's the actual differentiator, not the frame rate.

If you want the deep-dive tables and the "why" behind each number, read on.

Benchmark 1: The Dashboard

What It Measures

A live-updating dashboard with 1,000 rows of data updating in real time, 10 random rows updated every 10ms (100 updates/second), 4 live charts, filtering and sorting, and an FPS counter. This simulates factory monitoring dashboards, stock tickers, and logistics tracking systems — the kind of UI where high-frequency bulk updates are the norm.

Fairness Rules

All implementations share the same dataset and update frequency, the same chart model and data slicing, the same business logic shape (event-driven handlers responding to the same event names), the same top-level component structure, and the same CSS.

One specific thing worth calling out: the four chart components originally rendered their bars using each framework's default list primitive — Vue, Svelte, and React all key their bar lists by index, but Solid's <For> defaults to keying by item identity/value instead. Since the bar values are plain numbers, that meant Solid's list could skip re-invoking the row function for any bar whose numeric value happened to be unchanged since the last tick — a shortcut the other three don't get with index-based keys. To rule out that this was inflating Solid's numbers, all four Solid variants were switched from <For> to <Index>, which keys by position exactly like the other frameworks. The numbers below reflect that fix.

The Full Results

Variant	FPS (dev)	FPS (prod)	Bundle (kB)
React	52	113	62.39
React Memoized	112	120	62.58
React + RTK	32	92	72.21
React + RTK Memoized	87	118	72.30
React + RTK + Inglorious adapters	29	74	79.18
React + RTK + Inglorious adapters Memoized	69	93	79.29
React + Inglorious Store	33	95	71.98
React + Inglorious Store Memoized	87	120	72.05
Vue	116	117	26.80
Vue + Pinia	117	117	28.56
Svelte	112	119	16.02
Svelte + Store	110	119	16.04
Svelte + Runes	102	118	14.13
Solid	120	119	18.38
Solid Memoized	120	120	18.34
Solid + Store	119	118	23.02
Solid + Store Memoized	120	119	23.03
Inglorious Web	118	120	16.29
Inglorious Web Memoized	115	120	16.35

Measured on MacBook Pro 16" 2023, Chrome 144, macOS Tahoe.

What the Numbers Mean

Solid is the fastest thing in this benchmark, even after the keying fix. It hits 120 FPS in dev and 118–120 in prod with zero optimization work. React's dev/prod gap is the compiler story: React 19.2 ships an automatic compiler that adds memoizations at build time, closing most of the gap manual React.memo/useMemo used to require — though the compiler only optimizes patterns it recognizes, so there are still cases where you're back to reasoning about the component tree by hand. The Inglorious adapter layer is the real overhead in the RTK variants (29 FPS dev, 74 FPS prod) — the cost is in the adapter bridging two state models, not in RTK's middleware. Vue, Svelte, and Inglorious Web all stay above 100 FPS in development and reach the monitor refresh limit in production, making them effectively indistinguishable in normal interaction.

The bundle size gap is structural. React core alone is 62KB; React + RTK reaches 72KB. Inglorious Web is 16KB total — framework, state manager, and renderer. Vue is 27KB, Svelte is 14–16KB, Solid is 18–23KB. For global audiences on slower connections, that's a meaningful difference.

Breaking Down the Resource Overhead

FPS numbers show visual smoothness; they don't show how hard the CPU is working. The profiler over a 10-second window fills that in:

Variant	Main Thread (ms)	Scripting (ms)	Rendering (ms)	JS Heap (MB)
React	8389	3596	5029	10.4-44.6
React Memoized	8345	1694	6464	11.1-33.0
React + RTK	8722	4359	4539	21.9-102.0
React + RTK Memoized	8666	4261	4630	11.5-45.9
React + RTK + Inglorious Adapters	8964	5466	3638	22.0-61.2
React + RTK + Inglorious Adapters Memoized	8974	4355	4448	11.8-50.2
React + Inglorious Store	8640	4209	4612	10.9-44.9
React + Inglorious Store Memoized	8504	2241	6103	11.5-45.8
Vue	8645	2231	6297	9.1-40.3
Vue + Pinia	8608	2226	6251	9.1-38.3
Svelte	8488	1974	6412	6.8-44.0
Svelte + Store	8440	2026	6289	6.8-43.1
Svelte + Runes	8557	2115	6312	8.3-47.3
Solid	7764	531	6457	6.5-9.5
Solid Memoized	8041	692	6637	6.6-10.8
Solid + Store	8174	1052	6498	8.8-21.9
Solid + Store Memoized	7870	747	6495	8.4-18.4
Inglorious Web	8564	1924	6489	5.2-43.7
Inglorious Web Memoized	7463	1680	4235	5.3-36.8

Why Solid Wins

Solid's scripting time is in a different league, and the keying fix barely moved it. Switching from <For> to <Index> — removing the value-based skip-unchanged shortcut, forcing Solid to revisit every bar every tick like everyone else — took scripting time from ~510–530ms to a still-tiny 531–1052ms. That rules out the keying-artifact hypothesis: even keyed identically to the rest, Solid spends a third to a fifth of Svelte's scripting time (~2,000ms).

It's not a bigger cache, it's no cache to check. lit-html's caching (what Inglorious Web relies on) re-runs your render function in full every tick, re-evaluating every expression, then skips the DOM write per part if the value's unchanged — it saves the write, not the recompute. Solid's compiler instead reads your JSX at build time and emits a direct binding per signal — signal.subscribe(v => node.style.height = v) — with no template to walk at all. A signal change invokes exactly its one subscriber. That's why Solid's scripting time pulls away while its rendering time (the actual DOM/layout cost) stays in the same range as everyone else's — the gap is in the JS work before the write, not the write itself. The tradeoff: this requires a compile step over statically analyzable JSX; a runtime loop over arbitrary JS can't be unrolled the same way without one.

Could this gap be reduced without adding a compiler? Possibly — an opt-in runtime binding directive is something I'm exploring, but that's future work rather than something measured here.

Solid's memory footprint follows the same pattern. At 6.5–21.9MB, it uses roughly a fifth of Inglorious Web's peak (43.7MB) and Svelte's (49.8MB), because there's no intermediate "all the rows" representation sitting around to diff — updates touch exactly the affected nodes.

Where Inglorious Web Wins

Memoized selectors give Inglorious Web its own large win. Comparing the unmemoized baseline to Inglorious Web Memoized, Main Thread time drops over 1,100ms and rendering time falls from 6,489ms to 4,235ms, because the table and charts stop re-computing, sorting, and slicing raw data 100 times a second.

What This Means

Vue and Svelte are efficient in scripting (~2,000ms) but tied to DOM churn — without selector memoization for this workload, their rendering times stay pinned at 6,200–6,400ms, similar to Solid's own rendering time. That tells you raw DOM writes, not JS execution, are the shared bottleneck once scripting cost is out of the way. React pays a heavy rendering tax even with the compiler — scripting drops, but rendering time still skyrockets past 6,000ms, since virtual DOM reconciliation and layout passes are unaffected by cutting JS overhead.

Put plainly: for this workload, Solid's compiled, fine-grained model has a real structural advantage over React's virtual DOM, Vue/Svelte's uncompiled reactivity, and Inglorious Web's full-tree walk — and that holds up after specifically checking for and ruling out one likely confound (list-keying strategy).

Benchmark 2: The Deep Tree

What It Measures and Why It Matters

A tree of depth 8, branching factor 3, where one random leaf updates every 300ms. React, Vue, Svelte, and Solid all localize the update through their dependency graph — a proxy or signal knows exactly what changed. Inglorious Web walks the whole tree. This is the worst case for the full-tree model, chosen deliberately.

The Results

Variant	FPS (dev)	FPS (prod)	Bundle (kB)
React	120	120	62.16
Vue	120	120	25.84
Svelte	120	120	14.68
Solid	120	120	15.99
Inglorious Web	120	120	15.00

All five hit the monitor cap in both dev and production. FPS parity is complete.

Where the Difference Shows Up

Variant	Main Thread (ms)	Scripting (ms)	Rendering (ms)	JS Heap (MB)
React	251	37	124	23.9–24.5
Vue	196	38	89	28.8–29.6
Svelte	206	34	74	49.3–49.8
Solid	107	36	84	23.6–24.1
Inglorious Web	339	135	122	11.4–28.1

Inglorious Web uses 135ms of scripting time versus 34–38ms for the other four, over the full 10-second run — with no perceptible effect on FPS, which stays locked at 120 throughout.

Solid's number here is the interesting one, and it's not what Benchmark 1 predicts. At 36ms, Solid lands right next to React, Vue, and Svelte — not in a different league. Its dramatic scripting advantage in Benchmark 1 wasn't "signals are always this much faster" — it was specific to a workload where full-tree walking has real cost to avoid. Here, once an update is localized, there's almost nothing left to skip, so proxies, runes, and compiled signals all converge to roughly the same low cost — the compiler still buys Solid the lowest Main Thread total (107ms vs. 196–251ms), just not the same order-of-magnitude story.

Why full-tree specifically loses here comes down to scale. A depth-8, branching-3 tree has 3⁸ ≈ 6,561 leaf-level nodes; a dependency graph never visits the other 6,560 when one leaf changes, while render() walks from the root every time because there's no graph telling it what to skip. Bulk updates touch a meaningful fraction of the tree anyway, so walking isn't much extra work there — a single sparse update makes "walk everything" a ~6,561x larger task by comparison, which is the 135ms vs. ~35ms you see above.

When It Would Matter

Worth being precise about what this benchmark simulates: one update every 300ms, sustained continuously for 10 seconds — about 33 updates back to back with no pause. That's a deliberately adversarial, synthetic pattern, not how sparse updates arrive in a real app. A person expanding tree nodes does it in short bursts and stops; nothing about normal interaction sustains a continuous multi-times-per-second cadence for ten seconds straight. And even under that adversarial pattern, the per-update cost is small: 135ms over ~33 updates is about 4ms each — under a single 60fps frame budget, let alone 120fps.

So the honest conclusion isn't "full-tree rendering has a weak spot to watch out for." It's: this is a deliberately worst-case synthetic stress test, built to surface a cost, and even there the per-update cost is imperceptible. If something genuinely does sustain rapid, continuous, sparse updates — a live data feed driving a deep hierarchy, not occasional user clicks — the fine-grained frameworks' converging advantage (34–38ms vs. 135ms in total) is real and worth knowing about. For the far more common case of occasional, user-driven sparse updates, the difference won't be felt.

Put both benchmarks together: for bulk updates, full-tree rendering costs about the same scripting time as proxies and runes, and only compiled signals buy you meaningfully more. For sustained, rapid sparse updates, full-tree rendering costs more in aggregate — proxies, runes, and signals converge — though the per-update cost in both cases is small enough that it mostly matters for continuous, machine-driven update streams rather than everyday interaction.

Inglorious Web's case isn't that full-tree rendering is faster in either scenario. It's that the mental model stays simple regardless of workload shape: plain event handlers, no signal graph, no compiler step, and (see Testing, below) a simple story for writing and running tests. This fits real-time dashboards, financial tickers, IoT monitoring panels, and collaborative/multiplayer state sync particularly well — @inglorious/server uses the same event system over WebSockets, so adding real-time collaboration to an existing app is a middleware line, not an architectural change.

Testing: The Developer Performance Benchmark

Runtime benchmarks measure one dimension. Developer performance — how fast you can write, change, and verify code — matters at least as much over the life of a project.

React Hooks

import { renderHook, act } from "@testing-library/react";

const { result } = renderHook(() => useTaskList());

act(() => {
  result.current.addTask('Write documentation');
});

expect(result.current.tasks).toHaveLength(1);

You need @testing-library/react, renderHook, and act() wrappers, and the React runtime. The ceremony is high enough that many teams skip unit-testing hooks entirely.

React + Redux

import { tasksReducer, taskAdded } from './taskSlice';

const state = tasksReducer([], taskAdded('Write documentation'));
expect(state).toHaveLength(1);

Redux reducers test in complete isolation — no store setup, no runtime. This is genuinely good, and it's the same instinct behind Inglorious Web's handler design. Where it gets harder is async: testing a thunk requires mocking dispatch, getState, and side effects, and the setup grows with complexity.

Inglorious Web

import { trigger } from "@inglorious/web/test";

const { entity } = trigger(
  { tasks: [] },
  TaskList.taskAdd,
  'Write documentation',
);

expect(entity.tasks).toHaveLength(1);

No runtime. No store setup. No action creators. Call the handler, assert the result — and because handlers can be async and notify further events, the same pattern extends to async: trigger returns a promise when the handler is async, and the events array captures any notifications fired during it.

Conclusions

Aspect	React	Vue	Svelte	Solid	Inglorious Web
Dev FPS (bulk updates)	32–112 (optimization required)	116–117	102–112	119–120	105–118
Prod FPS (bulk updates)	92–120 (optimization required)	117	118–119	118–120	120
FPS (sparse deep tree)	120	120	120	120	120
Scripting overhead (bulk updates)	Medium–High	Low	Low	Lowest	Medium
Scripting overhead (sparse updates)	Low	Low	Low	Low (converges with others)	Higher in aggregate, still <1 frame per update
Memory footprint (bulk updates)	Medium–High	Medium	Medium	Lowest	Medium–High
Bundle size	62–79KB	27–29KB	14–16KB	18.3–23KB	16KB
Optimization required	Not in prod (compiler); yes in dev	No	No	No	No
Testing complexity	High (hooks) / Low (reducers) / Hard (async thunks)	Medium	Medium	Low	Low

Three tiers fall out of the data. Svelte, Vue, and Inglorious Web are all sufficiently fast for the large majority of applications — 116–120 FPS across bulk updates, 120 FPS on the sparse deep tree, none of the three ever close to a visibly choppy frame rate. Within this tier, the differentiator isn't speed; it's what else you get, and for Inglorious Web that's the testing story above. Solid is the right choice specifically for cascading dependency chains and resource-constrained devices — spreadsheet-shaped problems and constrained hardware, where its lowest-in-class scripting time and memory footprint are decisive rather than incidental. Full-tree rendering's cost shows up only under sustained, rapid, sparse updates, and mostly matters for continuous, machine-driven streams rather than everyday clicking; under bulk updates it costs about the same as proxies and runes, with only compiled signals pulling meaningfully ahead. For teams coming from React and Redux, the migration is incremental — Redux DevTools still work — and the testing story holds regardless of which tier your workload falls into.

Inglorious Web isn't trying to win the performance benchmark. It's trying to be fast enough that performance stops being the deciding factor, so the decision comes down to what you actually spend your time on day to day — reasoning about state, writing tests, and debugging — where a plain event-driven model offers a simpler testing and reasoning story than hooks, signal graphs, or reactive proxies.

Appendix: Further Notes

The following two points came up during review. They're worth recording, but they're a different kind of claim than the benchmarks above — one is a narrower, less rigorous comparison, and the other is architectural philosophy rather than a measured result. Both are flagged as such.

A note on chart rendering. An earlier draft of this post compared @inglorious/charts against Recharts and found Inglorious's charts hitting 115–120 FPS versus Recharts' 85–95 FPS. That comparison is weaker than Benchmark 1 or 2: Recharts and @inglorious/charts are chart libraries, not equivalent implementations of the same spec in different frameworks, so the gap could reflect library design as much as framework architecture. A fair version of this comparison — same chart spec, implemented natively across frameworks — is a big enough undertaking that it probably deserves its own follow-up post rather than a paragraph here.

A note on game engines and ECS. Inglorious Web's entity-centric model is drawn from game development, and the sparse-vs-bulk split in this post maps onto that origin: game engines don't reach for signals for their simulation core, because physics, animation, and AI tick nearly every active entity every frame — a bulk-update workload where almost nothing is stable frame-to-frame for a signal graph to skip. ECS's actual payoff there is cache locality and parallelism, not localized change tracking. Signals do show up inside games, just not in the simulation loop — HUDs and menus are sparse-update problems, structurally similar to Benchmark 2. This is a reasonable architectural parallel, not a benchmarked claim, and it's worth reading as color rather than evidence.

What Comes Next

Performance is one side of the picture. The other is server state — how you fetch data, handle loading and error states, and keep your UI in sync with the backend.

The next post looks at how the entity-centric model interacts with async data fetching, why handleAsync covers most of what TanStack Query provides, and when you'd still want a dedicated data-fetching library.

Docs · Repo

What If Components Aren’t the Unit of Composition?

Matteo Antony Mistretta — Tue, 24 Feb 2026 13:30:03 +0000

This is the second post in a series. Start with the first post if you haven't already.

In the first post I argued that the real problem with modern frontend frameworks isn't performance or verbosity — it's locality of reasoning. You can't look at a line of code and know when or why it will execute. I also laid out the case against signals, composables, and runes specifically: they shift the problem rather than solve it, trading one invisible system for another.

This post is about what the alternative actually looks like in practice — how the entity-centric model holds up beyond a counter example, where it fits, and where it honestly doesn't.

The Component-Centric Assumption

Every mainstream framework is built on the same foundational assumption: the component is the unit of composition.

Logic lives in components. State is owned by components or lifted up from them. The UI is a tree of components, each responsible for its own piece of the world.

This model works well for many applications, especially when UI structure and domain structure align closely. But as complexity grows — particularly in data-heavy tools and dashboards — a structural tension can appear: your business logic becomes entangled with your rendering tree.

State that should logically be global ends up local. Behaviors that should be composable get scattered across components. And when you need multiple independent instances of the same domain concept — say, four charts on a dashboard — you can find yourself working around the component hierarchy rather than describing your domain directly.

Framework ecosystems have evolved good solutions to mitigate this. Vue's composables and Pinia are excellent examples, and React applications often rely on external state managers. These tools solve real problems.

But they still operate within the component-centric model: components remain the primary organizing structure, and reactive machinery determines when logic runs.

The question isn't whether these solutions improve ergonomics. It's whether the component tree is the right abstraction for modeling application behavior in the first place.

The Entity-Centric Model

Inglorious Web starts from a different assumption: entities are the unit of composition, and some entities happen to render.

Your application is a flat collection of entities — plain JavaScript objects with an id and a type. Types define behavior: they're objects whose methods are event handlers.

Most types have a render method, because this is a web UI framework after all. But render is not privileged — it's just another method on the type, and the store doesn't care about it. Some types genuinely don't render at all: a session manager, a WebSocket handler, a background polling loop. They live alongside rendering entities in the same store and respond to events the same way.

The architecture becomes clearer when visualized:

Architecture overview: user actions emit events through api.notify().
Events are processed deterministically through a queue, dispatched to entity handlers, which update state and trigger rendering.
The event timeline and state snapshots can be inspected using Redux DevTools.

The simplest setup uses autoCreateEntities, which creates one entity per type automatically:

const types = {
  TaskList: {
    create(entity) {
      entity.tasks = [];
    },

    taskAdd(entity, text) {
      entity.tasks.push({ id: Date.now(), text, completed: false });
    },

    taskToggle(entity, id) {
      const task = entity.tasks.find((t) => t.id === id);
      if (task) task.completed = !task.completed;
    },

    render(entity, api) {
      return html`
        <ul>
          ${entity.tasks.map(
            (task) => html`
              <li
                class=${task.completed ? "completed" : ""}
                @click=${() => api.notify(`#${entity.id}:taskToggle`, task.id)}
              >
                ${task.text}
              </li>
            `,
          )}
        </ul>
      `;
    },
  },
};

const store = createStore({ types, autoCreateEntities: true });

When you need multiple instances of the same type — the four-charts case — you declare them explicitly instead:

const entities = {
  chart1: { type: "Chart", data: [ ... ] },
  chart2: { type: "Chart", data: [ ... ] },
  chart3: { type: "Chart", data: [ ... ] },
  chart4: { type: "Chart", data: [ ... ] },
};

const store = createStore({ types, entities });

Each instance gets its own state, managed independently, without lifting state or threading context through component trees.

Notice what's absent from the type definition:

no useState
no lifecycle hooks
no props

The entity holds the data. The type holds the behavior.

create and render live in the same object not because the framework requires it, but because they describe the same entity. You could split them across files and nothing would break — the co-location is for readability, not framework constraints.

Why Testing Gets Simple

Event handlers are plain functions. Testing them requires no DOM, no component tree, and no lifecycle setup.

import { trigger } from "@inglorious/web/test";

const { entity } = trigger(
  { tasks: [] },
  taskList.taskAdd,
  "Write documentation",
);

expect(entity.tasks).toHaveLength(1);
expect(entity.tasks[0].text).toBe("Write documentation");

Rendering is equally direct because render is a pure function of the entity state:

import { render } from "@inglorious/web/test";

const template = TaskList.render(
  { tasks: [{ id: 1, text: "Write documentation", completed: false }] },
  { notify: vi.fn() },
);

const root = document.createElement("div");
render(template, root);

expect(root.textContent).toContain("Write documentation");

This style of testing isn't unique — Redux reducers and well-structured composables can also be tested this way. The difference here is that this is the default architecture of the framework, not something achieved through discipline or additional patterns.

Type Composition: Behavior Without Inheritance

Types are plain objects and compose naturally as arrays. Each entry in the array can be either a behavior object or a decorator function that receives the type composed so far.

const Timestamps = {
  create(entity) {
    entity.createdAt = Date.now();
  },
};

const SoftDeletable = {
  softDelete(entity) {
    entity.deletedAt = Date.now();
  },
};

const types = {
  TaskList: [TaskList, Timestamps, SoftDeletable],
};

Decorator functions allow wrapping existing behavior:

const withLogging = (type) => ({
  render(entity, api) {
    console.log(`Rendering ${entity.id}`);
    return type.render(entity, api);
  },
});

const types = {
  TaskList: [taskList, withLogging],
};

This pattern handles cross-cutting concerns such as:

validation
analytics
route guards
permissions
logging

without inheritance hierarchies or higher-order components.

Cross-Entity Communication

Entities communicate through events.

Every api.notify() call supports three targeting modes:

api.notify("save")                     // broadcast
api.notify("chart:refresh", payload)   // type-targeted
api.notify("#chart1:refresh", payload) // id-targeted

Handlers can emit further events, and all events pass through a queue that processes them in order. This guarantees deterministic execution regardless of how many entities interact.

A common concern with event-driven architectures is that event flows can become difficult to trace. Inglorious Web addresses this by integrating with Redux DevTools, which provides:

a full event log
state snapshots
time-travel debugging

Every notify() call appears in the DevTools timeline, so you can inspect exactly which events fired, in what order, and how the state changed after each one. This makes the event graph visible rather than implicit.

If a render function needs to read another entity's state, api.getEntity() provides a read-only snapshot:

render(entity, api) {
  const table = api.getEntity("mainTable");
  return html`Showing ${table.filteredRows.length} rows`;
}

In practice this means that when something behaves unexpectedly, you can either:

search the codebase for the event name, or
inspect the event log in DevTools.

Either way, the dependency graph lives in your code and tooling rather than inside a reactive runtime.

What the Entity Model Is Not

A few clarifications that come up often:

It's not strict ECS.
Game-engine ECS separates entities, components, and systems into distinct concepts optimized for thousands of homogeneous objects updated every frame. Inglorious Web collapses those concepts into types that carry both data shape and behavior, which better fits typical web UI workloads.

It's not a universal replacement for existing frameworks.
If you're heavily invested in an ecosystem like React or building animation-heavy interfaces, switching architectures has real costs. The entity model targets a specific class of problems: predictable state, debuggable event flows, and complex data-driven interfaces.

The render model is a deliberate tradeoff.
When state changes, the whole tree re-renders and the DOM diff is handled by lit-html. It could seem like naïve re-rendering, but it's not. Fine-grained reactivity systems update only the nodes that changed, which can reduce CPU usage but often increase memory pressure and complexity. Lit-html, in contrast, performs surgical DOM updates while keeping allocations low — deliberately trading fine-grained tracking for a simpler mental model. For many dashboards and data tools the difference is negligible, and reasoning about the UI becomes easier.

How updates propagate.
In reactive component frameworks such as React and Vue, state changes pass through a reactive dependency graph that determines which components re-run.

In the entity-centric model, events update the entity store and trigger a single root render, making the UI tree a pure function of the current state.

The Ecosystem

Inglorious Web ships with built-ins that cover the most common needs: a Redux-compatible state manager with DevTools support, lit-html rendering, form handling, table, virtualized list, select, router, declarative SVG charts, an animation library, and SSG with HMR, file-based routing, and Markdown. Because it renders to the real DOM, it works with any web component out of the box — Shoelace, Material Web, Spectrum — no adapter, no wrapper.

The honest gaps: the third-party ecosystem is younger than React's. Event name strings in api.notify() are not yet type-checked. The animation library covers common cases but not everything.

Who This Is For

Inglorious Web is for teams who want their state to be predictable, their tests to be trivial, and their render logic to be legible. It scales from a todo list to a config-driven dashboard precisely because the mental model doesn't change as complexity grows — you keep adding entities and types, not new abstractions.

It resonates strongly with Redux veterans (the three principles are intact, the boilerplate is gone), developers who've worked with ECS in game engines, and engineers building dashboards, HMIs, and data-heavy tools where the component tree metaphor starts feeling forced. It's a harder sell for teams that prioritize deep React ecosystem integration or prefer declarative reactivity as a philosophical stance.

The learning curve is real — not because the framework is complex, but because thinking in entities and events rather than components and hooks is a genuine shift. Most developers who've used Redux and felt "this is almost right" pick it up quickly. For everyone else, it's a one-time investment rather than a continuous tax.

What Comes Next

In the third post, I'll show the numbers: a benchmark running 1000 rows at 100 updates per second across React (naive, memoized, and with RTK) and Inglorious Web (with and without memoization), and a live chart benchmark against Recharts. Performance, bundle size, and what "dramatically smaller optimization surface area" actually looks like when measured.

Docs · Repo

I'm Done With Magic. Here's What I Built Instead.

Matteo Antony Mistretta — Tue, 17 Feb 2026 13:30:04 +0000

The JavaScript ecosystem has a magic problem.

Not the fun kind. The kind where you stare at your code, everything looks correct, and something still breaks in a way you can't explain. The kind where you spend forty minutes debugging why your computed() stopped updating, or why an effect fired when you didn't expect it, or why destructuring a store value makes it stop being reactive.

We called it reactivity. We called it signals. We called it runes. And every new name comes with a new layer of invisible machinery running underneath your code, doing things you didn't ask for, breaking in ways you didn't anticipate. The deeper problem isn't performance or verbosity — it's locality of reasoning. You can't look at a line of code and know when or why it will execute.

I've been building complex web applications for eighteen years — interactive dashboarding systems, industrial HMI interfaces, config-driven UIs. Those projects are the reason this framework exists: not because they failed, but because I could see exactly how they would age. I got tired of the magic. So I built something without it.

This isn't the Nth framework built out of frustration. It's a deliberate synthesis of ideas that already proved themselves: Redux's three principles, the Entity Component System architecture from game engines, and lit-html's surgical DOM updates. None of these are new. What's new is putting them together and following the logic all the way through.

Once Upon A Time, There Were Three Principles

I really started digging React when they introduced Redux. It revamped Functional Programming concepts as good practices for large-scale systems — proving they belonged in production code, not just CS theory. Three principles made any webapp predictable, debuggable, and testable as never before:

Single Source Of Truth: one state to rule them all.
State Is Read-Only: reference comparisons make re-render decisions trivial and performant.
Changes Through Pure Functions: reducers make logic trivial to reason about.

But things went south. Devs complained that Redux was too verbose, immutable updates were painful, async logic was a hack. Those complaints were valid — the boilerplate was a genuine tax. Enter RTK, which solved real problems: simpler reducers, built-in Immer, sane async thunks. But then it kept going — createAppSlice, builder callback notation, circular dependency nightmares. The question isn't whether Redux needed fixing. It's whether the fixes took things in the right direction. Then the "Single Source Of Truth" dogma started bending entirely: local state here, Context there, Zustand, Jotai, signals. We write less code now, and it just magically works. Well — not for me.

The Problem With Magic

Let me be specific, because "magic is bad" is an easy claim to make and a hard one to defend without evidence.

React re-renders are actually fast — React was right about that. The real problem is that re-renders trigger effects and lifecycle methods. useEffect fires after every matching render, subscriptions re-initialize, derived state recomputes. Invisible dependency arrays silently break when you forget something, and useEffect lists grow into things nobody on the team fully trusts. React's answer? A stable compiler that adds layers of cache automatically. Which means you can have a suboptimal component hierarchy and the compiler will compensate — which is convenient until you need to understand why something broke.

Vue 3 introduced a subtle trap with the Composition API: destructuring a reactive object silently breaks the proxy chain that powers reactivity. Your variable stops updating and you get no warning whatsoever. Vue provides toRefs() specifically to patch this — which proves the point: you now have to manage the integrity of an invisible system on top of writing your actual application. And computed() knows when to recompute by secretly tracking which reactive properties you accessed while it ran, which can produce circular dependencies that only blow up at runtime.

Svelte 5 introduced runes — $state(), $derived(), $effect(). The docs themselves define the word:

rune /ruːn/ noun — A letter or mark used as a mystical or magic symbol.

It's impressive engineering. But unlike JSX — which is a purely syntactic transformation — Svelte's compiler is semantically active: it changes what your code means, not just how it looks. $state() isn't JavaScript with nicer syntax; it's a different programming model that requires the compiler to be correct.

All three are racing in the same direction: more reactivity, more compilation, more invisible machinery. I went the other way.

The Boring Alternative

Inglorious Web is built on one idea: state is data, behavior are functions, rendering is a pure function of state.

No proxies. No signals. No compiler. Just plain JavaScript objects, event handlers, and lit-html's surgical DOM updates. The mental model is a one-time cost, not a continuous tax — you learn it once, and it scales without adding new concepts.

const Counter = {
  create(entity) {
    entity.value = 0;
  },

  increment(entity) {
    entity.value++;
  },

  render(entity, api) {
    return html`
      <div>
        <span>Count: ${entity.value}</span>
        <button @click=${() => api.notify(`#${entity.id}:increment`)}>
          +1
        </button>
      </div>
    `;
  },
};

It looks like a hybrid between Vue's Options API and React's JSX. If you prefer either of those syntaxes, there are Vite plugins for both. But the key differences are in what's absent. There are no hooks, no lifecycle methods, no component-level state. create and increment are plain event handlers — closer to RTK reducers than to React methods. The templates are plain JavaScript tagged literals: no new syntax to learn, no compilation step required. Boring doesn't mean verbose — it means every line does exactly what it says.

One deliberate abstraction worth naming: state mutations inside handlers look impure but aren't. The framework wraps them in Mutative — the same structural sharing idea as Immer, but 2–6x faster — so you write entity.value++ and get back an immutable snapshot. That's the only reactive magic in the stack, it's a small and well-understood library, and it's what makes testing trivial.

When state changes, the whole tree re-renders. But lit-html only touches the DOM nodes that actually changed — the same way Redux reducers don't do anything when an action isn't their concern. Re-rendering is cheap. Effects and lifecycle surprises don't exist. The question "why did this effect fire?" is simply impossible to ask, because you can look at any handler and reason about exactly when it runs. And because every state transition is an explicit event, you can grep for every place it's fired — something you cannot do with a reactive dependency graph.

Testing That Actually Makes Sense

In React, testing a component with hooks means setting up a fake component tree and mocking the world around it. In Vue 3, testing a composable means testing impure functions swimming in proxy magic.

In Inglorious Web, testing state logic is this:

import { trigger } from "@inglorious/web/test";

const { entity, events } = trigger(
  { value: 10 },
  Counter.increment,
  5,
);

expect(entity.value).toBe(15);

And testing rendering is equally straightforward:

import { render } from "@inglorious/web/test";

const template = Counter.render(
  { value: 42 },
  { notify: vi.fn() },
);

const root = document.createElement("div");
render(template, root);

expect(root.textContent).toContain("Count: 42");
// snapshot testing works too:
expect(root.innerHTML).toMatchSnapshot();

No fake component tree. No lifecycle setup. No async ceremony. Because render is a pure function of an entity, and a pure function is just a function you call.

The Mental Model Shift

React, Vue, and Svelte are component-centric. The component is the unit. Logic lives in components, state is owned or lifted by them, everything is a tree.

Inglorious Web is entity-centric. Your application is a collection of entities — pieces of state with associated behaviors. Some entities happen to render. Most of the time you don't think about the tree at all.

If you've heard of the Entity Component System (ECS) architecture used in game engines, this will feel familiar — though it's not a strict implementation. Think of it as ECS meets Redux: entities hold data, types hold behavior, and the store is the single source of truth. The practical consequence is that you can add, remove, or compose behaviors at the type level without touching the UI, and you can test state logic in complete isolation from rendering. That's not just less magic — it's a different ontology.

What Comes Next

This is the first post in a series.

In the next post, I'll go deeper into the entity-centric architecture: how types compose, how the ECS lineage maps to real web UI problems, and whether the mental model holds up at scale — from a TodoMVC to a config-driven industrial HMI. I'll also be honest about the ecosystem, the tradeoffs, and where the framework fits and where it doesn't.

In the third post, I'll show the numbers: a benchmark running 1000 rows at 100 updates per second, comparing React (naive, memoized, and with RTK), and a live chart benchmark against Recharts. Performance, bundle size, and what "dramatically smaller optimization surface area" actually looks like in practice.

The ecosystem is moving toward more magic. I'm moving the other way.

Docs · Repo

DEV Community: Matteo Antony Mistretta

Why AI Hates Modern Frameworks (and Loves Web Standards)

1. The Token Tax (and the Cognitive Bottleneck)

2. Boilerplate-Induced Hallucinations

3. "Just-In-Time UI" Is Already a Real Use Case — Even If It Stays Niche

When I Designed Inglorious Web

The Code AI Won't Write

The Problem

Four Solutions, Four Instincts

1. The Flag — the average human

2. Recursion without a schema — the clever human (and the AIs' first attempt)

3. Schema + recursion — the AI that wants to cover everything

4. Function composition — knowing the right tool

Why Is This the Hardest Solution to Find?

Stop Blaming Re-renders. You're Optimizing the Wrong Thing.

What memoization actually costs

What signals actually cost

The actual benchmark

The right distinction

The caching tradeoff, plainly stated

You Just Need Entities That Can Die

Redux-Form: When the Principle Became the Problem

Formik and React Final Form: Escaping the Store

Inglorious Web: Forms as Entities

The FormSpy Problem Is Less Acute

The Pattern Again

What Comes Next

There's No Such Thing As Local State

Fattutto: Context API Hits Its Limits

Tetra Pak: The Right Tool, Right from the Start

Heineken: Multiple Sources of Truth

Inglorious Web: Global by Default, Free of Charge

"But You Don't Need a Store — You Need Signals"

The Decision You're Actually Making

What Comes Next

Suspense Is A Symptom

What Suspense Actually Does

The Problem Suspense Solves — And Where It Comes From

How Inglorious Web Handles It

Suspense Is a Symptom

When You Might Still Want Suspense

The Pattern

What Comes Next

How a Game Engine Accidentally Became a Web Framework

Summer 2022: The Idea

2023: Game AI and the Canvas

2025: Coding Is Coping

July 2025: The Conference

The Coding Spree

Not Only Games

What It Became

What Comes Next

You Might Not Need TanStack Query

What TanStack Query Actually Solves

The Entity Store Already Has One

The handleAsync Helper Is All You Need

The Comparison Side by Side

This Isn't a New Idea

What You'd Still Want

When You Should Use TanStack Query

The Takeaway

You Probably Don't Need to Think About UI Optimization: Honest Benchmarks

Executive Summary

Benchmark 1: The Dashboard

What It Measures

Fairness Rules

The Full Results

What the Numbers Mean

Breaking Down the Resource Overhead

Why Solid Wins

Where Inglorious Web Wins

What This Means

Benchmark 2: The Deep Tree

What It Measures and Why It Matters

The Results

Where the Difference Shows Up

When It Would Matter

Testing: The Developer Performance Benchmark

React Hooks

React + Redux

The `handleAsync` Helper Is All You Need