你的前端框架，是你為逃避學習 HTML 而付出的代價

Say it out loud: most front-end frameworks exist to rebuild things the browser already does.

• <dialog> with showModal() is a modal: it makes the page behind it inert and closes on Escape.
• <details> is a disclosure widget, and several <details> elements that share the same name attribute become an accordion.
• <form> validates. <progress> is a progress bar. <nav> is a landmark screen readers already understand.

And yet the industry default is to throw all of that away, write <Modal isOpen={open} onClose={...}> in a language that isn't HTML, compile it with a toolchain that isn't the browser, and ship a runtime so the browser can be talked into doing what it already knew how to do.

That isn't engineering. It's a tax, and we've been paying it so long we call it best practice.

The trade every framework makes

Each popular framework makes the same deal: to get components, you give up HTML.

• React turns markup into JSX and a build pipeline.
• Vue and Angular add template languages and compilers.
• Web Components hide your markup behind custom tags and shadow roots your own CSS can't reach.

Each one is a new vocabulary, a toolchain, a dependency tree and a breaking-change calendar. None of it is what the browser actually runs.

Then we write ARIA by hand to rebuild the accessibility we got for free from the element we refused to use.

The opposite trade

We wanted to know how far you get if you refuse that deal completely. The rules:

1. Semantic HTML5 elements only. No custom elements.
2. Light DOM only. No shadow roots. Your CSS reaches everything.
3. Composition, never inheritance. A behavior is a plain function that takes an element, adds capability to it and returns a cleanup.
4. No build step. The files you write are the files served.

That's the whole API:

<article x-draggable x-ripple>
  <h3>Hello</h3>
  <p>A card you can drag, with a ripple on press.</p>
</article>

Open dev tools and it's still an <article>. No wrapper component, no hydration marker, no #shadow-root. Turn JavaScript off and it's still a readable document.

"Fine for a toy." It isn't a toy.

The project is called WB (Web Behaviors), and at the moment it has:

• 106 behavior modules, described by 167 JSON schemas with 676 properties
• 8,523 Playwright tests in 624 spec files
• tests that measure rendered pixels, not class names: that size="lg" really is wider than size="md", that nothing overflows a 375px phone, that no text sits within 1rem of its container's edge
• a nightly full suite and a known-failures register that is only allowed to shrink

And the part people get uncomfortable about: AI wrote all of it. The runtime, the behaviors, the schemas, the CSS, the docs and every test were written by Claude, with a human (me) setting the standards and refusing anything that didn't come with a passing test.

Which raises a second uncomfortable question. If your framework's main selling point was "developer experience", and the developer is increasingly a machine, who exactly is the abstraction for? A model writes plain HTML just as happily as JSX, and plain HTML doesn't need a compiler, a runtime or a migration guide.

What I'm not saying

I'm not saying React is useless. If you're building Figma, use whatever lets you ship Figma.

I'm saying most of us aren't building Figma. We're building forms, dashboards, content sites and admin panels, and for those we've accepted a build pipeline, a megabyte of JavaScript and a yearly rewrite as the price of putting a modal on screen.

So, convince me

Bring your best argument. Specifically:

1. What does your framework give you that HTML plus small composable functions can't? Concrete cases, not "ecosystem".
2. Is the shadow DOM a feature or a mistake? Every design system I've seen ends up fighting it.
3. If AI writes most of your UI code within five years, do frameworks still matter, or do they become legacy?

Try it yourself: https://cielovistasoftware.github.io/wb-starter/

Tell me where I'm wrong. 👇'm wrong. 👇