Aura Router's real pitch is not routing, it is not maintaining two component models

A developer with a working HTML and Web Components project needed client-side navigation in a few sections, added React only to those sections, and ended up maintaining two stacks in one codebase ^[1][2][4]. The result is Aura Router, currently published as `@auraui/[email protected]` ^[13], and its argument is worth separating from its code: the expensive part of reaching for a framework to solve one problem is not the framework, it is the second component model you now own forever ^[5][22].

The constraint that produced this is common. Most pages had to stay HTML-first for SEO and initial render, so a full React rewrite did not make sense, and partial adoption was the pragmatic call ^[3]. It worked, in the narrow sense: routing was solved ^[4]. Then the bill arrived as maintenance of both stacks ^[4]. The author's own framing is blunt: React was not the problem, the combination was ^[5]. The follow-on question is the one that matters for anyone in the same position, which is why a browser that already ships a component model needs a second one to get SPA navigation ^[6].

The requirements the author set are more informative than the API. Every public URL should still return complete, indexable HTML from the server or static host; routes should be declared in HTML as Custom Elements; navigation should use ordinary `<a href>` links that still work without JavaScript; Web Components in shared layouts should stay mounted when only the child route changes; and the router should work anywhere Custom Elements work ^[9]. That yields a model where the host keeps serving complete pages and the router reuses the HTML already on screen, intercepting only marked links while unmarked links keep normal browser behaviour ^[10]. Opt-in is one attribute per link, `aura-router-link`, with existing hrefs untouched ^[11]. Routes are `<aura-route path view>` elements inside `<aura-router extract="#content">`, rendering into `<aura-outlet>` ^[12], with `AuraRouter.install()` registering the elements ^[14]. The `extract` selector both narrows a fetched HTML response to one element and, on first load, adopts the matching `#content` already in the document rather than refetching the current view ^[15].

Credit where it is due for the verification story. The demo assigns a Load ID to the document and counts client transitions, so navigating changes the URL, the heading and the counter while the Load ID stays put, and a reload changes it ^[16]. Disabling JavaScript turns the same navigation back into ordinary page loads that still work ^[17], and View Page Source shows content in the response rather than an empty shell ^[18]. That is a falsifiable claim, not a marketing one.

The nesting case is the state-preservation argument: a workspace sidebar with local state, listeners or expensive setup would lose its instance on remount, so shared UI lives in a parent layout template and child routes render into its outlet ^[19][20].

What to watch: the version number is below 1.0 and the install command pins it exactly ^[13][23], and the post does not report benchmarks, bundle size, a browser support matrix or named adopters ^[24]. The author also says he searched for an existing router with this model and could not find one ^[8], which is one developer's search, not a survey. Runnable examples are on StackBlitz and in a 10-minute walkthrough ^[21]; the honest test is whether a shared layout keeps its state across a real nested route tree, not a two-page demo.