What Is Vanilla Js
Vanilla JS is not a new idea. It has been a running joke, a counter-movement, and a legitimate architectural choice for decades. Here is what it actually means.
In the previous post I made the case that knowing vanilla JS gives you a choice. But before going further, it is worth pinning down what the term actually means, because it gets used loosely.
The Essentials
- Vanilla: In software, "vanilla" means the plain, unmodified base. No added libraries, no framework flavor on top. The term comes from Italian gelato, where vanilla is the base most ice creams are built from.
- It is a spectrum, not a binary: Using TypeScript still requires a compiler. Using a date library adds a dependency. Vanilla exists on a range from "zero dependencies" to "no full UI framework."
- The meaningful distinction: Whether you have handed control of your component model, rendering cycle, and state management to a framework, or whether your code talks directly to the browser's own APIs.
Where the Name Came From
Before diving into anything technical, the name deserves an explanation, because it is not obvious.
In Italian gelato culture, vanilla is the base flavor. Every creamy ice cream starts from vanilla and then something is added on top. Chocolate gelato is vanilla with chocolate. Pistachio is vanilla with pistachio. The plain base is called vanilla because it is what everything else builds from.
Software borrowed this word the same way. When developers say "vanilla JavaScript," they mean: the plain base, nothing added. Not React on top. Not Angular on top. Just JavaScript as the browser ships it.
A Fake Framework That Made a Real Point
Around 2010 to 2012, a website called vanilla-js.com appeared. It read exactly like a serious framework landing page. It had a headline calling the library "fast, lightweight, and cross-platform." It listed famous companies using it. It had a download configurator where you could select modules: AJAX, Functions, Math Library, Regular Expressions.
The byte count for everything selected was 0.
That was the joke. The whole site was aimed at the jQuery era, when adding a framework was the first thing you did on any project regardless of whether you needed it. The punchline was that "Vanilla JS" was already in the browser. You did not need to download anything.
What makes it worth remembering is that the same pattern shows up again and again. jQuery dominated, then fell out of favor. Backbone came and went. Angular 1.x was the obvious choice for years. Now React is the default. Each time, a segment of the developer community forms a counter-movement pointing out that a lot of what the framework does can be done with the platform directly.
We are in that moment again.
It Is a Spectrum
The definition matters here: vanilla JavaScript is "the usage of the core language and browser APIs to create web apps without any additional libraries or frameworks added on top."
Notice it says frameworks and libraries, not any dependency at all. This is not an extreme position. You can use TypeScript and still be working in a vanilla approach, because TypeScript is a compiler that produces plain JavaScript. You can use a small utility library for date formatting. The point is not purity for its own sake. It is the decision not to hand your rendering and component model to an external framework.
In practice, "vanilla JS" usually means: no React, no Angular, no Vue, no Svelte in the driver's seat. What you bring in beyond that is a judgment call based on the project.
Further Reading and Watching
- MDN: JavaScript - The full language reference, starting from the platform itself with no framework assumed.
- Web Platform Tests - A cross-browser test suite for the web platform APIs you use when writing vanilla JavaScript.
Video:
- Is Vanilla JavaScript Worth Learning? by Traversy Media. A practical discussion on when going without a framework makes sense.