English
Deutsch
PolskiVanilla 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 event listeners to parent containers reduces the number of listeners. Child elements can then be added or removed without attaching or detaching their own listeners.
// Example: Pragmatic UI component with fixed innerHTML markup and textContent (light DOM, no Shadow DOM)
class CustomStatusBadge extends HTMLElement {
connectedCallback() {
const status = this.getAttribute('data-status') || 'idle';
this.innerHTML = `
<span class="badge">
<span class="dot"></span> Status: <span class="label"></span>
</span>
`;
this.firstElementChild.className = `badge badge-${status}`;
this.querySelector('.label').textContent = status.toUpperCase();
}
}
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.
Questions and answers
Why does the CustomStatusBadge example keep data-status out of innerHTML?
If the attribute comes from server data, inserting it there would create an injection path. That risk needs an explicit explanation alongside the code sample.
An attribute value written into innerHTML is parsed as HTML. If that value comes from a request, a database or a URL, it can inject markup and script at that position. Custom elements do not change this: innerHTML uses the same HTML parser. The safe version shown in the example uses no more code: it puts only fixed markup in innerHTML, uses a class name for the variant and sets the text with textContent. Building markup with createElement or cloning it from a <template> works just as well.
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 — and an article recommending the native route should hand it over explicitly instead of demonstrating the shortcut, which is why the example applies it.
Sources
Related articles
