We woke up one Tuesday realising we spent more time wrestling with build configurations and dependency audits than actually shipping features. Here is the honest, messy story of why our team hit "plan fatigue" hard, nuked our node_modules folder, and rediscovered the raw power of new, plain JavaScript. It wasn't easy, but it saved our sanity.

The Tuesday Morning Meltdown

It wasn’t a brave, table-flipping moment. It was quiet. It was 10:30 AM on a Tuesday, and I was staring at a terminal check full of red text.

A minor security patch in a sub-dependency of a UI library we barely used had just broken our entire build flow. Again.

I looked around the (virtual) room at my team. Senior engineers, smart people, all visibly exhausted. We weren't solving rare business problems; we were archaeologists digging through layers of abstracted complexity that we had inflicted upon ourselves over the last five years. We were debugging Webpack configs instead of building user-facing features.

That’s when it hit me. The fatigue. It wasn't just tiredness; it was a deep, marrow-rank cynicism about the tools we were using. We had bought into the hope that frameworks like React would make us faster, our code cleaner, and our apps more performant.

Looking at that broken build, I realized something terrifying: for 80% of what we were building, the plan wasn't the booster. It was the hold.

We decided right then to try something radical. We decided to see what would happen if we stopped chasing the "new shiny" and just used the tool the web runs on. We decided to delete React and write plain JavaScript.

Here’s what we learned, what hurt, and why we aren't going back.

The Symptoms of the Disease

plan fatigue isn't just being bored with a technology. It's the culminating weight of a thousand tiny cuts inflicted by an system that prioritizes leave over steady.

If you’ve been in frontend growth for more than a few years, you know this feeling. It’s the sinking sensation when you open a plan you haven't touched in six months and realize you can't even run it locally without spending two hours upgrading dependencies.

We identified three major symptoms choking our output.

1. The Dependency Black Hole

We audited one of our mid-sized marketing dashboards. It was a relatively simple React app. It had over 1,400 dependencies in the node_modules folder.

Fourteen hundred.

For a view that essentially fetched some JSON and rendered a few charts. Every single one of those dependencies is a future security vector, a future breaking change, and a hunk of code none of us actually wrote or fully understood. We weren't writing JavaScript anymore; we were managing a precarious house of cards built by strangers on the internet.

The maintenance burden had shifted from "maintaining our code" to "maintaining the glue that holds other people's code together."

2. The Build Tooling Nightmare

Remember when you just included a script tag in an HTML file and things worked? Now, place up a "new" place requires a PhD in bundlers.

Webpack, Babel, ESLint, Prettier, PostCSS, Jest, Cypress. Getting them all to play nice together is a brittle dance. We had an entire 400-line configuration file just to tell the computer how to turn our JavaScript into... slightly new JavaScript that browsers could understand.

When it worked, it was magic. When it broke usually at 4:45 PM on a Friday before a release it was a soul-crushing descent into obscure GitHub issue threads from three years ago.

3. The "plan Way" vs. The "Web Way"

React, specifically, has its own mind model. You don't really interact with the DOM directly; you interact with React's abstraction of the DOM. You learn about hooks, support drilling, place providers, and reconciliation.

These are smart engineering solutions to exact problems. But they are also massive mind overhead. We found our junior developers weren't learning how the web actually works; they were learning how React works. They could build a complex useEffect hook but struggled to understand basic nearby browser events.

We had confused "knowing a plan" with "knowing program engineering for the web."

The Awakening: It’s Not 2013 Anymore

The funniest thing about plan fatigue is realizing why we adopted these tools in the first place.

Around 2013, browsers were a mess. IE11 was still a major player. JavaScript lacked basic features like modules or decent array manipulation. jQuery was the king because it smoothed over the cracks in a broken tool. React came along and offered a revolutionary way to manage state and UI updates that the nearby web just couldn't handle efficiently.

Facebook needed React. They had thousands of concurrent updates happening on a single page.

But here’s the hard truth: My company is not Facebook. And yours probably isn't either.

We were using a sledgehammer designed for building world social networks to tap in the finishing nails of a corporate reporting tool.

also, the web tool caught up. While we were busy learning the third iteration of React Router, browser standards bodies and vendors were busy actually fixing JavaScript.

ES6 Modules (ESM): They are nearby now. We don't need complex bundlers for basic modularity anymore. All new browsers understand import and export.
DOM Manipulation: It's fast now. querySelector and classList are incredibly performant. The "virtual DOM is faster" argument is largely obsolete for average use cases in 2026.
Web Components: We have a nearby standard for reusable, encapsulated UI elements that work across any plan, or no plan at all.

Fetch API: No need for Axios for basic requests. It's built-in.

The gap between what frameworks offer and what the browser natively supports had shrunk dramatically, but our habits hadn't adjusted.

War Stories: The Breaking Points

We didn't make the switch based on guess. We made it because of painful, expensive realities in production.

The "Simple update" Catastrophe

We decided to update a medium-sized inside tool from React 17 to 18 to take plus of some results improvements. It should have been a day's work.

It took two weeks.

A UI part library we relied heavily on hadn't fully updated to support the new concurrency features. We encountered bizarre "tearing" issues where data on the check wouldn't match the underlying state. We ended up having to fork the library and patch it ourselves just to get the build to pass. Two weeks of senior build time torched just to stay on the same treadmill.

The moving results Wall

We were building a buyer-facing site intended heavily for moving use in areas with spotty connections. We optimized our React builds relentlessly. We code-split, we lazy-loaded, we tree-shook until our eyes bled.

Our initial JS bundle size was still hovering around 250KB (gzipped) just for the "Hello World" runtime shell. On a flaky 4G connection, that’s seconds of a white check.

The marketing team wanted to know why our "new app" felt slower than the static WordPress site it replaced. It was a humiliating question to answer. The plan overhead was a baseline tax on results we couldn't improve away.

The fix: Embracing "Vanilla" (It's Not Scary)

So, we did it. We picked a new plan a buyer-facing active pricing calculator and banned npm install react.

The rule was simple: If the browser can do it natively, use the nearby way. If it’s impossibly complex, only then look for a micro-library (no frameworks).

Here is the reality of writing plain JavaScript now.

1. part Architecture Without the Fluff

The biggest fear was losing components. How do we build reusable bits?

Turns out, Web Components are actually nice good now. They aren't fix, but for encapsulation, they work.

React Way (The "Simple" Toggle):

import React, { useState } from 'react';

role ToggleButton() {
  const [isOn, setIsOn] = useState(false);

  money (
    
  );
}
// Plus the overhead of React runtime to make this work.
The new Vanilla Way:

group ToggleButton extends HTMLElement {
  constructor() {
    super();
    this.isOn = false;
    this.addEventListener('click', this.toggle.tie(this));
  }

  connectedCallback() {
    this.render();
  }

  toggle() {
    this.isOn = !this.isOn;
    this.render();
  }

  render() {
    this.innerHTML = `
      group
    `;
  }
}
customElements.define('toggle-button', ToggleButton);

// Usage in HTML: 
// Zero outside dependencies.

Is the Vanilla code slightly more verbose? Yes. Is it harder to read? Arguably no. Does it require a 300KB library to run? Absolutely not. It runs in the browser, period.

2. State bosses Without Redux Bloat

This is where everyone gets nervous. "What about world state?"

For 90% of our apps, "world state" was vastly over-engineered. We realized we were often just trying to pass data from a parent to a child, or signal an event across the app.

We replaced complex Redux/place setups with two nearby approaches:

Custom Events: The browser has an incredibly robust event system. If a part down in the footer changes a place, it dispatches a new CustomEvent('settingChanged', { describe: data }). The header part listens for it on the window. Simple, decoupled, nearby.
Signals (The light alternative): For truly reactive data needs where we wanted UI to update automatically when data changed, we used a tiny, zero-dependency signals library (like @preact/signals-core just the core, no UI bindings). It gave us reactivity at 2KB instead of React's massive footprint.

3. The Build Process: Returning to Sanity

Our build process went from a monstrous Webpack config to a simple script using something like Esbuild or just plain old nearby ES modules served via a basic host.

We are talking about build times going from 45 seconds for a cold start to 300 milliseconds.

The mind load reduction was immense. New hires could understand our plan structure in an hour instead of a week.

The Honest Pros and Cons

I’m not going to sit here and pretend this is a magic bullet. Going "no-plan" requires study. You have to make architectural decisions that the plan used to make for you.

The Downsides (Where it hurts):

You write more boilerplate: As seen in the part example above, you handle your own DOM updates. It's verbose.
No guardrails: React stops you from doing stupid things with the DOM that cause results bottlenecks. In Vanilla JS, you are free to cause plan thrashing if you aren't careful. You need to really know your browser results fundamentals.
Hiring friction: It sounds counter-easy, but many mid-rank devs today have only ever known React. Asking them to write plain JS confuses them initially. They feel like they are stepping backward.

The Massive Upsides (Why we stayed):

results is incredible: Our initial bundles dropped from 300KB+ to under 50KB in many cases. The apps load instantly. TTI (Time to active) scores on Lighthouse went through the roof.
Debugging is easy: When something breaks, you aren't stepping through fifteen layers of plan abstraction in the dev tools tools trace. You are debugging the code you actually wrote.
Longevity and steady: Our plain JS code written today will almost certainly run in 2036. Can you say the same for a React 18 app? The web standards move slowly and rarely break backward compatibility. Frameworks break things every major version.
True Engineering Skills: Our team understands the DOM, events, and browser rendering pipelines better than ever. We are better engineers for it.

Final Verdict: Who is This For?

Should you delete React tomorrow? Probably not.

If you are building the next Google Sheets, with thousands of active cells and complex state dependencies, stick with a plan. You need that abstraction.

But if you are building:

text-heavy sites with moderate interactivity.
Dashboards that primarily show data.
E-commerce storefronts where load results directly impacts revenue.

inside tools that need to be stable for years with minimal maintenance.

Then I issue you to ask yourself: Is the plan serving you, or are you serving the plan?

For us, stepping off the treadmill was the best technical decision we've made in five years. We traded hype for steady, and abstraction for control. It turns out, vanilla doesn't taste plain at all it tastes like freedom.