DEV Community: Matteo Antony Mistretta

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 of corollaries to the Inglorious Web series. It stands alone, but the examples make more sense if you've read the architecture post first.

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.

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.

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.

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, 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.

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.

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.

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.

The short version: Inglorious Web matches the fastest alternatives without any optimization work, in a bundle that's 4–5x smaller than React. Vue and Svelte are equally fast — that's not a surprise, and it's not a problem. The real differentiator isn't raw speed. It's that Inglorious Web's optimization surface area is dramatically smaller. You write naive code and get optimal performance. But there's a scenario where full-tree rendering has a measurable cost, and I'll show you that too — along with why it almost certainly doesn't matter for your users.

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

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. This is a genuine apples-to-apples comparison.

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
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

Vue and Svelte are fast. That's expected and honest. Both reach comparable FPS to Inglorious Web in development and match it in production. Raw rendering speed is not where Inglorious Web differentiates — and this post won't pretend otherwise.

The React dev/prod gap is the compiler story. These benchmarks use React 19.2, which ships with an automatic compiler. The naive React variant drops to 52 FPS in development but recovers to 113 FPS in production — because the compiler adds memoizations automatically at build time. Manual React.memo, useMemo, and useCallback are no longer required for production performance. The compiler recovers performance that would previously require manual optimization work. The underlying rendering model remains the same, though — components can still re-render broadly, and the compiler only optimizes patterns it can safely recognize. When it encounters a pattern it can't, you're back to reasoning about the component tree manually.

The Inglorious adapter layer is the real overhead in RTK variants. React + RTK on its own (32 FPS dev, 92 FPS prod) isn't slow because of RTK's middleware — it's slow because of how RTK interacts with React's rendering model in this workload. The variants using Inglorious adapters on top of RTK perform worse still (29 FPS dev, 74 FPS prod), which tells you the cost is in the adapter layer bridging two state models, not in RTK's middleware itself.

Inglorious Web is fast by default and gains little from memoization. The baseline variant (105 FPS dev, 120 prod) already matches the best alternatives. Adding compute() for derived state brings it to 110 FPS dev — a modest gain, confirming that the baseline update model is already efficient. You don't need to think about optimization, and there's no compiler pass silently doing it for you.

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 16KB. For global audiences on slower connections, this matters.

Benchmark 2: The Charts

What It Measures

Four live-updating charts — line, area, bar, pie — with 100 data points each, updated at 10 updates/second. Compared against Recharts, the most widely used React chart library.

The Results

Implementation	FPS (120Hz monitor)	vs Recharts
📊 Recharts	85–95 FPS	baseline
🚀 Inglorious Charts (Config)	115–120 FPS	+35% faster
🚀 Inglorious Charts (Composition)	115–120 FPS	+35% faster

On 60Hz monitors: Inglorious ~60 FPS, Recharts ~51 FPS.

This one Inglorious Web wins clearly. Recharts carries React's rendering overhead. @inglorious/charts is built on the same entity-centric model — charts are entities, lit-html handles surgical DOM updates, no virtual DOM reconciliation. For data-dense dashboards with multiple live charts, the gap is meaningful.

Benchmark 3: The Deep Tree

What It Measures and Why It Matters

This benchmark is specifically designed to challenge full-tree rendering: a tree of depth 8 with a branching factor of 3, where one random leaf updates every 300ms.

React, Vue, and Svelte handle this with fine-grained reactivity — only the affected leaf rerenders. 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
Inglorious Web	120	120	15.00

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

Where the Difference Shows Up

FPS isn't the whole story. Here's what the profiler shows in production over a 10-second window:

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
Inglorious Web	339	135	122	11.4–28.1

Inglorious Web uses 135ms of scripting time versus ~35ms for the others. That's about 100ms more — over 10 seconds. That's 1% of wall-clock time, on a workload specifically engineered to be the worst case for full-tree rendering, with no perceptible effect on the user and all variants locked at 120 FPS throughout.

It's a real cost. The profiler can measure it. But it's not a practical concern for any real application — and it comes with a tradeoff in the other direction: Inglorious Web's JS heap (11.4–28.1 MB) is substantially lower than Svelte's (49.3–49.8 MB). Full-tree rendering trades a small amount of CPU time for lower memory pressure. Whether that's a good trade depends on your constraints.

When It Would Matter

If you're building a deeply nested UI where individual nodes update rarely and in isolation, and CPU efficiency is a hard requirement, fine-grained reactive frameworks have a genuine edge. Inglorious Web's primary workload is the opposite — high-frequency bulk updates across many entities simultaneously. Workloads that fit this model well include real-time dashboards, financial tickers, IoT monitoring panels, collaborative editing tools, and multiplayer state synchronization. The last two are worth noting specifically: @inglorious/server uses the same event system over WebSockets, so adding real-time collaboration to an existing app is a single middleware line rather than an architectural change. The deep tree benchmark is a useful stress test of the tradeoff, not a representative scenario for any of these.

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. Testing is where architectural choices become visceral.

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. The React runtime is required. 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 are pure functions and test in complete isolation — no store setup, no runtime needed. 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 any side effects, and the setup grows quickly 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. Just call the handler, assert the result. And because handlers can be async and can notify further events, the same pattern works for async too — trigger returns a promise when the handler is async, and the events array captures any notifications fired during the handler. There's nothing else to learn.

The Honest Summary

Aspect	React	Vue	Svelte	Inglorious Web
Dev FPS (bulk updates)	32–112 (optimization required)	116–117	102–112	105–110
Prod FPS (bulk updates)	92–120 (optimization required)	117	118–119	120
FPS (sparse deep tree)	120	120	120	120
Scripting overhead (sparse updates)	Low	Low	Low	~1% higher
Bundle size	62–79KB	27–29KB	14–16KB	16KB
Optimization required	Not in prod (compiler); yes in dev	No	No	No
Testing complexity	High (hooks) / Low (reducers) / Hard (async thunks)	Medium	Medium	Low

The right framework depends on your workload and priorities. For high-frequency bulk updates, data-dense dashboards, and event-driven UIs, Inglorious Web performs optimally without any optimization work. For deeply nested UIs with sparse, localized updates and strict CPU budgets, fine-grained reactive frameworks have a measurable efficiency edge. For teams coming from React and Redux, the mental model transfer is natural and the Redux DevTools compatibility makes migration incremental.

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. The short version: if you have a centralized store, you may not have the problem TanStack Query was built to solve.

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

Inglorious Store: a Redux-compatible state manager inspired by ECS

Matteo Antony Mistretta — Fri, 17 Oct 2025 16:58:56 +0000

I love Redux. It taught me how cool functional programming can be. For a long time I even wondered if using functional programming for games could be a good fit. Some examples proved that you can indeed program games in Haskell, Lisp, or F#. But, is it worth it?

A few years ago I had an idea: create my own version of Redux, but tailored for videogames. Thus the Inglorious Engine was born. The proof-of-concept was solid, but then other things got in the way and I abandoned it for quite some time.

Last summer I was asked to speak at a conference, so I brought the engine back. While re-reading its code I said to myself: "You know what? This isn't half bad!" So I went on evolving it. I even created a new superset of JavaScript: IngloriousScript adds vector operations natively to the language, making game logic even simpler.

Then I went back to the state management component, and I noticed something: this can be used for apps too! It could have been a life-saver that time I had to build a React framework for interactive dashboards.

Long story short, this is how the Inglorious Store was born. To me, it's like Redux should be rewritten now that it has been tested in the field for so many years. RTK cuts a lot of the original verbosity, but it also adds some more.

Redux is awesome, because the Three Principles (Single Source of Truth, Immutable State, and Pure Functions) allow us to build predictable, testable, and debuggable logic. But defining the state through reducers is not really intuitive; actions are best defined through action types and action creators; any impure logic has to be moved to thunks or other similar middlewares.

Redux Toolkit (RTK) solved a few of these problems: slices are more intuitive, reducers can be written with mutable code, and actions are easier to define. But then we need to tell apart reducers and extraReducers, use the builder callback notation, and creating async thunks is not immediate. It's an amazing piece of technology, it powers RTK Query, and I use it everyday at work, but it's not really the simplest.

That's probably why so many other state management libraries started to emerge: Zustand, Jotai, Recoil, MobX, ... each one tries to simplify state management. And they do! But they had to sacrifice a few things: limited testability and predictability, not 100% compatible with time-travel debugging, ... Most of these libraries are perfect for small states, like in a Next.js server-side rendered page.

What if we could have a new library that is 100% compatible with Redux, maintains the Three Principles (mostly) unvaried, but allows to do more with less code?

Enter the Inglorious Store. It's basically a drop-in replacement for Redux, so it's 100% compatible with react-redux and the Redux DevTools. The difference is mainly on how you write your code with it.

You can easily manage multiple instances. Say you have a dashboard with some widgets: it's very intuitive to define a state that describes those widgets, and you can even easily add and remove them at runtime.
It lessens the constraint of pure functions, allowing a reducer to dispatch an event. Your code will still be predictable and testable though, because...
Your events are sent to an event queue, like a publisher/subscriber bus. If you use batched mode, you can even process multiple events before updating your state (thus minimizing re-renders).
The store uses an immutable library like Immer (it's actually Mutative, who claims to be 10x faster) under the hood, so you can write your immutable code as if it was mutable.
You don't need thunks or anything. Your event handlers can be asynchronous functions. Just don't try to mutate the state right after a promise because it's not going to work. Just dispatch another event, like you're used to with redux-thunk or redux-saga.
You don't need to define action types and action creators. Just notify events in a concise way.
Are you scared that you will mistype an action name without action creators and action types? Just use TypeScript: the Inglorious Store is completely typesafe, and it's really trivial to add types to your logic (no const increment: CaseReducer<State, PayloadAction<number>> = (state, action) => state + action.payload, just const increment = (entity: CounterEntity, amount: number) => entity.value + amount)
It features built-in events for entity creation and destruction, and even for hot-replacing reducers.
It features lifecycle events for when an entity has been created or destroyed.

The README is pretty exhaustive, so I'm not going to repeat myself here. Just know that it's open source, that I put my heart in it, and that I would really appreciate it if you could try it out and see if it suits your needs.

You can find code examples here:

TodoMVC: An (ugly) clone of Kent Dodds' TodoMVC experiments, showing the full compatibility with react-redux and The Redux DevTools.
TodoMVC-CS - A client-server version of the TodoMVC, which showcases the use of notify as a cleaner alternative to dispatch and async event handlers.
TodoMVC-RT - A "multiplayer" version, in which multiple clients are able to synchronize through a real-time server.
TodoMVC-TS - A typesafe version of the base TodoMVC.

Happy coding!

DEV Community: Matteo Antony Mistretta

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

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

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

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

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

Benchmark 1: The Dashboard

What It Measures

Fairness Rules

The Full Results

What the Numbers Mean

Benchmark 2: The Charts

What It Measures

The Results

Benchmark 3: 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

Inglorious Web

The Honest Summary

What Comes Next

What If Components Aren’t the Unit of Composition?

The Component-Centric Assumption

The Entity-Centric Model

Why Testing Gets Simple

Type Composition: Behavior Without Inheritance

Cross-Entity Communication

What the Entity Model Is Not

The Ecosystem

Who This Is For

What Comes Next

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

Once Upon A Time, There Were Three Principles

The Problem With Magic

The Boring Alternative

Testing That Actually Makes Sense

The Mental Model Shift

What Comes Next

Inglorious Store: a Redux-compatible state manager inspired by ECS

The `handleAsync` Helper Is All You Need