DEV Community

Cover image for Why the Latest JavaScript Frameworks Are a Waste of Time
Leon Martin
Leon Martin

Posted on

38 3 3 4 4

Why the Latest JavaScript Frameworks Are a Waste of Time

If you’ve been in web development for more than five minutes, you know the drill. Every few months, a new JavaScript framework pops up, promising to fix everything wrong with the previous generation.

At first, it’s exciting. A cleaner syntax, better performance, fewer headaches! But after years of jumping from React to Vue to Svelte to Solid (and back again), I’ve come to a realization constantly chasing the latest JavaScript framework is a waste of time.

Don’t get me wrong—innovation is great. But at some point, you have to ask yourself Am I actually building things, or am I just constantly relearning how to build the same thing in a slightly different way?


The JavaScript Hype Cycle Never Stops

Let’s be honest, JavaScript developers are obsessed with the new and shiny. Every year, there’s a new framework, a new bundler, a new meta-framework, a new way to manage state. The cycle goes something like this:

  1. Someone announces a "game-changing" framework. It’s smaller, faster, better than everything before it.
  2. Devs flock to it. Blogs, YouTube tutorials, conference talks—everyone hypes it up.
  3. Companies hesitate. Adoption is slow because they have production apps that actually need to run.
  4. The initial excitement dies down. The framework matures, gains complexity, and starts resembling what it originally tried to replace.
  5. Rinse and repeat with the next hot framework.

Remember when Vue was supposed to replace React? When Svelte was going to kill them both? Now we’re talking about Solid and Qwik in the same way. Meanwhile, React and Angular are still here, and jQuery (yes, jQuery) still powers a ridiculous number of websites.

At some point, I had to ask myself << What am I actually gaining by switching frameworks every year? >>


Rewriting Everything Is Not Productive

I love trying new tech. I get excited about performance gains, better DX, and cleaner syntax. But there’s a cost to switching frameworks, it slows you down.

Every time I jumped on a new framework, I had to:

  • Learn a new component syntax.
  • Figure out state management (again).
  • Read new documentation and fix weird edge cases.
  • Convince my team (or myself) that this was actually worth it.

And for what? To build the same UI components, handle the same API calls, and manage the same state as before?

At some point, I realized I was spending more time learning frameworks than actually building things.


"Best Framework" Is a Myth

Developers love arguing about which framework is best. But here’s the truth, there is no best framework—only trade-offs.

  • React gives you a massive ecosystem but forces you to deal with complex rendering patterns.
  • Vue is intuitive but gets opinionated with Vuex, Pinia, and its build tools.
  • Svelte eliminates boilerplate but locks you into its compiler-based approach.
  • Solid gives you React-like ergonomics with better performance but lacks ecosystem maturity.
  • Angular is a powerhouse but comes with a steep learning curve.

Every framework has strengths and weaknesses. The moment you switch, you just trade one set of problems for another.


The Job Market Is Still Dominated by React and Angular

Here’s a reality check Companies don’t care about the latest JS framework.

If you’re job-hunting, React and Angular are still the dominant forces. Vue has a respectable share. The rest? Niche.

A startup might experiment with Svelte or Solid, but most production applications don’t switch tech stacks just because something new is trending on Twitter.

At the end of the day, companies need stable, maintainable codebases. They’re not rebuilding everything in Qwik just because it sounds cool.


Frameworks Won’t Make You a Better Developer

At one point, I convinced myself that mastering every new JS framework would make me a better developer. But the truth is, jumping between frameworks teaches you very little beyond syntax differences.

What actually makes you a better developer?

  • Understanding core JavaScript deeply (async, closures, event loops, prototypes).
  • Learning system design (how to build scalable applications).
  • Writing maintainable code (clean architecture, testing, documentation).
  • Thinking beyond the frontend (APIs, databases, cloud deployment).

A good developer isn’t the one who can rewrite a todo app in 10 frameworks. It’s the one who knows how to design software that works, scales, and is easy to maintain—regardless of framework.


What I’m Doing Instead

I’m not saying I’ll never try a new framework again. But I’ve changed my approach:

Stick to frameworks that are widely adopted (React, Vue, Angular).

Only switch when there’s a real reason (not just because Twitter says so).

Focus on core programming skills, not just syntax differences.

Build more, chase less.

The next time a new JS framework drops, I won’t be rushing to rewrite my projects. Instead, I’ll be focused on shipping products, writing solid code, and improving my problem-solving skills.


Final Thoughts

Frameworks come and go. The skills that matter—problem-solving, architecture, and clean code—stick with you for life.

If you’re always jumping from one JS framework to the next, ask yourself << Are you actually getting better, or just running in circles? >>

Let’s talk—are you still chasing frameworks, or have you stepped off the hype train too? Drop a comment below!

Hostinger image

Get n8n VPS hosting 3x cheaper than a cloud solution

Get fast, easy, secure n8n VPS hosting from $4.99/mo at Hostinger. Automate any workflow using a pre-installed n8n application and no-code customization.

Start now

Top comments (23)

Collapse
 
webjose profile image
José Pablo Ramírez Vargas

There are many things you got right and almost as many wrong.

The Right Ones

  • Don't follow hype. Don't be a sheep. Be your own free thinker.
  • Many frameworks never mature.
  • Many frameworks/libraries are just syntax changes from A to B.
  • All claim they are the new best thing ever.

I don't intend to make this section the smaller one. Is just that, because these are the things we agree on, there's nothing else to add. The next section will be more elaborated.

The Wrong Ones

Being a Svelte fan I just have to ask about Svelte's "but": Why "but you're locked into a compiler". So what? C++ has one, and I don't hear anyone saying "it is so much better to just write assembly". This is not a "but" in any shape or flavor.

Yes, it is true that many frameworks don't really advance anything. However, some do, and a few of those really do it. Let's go back to the jQuery days. jQuery is awesome, even if it is already in the list of banned technologies at companies. I agree. But the "ridiculous amount" of websites still using it may not be due to its greatness. It might be because of its timing: It was the first of its kind.

Moving forward, we encounter React. This one was the child with the silver spoon: Not only was it the child of a big company, it appeared early enough to wow the world. In retrospective, people should have stuck with knockout.js, but that's a different story.

Moving forward, enter Vue, Svelte, SolidJS. Vue did a great job bringing simplicity to the now chaotic React, but then, the next kings came. Yes, I do consider Svelte and SolidJS the next royalty. Why? Because these are the frameworks that really did it. But I'll talk about that a bit later.

Point being here: If we discourage innovation, if we are dismissive of new attempts, we will not advance. Just because only a few percentage is worth it, we should... nay, we must never stop trying new things.

About the money: Job security is around React and Angular, true. But will this hold true forever? No chance. Actually, if you're really smart, you'll promote and foster change and research. Better than hoping things will never change is driving the change yourself. Embracing change is always the better option, but has to be done responsibly.

The New Royalty

Before Svelte, "React is so performant because of its Virtual DOM algorithm". After Svelte, "React is so slow because of its Virtual DOM algorithm". This is a well-proven fact. What once was a great strength, Rich Harris tore down to tiny pieces and fed the dogs with the remains.

Close by was Ryan Carniato cooking something just as awesome, aguably more awesome to be exact: Signals. Well, at this point I should bring knockout.js again, as it was, to the best of my knowledge, the first signal-based library. Still, full credit to Ryan Carniato, author of SolidJS. He saw it, he evolved it, and damn, it was great. So great, Svelte favored signals over compiled reactivity, which brings us to present times.

Have We Advanced?

Yes! There is no doubt. For people that are unaware, see the benchmarks for yourself. The once great React is in the bottom. Angular? Definitely hotter, but still significantly down. And who's on top? You guessed it: The new royalty. Svelte and SolidJS are the top performers that are in good enough shape to be seriously considered to take over.

But we haven't advanced in performance only. Svelte is so much simpler than React it's scary. Svelte can do React's job in around 30% less code, and can do it better. Svelte's DX is superior, and I don't say this, developers around the world say this.


So what should we infer of all this? That trying and failing is not a futile exercise, because without trying there won't be successful instances. We just need to be cool-headed about the "next best thing".

Collapse
 
codeguage profile image
Codeguage

Svelte is one of the most beautiful things that have ever happened to frontend development.

Collapse
 
mfm347 profile image
MFM-347

So, your next jump will from tree to tree (js -> rs) instead of branch to branch (react -> vue -> angular -> solid).

I think, you should focus more on frontend (UI) instead of DevEnd, mean to say you should stick to one base framework (although you can choose from a variety of js and ts libs for third party tasks) that fits your level and favor (speed or style or support) and try inventing new things in frontend (UI) and that matters the most, in my perspective.

Collapse
 
getsetgopi profile image
GP

I completely agree with your perspective, and I've been following a similar approach for quite some time now. It's crucial to focus on understanding core concepts and problem-solving techniques rather than getting caught up in the ever-changing landscape of syntax variations.

Front-End domain is constantly bombarded with new NPM packages claiming to be the next big thing. However, more often than not, these are just repackaged versions of existing solutions with slightly different syntax and API names.

My strategy is that keeping things simple (KISS and DRY principle) and minimal is the best approach which involves writing custom code where it's truly needed and only use NPM packages when they provide significant value. This approach has benefited me in keeping my applications healthy and performant, makes scaling much easier, improves maintainability and manageability.

I can't help myself being a bit nostalgic for the days when web development was more straightforward – just HTML, CSS, and vanilla JavaScript (No bells and whistles). Those technologies, in their purest form, were often all we needed to create functional and efficient websites. I hope many agree with me if you are from the era of IE 5.5 :)

While modern frameworks and libraries certainly have their place, there's something to be said for the elegance and simplicity of the basics. By focusing on fundamental skills and concepts, we can adapt more easily to new tools and technologies as they emerge, rather than becoming overly reliant on specific frameworks or libraries that may become obsolete.

Collapse
 
tracygjg profile image
Tracy Gilmore

GP, I share your feeling nostalgia for simple web standards. In a recent project we have abandoned JS frameworks in favour of HTMX for server interaction, Alpine for progressive enhancement of the UI and Web Components based on Lit. I have found this combination, with the backend (templating engine) of your choice, to hit the sweet spot. Say goodbye to building/bundling the frontend. It's working well for our CRUD applications.

Collapse
 
jefferson_chidiox profile image
Jefferson Chidiox

You're absolutely right.
I'd prefer those three than any frameworks anyday

Collapse
 
mfm347 profile image
MFM-347 • Edited

There are also state management libs other than Pinia and VueX for vue.js like rstore and nanostores, although I haven't tested them.

Collapse
 
tobyliu profile image
Toby

I also think front-end frameworks change too quickly. We should focus on understanding the core theories and design ideas of these frameworks, rather than getting caught up in their syntax.

Collapse
 
himanshu_code profile image
Himanshu Sorathiya • Edited

P.S. - I know it's not place to write ps at top, I just wanna say that I'm still newbie, 1 year old I guess and currently learning React😅

If.im being honest, I read this yesterday night and thought about this that you were correct from start to end but in those midnight thoughts, I researched with myself and found many conflicting things.
There are many rights which were totally right like don't go in hype ( your hype cycle was totally agreed. I also found someone who had same thoughts just like me🤣🤣🤣 ), but then my mind came to something when you said there's still thousands of websites running on jQuery the og, it's not because people loved that, it's because at that time it was only one and just like you said companies can't change thier working app ( just because someone hyped it ), same goes for php, there are Manu sites running on it not because it's great but because at that time it was only one.

Most old thing came to end, found better alternatives, jQuery is nearly dead ( as from current people choice, php is dead.
Only Bootstrap I guess is exception ( I know it's not js, it's css framework, I mentioned this cause just like js, css also has nearly same lib/firework hype and new new things ), cause it's great and then few years back came tailwind, which gave more customization and became favorite, and I don't think for next several years they are going anywhere.

Now come to React and Angular, yeah, they have great community and people, has nearly job securance so why would I learn to go towards Solid or Svelete where in my country React, Angular, Vue is dominant. I know it's cowardness to support wrong ( which still isn't wrong ), but I can learn other things when I've a job, then after learning I can tell anyone with my own experience that what is nice or not, should we change over app framework to x to y just for few milliseconds/microseconds. I also learnt React Router, Redux cause they were ( are ) popular, but I just finished learning of TanStack router ( I can't give my real opinion until I taste that with thousands of time ), learnt Zustand, and I can tell that not all needs Redux, if can work with smaller, go for smaller.

All I just wanna say is If I've job then I'd like to try new things, just because it's fast and better but no job then what imm gonna do with that thing.

And bro, I don't know what's future of React, Angular, thay can also become just like jQuery or php, and more better things come ( always hopeful ) which actually changes WINDS.

I've heard from many people that Svelte and Solid are great ( even I talked with Solid creator ), and heard many people saying that React becoming chaos tonnage, don't go for react, but instead of listening to any of those, you've a family to feed, should consider for yourself first.

Note : I know flow of this replay is total mess🤯

Edit : same goes for code editors, many IDE came and many IDE gone, many came with built in AI and gone and many of people are still comparing one with another, after writing this article, I just found a article Co.aring two AI ides and came back here to edit this. People still love VS code even I tried few of them and always found VSC as per needs, it gave me confortaness, it has mostly all features I think of ( if you belive I've 250+ modifications in my settings of vscode which shows how greatly customizable it is and each month they're adding new to it ), and for something which isn't builtin in default, I finds an extention. And 2 Iade foeyself ( 1. I guess majorly for react, you all time needs to create 2 files, one compo file and second it's corresponding module css file, so I made that and Happily using it,,, 2. About organization of import, I made custom script with high customization and will publish after more testing and implementing everything )

Collapse
 
naghikhanimahmoud profile image
Mahmoud Naghikhani • Edited

Thank you. You are right. Learning database and API and security is more important than new frameworks. I hope others use this brilliant experience and doesn't waste time. Regards

Collapse
 
awinooliyo profile image
Erick Otieno Awino

This is a great piece. Often, I get confused about what framework to jump on next.

Collapse
 
gopikrishna19 profile image
Gopikrishna Sathyamurthy

My approach to this is to play "King of the hill". For a given problem, I have a tool. Unless what I proof-of-concept knocks it out, it stays in belt. That's why I moved from jQuery to angular.js to react in 2015 and still use it. Moved from custom webpack config to vite for spa and nextjs for full stack. Still use redux in spa, no mobex or saga. Vitest from jest. RTL from enzyme.

Although I try a lot of things, not many of them impressed me in the last 15 years my frontend career. Very few managed to replace my go to tools to become the next one. So, hype? Try it, learn from it, sometimes they teach you unique patterns to augment your toolset. If it's same grind, keep an eye on it for it's promises, otherwise forget it.

Currently I'm eyeing web-components to augment react, but it's still a challenge. I shall probably revisit after another couple of years...

Working in an enterprise, a tip: a company usually follows my strategy at a large scale. 10 years ago everyone in my company was using angularjs. Enter react, every single one adopted it. Although we are on different versions now, we are all on react. Unless vue, svelte or another shiny thing manage to outclass react, we probably won't switch. Does that mean we don't try other frameworks? No, we still do. There are some sporadic teams that use Angular, Jekyll, home grown frameworks, but mostly because either it's convenient, not maintained, or just want to try.

I'm sticking with react for now. It's not worth rewriting thousands of LOCs in vue or svelte just because it builds faster or runs faster or outputs smaller. If you know what you are doing, you won't see difference in any of these.

Collapse
 
webjose profile image
José Pablo Ramírez Vargas

Unless vue, svelte or another shiny thing manage to outclass react

This happened a long time ago. It is measurable and quantifiable.

Collapse
 
gopikrishna19 profile image
Gopikrishna Sathyamurthy

You are missing my point. But that's okay 😌

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

Hmm, I don't think so. You're clearly stating a premise that has already fulfilled, yet you claim to continue using React. You are therefore not upholding your own "King of the hill" approach: React has been dethroned long ago. You're not being consistent.

Now tell me: If this is not the point of your comment, which is it?

Collapse
 
zeroevidence profile image
Dale Moore

I get paid way, way, way more working with svelte than any other js framework because I can deliver 10x as much as any other developer specialising in another framework. And no shortage of work!

SurveyJS custom survey software

JavaScript Form Builder UI Component

Generate dynamic JSON-driven forms directly in your JavaScript app (Angular, React, Vue.js, jQuery) with a fully customizable drag-and-drop form builder. Easily integrate with any backend system and retain full ownership over your data, with no user or form submission limits.

Learn more

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay