I Tried Writing Vanilla JavaScript for 30 Days — Here’s What Happened

React made me faster. Vanilla JavaScript made me better.

For the past four years, most of my JavaScript has lived behind abstractions.

React components.

Next.js routing.

State management libraries.

Custom hooks.

Build tools.

TypeScript.

The modern frontend stack is designed to make you productive without thinking too much about what the browser is actually doing.

And for the most part, that’s a good thing.

Nobody wakes up excited to manually attach DOM event listeners or write their own state synchronization logic.

But a month ago, I started noticing something uncomfortable.

I could solve complex product problems quickly.

I could ship features.

I could architect systems.

Yet every now and then I would open Chrome DevTools during a production incident and realize I was reasoning about abstractions instead of the platform underneath them.

That bothered me.

So I created an experiment.

For 30 days, every side project, utility, dashboard, and browser tool I built would use only Vanilla JavaScript.

No React.

No Vue.

No Svelte.

No framework.

Just JavaScript, the DOM, and whatever pain the browser decided to inflict upon me.

I expected nostalgia.

What I got instead was a reminder of why senior developers often debug framework problems faster than framework specialists.

The First Week Was Humbling

Frameworks quietly solve an enormous number of problems.

You don’t realize how many until they’re gone.

A simple modal suddenly becomes a lesson in focus management.

A dynamic list becomes an exercise in DOM reconciliation.

A loading spinner becomes state management.

A search box becomes event handling.

A dropdown becomes accessibility.

Everything feels simple until you have to build it yourself.

One afternoon I found myself writing code that React developers never think about anymore.

button.addEventListener("click", () => {
  state.isOpen = !state.isOpen;
  render();
});

Nothing impressive.

In fact, it looks almost primitive.

But after a few days, something interesting started happening.

I became painfully aware of every render.

Every DOM update.

Every event listener.

Every piece of state.

The browser stopped feeling like a black box.

It started feeling like a machine again.

And machines are easier to debug than magic.

The Hidden Cost of Framework Comfort

Modern frontend development trains you to think in components.

The browser thinks in documents.

That distinction sounds philosophical until performance issues show up.

One project in my experiment displayed several thousand rows of live-updating data.

My first instinct was framework thinking:

“How do I efficiently re-render this?”

The browser had a different answer.

“Why are you re-rendering it at all?”

Instead of replacing DOM nodes, I started updating only the text that changed.

priceElement.textContent = latestPrice;

That’s it.

No virtual DOM.

No diffing.

No memoization.

No optimization discussions in pull requests.

Just updating exactly what changed.

The result was faster than I expected.

Not because Vanilla JavaScript is magically faster.

Because writing Vanilla JavaScript forces you to confront unnecessary work.

Frameworks can hide waste.

The browser cannot.

Event Delegation Is Criminally Underrated

One lesson appeared over and over.

Most frontend developers underestimate how expensive complexity becomes at scale.

Consider a table with thousands of interactive rows.

Many developers instinctively do this:

rows.forEach(row => {
  row.addEventListener("click", handleClick);
});

It works.

Until the table becomes large.

Until rows are dynamically added.

Until memory usage starts creeping upward.

Until debugging becomes annoying.

The Vanilla JavaScript solution is often simpler.

table.addEventListener("click", event => {
  const row = event.target.closest(".row");

  if (!row) return;

  handleClick(row);
});

One listener.

Infinite rows.

Less code.

Less memory.

Fewer problems.

The funny thing is that understanding event delegation makes you better at React too.

Because the lesson isn’t about DOM APIs.

It’s about understanding how events actually flow through a system.

The implementation changes.

The mental model survives.

I Finally Understood Why Some Bugs Feel Impossible

There is a specific category of frontend bug that junior developers struggle with.

The bug appears random.

Intermittent.

Impossible to reproduce.

The root cause is usually timing.

Not logic.

Timing.

During the experiment, I spent far more time dealing directly with the event loop than I normally would.

Promises.

Microtasks.

Rendering cycles.

Browser scheduling.

Animation frames.

And once you start looking closely, you realize many “framework bugs” are actually JavaScript timing bugs wearing framework clothing.

A state update arrives later than expected.

A DOM measurement occurs before layout finishes.

A network response races another request.

An animation frame executes after assumptions have already become invalid.

The framework didn’t create those problems.

It merely inherited them from the platform.

Understanding the platform changes how you debug everything built on top of it.

The Browser Is More Capable Than Most Developers Think

The JavaScript ecosystem has a habit of solving yesterday’s problems.

Sometimes we continue using abstractions long after browsers no longer need them.

During the month, I replaced several small libraries with native APIs.

Not because dependencies are bad.

Because I wanted to see how much the platform had evolved.

The answer surprised me.

Modern browsers already provide:

• Efficient DOM querying
• URL parsing
• State persistence
• Animations
• Observers
• Fetching
• Streams
• Internationalization
• Form validation

The platform has quietly become extremely powerful.

Many developers still carry mental models from 2018.

The browser moved on.

The Most Valuable Lesson Had Nothing to Do With Code

Around day twenty, I noticed something unexpected.

My debugging speed improved.

Not slightly.

Noticeably.

Production debugging is mostly an exercise in building accurate mental models.

The closer your mental model is to reality, the faster you find the problem.

Frameworks provide useful abstractions.

But every abstraction creates distance.

Sometimes that distance helps.

Sometimes it hides the thing you actually need to understand.

A senior engineer once told me something that sounded obvious at the time.

I didn’t appreciate it until this experiment.

The fastest debugger in the room is usually the person closest to how the system actually works.

That’s true for databases.

It’s true for operating systems.

And it’s definitely true for JavaScript.

Would I Abandon React?

Absolutely not.

React solves real problems.

So does Next.js.

So does TypeScript.

The productivity gains are undeniable.

This experiment wasn’t about replacing modern tooling.

It was about understanding what the tooling is replacing.

There’s a difference.

Developers sometimes treat Vanilla JavaScript as something you graduate from.

As if learning React means you’ve moved beyond it.

The opposite is often true.

The deeper your JavaScript knowledge becomes, the more valuable frameworks become because you understand their trade-offs instead of merely accepting them.

You know when they’re helping.

You know when they’re hurting.

And perhaps most importantly, you know where to look when everything catches fire at 2:13 AM after a deployment.

What Happened After 30 Days

I went back to React.

I went back to TypeScript.

I went back to modern tooling.

But I didn’t return as the same developer.

Frameworks felt less magical.

Performance discussions felt clearer.

Debugging felt easier.

Architecture decisions felt more grounded.

The biggest surprise wasn’t that Vanilla JavaScript made me appreciate JavaScript.

It made me appreciate frameworks more accurately.

Because the best developers aren’t the ones who memorize the most framework APIs.

They’re the ones who understand what exists underneath them.

AI can generate React components.

It can scaffold Next.js applications.

It can produce TypeScript types.

What it cannot do is build the intuition that comes from spending a month staring directly at the machinery.

And in a world increasingly filled with generated code, that intuition is becoming more valuable, not less.

The browser is still there beneath every abstraction.

Spend enough time with it, and you’ll discover something strange.

Most of the frontend skills that compound over a career live much closer to the platform than the framework.