What is "Why Vanilla Js" about?

Libraries sit on top of the same DOM APIs you can use directly. Understanding the platform makes you better at everything, including the frameworks you already use.

What topics does "Why Vanilla Js" cover?

This article covers: why vanilla javascript, javascript performance, dom api advantages, frontend without framework.

Why Vanilla Js

In the last post I laid out what vanilla JavaScript actually means and where the term came from. Now the more important question: why should you bother learning it today, when frameworks are so good and so widely adopted?

The Essentials

Libraries use the same APIs you can use directly: No framework changes the browser's engine. Every React render ultimately calls createElement, appendChild, and textContent, just like you can.
Understanding the platform makes you better at frameworks: When you know what React is doing underneath, you can write better React, not just better vanilla code.
Performance overhead is real: Enterprise apps regularly ship 5 megabytes of JavaScript. Parsing and executing that payload blocks rendering. Vanilla eliminates that category of problem.
The fears are mostly overblown: Routing, state management, components, and scalability are all achievable in vanilla JS. The learning curve is lower than most developers assume.

Why This Matters Now

A few years ago, if you wanted to argue for vanilla JavaScript you were fighting an uphill battle. Frameworks solved real problems and the performance delta was acceptable for most projects.

Two things have shifted.

First, React's own documentation quietly changed. The recommendation moved away from "use Create React App for your client-side app" toward "use a framework like Next.js." The reason is performance. Client-side rendering means the user downloads, parses, and executes your entire JavaScript bundle before seeing anything. On a low-end device or a slow connection, that delay is measurable and frustrating. The push toward server-side rendering is a correction for years of over-reliance on client-side frameworks.

Second, we are in an era of micro-apps. Specific tools, deployed instantly to a URL, optionally installable as PWAs. For something that does one thing and weighs 50 kilobytes, pulling in React adds friction with no benefit.

What the Benchmark Numbers Actually Mean

There is a well-known performance benchmark table that compares JavaScript UI libraries across operations like creating rows, replacing rows, and clearing lists. Vanilla JavaScript consistently lands at the top or very near it.

This should not be surprising. Any library that runs in the browser is JavaScript. It cannot be faster than JavaScript itself. It is JavaScript. Everything it does eventually reaches the same DOM APIs you can call directly. The overhead is the library's own logic: diffing, component lifecycle tracking, event delegation layers, reactivity systems.

None of that overhead is inherently wrong. When your app is complex enough to benefit from a virtual DOM diffing algorithm, the overhead is worth paying. But it is useful to know you are paying it, and to know what the baseline looks like without it.

What You Actually Gain

The argument for learning vanilla JS is not "you should abandon React." It is more specific than that.

You understand what your library is doing. When a new version of React ships with a new API, you can look at it and understand why that choice was made. When something behaves unexpectedly, you can reason about it from first principles rather than guessing.

You can get out of your library when you need to. Hardware access, platform APIs, third-party integrations: sometimes you need to write code that bypasses the framework and talks directly to the browser. Knowing what that layer looks like is essential.

You can mix approaches. React does not need to own your entire page. A React widget can live inside a vanilla JS app. A vanilla JS component can sit inside a React tree. When you understand both sides, you can make that call.

You get a simpler starting point for the right projects. No CLI. No build process. No node_modules folder. An HTML file, a JavaScript module, and a URL that works. That is a real option that most developers forget they have.

The Fears Are Mostly Overblown

Developers consistently cite routing, state management, and lack of components as the main worries about going vanilla. These concerns are real but much more tractable than people assume.

Routing without React Router is not hard. The History API is straightforward. State management without Redux is a well-understood problem with clean solutions. Components in the form of Web Components are a browser standard with solid cross-browser support.

We will work through each of these in the posts ahead. What you will find is that the concepts are familiar. The implementation without a framework is different, but it is not significantly more complex.