The Hammer Problem

There is a version of a developer who has learned React thoroughly, built real things with it, and genuinely understands its patterns. When they start a new project, they reach for React. That makes complete sense.

There is another version who has learned React but never understood what came before it, or what it sits on top of. When they start a new project, they also reach for React. But for a completely different reason. It is the only thing they know.

From the outside, these two people look the same. But they are not.

The Essentials

1. Vanilla JavaScript: The core language and browser APIs used directly, without additional libraries or frameworks on top.
2. DOM API: The set of functions and properties browsers expose so JavaScript can read and manipulate the page structure.
3. Informed choice vs. default choice: Using a framework because you decided to is different from using it because you never considered anything else.
4. Micro-apps: Small, single-purpose web tools that deploy instantly and often need no framework overhead at all.

---

When All You Have Is a Hammer

I have seen blogs built with Create React App. Not because the developer decided a blog needed client-side rendering, a virtual DOM, and a component tree. But because when you only know one tool, every problem looks like a nail for that tool.

This is not a new problem. Around 2010 to 2012, the same thing happened with jQuery. You would start a new project, create index.html, and the next line was a <script> tag for jQuery. Did not matter what you were building. jQuery went in. That was just how web development worked at the time.

We are in the same moment right now, with a different set of libraries.

The problem is not that people use frameworks. Frameworks are genuinely good tools that solve real problems. The problem is when you cannot not use them. When the choice has been made by default before you have even thought about the project.

What You Gain From Knowing the Platform

When I first started understanding what browsers actually expose to JavaScript, the DOM API, the History API, the Fetch API, custom events, something clicked that I had been missing.

Frameworks are not changing the browser's engine. They are sitting on top of the same APIs that you and I have direct access to. React, Angular, Vue, Svelte: they all ultimately call the same document.createElement, the same addEventListener, the same innerHTML assignments you can write yourself.

That means two things:

First, when you understand the platform, you understand why frameworks make the decisions they make. Why React's reconciler batches DOM updates. Why Vue's reactivity system uses Proxies. Why Angular has its own change detection cycle. These are not magic. They are design choices layered on top of known APIs. You can read those choices and understand them rather than just accepting them.

Second, you can make real decisions. Not "which framework do I use?" but "do I need a framework at all?" Sometimes the answer is obviously yes. A complex dashboard with shared state and real-time updates probably benefits from a framework. But sometimes the answer is no, and having that option changes what you build and how fast you ship it.

The Era We Are Actually In

There is a shift happening that makes this more relevant than it has been in years. The web is moving back toward server-rendered content. React's own documentation now steers toward frameworks like Next.js rather than pure client-side rendering, because the performance cost of shipping megabytes of JavaScript to parse and execute before the user sees anything has become impossible to ignore.

At the same time, we are in an era of micro-apps: small, specific tools that do one thing, deployable in minutes, optionally installable as PWAs. For these, the overhead of a full framework is genuinely wasteful.

Understanding vanilla JS does not mean writing every project without React. It means having the judgment to know when React is the right call and when it is not. That is the difference between a developer who uses tools and one who chooses them.

Further Reading and Watching

• The cost of JavaScript in 2019 by Addy Osmani at Google. The numbers on parsing and execution overhead are still directionally relevant today.
• MDN: Web APIs - An index of everything the browser exposes natively before any library is involved.

Video:

• JavaScript DOM Crash Course - Part 1 by Traversy Media. A practical walkthrough of the APIs that frameworks wrap.