DEV Community: Aleksandr Buryakov

Less Framework, More Platform

Aleksandr Buryakov — Tue, 25 Aug 2026 10:09:24 +0000

When I started building Aura Router, I thought I was solving a routing problem.

I wasn't.

I had an HTML and Web Components application that needed client-side navigation. I didn't want to rewrite it in React just to get SPA routing, and I didn't want another component model.

So I built a router around the platform I was already using:

HTML. Web Components. DOM. URLs. Browser navigation. JavaScript.

That became Aura Router.

I wrote about that journey in Why I Built an SPA Router for HTML and Web Components.

But building the router exposed a bigger question:

Why do we keep rebuilding parts of the Web Platform inside frameworks?

And then an even bigger one:

What would frontend development look like if the browser remained the foundation instead of becoming an implementation detail?

That led to three ideas: MAGA (Make the Web Great Again), Platform First, and — most importantly — MANA (Minimal. Aligned. Native. Additive.).

TL;DR — MANA in four questions:

Minimal — Does the platform already solve this?
Aligned — Does the API preserve native semantics?
Native — Is it built on browser primitives?
Additive — What still works if we remove it?

MAGA is the vision. Platform First is the architecture. MANA is the checklist you can apply tomorrow.

MAGA: Make the Web Great Again

Yes, the acronym is deliberately provocative. And yes, it's a joke.

The idea behind it isn't.

Not by going back — by recognizing how capable the Web has become. Frameworks helped us build the modern Web. But the platform changed too: HTML, CSS, the DOM, Web Components, modules, and browser APIs have all grown substantially.

So maybe it's time to ask:

What if the browser is already good enough to be the platform?

Not nostalgia. Not anti-framework ideology.

Simply:

Less framework. More platform.

The Web is already a platform

The browser is not a primitive runtime waiting for a framework to make it useful. It is already a platform.

It gives us HTML, CSS, the DOM, Custom Elements and Shadow DOM, templates and slots, JavaScript modules, URLs and navigation, Fetch, and many other Web APIs — and it keeps evolving.

So the question is no longer simply "Which framework should we use?"

Sometimes the better question is:

"Does the platform already solve this?"

The problem isn't frameworks

I am not arguing against React, Vue, Svelte, or Angular. Frameworks solve real problems.

The problem is not that abstractions exist. The problem is that abstractions have costs: another API, mental model, runtime layer, lifecycle, convention, and compatibility surface.

Sometimes that cost is worth paying. Sometimes it isn't.

Do we need a second model?

That is where MANA begins.

Platform First

Platform First is not "vanilla JavaScript," "no dependencies," or "never use a framework."

It is an order of decisions.

The traditional model often looks like:

Framework
    ↓
Framework abstractions
    ↓
Application
    ↓
Browser

Platform First reverses the direction:

Web Platform
    ↓
Application

And when the platform isn't enough:

Web Platform
    ↓
Thin abstraction
    ↓
Application

The platform is the default. The abstraction is the addition.

A simple example

Suppose we want to enhance navigation.

Less aligned:

<aura-link href="/settings">Settings</aura-link>

Another element. Another API. Another mental model.

More aligned:

<a href="/settings" data-aura-link>Settings</a>

The router enhances an existing link. The URL stays a URL. The browser still understands it.

That is the difference between replacing a platform primitive and adding capability around it.

MANA

Platform First describes the architecture. MANA describes how we make decisions inside it.

MANA doesn't tell you whether to use an abstraction. It tells you how to judge one.

M — Minimal

How much abstraction do we actually need?

Use the smallest abstraction that solves the problem. If the platform already solves this, don't create another system simply because a framework normally does. If not, an abstraction may be justified.

Minimal does not mean the fewest lines of code. It means minimizing unnecessary machinery.

The burden of proof is on the abstraction.

A — Aligned

What meaning does the abstraction preserve?

Preserve the platform's semantics and contracts. A router can enhance a normal <a href>, but the URL should remain a URL, the link a link, and the browser, server, and user should still understand it — including opening it in a new tab.

The abstraction improves the experience without changing the underlying meaning.

A developer who understands the Web should be able to understand what the abstraction is doing.

N — Native

What does the abstraction build on?

Prefer native platform primitives as the substrate. Native does not mean "native is always better." It means:

Start with what the browser already understands.

HTML before a component abstraction when HTML is enough. CSS before a styling runtime when CSS is enough. DOM before another rendering model when the alternative provides no required capability. URLs before a framework-specific navigation model. Web APIs before recreating the same capability inside a framework.

Native is the default, not the religion.

A — Additive

What happens when you remove the abstraction?

Add capability without unnecessarily replacing the platform underneath it.

If you remove the abstraction, what remains?

With a router, a link can become client-side navigation. Without it, it is still a valid link. The application gained an enhancement without losing the Web.

Not every system needs to be fully reversible. The useful distinction is:

platform + capability

versus:

platform replacement

Platform First is not Platform Only

Sometimes the platform is too low-level. Sometimes a library or thin wrapper is the better engineering choice. That's fine.

The question is not "Can we avoid an abstraction?"

The question is:

"Does this abstraction add enough value to justify another model?"

MANA is a decision-making discipline, not a purity test.

The Removal Test: Aura Router

A conventional SPA router can become the owner of application navigation:

Router
 ├── route definitions
 ├── navigation state
 ├── URL handling
 ├── rendering lifecycle
 └── application navigation

Aura Router takes a different approach. The browser still owns the primitives:

URL
<a>
history
navigation
DOM

Aura adds client-side behavior around them. A server-rendered HTML response can remain the foundation; a normal link remains a normal link; the router enhances navigation when JavaScript is available.

What Aura does not require:

route configuration does not replace the URL
<a href> does not become onClick or a framework-specific to=
without JavaScript, navigation can still fall back to the server

You can verify this in the live demo: disable JavaScript, reload, and use the same links. Navigation falls back to ordinary page loads. The links still work.

Add capability without making the platform disappear.

That does not mean every router should work this way. It means the browser's navigation model is worth treating as an architectural asset rather than something a framework has to replace.

The platform is the continuity layer

Web Components matter to Aura because they are already part of the Web Platform — Custom Elements, Shadow DOM, templates, and slots. They are not a framework between the application and the browser. But the principle is bigger than Web Components.

Frameworks rise and fall. Rendering models, build tools, and component models change with them. The Web Platform evolves differently, with a strong compatibility model across decades.

A URL is not a React primitive. HTTP is not a Vue primitive. CSS is not a Svelte primitive. The DOM is not an Angular primitive.

Frameworks are products. The Web is a platform.

Platform First is not about choosing today's technology. It is about building on the layer most likely to still matter when today's technology is gone.

Use the platform that exists. Add what is missing. Don't unnecessarily replace what already works.

The experiment continues

MANA needs to be tested against real applications — including cases where the platform genuinely isn't enough.

Tell me where an abstraction is clearly justified.
Tell me where Aura's APIs fight the browser instead of working with it.

If you want to see the idea in code, try Aura Router.

Build on the Web. Don't rebuild it.

Why I Built an SPA Router for HTML and Web Components

Aleksandr Buryakov — Thu, 13 Aug 2026 15:47:51 +0000

I didn't set out to build a router.

I had a project built with HTML and Web Components. It worked, and I was happy with that stack. Then a few sections needed client-side navigation.

Most pages needed to remain HTML-first for SEO and the initial render, so rewriting the entire site in React didn't make sense.

I added React only to those sections.

It solved the routing problem, but now I had React and Web Components in the same project. Maintaining both stacks became the new problem.

React wasn't the problem. The combination was.

At some point I started asking a simpler question: if the browser already has a component model, why do I need a second one just to get SPA navigation?

I wanted a router that treated HTML and Web Components as the application—not as legacy markup waiting to be replaced.

I looked for one. I couldn't find anything that matched the model I had in mind, so I started building Aura Router.

That became the use case for Aura: adding SPA navigation to an existing HTML or Web Components project without introducing a second component model.

The part I did not want to throw away

What I didn't want to throw away was the existing HTML and Web Components stack. The router had to fit that stack, not replace it. In practice, that meant:

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;
the router should be framework-independent and usable anywhere Custom Elements work.

Those requirements led to a simple model: the host keeps serving complete pages. Aura can reuse the HTML already on screen, then handle marked links without loading a new document. Unmarked links keep their normal browser behavior.

That was the idea. But I still needed a way to prove that the browser was not reloading the page. So I made the demo show exactly what was happening.

A demo you can verify

Open the live demo and look at the strip labeled Live navigation proof.

It assigns a Load ID to the current document and counts client transitions. Click How it works.

The URL changes. The heading changes. The client transition counter goes up. The Load ID doesn't change.

Now reload the page. The Load ID changes.

That's the whole idea in one small experiment: Aura changed the page, but the browser did not load a new document.

There is another test I care about just as much. Disable JavaScript, reload the demo, and use the same navigation. The transitions become ordinary page loads, but the pages and links still work.

You can also use View Page Source. The content is already in the response; the demo is not an empty app shell waiting to be rendered.

What this looks like in code

Existing links keep their href. Add one attribute when a link should use client navigation:

<a href="/about/" data-aura-link>About</a>

Routes are declared in HTML. path defines which URL a route matches, while view defines what that route should load. <aura-outlet> provides the target for the active view:

<main id="content">
    <h1>Home</h1>
</main>

<aura-outlet></aura-outlet>

<aura-router extract="#content">
    <aura-route path="/" view="/"></aura-route>
    <aura-route path="/about/" view="/about/"></aura-route>
</aura-router>

Install the current release:

npm install --save-exact @auraui/router@0.3.0

In JavaScript, one call registers Aura's Custom Elements:

import { AuraRouter } from "@auraui/router";

AuraRouter.install();

When view points to an HTML page, the optional extract selector narrows the response to a single element.

The same extract selector is used on the initial page load: Aura adopts the matching #content element already in the document instead of loading the current view again.

The complete runnable example is available in StackBlitz and in the 10-minute walkthrough.

Swapping a page was only the first test

The flat example solves basic navigation. But I also wanted shared Web Components to survive child route changes.

Suppose a workspace has a sidebar with local state, event listeners, or expensive setup. If only the child URL changes, remounting the sidebar would throw away its component instance and state.

To avoid that remount, Aura keeps the shared UI in a parent layout and renders child routes into its outlet:

<template id="workspace-shell">
  <workspace-sidebar></workspace-sidebar>
  <aura-outlet></aura-outlet>
</template>

<aura-route path="/workspace/" layout="workspace-shell">
  <aura-route path="." view="/workspace/"></aura-route>
  <aura-route path="settings" view="/workspace/settings/"></aura-route>
</aura-route>

When navigation stays inside /workspace/, Aura keeps the matched parent layout mounted and changes only the nested outlet.

I made that visible in the nested demo. Open it, note the Layout ID, and then click Settings. The child content changes, but the Layout ID does not.

This is the part that mattered for Web Components: their instances can stay alive while navigation changes only the child view.

One current boundary is worth calling out: the server or static host still owns the initial response. Today, a direct nested URL must return the parent layout, nested outlet, and child content; Aura does not generate that backend markup.

Why publish at 0.3?

Aura Router is currently at 0.3.0. Core navigation, first-paint adoption, and nested layouts are implemented and tested, but the public API may still change before 1.0. I recommend pinning the exact version.

I've tested the cases I know. The gaps I care about now are the ones that show up in projects I didn't build: awkward server setups, integration edge cases, and places where the HTML-first model does not fit. Publishing now gives that feedback a chance to shape the API before 1.0.

This post focuses on why Aura exists and how its core model works. The guide documents the API available today; I plan to publish a deeper API walkthrough as it stabilizes toward 1.0.

Try Aura Router:

Live demo — verify the navigation behavior
StackBlitz — explore the runnable project
GitHub — source, documentation, and issues
npm — install @auraui/router

If you try Aura in an existing HTML or Web Components project, I'd like to know what worked and what got in your way. Share your experience in the comments or in GitHub Discussions.