I have a wide range of experience with full stack web development, graphic design, UI/UX, 3d and architecture. I enjoy solving a variety of problems in simple and creative ways.
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
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.
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.
I have a wide range of experience with full stack web development, graphic design, UI/UX, 3d and architecture. I enjoy solving a variety of problems in simple and creative ways.
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.
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:
useMemo is 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 useMemo whenever 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, useMemo used as a "band-aid" to plaster over the real problems :)
(of course sprinkling useMemo over 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 useMemo when 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.
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.
I have a wide range of experience with full stack web development, graphic design, UI/UX, 3d and architecture. I enjoy solving a variety of problems in simple and creative ways.
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.
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!
Is solidjs even a thing. Its just a copy cat and an excuse in the name of speed. For me i think that solid js is just an excuse for writing bad or slow code in react
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.
Passionate & reliable web professional with experience in both design and development. Recognized as a top contributor, excellent communicator, encouraging & supportive teammate, and natural leader.
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).
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.
Currently in fintech. Formerly in telephony. Started a Linux distro ages ago that's somehow still active. Generally prefers backend webdev to everything else.
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.
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).
I have a wide range of experience with full stack web development, graphic design, UI/UX, 3d and architecture. I enjoy solving a variety of problems in simple and creative ways.
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.
I have a wide range of experience with full stack web development, graphic design, UI/UX, 3d and architecture. I enjoy solving a variety of problems in simple and creative ways.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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
The last line is kinda funny
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.
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.
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.
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.
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!
Exactly! An "historical accident"... No more! Even React alternatives (like SolidJS or Preact) are far better!!!
Is solidjs even a thing. Its just a copy cat and an excuse in the name of speed. For me i think that solid js is just an excuse for writing bad or slow code in react
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.
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).
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.
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.
LMAO, Yes, OP is listing down React features like they're unique to it 🤣
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.
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.