Modern HTML Replaced Your UI Framework (You Just Didn’t Notice)

- February 01, 2026

You Don’t Need a UI Framework Anymore

Modern HTML & CSS Are the UI Library

For years, the default answer to “How do I build a UI?” has been:

Use React
Use Angular
Use a component library like Telerik, MUI, or Bootstrap

That advice made sense 10 years ago.

It makes far less sense today.

Modern HTML and CSS have quietly absorbed huge portions of what UI frameworks used to justify themselves for — and most teams haven’t noticed.

This post shows how far plain HTML + CSS has come, how much payload you can avoid, and why building a native, framework-agnostic UI library is now not only possible — but often the better architectural choice.

This is a continuation of a previous post, Beyond AI: Why HTML Elements Still Boost Productivity in Blazor

The Hidden Cost of “Just Use a Framework”

Before we even look at code, let’s talk about downloads.

Typical UI stack sizes (approximate, min+gzip)

Stack	Download Size
React + React DOM	~120–150 KB
React + common UI libs	300–600 KB
Angular (runtime)	500 KB+
Telerik UI (Blazor)	1–2+ MB
CSS-only UI system	5–30 KB

That’s before:

Your app code
localization
icons
charts
polyfills

And that cost is paid:

on every cold load
on every mobile device
on every constrained network

All for functionality that the browser increasingly gives you for free.

Modern HTML Has Grown Up

HTML is no longer just <div> and <span>.

Today, browsers ship semantic, accessible, interactive primitives that used to require thousands of lines of JavaScript.

Let’s look at what you can do without a framework.

Modal Dialogs — No Framework Required

The <dialog> element is a native modal dialog with built-in accessibility.


<button type="button">Open modal</button>

<dialog aria-labelledby="modalTitle">
  <form method="dialog" class="ui-modal">
    <header>
      <h2 id="modalTitle">Confirm action</h2>
    </header>

    <p>This modal is pure HTML.</p>

    <footer>
      <button value="cancel">Cancel</button>
      <button value="ok">Confirm</button>
    </footer>
  </form>
</dialog>

What you get for free:

keyboard focus handling
ESC to close
screen-reader semantics
no JS dependency

Ten years ago, this was a framework feature.
Today, it’s a browser feature.

Accordions — Native and Accessible

Accordions no longer require state management or JavaScript.


<section class="ui-accordion">
  <details>
    <summary>What is this?</summary>
    <p>A native accordion using HTML.</p>
  </details>

  <details>
    <summary>Why use it?</summary>
    <p>Because it’s fast, accessible, and simple.</p>
  </details>
</section>

This supports:

keyboard navigation
screen readers
toggle state
zero JavaScript

Dropdowns and Menus — Semantic HTML First

You don’t need custom components to express intent.


<div class="ui-dropdown">
  <button aria-haspopup="menu" aria-expanded="false">
    Menu
  </button>

  <div role="menu" hidden>
    <button role="menuitem">Profile</button>
    <button role="menuitem">Settings</button>
    <button role="menuitem">Sign out</button>
  </div>
</div>

This is:

readable
accessible
framework-agnostic
styleable anywhere

The behavior layer can be added later — without changing the markup.

Toast Notifications — HTML + ARIA

Even transient UI like toasts no longer require a framework.


<div class="ui-toasts" aria-live="polite" aria-atomic="false">
  <div class="ui-toast" role="status">
    <strong>Saved</strong>
    <p>Your changes were saved successfully.</p>
  </div>
</div>

ARIA handles:

announcement timing
assistive technology support
user feedback

Your CSS handles layout and animation.

Tooltips and Popovers — Standards, Not Components

Tooltips can be entirely CSS-driven.


<span class="ui-tooltip-wrap">
  <button aria-describedby="tip1">Info</button>
  <span id="tip1" role="tooltip" class="ui-tooltip">
    Helpful explanation
  </span>
</span>

Modern browsers also support native popovers:


<button popovertarget="info">More info</button>

<div id="info" popover>
  <p>This is a native popover.</p>
</div>

No framework.
No lifecycle hooks.
No state containers.

Focus Management — Built In

Focus trapping, tab order, and keyboard interaction used to be a framework selling point.

With modern HTML:

<dialog> handles focus naturally
Semantic elements guide keyboard flow
tabindex is rarely needed

You’re aligning with the browser instead of fighting it.

Why This Changes How You Build UI Libraries

When your UI library is HTML + CSS:

✅ It works everywhere

Blazor
MVC / Razor Pages
React
Next.js
Static HTML
Future frameworks you haven’t met yet

✅ It’s stable

HTML rarely has breaking changes.
Frameworks do — constantly.

✅ It’s inspectable

Developers can read it in DevTools and understand it instantly.

✅ It’s portable

No transpilation.
No runtime dependency.
No lock-in.

✅ It’s smaller

Measured in kilobytes, not megabytes.

A More Flexible “Native” UI Library

Instead of shipping components, you ship patterns:

design tokens (colors, spacing, typography)
layout utilities (grid, stack, flow)
component classes (buttons, cards, forms, dialogs)
optional behavior hooks (data-* attributes)

Your consumers decide:

how much behavior they want
where it runs
which framework (if any) they use

You stop exporting opinionated components
and start exporting capability.

This Is Not Anti-Framework — It’s Anti-Overkill

Frameworks still have a place:

complex client-side state
highly interactive apps
rich visualization tools

But most internal business apps don’t need:

2MB of UI runtime
virtual DOM diffing
component lifecycles for buttons and forms

They need:

fast loads
accessibility
consistency
longevity

Modern HTML and CSS already deliver that.

Final Thought

We spent a decade compensating for missing browser features.

The browser caught up.

Now it’s time our architectures did too.

If your UI library can be:

smaller
simpler
more portable
more future-proof

…and all it takes is trusting the platform again?

That’s not regression.

That’s maturity.

[source code]

Search This Blog

Coding With David