What the Browser Already Does Without a Framework

Frontend frameworks solve real application problems. They are less convincing when a mostly static company site uses one to recreate links, forms, responsive layout, and a menu the browser already understands.

I like treating the browser as the first framework. It has routing, form submission, UI controls, layout, state selectors, image selection, preferences, caching, and an accessibility model built in.

Links and forms are working infrastructure

<a href="/contact/">Contact</a>

This supports navigation, history, opening in a new tab, copying the address, and browser status previews. A click handler that changes window.location rebuilds a worse version.

A form can send data without client-side state:

<form action="/contact/" method="post">
  <input name="email" type="email" required>
  <button type="submit">Send</button>
</form>

JavaScript can improve feedback later while the basic contract remains usable.

HTML and CSS already contain components and state

<details>, <dialog>, and popovers provide native starting points for common interactions. CSS handles responsive grids, container queries, sticky positioning, focus styles, and user preferences.

State is not limited to a JavaScript store:

details[open] { ... }
input:checked { ... }
button:focus-visible { ... }
.field:has(input:invalid) { ... }

The browser also selects responsive image candidates from srcset, honours reduced-motion and colour-scheme preferences, and manages HTTP caching. Using those features means less application code must observe and reproduce them.

Native accessibility is a head start, not a guarantee

A real button has semantics, focus, and keyboard activation. A clickable <div> needs those rebuilt. Native elements can still be labelled or styled badly, but beginning with the correct control removes avoidable work.

Applications still justify application tools

Complex shared state, real-time collaboration, rich editors, and large product teams can make a framework valuable. The point is not to reject frameworks. It is to stop assuming a company homepage becomes an application because it has a navigation menu and contact form.

My preferred order is to build the document and native interaction first, add CSS, then write the JavaScript required by the remaining behaviour. Fewer layers can mean fewer dependencies, smaller downloads, and a page that keeps working when one enhancement fails.

The browser keeps gaining features. Before installing another abstraction, I check whether the platform has already made the problem boring. Boring, in this case, is quite good.

← Back to all articles