Why I Stopped Chasing the Latest JavaScript Framework

I spent three years rewriting the same app in five different frameworks. Then I realized I wasn't building anything—I was just running in place.

---

The Framework Treadmill

It was 2 AM on a Tuesday when I found myself refactoring my side project again. This time, I was migrating from Vue 2 to React with Next.js because—well, because everyone on Twitter said it was the future. Six months earlier, I'd moved from Angular to Vue because Angular felt "too heavy." Before that? jQuery to Angular because "real developers use frameworks."

The app? A simple task manager. The kind you could build in vanilla JavaScript in a weekend.

But here I was, three years in, with nothing to show for it except a graveyard of node_modules folders and a creeping sense that I'd been scammed.

That night, staring at my screen, I had an uncomfortable realization: I'd become better at learning frameworks than at solving problems.

---

How I Got Here

Let me take you back to where this started.

I learned JavaScript in 2016, right when the "JavaScript fatigue" articles were everywhere. Ironically, I thought I was immune. I'd just focus on learning "the right tools," I told myself. I'd stay current, stay relevant.

So I followed the thought leaders. I read the blog posts. I watched the conference talks. And every single one told me the same thing: if you're not using [Framework X], you're falling behind.

• 2017: Angular was enterprise-grade and TypeScript was the future
• 2018: React was winning, and I needed to learn hooks
• 2019: Vue was simpler and more intuitive
• 2020: Svelte was revolutionary with its compiler approach
• 2021: Next.js and server components were changing everything
• 2022: Remix was web fundamentals done right
• 2023: Astro was the performance king

Each time, I'd spend weeks learning the new framework. I'd rebuild my projects. I'd feel that dopamine hit of "now I'm using the best tool." And then, three months later, something newer would appear on Hacker News with 2,000 upvotes.

The cycle repeated. My side projects never launched. My GitHub was full of half-finished repos with names like todo-app-react, todo-app-vue, todo-app-svelte.

---

The Breaking Point

The breaking point came during a job interview.

The interviewer asked me to build a simple feature: a filterable list with search. Real-world stuff. I reached for Create React App instinctively, spent 10 minutes setting up the boilerplate, then got lost in deciding whether to use Context API or a state management library.

Twenty minutes in, I hadn't written a single line of business logic.

The interviewer stopped me. "Can you just... use vanilla JavaScript? I want to see how you think through the problem."

I froze. I genuinely wasn't sure I remembered how. My brain had been so trained to think in framework patterns—components, props, state, effects—that I'd forgotten how to just manipulate the DOM and handle events.

I didn't get the job.

But I got something more valuable: a wake-up call.

---

What I Learned (The Hard Way)

1. Frameworks Solve Framework Problems

Here's the thing nobody tells you: most frameworks are built to solve problems that massive companies have. React was built for Facebook's scale. Angular for Google's enterprise needs. Next.js for Vercel's hosting platform.

Your task manager app? Your portfolio site? Your small business landing page? They don't have those problems.

I was using a semi-truck to buy groceries. Sure, it works, but it's overkill—and now I need to learn how to drive a semi-truck.

2. The Best Code is Code You Understand

I used to think "best practices" meant using whatever framework had the most GitHub stars. Now I know it means writing code that you—and your team—can understand and maintain.

A 50-line vanilla JavaScript file that everyone on your team can read and modify is infinitely better than a "modern" React app with custom hooks, context providers, and HOCs that only you understand.

3. Fundamentals Don't Expire

Frameworks come and go. I've watched Backbone, Knockout, Ember, and Meteor rise and fall. But JavaScript? The DOM? HTTP? CSS? Those are still here.

The time I spent learning how closures work, how the event loop operates, how browsers render pages—that knowledge is still valuable. The time I spent learning Angular 1's digest cycle? Completely wasted.

4. Complexity is a Tax

Every dependency is a liability. Every abstraction is a bet that you'll never need to understand what's underneath.

When I was framework-hopping, I never thought about:

• Bundle sizes (my "simple" React app was 200KB minified)
• Build times (5 minutes to compile on every change)
• Debugging (stack traces through 15 layers of framework code)
• Upgrades (breaking changes every major version)

Now I think about these things constantly. Because I've been burned.

---

What I Do Now

I didn't quit frameworks entirely. I'm not a zealot. But I changed my approach completely.

I Start With Vanilla

Every project starts with HTML, CSS, and vanilla JavaScript. No build tools. No frameworks. Just the browser.

If the project is simple enough—and most are—I stop there. A static site generator like 11ty or Hugo if I need templating. Maybe a sprinkle of Alpine.js if I need reactivity.

I Reach for Frameworks Only When I Feel the Pain

Now I only add a framework when I'm actually experiencing the problem it solves. Not because I might need it someday. Not because it's popular.

Need to manage complex state across dozens of components? Okay, maybe React makes sense. Building a real-time collaborative app? Sure, a reactive framework could help.

But a blog? A landing page? A CRUD app? Vanilla is fine.

I Optimize for Deletion

I write code that's easy to delete. Small, focused modules. Minimal dependencies. No clever abstractions.

Because I know now that the best code is code that can be thrown away without taking the entire project with it.

---

The Uncomfortable Truth

Here's what I wish someone had told me three years ago:

The JavaScript ecosystem doesn't want you to stop learning frameworks. There's an entire industry built on keeping you anxious about falling behind.

• Framework creators need adoption
• Course sellers need new content
• Consultants need new specializations
• Conference organizers need new topics
• Tech influencers need engagement

Everyone benefits from the churn except you—the developer trying to build something real.

The dirty secret? Most successful products are built with "boring" technology. They're using jQuery, or Rails, or PHP, or frameworks that are five years old. And they're making money while we're rewriting our todo apps.

---

What Changed

I'm not going to pretend I'm some enlightened developer now. I still feel FOMO when I see a shiny new framework on the front page of Hacker News. I still wonder if I'm missing out.

But now I have a filter. Before I learn something new, I ask:

1. What problem does this solve that I actually have?
2. What's the cost of adoption? (Learning curve, bundle size, ecosystem lock-in)
3. What's the cost of maintenance? (Updates, breaking changes, community support)
4. Could I solve this with what I already know?

Most of the time, the answer to #4 is yes.

---

My Advice (If You Want It)

If you're where I was—exhausted, anxious, feeling like you're always behind—here's what helped me:

Stop following framework thought leaders. Unfollow the people who make you feel inadequate for not using the latest tools. They're optimizing for engagement, not your success.

Build something real. Not another todo app. Something you'll actually use. Something with users who don't care what framework you used.

Learn the platform. Spend a month just reading MDN. Learn how fetch works. Understand the CSS cascade. Master the DOM API. This knowledge will outlast every framework.

Embrace boredom. Boring technology is proven technology. There's a reason banks run on COBOL and e-commerce sites use PHP. It works, it's stable, and everyone knows how to fix it.

Measure what matters. Not bundle size or lighthouse scores or how "modern" your stack is. Measure: Did you ship? Do users like it? Can you maintain it?

---

Where I Am Now

That task manager I kept rewriting? I finally finished it. In vanilla JavaScript. It's 300 lines of code, loads in 50ms, and works perfectly.

I launched it six months ago. It has 500 users. I've added features, fixed bugs, and haven't touched the "framework" layer once—because there isn't one.

I'm building again instead of learning. I'm shipping instead of refactoring. I'm solving problems instead of collecting tools.

And honestly? I'm having more fun than I have in years.

---

The JavaScript ecosystem will keep churning. New frameworks will keep appearing. The thought leaders will keep telling you you're behind.

But you don't have to run on that treadmill anymore.

Sometimes the most productive thing you can do is stop chasing and start building.

What framework are you using? The one that lets you ship.