Vanilla JavaScript and Native DOM APIs as an Alternative to React and Other Frameworks
Contents
Vanilla JavaScript and Native DOM APIs as an Alternative to React and Other Frameworks
Modern frontend architecture frequently defaults to complex single-page application (SPA) frameworks like React, Angular, or Vue, even for straightforward user interfaces and modular SaaS tools. However, the overhead introduced by large runtime bundles, virtual DOM diffing algorithms, and heavy JavaScript re-hydration directly penalizes Core Web Vitals—specifically Interaction to Next Paint (INP) and Largest Contentful Paint (LCP). Modern browsers provide native DOM APIs and Web Components that render heavy pre-made frameworks technically redundant for pragmatic, high-performance web engineering.
1. The Performance Cost of Virtual DOM and JavaScript Bundle Bloat
Frameworks rely on an abstraction layer called the Virtual DOM to batch and calculate layout updates before applying them to the real Document Object Model. While historically beneficial for mitigating slow browser rendering engines, modern rendering pipelines process direct DOM manipulations with exceptional speed. Introducing a virtual representation creates measurable disadvantages:
- Memory and CPU Overhead: Maintaining duplicate tree representations in memory forces the JavaScript engine to perform CPU-intensive reconciliation loops on every state change.
- Main-Thread Blocking: Large JavaScript bundle evaluation and client-side hydration block the browser main thread, delaying interactivity and downgrading INP scores across mobile devices.
2. Modern Native DOM APIs and Web Components
The ECMAScript specification and modern browser engines now natively supply the modular features that previously required third-party libraries. Building interfaces in clean Vanilla JavaScript allows leveraging robust browser standards directly:
- Custom Elements & Shadow DOM: Native Web Components allow encapsulating HTML, CSS, and interactive logic into reusable tags without external dependencies or build-step compilation.
- HTML
<template>Tags: Browser-native cloning of DOM fragments executes instantaneously without requiring JSX transpilation or client-side templating engines. - Event Delegation: Attaching unified event listeners to parent containers eliminates memory leaks and simplifies dynamic element management.
// Example: Pragmatic UI component rendered cleanly via native DOM cloning
class CustomStatusBadge extends HTMLElement {
connectedCallback() {
const status = this.getAttribute('data-status') || 'idle';
this.innerHTML = `
<span class="badge badge-${status}">
<span class="dot"></span> Status: ${status.toUpperCase()}
</span>
`;
}
}
customElements.define('status-badge', CustomStatusBadge);3. Maximizing Core Web Vitals Through Zero-Dependency Architecture
Pragmatic engineering prioritizes delivery speed and deterministic code execution over framework abstraction layers. Eliminating multi-kilobyte vendor libraries ensures that web pages parse, execute, and render immediately upon HTML delivery. Combining native DOM selectors (querySelector), CSS Grid layouts, and Vanilla JavaScript controllers creates highly responsive, maintainable SaaS user interfaces that achieve perfect Core Web Vitals metrics without architectural complexity.
Summary
Modern browser engines no longer require heavy JavaScript frameworks to construct responsive, maintainable user interfaces. Relying on Vanilla JavaScript, native Web Components, and direct DOM manipulation eliminates bundle bloat, prevents main-thread blocking, and ensures superior Core Web Vitals performance across all devices.
Sources
Related articles
2 comments
Agreed on the general point, and the INP argument is the one that tends to convince people who do not care about bundle sizes.
A detail in the example bothers me, though.
CustomStatusBadgeinterpolatesdata-statusstraight intoinnerHTML. In a page where that attribute is written from server data, that is an injection path. Is the example shorthand for brevity, or is there a reason the native route is safe here?Shorthand, and the objection is correct — it deserves saying plainly rather than being left in a code sample.
An attribute read from a component and written into
innerHTMLis parsed as markup, so any value that reaches it from a request, a database or a URL is executable in that position. Nothing about custom elements changes that; the parser is the same one the framework would have used. The version without the hole is not longer: a class name for the variant,textContentfor the text, and the markup assembled withcreateElementor cloned from a<template>.That is also the honest reading of the wider argument. Frameworks escape interpolated values by default, and dropping the framework means taking that responsibility back rather than inheriting it. It is a small, well-understood responsibility — one rule, applied wherever a value meets markup — but an article recommending the native route should hand it over explicitly instead of demonstrating the shortcut.