Why we still write vanilla JavaScript in 2026

We last reached for React on a greenfield project in early 2022. Since then every new build, internal and client-facing, has shipped on vanilla JavaScript with a small set of in-house utilities. We get asked about this on every sales call, so it is worth writing down.

§ 1.0 — The decision in one paragraph

The applications we build are not single-page apps. They are server-rendered PHP pages with islands of behaviour on top: a search dropdown, a dispatch grid, a checkout flow. For that shape of work, a framework adds a build step, a bundle, a hydration cost, and a hiring filter, in exchange for ergonomics we can replicate with two hundred lines of plain JavaScript.

§ 2.0 — What we actually ship

Three things, in this order:

• A 4 KB utility for selectors, event delegation, and small reactive updates.
• Per-feature modules that import only what they need. No global state.
• Native fetch, native form events, native dialog elements where possible.

The total JavaScript shipped to a logged-in admin page on our largest production system is 38 KB gzipped. The same dashboard rebuilt as a React/SPA prototype was 287 KB. Both render under 200 ms on a mid-tier Android.

§ 3.0 — When we would change our minds

We are not framework purists. If a project needed deeply nested reactive state — a Figma-like canvas, a spreadsheet, a real-time multiplayer editor — we would reach for Solid or Vue without hesitation. We are not arguing that vanilla is universally correct. We are arguing that for the shape of system most of our clients ship, it is the right answer and the cost of being wrong is low.

§ 4.0 — What this changes for the client

Three concrete things:

1. Future maintenance does not require hiring a specialist. Any PHP-comfortable engineer can read the codebase.
2. The browser does the work the browser was designed to do.
3. The bundle is small enough that we never debate whether to lazy-load it.

None of these are revolutionary. They add up.