Web Standards and Long-Term Maintenance

The Two-Year Rewrite Treadmill

Here is a conversation that happens in a lot of small businesses, usually with a cup of coffee and a laptop open:

“The site is fine, but the framework it was built on is two versions behind and out of support. The developer who built it has moved on. The agency that maintained it has closed. We either pay someone to modernise it, or we start again.”

For a twelve-person wholesaler, that is a real bill and a real interruption. Nobody chose this. The site was not designed to be thrown away every second year. It just sat on top of something that was.

Consider the historical trajectory of mainstream JavaScript frameworks over the past decade:

┌──────────────┬────────────────────────────────┬───────────────────────────────┐
│                           THE FRAMEWORK CHURN CYCLE                           │
├──────────────┼────────────────────────────────┼───────────────────────────────┤
│ YEAR         │ INDUSTRY FASHION               │ SUBSEQUENT FATE               │
├──────────────┼────────────────────────────────┼───────────────────────────────┤
│ 2014 - 2016  │ AngularJS (1.x) Controllers    │ Deprecated; Complete Break    │
│ 2016 - 2018  │ React Class Components & Redux │ Deprecated for Hooks          │
│ 2019 - 2021  │ Next.js Pages Router (SSR)     │ Deprecated for App Router     │
│ 2022 - 2024  │ Next.js App Router & RSC       │ Migration friction            │
│ 2025 - 2026+ │ Server Actions, PPR            │ Platform lock-in              │
└──────────────┴────────────────────────────────┴───────────────────────────────┘

Every one of these transitions broke backward compatibility. Businesses that paid a developer to write React class components or AngularJS directives found their site obsolete within three years, and the fix was a second invoice.

Meanwhile, a plain HTML and CSS document written in 1996 still renders perfectly in Google Chrome, Apple Safari, and Mozilla Firefox today.

That contrast is the whole argument: frameworks are ephemeral; web standards are perpetual.

---

1. The Maturation of the Browser Platform

A decade ago, frameworks were genuinely necessary. Browsers were fragmented, Internet Explorer 11 lacked modern layout capabilities, and vanilla JavaScript lacked modularity, requiring jQuery, Backbone, and early React to normalise the environment.

In 2026, the browser has caught up to the frameworks that set out to replace it.

A. Native Dialogs and Overlays

For years, teams pulled in heavy React modal packages (react-modal, radix-ui/dialog) to handle focus trapping, backdrop blurs, and ESC-key bindings.

Today, native HTML provides the <dialog> element and the popover API with built-in accessibility and top-layer rendering:

<!-- Native HTML5 dialog: no JavaScript library, keyboard and focus handled by the browser -->
<dialog id="booking-modal" class="aura-dialog">
  <form method="dialog">
    <h2>Book a consultation</h2>
    <button type="submit" aria-label="Close dialog">✕</button>
  </form>
</dialog>

<script>
  const dialog = document.getElementById('booking-modal');
  document.getElementById('open-btn').addEventListener('click', () => dialog.showModal());
</script>

B. Declarative CSS Layout and Animation

Complex, state-driven animations once required a library like GSAP or Framer Motion.

Modern CSS natively supports Subgrid, container queries, scroll-driven animations, and @starting-style:

/* Native scroll-driven animation: no JS, runs on the GPU compositor */
@keyframes fadeSlideUp {
  from {
    opacity: 0;
    transform: translateY(30px);
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

.work-card {
  animation: fadeSlideUp linear both;
  animation-timeline: view();
  animation-range: entry 10% cover 30%;
}

C. The Native View Transitions API

The historical justification for Single-Page Applications was smooth page transitions without a white flash between pages.

With the W3C View Transitions API, the browser cross-fades between document loads on its own, with hardware-accelerated motion:

/* Enables native page transitions across plain static HTML pages */
@view-transition {
  navigation: auto;
}

::view-transition-old(root) {
  animation: 90ms cubic-bezier(0.4, 0, 1, 1) both fade-out;
}
::view-transition-new(root) {
  animation: 210ms cubic-bezier(0, 0, 0.2, 1) both fade-in;
}

---

2. Web Components: UI That Outlasts the Framework

When a page does need client-side logic, it can live inside a Web Component instead of inside a framework’s component tree.

Because a Web Component is registered directly on the browser’s window.customElements registry, it does not care which framework built the page around it.

// A durable Web Component: works in plain HTML, React, Vue, or Svelte
class QuoteCalculator extends HTMLElement {
  connectedCallback() {
    this.rate = parseFloat(this.getAttribute('data-rate') || '1.0');
    this.innerHTML = `
      <div class="quote-box">
        <span class="quote-value">$${(450 * this.rate).toLocaleString()}</span>
      </div>
    `;
  }
}

customElements.define('aura-quote-calculator', QuoteCalculator);

Why It Outlives Everything

A custom element written today should still run in 2036. It does not matter if React has reached version 25, or been dropped entirely. It depends on the HTML Living Standard, which does not remove features the way a framework release does.

For a business owner, that is the difference between a site you own and a site you rent. Renting is fine, but you should know which end of the lease you are on.

---

3. How Astro Bridges Standards and Authoring

Recommending web standards does not mean hand-stitching HTML files. You still want reusable components, layouts, and a way to catch mistakes before they go live.

Astro is a compiler that dissolves at runtime:

┌─────────────────────────────────────────────────────────────────────────────┐
│                   THE ASTRO COMPILE-TO-STANDARDS PIPELINE                   │
├─────────────────────────────────────────────────────────────────────────────┤
│  AUTHORING (WHAT YOU WRITE)                                                 │
│  |- Modular .astro component files                                          │
│  |- Strict TypeScript typing                                                │
│  |- Content collections with schema validation                              │
│  |- Tailwind or plain CSS tokens                                            │
│  COMPILE PHASE (Vite)                                                       │
│  |- Strips template logic, loops and framework machinery                    │
│  OUTPUT (WHAT THE VISITOR GETS)                                             │
│  |- Plain, semantic HTML                                                    │
│  |- Modern CSS, hardware accelerated                                        │
│  |- No runtime JavaScript unless you ask for an island                      │
└─────────────────────────────────────────────────────────────────────────────┘

You write components, layouts and typed content. The browser receives plain HTML and CSS. Nobody has to maintain the machinery in between.

---

4. The Five-Year Ledger: Churn vs. Standards

The cost of a framework is not the build. It is everything that happens to the build afterwards:

┌──────────────────────────┬──────────────────────────┬─────────────────────────┐
│                   THE FIVE-YEAR LEDGER: CHURN VS. STANDARDS                   │
├──────────────────────────┼──────────────────────────┼─────────────────────────┤
│ WHAT YOU FACE            │ A FRAMEWORK SITE         │ A STANDARDS SITE        │
├──────────────────────────┼──────────────────────────┼─────────────────────────┤
│ Year 1: launch           │ Built, handed over       │ Built, handed over      │
│ Year 2: dependencies     │ Patch, then upgrade      │ Nothing to upgrade      │
│ Year 3: major release    │ Breaking change          │ Nothing to change       │
│ Year 4: handover         │ New developer, new setup │   Any developer can read│
│ Year 5: hosting          │ Tied to a platform       │ Any host, any file      │
└──────────────────────────┴──────────────────────────┴─────────────────────────┘

The right-hand column is not cheaper because standards are clever. It is cheaper because nothing breaks.

---

Conclusion: Build for Years, Not Quarters

You can either keep funding the churn of commercial JavaScript frameworks, or anchor your site in the W3C Web Standards that browsers have kept compatible since 1996.

The choice is not technical taste. It is what happens to your business on the morning someone wants to buy it, or the month the developer who built it leaves.

Long-term maintenance is the cost nobody budgets for, and it is the one that decides whether a site is still an asset in five years or a liability.

Aura Logic builds sites for small businesses that plan to be here in five years.

STRUCTURED PROTOCOL // FAQS

Frequently Addressed Technical Inquiries

What is the 'Anti-Framework Thesis' in modern web engineering? [+]

The Anti-Framework Thesis asserts that modern browser standards (HTML5, CSS3/4, ECMAScript 2026, Web Components) have matured to the point where complex JavaScript runtime frameworks are no longer necessary for 95% of public web functionality. Relying on standards ensures multi-decade backward compatibility, zero vendor lock-in, and immunity from the continuous churn of commercial JavaScript frameworks.

Why do JavaScript frameworks deprecate APIs so frequently? [+]

Commercial frameworks (particularly those backed by venture capital or cloud hosting platforms like Vercel) iterate rapidly to lock users into proprietary deployment infrastructure and edge compute models. This structural incentive drives frequent architectural pivots that deprecate previous paradigms, forcing small businesses into costly upgrade cycles.

Are Web Components fully production-ready for small business websites? [+]

Yes. Web Components (Custom Elements, Shadow DOM, and HTML Templates) are supported natively across 100% of modern browsers without polyfills. Organizations like YouTube, GitHub, Adobe, and Salesforce use Web Components for core interface primitives, which is why those components keep working across framework changes.