I used to have FOMO about frameworks. Every time a new JavaScript framework launched — and they launched constantly — I’d feel this compulsive need to try it. Build a todo app, follow the tutorial, write a blog post about it, move on to the next one.

Between 2019 and 2023, I touched Angular, React, Vue, Svelte, Solid, Qwik, Fresh, Astro, Remix, and probably a few others I’ve blocked from memory. I never got truly deep with any of them. I was always surface-level, always chasing the latest thing, always feeling like I was behind.

Then I stopped. And my career got noticeably better.

The Problem with Framework Hopping

Here’s what I eventually figured out: frameworks are tools, not identities. The web development community treats framework choice like a sports allegiance — you pick a side, defend it on Twitter, and look down on people who chose differently. This is deeply unproductive.

More importantly, framework hopping keeps you at the tutorial level forever. You learn enough to build a demo, but you never encounter the hard problems — state management at scale, performance optimisation, complex routing, accessibility patterns, testing strategies — that only appear in real production applications.

The developers who get hired for senior roles aren’t the ones who’ve tried twelve frameworks. They’re the ones who’ve shipped complex applications with one or two frameworks and can talk intelligently about the tradeoffs they encountered.

What I Do Now

I picked React. Not because React is the best framework — I don’t think that category is meaningful — but because it has the largest job market, the most mature ecosystem, and enough staying power that my investment won’t be wasted.

Then I went deep. Really deep.

I read the source code. Not all of it — React’s codebase is enormous — but key sections. Understanding how useState actually works under the hood changed how I think about state management. The React team’s blog posts about the architecture are surprisingly accessible and worth reading.

I built progressively complex projects. Not todo apps. I built a real-time dashboard with WebSocket connections. A form builder with dynamic validation. A multi-tenant SaaS application with role-based access control. Each project forced me to solve problems that tutorials never cover.

I learned the adjacent skills. TypeScript. Testing with Vitest and React Testing Library. Performance profiling with Chrome DevTools. Accessibility auditing with axe. CI/CD pipelines. Docker. These skills transfer across frameworks — if I ever need to switch to something else, 80% of what I know remains valuable.

I stay informed without investing. I follow the development of other frameworks through newsletters, podcasts, and conference talks. I understand what Svelte’s runes are doing, I know why Solid’s fine-grained reactivity is interesting, I’ve read about Astro’s content layer. But I don’t build projects with them unless I have a specific reason to.

When to Actually Switch

I’m not saying you should never learn a new framework. There are legitimate reasons to switch:

When the job market shifts dramatically. If React’s market share dropped to 20% and something else took over, I’d adapt. So far, State of JS surveys show React’s dominance is fairly stable, but I watch the numbers.

When a project genuinely requires it. If a client or employer uses Vue, I’ll learn Vue. Professional obligations override personal preferences.

When a technology offers a genuine paradigm shift. Astro’s approach to content sites was different enough from React that I added it to my toolkit — I use it for static content sites and React for interactive applications. That’s a meaningful distinction, not a trend chase.

When you’re genuinely bored and need intellectual stimulation. Building something in a new language or framework can reignite your enthusiasm. Just be honest about whether you’re exploring for growth or avoiding depth in your current stack.

The Skills That Actually Matter

After six years of professional development work, here’s what I’ve found matters most — and none of it is framework-specific:

Understanding HTTP. How requests work, what status codes mean, how caching behaves, what CORS actually is. I’m consistently surprised by how many developers can build a React component but can’t explain what happens when they call fetch().

JavaScript fundamentals. Closures, prototypes, the event loop, promises, generators. These concepts underpin every framework and outlast all of them. When frameworks abstract these away, you need to understand what’s being abstracted to debug effectively.

CSS. Seriously. Most developers I work with are mediocre at CSS and it shows. Understanding flexbox, grid, specificity, the cascade, responsive design patterns, and CSS architecture (BEM, utility-first) will serve you for decades. CSS has changed less in the last decade than any other web technology.

Databases and data modelling. Whether you’re using PostgreSQL, MongoDB, or a headless CMS, understanding how to model data efficiently is a transferable skill that pays dividends everywhere.

Debugging. The ability to systematically isolate a bug — reading error messages, using breakpoints, checking network requests, reading stack traces — is more valuable than knowing any framework’s API by heart.

My Honest Advice

If you’re early in your career, pick React, Vue, or Svelte. Any of them will get you employed. Pick one. Spend a year going deep with it. Build something real — something with user authentication, database interactions, deployment, and at least one problem that makes you want to throw your laptop out the window.

Then assess. If you’re happy and employed and productive, stay. If there’s a compelling reason to switch, switch deliberately. But don’t let the noise of the JavaScript ecosystem convince you that staying still is falling behind. It’s not. It’s how you actually get good.

Murtaza Khan is a self-taught developer sharing what he’s learned the hard way.