Vanilla JavaScript — Why It Still Matters in the Age of React and Next.js
In modern web development, it's easy to feel like JavaScript alone is no longer enough.
You open GitHub or LinkedIn and see:
React.
Next.js.
Vue.
Angular.
TypeScript.
Vite.
And sometimes dozens of libraries that a project seems to need before you even write your first line of code.
So beginners often ask:
"If all these tools exist, why should I learn Vanilla JavaScript?"
It's a reasonable question.
But the problem is that many developers learn the tools built on top of JavaScript before understanding the language those tools are built on.
It's like learning to drive a modern car without understanding the basics of controlling a vehicle.
You may be able to drive.
But when something unexpected happens, it becomes much harder to understand why.
What Does Vanilla JavaScript Mean?
Vanilla JavaScript isn't a different programming language.
It's simply a term developers use when they mean JavaScript without a framework or library such as React or Vue.
For example:
const button = document.querySelector("#btn");
button.addEventListener("click", () => {
console.log("Button clicked");
});
That's Vanilla JavaScript.
No React.
No Vue.
No jQuery.
Just JavaScript and the Web APIs provided by the browser.
Why Does a React Developer Need Vanilla JavaScript?
Because React doesn't replace JavaScript.
React is built with JavaScript and runs within the JavaScript ecosystem.
When you write:
const result = users.filter(user => user.age > 18);
you're using JavaScript.
When you write:
const names = users.map(user => user.name);
you're using JavaScript.
And when you work with:
Promise
async
await
fetch
map
filter
reduce
objects
arrays
destructuring
modules
closures
you're working with JavaScript.
React provides a way to organize and build user interfaces.
It doesn't replace the language itself.
The Problem Starts When You Learn a Framework Before the Language
Imagine someone starts learning development like this:
HTML
↓
React
↓
Next.js
↓
Node.js
↓
MongoDB
They can build a beautiful page.
But when they encounter:
const result = users.filter(user => user.age > 18);
they don't know why filter works.
Or:
const newUser = {
...user,
active: true
};
they don't understand Spread Syntax.
Or:
const data = await fetch("/api/users");
they don't understand what await actually does.
That's when the problem becomes clear.
A developer can use a framework without truly understanding the language underneath it.
A Framework Is Not a Replacement for Fundamentals
Frameworks solve important problems.
React, for example, helps developers build user interfaces in a structured and reusable way.
Next.js adds a large set of capabilities on top of React for building web applications.
But when something goes wrong inside these tools, you often end up going back to JavaScript.
This happens all the time.
The problem might involve:
- Scope
- Closures
- Objects
- Arrays
- References
- Asynchronous JavaScript
- Promises
- Event Loop
- Modules
- DOM
- Browser APIs
The stronger your JavaScript foundation is, the easier frameworks become.
Vanilla JavaScript Forces You to Understand What Is Happening
When you use a framework, many details are organized or abstracted away from you.
That's a good thing.
But when you work with Vanilla JavaScript, you are forced to interact with things such as:
document.querySelector();
addEventListener();
classList.add();
fetch();
localStorage;
setTimeout();
This helps you understand the relationship between JavaScript and the browser.
You're not just learning how to write code.
You're learning about the environment in which that code runs.
The DOM Is Not JavaScript
This is a very important distinction.
Many beginners assume that:
document.querySelector();
is part of the JavaScript language itself.
The reality is more precise.
JavaScript is a programming language.
document, window, localStorage, fetch, and many other APIs are provided by the environment in which JavaScript runs.
In a browser, you have Web APIs.
In Node.js, you have a different set of APIs.
Understanding this distinction becomes increasingly important as you go deeper into JavaScript.
A Simple Example
Suppose we have a button:
<button id="btn">Click me</button>
We can interact with it using Vanilla JavaScript:
const button = document.querySelector("#btn");
button.addEventListener("click", () => {
alert("Hello!");
});
Several things are happening here:
- JavaScript gets a reference to the element.
- The browser provides the
documentAPI. - We register an event listener.
- The browser waits for a
clickevent. - When the event occurs, the callback function runs.
Once you understand this process, many React concepts become easier to understand.
React Doesn't Make These Concepts Disappear
When you write:
function Button() {
return (
<button onClick={() => console.log("Clicked")}>
Click me
</button>
);
}
it may look completely different.
But the underlying ideas haven't disappeared.
You still have:
- JavaScript
- Functions
- Events
- Callbacks
- Objects
- State
- Asynchronous behavior
React provides a different abstraction and structure for building user interfaces.
But JavaScript is still underneath it.
Vanilla JavaScript Teaches You to Solve Problems Before Reaching for a Library
There is a common habit among some developers:
"I need to do X, so I'll find a library that does X."
That isn't always wrong.
The problem starts when it becomes the only solution.
A good developer asks first:
"Do I actually need a library for this?"
Sometimes the problem is extremely simple.
For example:
const uniqueUsers = [...new Set(users)];
You don't need a library just to remove duplicate values.
Or:
const activeUsers = users.filter(user => user.active);
You don't need a library to filter data.
Or:
const userNames = users.map(user => user.name);
You don't need a library to extract values from an array.
Understanding JavaScript reduces your dependence on libraries for simple problems.
But This Doesn't Mean Vanilla JavaScript Is Always Better
This is where we need to be realistic.
I'm not saying:
"Don't use React."
And I'm not saying:
"Vanilla JavaScript is better than frameworks."
That's not true.
As an application grows, manually managing the UI, state, and component structure can become complicated.
That's where frameworks and libraries become valuable.
The problem isn't using tools.
The problem is using them without understanding the problem they're solving.
When Should You Use Vanilla JavaScript?
Vanilla JavaScript is excellent for projects such as:
- Simple interactive websites
- Landing pages
- Small tools
- Scripts
- Widgets
- Prototypes
- Educational projects
- Projects that don't require a framework
It's also excellent for learning.
Because you interact directly with JavaScript and the browser.
When Do You Need React or a Framework?
As a project grows, you may need:
- Component Architecture
- State Management
- Reusable UI
- Routing
- Complex Interactions
- Data Fetching
- Large Application Structure
At that point, frameworks such as React and Next.js can become a logical choice.
But using these tools doesn't make understanding JavaScript less important.
It makes it even more important.
Vanilla JavaScript Is Not a Phase You Should Leave Behind
Sometimes Vanilla JavaScript is treated as a temporary stage:
JavaScript
↓
React
↓
Forget JavaScript
But the better path looks more like:
JavaScript
↓
Deep JavaScript Understanding
↓
React
↓
Next.js
↓
Full Stack
Each stage builds on the previous one.
You don't move from JavaScript to React so that you can forget JavaScript.
You move to React because you're ready to use a higher-level tool.
What Should You Understand Before React?
You don't need to become an expert in everything.
But you should be comfortable with:
Variables
Data Types
Functions
Arrays
Objects
Destructuring
Spread Syntax
Rest Parameters
Array Methods
Scope
Closures
this
DOM
Events
Promises
async/await
Fetch API
Modules
Error Handling
Once you start learning React, many concepts will already feel familiar.
The Best Way to Learn Vanilla JavaScript
Don't just watch tutorials.
Build small projects.
Todo List
You'll learn:
- DOM
- Events
- Arrays
- Objects
- Local Storage
Weather App
You'll learn:
- Fetch
- Promises
- Async/Await
- APIs
- Error Handling
Quiz App
You'll learn:
- State-like logic
- Events
- Arrays
- Objects
- Conditional Rendering
Expense Tracker
You'll learn:
- Data manipulation
- Forms
- Local Storage
- Array methods
After building these projects, React will feel much less mysterious.
JavaScript First, Tools Second
One of the biggest challenges in the modern JavaScript ecosystem is the sheer number of tools.
Every week, a new library may appear.
A new framework.
A new tool.
A new way of building applications.
If you try to memorize all of them, you'll enter a race that never ends.
But if you understand JavaScript well, you can learn new tools much faster.
Because you aren't starting from zero.
You're simply learning:
How to use a new tool to solve a problem you already understand.
Conclusion
Vanilla JavaScript isn't a competitor to React.
And it's not an outdated technology that should be discarded.
It's the foundation that makes React, Node.js, Next.js, and the rest of the JavaScript ecosystem easier to understand.
You can learn a framework without deeply understanding JavaScript.
You may even be able to build a working application.
But when something unexpected happens, you'll often find yourself searching for a ready-made solution instead of understanding the underlying cause.
When your foundation is strong, frameworks become tools.
And that's the real goal.
Don't learn JavaScript just so you can use React.
Learn JavaScript so you can understand what React is doing when you use it.
In the end, the best developer isn't the person who knows the largest number of libraries.
It's the person who understands the problem, knows when to use JavaScript directly, knows when a higher-level tool is needed, and—most importantly—understands why.
Top comments (0)