From Unreachable to Reachable
Why web UI state architecture is broken for small teams, and why Active Tags exists as a reachability layer instead of just another glue-heavy framework story.
The Problem
The core sell of Active Tags + m7 is simple: make medium and high complexity web targets reachable for small teams and solo operators. That sounds obvious, but for most teams it is not reality. Reality is glue work, repeated plumbing, and state chaos.
Megacorps can brute-force framework ceremony with people; solo operators and small teams cannot. If your labor model assumes an army, your architecture is already broken for everyone else, especially when the website is still the front door of the business.
The browser is already the right runtime for most product surfaces. The bottleneck is not HTML/CSS design velocity; the bottleneck is JavaScript interaction architecture.
The Core Claim
The web is not weak; our default methods for coordinating HTML, JS state, and remote calls are weak. That is why projects look clean on the outside and rotten on the inside, why two pages feel fine and twenty pages feel like surgery, and why teams keep rewriting the same glue forever.
The Macro Failures
-
State Governance Gaps.
Most websites do not have a deterministic state-governance model. Route changes, click events, async data, feature flags, and partial reloads all compete to decide what is active. Usually there is no formal arbitration order, no authoritative owner, and no transition policy.
- silent overrides
- stale active state
- teardown misses
- semantic drift between visual active state and aria state
-
Boundary Collapse.
Behavior leaks into markup and fragments, markup leaks into control flow, and policy leaks into random handlers. You start with "just add this one attribute" and end up with templates nobody can safely refactor. Cross-project reuse gets worse, portability breaks, diff quality drops, and code review quality follows.
-
Glue-Driven Architecture.
Handlers get written everywhere, request plumbing gets repeated everywhere, and status and payload validation gets repeated everywhere. Each local fix makes sense, but systemically it becomes duplication at scale.
-
Framework Dependency Debt.
Large framework stacks create maintainability thresholds. If the original team leaves, key people leave, or team capacity drops below that threshold, maintainability collapses fast. Migration is usually not migration; it is a rewrite with different marketing.
Then add vendor and ecosystem risk: pricing shifts, project abandonment, policy shifts, ecosystem churn. Now your architecture is coupled to external business decisions you do not control.
-
Poor Operability.
When state transitions go bad, can you answer what changed, why it changed, when it changed, and who or what policy source changed it? In most projects, no. The transition story gets reconstructed from scattered logs, assumptions, and luck.
-
Non-Linear Scale Failure.
As systems grow, complexity grows in multiple dimensions: code volume, state interactions, async behavior, team coordination, runtime variance. Most web stacks do the opposite in the UI-state layer, which is why complexity grows faster than lines of code.
Why This Hits Small Teams Hardest
Large organizations can pay labor tax; small teams pay with survival. If you are solo or small-team, you cannot afford repeated rewrites, repeated glue, repeated hand-rolled state logic, or fragile architecture that only works while one hero is awake. Time is not just money here; time is runway.
The Real Point
Web development is still stuck between two bad extremes: heavy architecture with heavy ceremony, or lightweight scripts with heavy glue debt. Neither is a good default for teams that need velocity and longevity.
If the website is front-and-center for your business, the state layer cannot be an afterthought; it has to be deterministic, inspectable, reusable, and boring. That was the problem. What follows is the system I built to solve it.