MAGA: 적은 프레임워크, 더 많은 플랫폼

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:

1. Minimal — Does the platform already solve this?
2. Aligned — Does the API preserve native semantics?
3. Native — Is it built on browser primitives?
4. 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

Enter fullscreen mode Exit fullscreen mode

Platform First reverses the direction:

Web Platform
    ↓
Application

Enter fullscreen mode Exit fullscreen mode

And when the platform isn’t enough:

Web Platform
    ↓
Thin abstraction
    ↓
Application

Enter fullscreen mode Exit fullscreen mode

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>

Enter fullscreen mode Exit fullscreen mode

Another element. Another API. Another mental model.

More aligned:

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

versus:

platform replacement

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

URL
<a>
history
navigation
DOM

Enter fullscreen mode Exit fullscreen mode

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.