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 (163)
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
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.
Exactly! An "historical accident"... No more! Even React alternatives (like SolidJS or Preact) are far better!!!
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"?
Incorrect. The compiler comes with its own set of issues and gotchas… In complex setups the compiler leads to slower apps with huge memory footprints. Apart from that it will be years until the rest of the ecosystem adapts. I can’t believe they’ve been working on this thing for 3+ years and still can’t make it work. It’s just sad
Sounds like a proper mess - which supports my thoughts about React and the limitations of its "rendering model" based on "just re-render the whole child component tree, and we'll do the VDOM diffing" ...
(as opposed to, for instance, Vue - which depends to a larger degree on signals/reactivity, allowing much more fine-grained re-rendering ...)
True it's a completely different model. The whole premise of React was/is that javascript is fast and it doesn't matter that the whole tree is recreated. While that is true, it's still bad practice to create intermediate states that are incomplete and should not be rendered to the user. With signals this concept may be a little easier to understand for developers and if there is a problem, it remains more confined instead of being propagated throughout the entire tree. I'm not a big fan of vue tbh, but I'm keeping a close eye on solidjs... Signals might be the future.
Thanks for the response ... why are you "not a big fan of Vue" if I may ask? I'm really curious to hear the reasons ...
Not a fan (anymore) of the angular style of directives inside html tags and I prefer the declarativeness of React/jsx.
You can use JSX with Vue, apparently ... I never did it, but it should be possible.
But, I've read that the separation of "code" and "template" in Vue is exactly what makes certain optimizations (with regards to rendering) possible ... another thing I like about Vue is that it's just more "batteries included" and a bit more opinionated (but still flexible).
I absolutely don't "hate" React (well, what's the point of hating anything or anyone?), but I've always liked Vue.
Well I haven't used vue in a long time, so maybe I'll give it a try again sometime (although I don't see reason to switch at this moment), but that separation of code and template is what I've come to find problematic tbh. Although I used to love that in my angular days, I'm not a fan anymore. It took some time to get used to React, but now I find it much easier to translate business logic into an app. It makes it easier for me to divide the logic into separate components and create clear boundaries and reusable pieces of code. It makes more sense in my brain so to speak...
For me JSX is also fine, I think it's quite elegant actually ... I don't dislike React, actually I've been using way more React than Vue over the last couple of years and generally I'm fine with it - but, we're now onboarding another dev, who is more of a Vue fan, and we're planning to rewrite the frontend using a Vue-based framework, hoping to make a "quantum leap" - so, I'll need to brush up on my Vue!
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 don't agree with much of your first point. Yeah, people have to defer to what the company they work for uses, but almost everyone I know would love to have more of a say in the stack they're using.
Completely agreed with point two.
Regarding point three, the "ease of finding React devs" argument is one that's always struck me as nonsensical rubbish. In my experience, any reasonably competent React developer can pick up Vue/Svelte/Solid/etc within a couple of weeks (usually less than that). In order to be productive in React, they should already understand the major concepts like component-driven architecture and state management, so what's to say they can't take that knowledge and transfer it to another stack that's even easier to learn in the first place? It's not like a working understanding of React precludes you from ever being able to wrap your head around Vue. It'd be like a delivery company refusing to buy vehicles with automatic transmissions because they're worried that drivers used to manual transmissions wouldn't be able to operate them. That sort of logic might follow for someone who knows nothing about vehicles or transmissions, but in reality it's absolute nonsense.
Anyway, I believe there are other forces at work that have significantly influenced React's popularity. Things like non-technical executives influencing architectural decisions, non-technical employees writing job postings and prescreening applicants, the whole labor arbitrage thing (basically if every company is using React, it drives down the cost of React devs), and a hype cycle that has pressured a lot of developers into feeling like they have to use React for everything.
For the record, I'm not a straight-up React hater or anything. I do believe it's the right tool for some jobs in some circumstances, but these days there are newer tools that make more sense for most projects most of the time. If a company is has been using React for years and already has several products in the market, yeah use React all day long. On the other hand, if a startup is choosing React for a greenfield project in 2024, I take that as a pretty big red flag.
On point 1, I cover 2 trains of thought, there are the ones who do want to have a say on what they want to work with, and those who just don't care, both exist and are valid, but, t the end, it doesn't matter, what got chosen, got chosen, and it is usually React.
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.
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).
I was following rise of vue very closely in the past, but as soon as they introduced the composition api they lost their momentum, lost the war against react. Their documentation still to this day welcomes new developer with a question rather than a solution. A new comer have to decide which one to choose, composition api or options api. New comer cant find answers easy beacuse solutions/tutorials/blog posts all fragmented over internet rooted by this dilemma. New comer is not happy. He moves away from vue.
Although what you wrote is truth, you could say the same regarding react classes vs hooks. Or angular 1 vs 2. Or any other framework older than 10 years. Progress has to be made and backward compatibility is a bitch. Composition API is superior and the primary solution atm. Vue’s documentation is very easy to navigate with examples for both as well as detailing the differences. Compare that to the alternatives where the comparison and examples of both approaches are completely lacking.
React gives you more freedom when it comes to dom manipulation. I used Vue and Nuxt, and I can tell you both are nowhere close to React and Next, regarding eco system, libraries availability (react has been around longer), and dom manipulation. If you want to build a prototype or CRUD app and you want to move fast, choose Vue, if your system will grow in complexity choose React (you will find everything out there to build it).
Can you give an example of DOM manipulation you can do with react, that’s not possible with Vue?
Regarding ecosystem, jQuery had been around even longer, so what? Check the state of JavaScript surveys: Best build tool: Vite. Best testing library: Vitest, Best dev tool: Vue Dev extension. Best static generator: Vuepress. And so on.
I work on large React and Vue projects on daily bases. React is literally terrible for large projects due to global and local state management complexity. Unit testing react components is a game of mock, hide and seek. Any table or chart with over 10000 nodes consumes so much memory that you need to add minimum memory requirements to your app. And this is without mentioning the insane amount of useMemo, useCallback and usePrayer you need to deploy to keep your app running without re-rendering because someone whispered they want to click on a white space in your app. React gives developers so many ways to shoot themselves in the foot that code reviews literally take 3 times longer just trying to make sure someone didn’t introduce a regression because added wrong useEffect dependency… Meanwhile updating dependencies is a no mans land because 1. Most third parties publish changes once a year and 2. Half of the react library is experimental features so you never know if suspense will resolve or you need to wait another 3 years until it becomes stable. And no the 3 years of development of React Compiler are not the promised land it was supposed to be, because it somehow (really didn’t think that’s possible) it results in even slower and higher memory app. Anyone who's build a React app for more than 100 domain objects immediately starts talking about micro frameworks, because this sh*t is unmanageable.
To understand the WHY, you have to go back to the beginning. It was originally marketed to Java and C++ devs. It was an attempt to turn something inherently not functional (html,css) into something functional. The original concept was extremely flawed and I never understood quite why so many web devs turned to it. I guess they bought into all of Facebook's hype.
The last line is kinda funny
Vue is not a go-to when it comes to web3 development.
Another great point in favor of Vue! I don't expect people who buy snake oil to understand it's advantages.
LOL, you f'king ignorant bro. I bet you don't even know what web3 is 🤣
The point is React is more popular, and is the go-to for everything frontend. Vue on the other hand might offer a better DX. There's no need for sentiments look up the stats. It's not my fault I prefer React, and it's more popular than Vue for whatever reason.
Oh the irony. I am ignorant because I am not interested in buying a lowHD.png for millions of dollars. I just happened to write my first linked list implementation so long ago that I find it funny how excited the new kids on the block are when they discover how serialization and deserialization works. One day when you have to start paying your own electricity bills you might realize that there are things like efficiency, performance and reliability that matter more than “stats”. In the meantime keep dreaming for imaginary worlds with no vendors and consumers where everyone eats 0s and 1s and lives under the same metaverse roof.
MF, I pay the bills, and take care of my own. Smart ass, you think web3 is about NFTs & some metaverse? You are very far from it.
Bla bla bla serialization & deserialization, man shut the f'up. I am sure you don't know Jack about how blockchain technology works and, decentralization—which is quite in the favor of Vue when you think about the global mind share.
Amazing, I’ve always been curious how Ponzi schemes manage to indoctrinate their members to a level where everyone is confused if the goal is to play nice and recruit more people or defend the promise land at all cost due to the enormous investment they have in it. It’s like a self fulfilling prophecy. But hey, I don’t blame you. Dreaming is free and it sounds like a nice dream. I wonder why do they call it “the dark web”. Sounds like you need a better marketing team. Maybe if they buy some Google Adds? Makes you wonder, if people like me know nothing about it, than is it really a thing? And how do you expect the average Jack to buy it? “Oh we should call it the next big thing, the web is big, right? Right?”
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 was laughing throughout the article buddy 😂
I couldn't even swallow the introductory paragraph to get past that point 🤦♂️
@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!
The same goes for Svelte. It lacked popularity, but, like Vue, if you use it after using React, there is no reason to go back.
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...
I must agree with the previous comment that React is extremely opinionated. Take hooks for example, it might just be plain JS functions, but they behave nothing like you'd expect in vanilla JS. Your hook must be prefixed with "use", and it can only be called in a component or other hook, and it must be side effect free and deterministic, and by the way, that JS code you are writing could be called an arbitrary amount of time by the engine and you have little to no control over that, in fact, in dev mode only we'll call it twice just because but not in the prod build. There's literally an official rules of React documentation describing how you must abide by React's way of doing things, that's as opinionated as it gets.
Tldr: people are dumb and Facebook exists.
Try Svelte, believe me.
It's a compiler, not a framework 🤣
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.
I love the sarcasm, but I'm missing a few gags:
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.