Hi HN,After 18 years building complex web apps (dashboards, industrial HMI interfaces, config-driven UIs), I kept running into the same problem across every generation of magic — reactivity, signals, runes: you can t look at a line of code and know when or why it will execute. Forty minutes debugging why a computed() stopped updating, or why destructuring a store value silently kills reactivity, stopped feeling like a fluke and started feeling like the point of these systems.So I built Inglorious Web around the opposite premise: locality of reasoning over convenience. It goes back to Redux s original three principles — single source of truth, read-only state, changes only through explicit events — but strips out the boilerplate that made people abandon Redux in the first place (no action types to define, no reducers to wire up, no slices).The only magic left in the whole stack: state mutations inside handlers look impure (entity.value++) but aren t — they re wrapped in Mutative (same structural-sharing idea as Immer, 2–6x faster) and handed back as immutable snapshots. That s it. One well-understood library, not a dependency graph.Rendering is lit-html, so a state change re-renders the tree but only touches the DOM nodes that actually changed — no virtual DOM, no effects, no lifecycle surprises. Every state transition is an explicit, greppable event, which you can t say about a signal graph.Full writeup: https://dev.to/iceonfire/im-done-with-magic-heres-what-i-bui... Docs: https://inglorious.dev/webHappy to defend the tradeoffs — curious whether others have hit the same locality-of-reasoning wall with signals/runes.