React, The king of front-end frameworks—or should I say "libraries," since React purists will remind you every 10 minutes that it’s not a framework. But let's not get caught up in the technicalities. If you're doing any serious front-end development in 2024 and you're not using React, then congratulations, you're a hipster. But for the rest of us mere mortals, React has emerged as the undeniable winner of the front-end race, and here’s why you should love it (or at least pretend to).
1. It’s Backed by Facebook—Oops, I Mean Meta
Let’s start with the elephant in the room: React is backed by Meta. You know, that small company that only runs the social lives of 3 billion people. If you’re looking for a safe bet in tech, a product maintained by the folks behind Facebook and Instagram isn’t a bad one. Nothing says "we own the internet" quite like having one of the biggest data-harvesting companies ensuring your beloved front-end tool remains relevant.
But hey, don't worry. This isn't some evil corporation monopolizing the web or anything. Nope, not at all. Just relax and trust in Zuckerberg’s quest to ensure your React app will run smoothly until the end of time (or until the next privacy scandal).
2. It’s a Library, Not a Framework (And You Will Hear This Until the Day You Die)
Let's clear the air: React is not a framework. You’ll hear this fact proudly stated over and over in developer circles, as if it’s somehow a badge of honor. “Oh, you’re using Angular? Cute. I prefer React because it gives me more flexibility.” Yeah, React developers love to remind you that, unlike those “restrictive” frameworks, React lets you piece together your app however you want. You like chaos, don’t you?
Because who wants a cohesive, opinionated structure when you can have the glorious freedom of picking and choosing your own routing, state management, and project structure? It’s like being handed an IKEA flatpack with no instructions and told, “You figure it out. It’s more rewarding this way.”
The flexibility is great—until it isn’t, and you’re 15 dependencies deep just to render a button. But hey, at least React didn’t impose any constraints on you. That’s worth something, right?
3. Component-Based Architecture (A Fancy Way of Saying You’ll Be Writing HTML in Your JavaScript)
The innovation! The creativity! The pure genius of combining HTML and JavaScript into one delicious hybrid called JSX. With React, you can finally mix your structure with your logic in ways no one asked for. Why keep them separate, like in the good old days of clear separation of concerns, when you can jumble everything into one component and call it progress?
But wait, there’s more! Not only can you write HTML in JavaScript, but you can also nest components inside other components like some kind of Russian nesting doll of web design. Need a button inside a form inside a modal? No problem. Just keep nesting, and eventually, you’ll forget where the component boundaries are. It's like React wants to challenge your mental stability and your love for clean code simultaneously.
Still, I guess there’s something beautiful about knowing that, with React, your front-end code will soon look like an avant-garde modern art installation. Bonus points if your boss has no idea what’s going on and thinks you’re a genius for making such “sophisticated” applications.
4. The Virtual DOM: So Cool You Don’t Even Have to Understand It
Ah, the Virtual DOM. React’s pièce de résistance. It’s the reason why React is so blazingly fast—at least, that’s what they tell you. Most of us just nod along and pretend to understand what the Virtual DOM actually does because it sounds complicated and impressive. Here’s a pro tip: if you’re ever caught off guard, just say something like, “It diff-checks the DOM for minimal updates,” and people will assume you’re a genius. Trust me, it works.
But the real beauty of the Virtual DOM is that you don’t actually need to know how it works. It’s just there, humming along in the background, making your app marginally faster in ways that are probably important but are also mostly invisible. Think of it as React’s way of saying, “Don’t worry, I got this.” After all, the last thing you want is to be bogged down with boring, low-level details when there are memes to scroll through.
5. State Management: Because Props Alone Aren’t Confusing Enough
If you thought managing state was straightforward, then clearly, you haven’t been properly introduced to React’s various approaches to state management. Sure, React comes with a simple useState hook, but that’s just the gateway drug. Before long, you’ll be knee-deep in useReducer, useContext, or, better yet, a shiny new external library like Redux, MobX, or Recoil.
Why? Because React developers thrive on complexity. The mere act of passing props down through a few components is too easy. Let’s mix things up! Why not have global state containers where your components can interact with variables that are seemingly nowhere near them in the code? It’s the developer equivalent of playing Minesweeper—one wrong move, and boom, everything blows up.
Of course, you could keep things simple, but where’s the fun in that? Half the joy of React is watching junior developers drown in a sea of state, props, and lifecycle methods while you offer sage advice like, “Have you tried using Redux Thunk?”
6. Hooks: The Shiny Toy You Now Can’t Live Without
React Hooks. Remember when React was class-based, and lifecycle methods were all the rage? Ha, what an ancient time that was—2018, I think? Well, forget about all that because React Hooks are here, and they are absolutely revolutionary. And by revolutionary, I mean they allowed React to fix the mess it created with class components.
With hooks, you can finally write components with more convoluted logic in just a few lines! Want to fetch some data, track a loading state, and trigger a side effect all in one component? No problem, just sprinkle in a few useEffect hooks and a useState for flavor, and you’re golden. Sure, you might accidentally trigger infinite loops if you don’t understand dependency arrays, but where’s the excitement without a little chaos?
Hooks are React’s way of saying, “We know this was already complicated, so here’s a whole new paradigm to make it even more fun.” But you’ll keep using them because, well, once you hook, you never go back. (Sorry for the pun. I couldn’t resist.)
7. The Ecosystem: Thousands of Packages You Probably Don’t Need
The React ecosystem is vast. And when I say vast, I mean it’s like walking into an all-you-can-eat buffet and realizing there are 57 different types of pasta. Need a router? React Router has you covered. Need state management? Take your pick from Redux, MobX, Zustand, Recoil, or whatever new library hit GitHub yesterday. CSS in JS? Styled-components, Emotion, or maybe just plain old CSS modules. The options are endless.
You’ll soon find yourself drowning in NPM packages. Some are beautifully maintained, others are abandoned wastelands of forgotten code, but that won’t stop you from loading up your package.json with dozens of dependencies. Sure, you could stick to the basics, but why settle for vanilla React when you could create the most bloated front-end application in history?
After all, nothing screams "modern developer" quite like spending an entire day choosing between state management libraries instead of, you know, building your actual app.
8. React Native: One Codebase to (Almost) Rule Them All
Let’s not forget about React’s younger sibling, React Native. The dream of writing one codebase and deploying it to both Android and iOS sounds amazing, right? Well, React Native promises exactly that—sort of. It’s like a good infomercial. You’ll get 80% of what you expect, but that last 20%? Oh boy, it’ll make you work for it.
“Write once, run everywhere” becomes “write once, and then spend weeks debugging why your UI looks fine on Android but is a hot mess on iOS.” But hey, at least you don’t need to write separate apps, and who needs sleep anyway?
React Native is a key part of React’s victory lap. It’s just close enough to the dream of a universal codebase to keep you hooked, but just far enough to make sure you’ll never stop tweaking and optimizing. A perfect balance.
Conclusion: Resistance is Futile
So, why did React win the front-end race? Because it had everything going for it: corporate backing, an ecosystem that makes you question your life choices, and enough complexity to keep developers both excited and frustrated at all times. You don’t have to love React, but let’s be honest—you don’t have a choice.
At the end of the day, React is like that blockbuster movie franchise that you keep seeing ads for. You’re not sure you want to watch it, but eventually, you’ll cave because everyone else is talking about it. And just like that, you’re one of us now, writing JSX, managing state, and explaining to people why “it’s not a framework.”
Welcome to the club. Don’t worry—you’ll get used to it.
Top comments (122)
It’s crazy how Vue hits all of these points in the complete opposite (positive) way, yet its so far behind react. I’ve been working with both professionally for half a decade and have no idea why anyone chooses react over Vue. And no, the react ecosystem is not bigger nor more mature. No, it’s not easier to learn. I think the only logical conclusion I can come up with is that developers enjoy complexity and making things harder than they should be
YES !
Vue is so much better, in all respects - it really beats me why people don't see that, and are torturing themselves with React "arcana" and ugly band-aid fixes like "useMemo" and so on ...
The reasons given in this article seem largely nonsense (everything stated about React is true for Vue as well, and for other frameworks) - I think the reason why React became more popular than Vue is just timing and "historical accident" - see my comment:
dev.to/leob/comment/2i5f7
Exactly! An "historical accident"... No more! Even React alternatives (like SolidJS or Preact) are far better!!!
As a dev who work on both React and Vue, i second this.
Vue is better, and easier to learn. But, i work more on React now, because thats what's my company use.
Since when is useMemo a bandaid?
useMemois really a band-aid if ever I saw one - it's only needed because the framework (React) itself apparently sucks at optimizing rendering, and pushes that kind of "low level" responsibility to the developer ...Also, I'm seeing way too many articles here on dev.to which advocate throwing in
useMemowhenever there's a performance problem (as in, too many renders), while in many cases it would be better to analyze why there's too much rendering going on, and fix the underlying issue - again,useMemoused as a "band-aid" to plaster over the real problems :)(of course sprinkling
useMemoover your code indiscriminately will quickly lead to memory consumption issues)But the deeper issue is that React forces the developer to worry about all kinds of "low level" issues (performance and rendering), which the framework should take care of itself - as other frameworks do ...
P.S. yes I know, with each React release it gets better, because they're putting solutions in place to "fix" what's broken - for instance, they're now introducing a compiler which will "intelligently" apply
useMemowhen needed ...Nice - but all of that is IMO just papering over the cracks of a framework (eh, "library") which is fundamentally "broken" ... well, maybe "broken" is a bit too harsh - the point is just that React has chosen a rendering model which relies on fully rendering the component (then diffing it with the virtual DOM to optimize it), rather than other frameworks which rely more on "signals" to render stuff selectively ... this is a choice they've made, and I can't say it's "wrong" per se, but it does have consequences, and it does result in "limitations" ...
But hey, it's the "900 pound gorilla", and even I am using it when I have to, so there's that ;-)
Actually yes, React is opting into memoizing everything now, which sucks. useMemo was incorrectly advertised as a performance enhancer. It's about controlling state. Passing an object as a value or reference means something completely different. useMemo let's you explicitly pass state by reference, so you only trigger a rerender of the children that use the memoized state, when the values used to create that state have actually changed. Unfortunately a lot developers these days have no idea what the difference is between pass by value and pass by reference, so they felt the need to put memoization in a black box ☹️
I would agree that React.memo is often used as a bandaid instead of fixing the actual performance issue which is usually state that is incorrectly being passed by value 😛
Thanks for this "deep dive" ... that's pretty impressive in my book, because I've never mastered an understanding this deep of React - I understand the basics, but for the rest a lot of it is just opaque to me (probably because I never really bothered to invest in learning what goes on "under the hood") ...
In my opinion this goes to show that (a) the React team isn't even explaining the purpose of their features adequately, and (b) this stuff just makes frontend devs focus too much on low level details - while they should ideally be able to focus on building functionality (UX and "business logic") ...
But yeah, being able to understand the nitty gritty of how all of this works is for sure good "job security" !
Yes you can definitely blame them for poorly explaining memoization, even in the new docs its still a mess ☹️ but yea... In React 19 it wont matter anymore... Basically useMemo and useCallback will be obsolete from React 19 onwards.
They will? Because of this "compiler"?
Yes the new compiler basically wraps every piece of state in useMemo and every callback function in useCallback. It's slightly more intelligent than that, but that's the basic gist.
Well I can of something. Thats that Vue 2 did not support Typescript (/out of the box). But with Vue 3 that issue is gone. But most have learned React know, therefore most jobs require React, therefore people learn it. I prefer Vue over it because the api and docs are better. People that have learned React, have no real reason to learn another thing because the development, the support, and the amount of jobs are plenty.
Fact number 1: most devs don't have or want to have a say on what framework to choose, you probably use to work on smaller companies or have decision power, but, most devs, don't, and they work with whatever the company/architect decided to use.
Fact number 2: switching frameworks is difficult, costly or plain impossible, so, whatever got picked at some point, stays forever (for as long as the project exists), React hit first, and has been able to keep it, which makes change unlikely.
Fact number 3: ease to find devs is an important thing to consider when choosing a framework, it is simply easier to find React devs than it is to find Vue devs, and this is a circle that feeds itself, the more companies think (they could be wrong of course) devs are easier to find, the more they'll lean into that technology, and the more the devs think that's what companies look for, the more they get invested into it.
React would have to secrew it up deeply to get surpassed by Vue in the short term, they just hit first, got everyone invested into it and things will just stay that way for now.
I couldn't agree more! I find myself using Vue and Nuxt for almost everything I build anymore. It's an absolute delight for developers, can match React is almost everything, and avoids the JSX (unless you elect to be a glutton for punishment).
Have hope. When I was first exploring various front-end tools I spent a lot of time with React, then with Vue, and immediately took to Vue over React. I appreciated that so much wasn't "hidden behind the curtain" in Vue and I felt like I had much more granular control of what I was building. Others moving into FE dev are bound to find the same.
This arrogant article alone would be the reason I'd never even start thinking about using React 👎
I guess the sarcasm is wasted on you.
Your lost :D . But agree that the article sucks
I couldn't even swallow the introductory paragraph to get past that point 🤦♂️
I was laughing throughout the article buddy 😂
@aloisseckar
Yeah, give it another look - the author of being sarcastic about all the bold claims.
I think all of these "reasons" are not "the reason" - because most other frameworks (or "libraries" ;-) also have these features (well, except being backed by FB / Meta) ...
I think the main reason is just "timing" - React came on the scene exactly at the right moment, back when Angular 1.x was (by and large) "king of the frontend frameworks" - and then the Angular team announced:
"Here we have a new version for you - now please simply COMPLETELY rewrite your apps from scratch!"
... and then Angular 2.x looked complex, heavy, clunky ... and right at that moment React came on the scene - simple, fast, lightweight ... and the rest is history ;-)
P.S. I am (and have always been) way more of a Vue fan, I think it's vastly superior in all respects - but yeah, again "timing" - Vue arrived just a little bit later (too late), when React was already more or less "entrenched" ...
History and "accident" determines so many of these things!
Agree with you completely. Vue is a winner for me!
I've been a web developer for almost 30 years. I started when JavaScript was in its infancy. I've used every language and framework for developing web applications from JavaScript, to Perl, PHP, Python and now React and TypeScript. I'm perfectly capable of developing an application with nothing but HTML, CSS and JavaScript, but doing so on a large complex project would quickly turn chaotic. I depend on React for the baseline of sanity that it provides.
I would agree that React is very complicated to learn. It does not use a programming paradigm that I am used to in my long career. But once you learn it, you really start to appreciate what it does for you. And they keep improving it with each new iteration (check out React Compiler).
I think it's a positive thing that certain things are left out, like routing, for example. What if your app doesn't need routing? Why do you need to use filesystem routing for a SPA?
Also, you are more than welcome to continue using class components if that floats your boat. Not everyone subscribes to the same coding style / paradigm. I personally think the concept of "clean code" is nonsense, but that's my opinion. I personally prefer kind of a hybrid of functional and limited OO programming. So react functional components and hooks work really well for how I code. That doesn't make either you or me wrong, it's just a preference. Sure one way or the other could have a minor impact on performance, but that's usually a matter of just using way too many dependencies.
So even if React does suck, you offer no alternative. To my mind, the only alternative would be to return to pure HTML and JavaScript. I did try Sveltekit but I feel it does the same thing React does and interjects the same level of "convolution" that you accuse React of doing.
Lastly, I disagree with your conclusion: why React won. The real reason that React won is because it has the largest package ecosystem. There are thousands of published NPM packages designed specifically for React. In fact, I've authored 2 of them. I'm not saying this is a good thing. In fact, I think people depend on way too many packages when taking the time to write a simple helper function would suffice, but I digress.
Vue, Svelte, Solid, Marko, ... there are a lot of feasible alternatives.
He already answered that argument. A whole lot of that "largest ecosystem" is deprecated and unmaintained. The ecosystems of other front end frameworks may be smaller, but are still better quality.
The actual reason why React won is because managers believed that it would allow them to get away with less experienced developers and still being able to scale. Unfortunately, the foot guns included in react counter the scalability promises - especially if you hire less experienced devs and expect them to be architect and dev ops combined.
What is your source for this?
Personal experience.
Ah. Opinion discarded
You sound a bit angry. I'm not even sure where to start...
Yes, react is unopinionated. No that's not the reason why people write bad react code. Bad developers write bad code in opinionated frameworks as well. React's component structure actually lends itself really well to apply basic SOLID principles.
The whole framework/library discussion is nonsensical. React is whatever Svelte and Angular and all the other frontend frameworks are. Some of those (like angular) just have a lot more gravy on top, which makes them opinionated and less suited for some use-cases.
You summed it up.
The difference between frameworks like Vue and libraries like React is the opinion factor. I've worked on Angular projects where people misused it like crazy. It's like using a Miter Saw to hammer in a nail.
The one thing I tell people when building out any kind of solution is less is more. Bad code is bad code.
Do you people realize how much boilerplate and nonsense exists in React. I am very experienced with the framework. I use it everyday at a very high level and I hate it. It's one of the most opinionated frameworks that exists right now ( for instance other frameworks don't require you to wrap everything in useMemo, useCallback etc). When it was first released I would have bought the library angle but not since hooks. It is now very much an opinionated framework. Web Components/vanilla JS imho are and the only truly unopinionated ways to build UIs.
Who said you have to wrap everything in useMemo and use callback? You don't have to, but you can if you want to.
If you have a ton of expensive computations happening on the frontend, then maybe you need to re-think how you're handling and perhaps where, as well. Memorizing data (at least in my experience) is usually warranted when you have a large amount of data that you don't want to re-calculate or apply.
I agree that going pure vanilla is as "unopinionated" as it gets, but that's because it's vanilla. :) React is an abstraction that will fire off max call stacks if you use a hook incorrectly, but it won't stop you from rendering 1000 rows all at once. Vue probably will.
Show me in the javascript spec where it describes ngIf. React is as pure as it gets... Its all basic javascript functions... I'm honestly not sure if you're serious or just trolling...
Because it came out early and was simpler than Angular which was it's main competitor at that time. For me though Solid is a better version of React, Svelte is elegant too.
Yeah that would be it. AngularJS was a leader, a first run at something, interesting but a bit crap. React was better than it at the time. There are better things now, but whether that matters is probably down to what you are building and who is using it.
Tldr: people are dumb and Facebook exists.
Try Svelte, believe me.
It's a compiler, not a framework 🤣
I am have advocated Angular over React forever, and I love the way this article is written. But also, I did want to throw up a little at inevitably. 😜
It's really because of this kind of useless, outdated article, which brings no real argument, which compares things in a childish way and wastes people's time that I've stopped coming to dev.to (sarcasm or not). 99.99% of the articles are of the same level and it's a shame. And yet I've been a React/React-native developer since 2016.
I love the sarcasm, but I'm missing a few gags:
I am prefer React because the core ide is so simple: action -> state -> view; Whole code can write in a JSX/JS files in simple js code, don't need to learn any template languages.
Try my 65 LOC State handling helper jsdoc-duck
Yes I saw a tons of owerenginered React applications. I am agree keep your package.json as low as possible, my other advice is don' need to setup Tailwind instead can use 1 liner html, this is work with or without any framework:
React won the front-end race due to its flexibility, performance, and vast ecosystem. Its component-based architecture allows developers to build reusable UI elements, making code easier to maintain and scale. React's virtual DOM improves rendering efficiency, resulting in faster user experiences. Additionally, the strong backing from Facebook and an active developer community have led to a rich ecosystem of libraries, tools, and continuous updates, solidifying React's dominance in the front-end development landscape. This combination of innovation, support, and scalability helped React outpace its competitors.
It won when it comes to getting users. But it didn't win at making developers lives easier. There's so many more choices now that are simultaneously easier to understand/use and more powerful. But we're still stuck with this annoying clunky dinosaur because it's just too big to fail.
Yours truly,
ChatGPT
React community being under influence of an advertising company, Meta, is fooled by lots of lies organized by Meta and its dev-rel team. This article name, reflects one of such much believed lies among React practitioners, which you only understand it's a lie if you are not fooled by Meta.
React is not even popular, it's just evangelized by many paid-to-write populist columnists and regretfully believed by those who lack critical thinking skills, those who believe whatever they read. You need some knowledge about higher order functional programming (type and kind level programming) to understand why functional reactive programming, which is practiced by react is a dead end when principled products like ScalaJS thrive.
And it's not only ScalaJS which is way better than React. Actually whoever knows Elm and it's clean TEA pattern understands React is under a heavy technical debt. And by Tyrian this TEA pattern is included in ScalaJS ecosystem too.
I named ScalaJS because it's the ideal product and hence everything should be compared with ScalaJS to have a fair basis. Then we understand YES React may be a good product when compared to WORST products like Angular. Solutions based on Typescript and even vanilla JS which can easily implement Custom Element are way better than React. And I'm not talking about React projects testing and tools like Jest which are more like a nightmare.
React already wasted many open source human resources. I think open source community should sue Meta for waisting it's resources. Advertising technics has nothing to offer against principled computer science design. Stop using Reacts today for a better future.
He's currently learning Flutter after praising React (Native)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.