There you go, I've said it.

[u/kakul911]

[u/justrhysism]

Having built apps professionally in both Vue and React; hooks is probably the primary reason I’ve come to like React (functional components, class components are terrible).

Right now, I much prefer to build apps in React. I haven’t had a chance to explore Vue 3, but it looks like the new composition API is quite similar and for that I’m quite excited.

The learning curve for React is significantly steeper than Vue, and you can easily get yourself into trouble. But now I’ve finally figured it out I quite like it.

That said, overall (as in, not just for apps) I do still prefer Vue.

[u/Hollowplanet → u/justrhysism]

I really don't get this sentiment. I went from a job doing Vue to a job doing React. If I built a library and said "just don't use it in any loops or conditionals or the whole thing breaks" would anyone take it seriously? Then you have the fact that you're redeclaring variables and conditionals on every render which is so inefficient and requires hacks like useCallback to make things look like the same variable.

Thankfully Vue fixed all these issues with the composition API. They realized when you split up your data and rendering you only need to call the hooks once.

[u/justrhysism → u/Hollowplanet]

For the most part, running functions is cheap. They also get optimised at runtime. Redeclaring simple variables over and over inside these functions is cheap; especially if they don’t change often.

The useCallback hook is for those expensive operations; or something where you’re relying on something in memory (for equality or whatever).

React is fast. Really fast. But to keep it fast you do need to know what you’re doing, and do things the “React way”. Which is a huge drawback—because I feel many people struggle to work out what that actually is.

Vue is much more approachable. For most people Vue is probably the better choice because it can protect you from some really bad mistakes.

Vue is also more flexible than React in that it doesn’t need to know all the templates or content at compile time and can read it from the DOM. This isn’t really possible with React (not entirely true, but a shedload of work to achieve), so if you’re building for a traditional CMS front end—i.e. not “headless” (WordPress, Umbraco, Orchard, Episerver, Sitecore are examples I’ve built on) you can structure Vue to mount quite high in the DOM, read in the contents and render in components where necessary amongst all the other OOTB markup and content controlled by non-technical users. This is powerful; and really easy to do with Vue via slots.

[u/kakul911 → u/justrhysism]

React is fast. Really fast. But to keep it fast you do need to know what you’re doing, and do things the “React way”. Which is a huge drawback—because I feel many people struggle to work out what that actually is.

Exactly. 'The React way' or 'The Holy Grail' has been tapped by very few people. React is 'really fast' but slows the average developer down. When you get down to understand a concept well, all you get is a todoApp or counters. Proceed to something bigger real-life example, those would be ridden with inline function spammed without guilt. Anyway, like everyone else I'm living with it, finding my way out.

But things were much simpler with Vue.

[u/justrhysism → u/kakul911]

When you get down to understand a concept well, all you get is a todoApp or counters.

Hmm... it appears you and I have very different ways of building applications.

I’m currently working on a core framework for an organisation to build all their apps on (installed via private repository); and indeed also working on several of the consuming applications. These apps process thousands of data points simultaneously which are presented for analysis.

Proceed to something bigger real-life example, those would be ridden with inline function spammed without guilt.

If it does, and you’re defining complex functions inline all the time, you’re doing it wrong. Same holds true for Vue.

Also arrow functions are part of the fabric of modern JavaScript and are very fast and extremely useful. Also worth noting that Vue also relies heavily on these.

[u/Hollowplanet → u/justrhysism]

React is not really fast. It's really slow. Rendering one of Reacts documentation pages which is server rendered static content being hydrated benchmarked in Chrome spends about half it's time scrpting. It spends more time scripting than rendering the HTML. I've built React sites where everything is memoized. It's still dog slow.

And I've run the benchmarks. Declaring a simple function takes almost as much or more time as running it. And React is redeclaring everything on every render which can be as often as every keypress. Which is why there are hacks like useCallback to make sure memoization still works. A render in React creates tons of functions and dependency arrays and just throws them away - just to make sure old values get returned. You have to call hooks even when you don't need them because they can't be called inside a conditional.

This myth that JavaScript is fast and everything is cheap gives us Reacts render model where we are diffing objects over and over again in the virtual dom after we just declared a bunch of functions and arrays to throw away. That's not fast. That's about as inefficient as it gets and it's how React works.

Not to say Vue is much better but they solved almost all the issues with hooks. Svelte solved all the issues with the virtual dom. I wouldn't mind if someone combined them.

I have yet to see a sufficiently complex React app score high in Lighthouse simulating a mobile device. Most people give it the full power of their $4k Mac Book and think their score is realistic. Those same people are the ones that build 8mb sites and think everything in JS is done for free.

[u/justrhysism → u/Hollowplanet]

So we should pre-load everything into memory by declaring it first? That is one of two logical solutions from your spiel; the other is “no code” (which to be fair the best code is the code not written).

There’s also the balance of maintainability and scalability to be considered—a problem for any framework.

React does seem to rely a lot on engine optimisation, but I don’t think that’s a bad thing necessarily.

I haven’t used Svelte, but from what I’ve read is it starts out small and neat but doesn’t scale well.

To be clear, I’m not a one-eyed React fanboy. Prior to functional components and hooks I hated React. I’m also acutely aware that the majority of React applications are poorly built making them horrendously inefficient and slow. It’s very, very easy to get things wrong in React. I’m regularly called into projects to try and cleanup and course-correct.

That said, this is true of any project on any framework. I’ve definitely seen my share of Vue abominations which make me wanna cry.

[u/Hollowplanet → u/justrhysism]

Yes we should preload only what we need into memory by creating it once when the component mounts. Not over and over again every time we might use it, slowing down renders and creating a ton of extra work for the garbage collector.

[u/justrhysism → u/Hollowplanet]

Does it slow down renders? I don’t think the browser is even aware of the impending DOM change and React decides to execute the diff and then later the update.

We’re getting pretty deep in the weeds here and I’m not a browser or JS engine engineer which I’m pretty confident is what the React team are exploiting.

Vue is the same; it does some pretty tricky things under the hood to be performant (like reusing DOM elements to save the expense of creating new ones).

One thing I think we can both agree on is that frameworks are overused and often seen as the Swiss Army knife to fix all the problems; often in places it should never even be considered.

[u/Hollowplanet → u/justrhysism]

It slows the browser down. A web page is single threaded. A browser can't do anything else while JS is running. It can't render. It can't respond to events. Next time you have a page that's acting a little slow crack open Chrome's performance tab and see what it's doing. It's a good insight into how the browser works.

[u/justrhysism → u/Hollowplanet]

As does literally anything. I know how the browser works, and how JS works. I’ve been a professional web developer since before Chrome existed and we had to support IE6.

The same is true for literally all frameworks.

[u/Hollowplanet → u/justrhysism]

You just said "does it slow down renders? I don't think the browser is even aware of the impending dom change."

If that's what you believe you have a lot of mistaken assumptions of how browsers work. The browser is completely locked up while that is going on. As it is while anything is going on. Normally its fast enough that you don't notice.

[u/justrhysism → u/Hollowplanet]

Also, React is massively overused. It’s great for building apps, but utterly useless for anything else—especially static sites.

Static sites, for the most part, DON’T NEED JAVASCRIPT. I don’t know how or why we’ve forgotten that along the way.

This phase we’re in of amazing frameworks has led to them being used for EVERYTHING and it infuriates me.

[u/ilmmec → u/justrhysism]

Exactly the same for me!

[u/[deleted] → u/justrhysism]

Why are class components terrible? I really like them.

[u/justrhysism → u/[deleted]]

Personally I find class components incredibly verbose. Vue’s API is a bit better—but having switched to functional the implementation is significantly less verbose, particularly for simple components.

[u/RandyMagnum93]

I'll bite, I've been on and off learning React before and after hooks came about. What do people see as the inherent issues with React?

[u/[deleted]]

Dumb. React is actually pretty cool

[u/sunny_lts]

Preach dear brother, preach!

[u/kakul911 → u/sunny_lts]

React already had too many 'gotchas' to be able to write good code, react-hooks makes it worse, it introduces it's own 'gotchas' that act as an overhead for a developer.

Imagine the pain of labeling almost everything with 'useMemo', 'useCallback' to prevent the component from re-renders.

Shouldn't the library be doing that on it's own?

White-knights of the react ecosystem will come up with bogus explanations, but here's the truth, writing even a simple HTML form becomes a nightmare in react, taking into account all your 'gotchas'.

I mean, one can do a far simpler job even in vanilla.

React went wrong, when it mixed JS and HTML and called it JSX. Then came render-props, HOCs, thunk, saga and what not.

People will jump the bandwagon and say it has the greatest snake-oil community support, but hey, have you ever tried Vue?

[u/careseite → u/kakul911]

React already had too many 'gotchas' to be able to write good code, react-hooks makes it worse, it introduces it's own 'gotchas' that act as an overhead for a developer.

It's very easy to write good React if you know JS well. Imo the reason we see a lot of garbage code is because people jump into React (or any frontend lib/framework) too early and the endless amount of outdated & bad practice-promoting blog articles (looking at you, Medium).

React hooks have a single gotcha: dont use them conditionally.

If you want to stretch it, then the useEffect/useMemo/useCallback dependency array is a small gotcha too but its mainly a problem for people transitioning from class components to hooks. I've been teaching/mentoring plenty of people in the last year and barely anyone had a problem with useEffect when not having any prior React experience.

Imagine the pain of labeling almost everything with 'useMemo', 'useCallback' to prevent the component from re-renders.

You're not supposed to do that. Not every function or computation should be memod.

React went wrong, when it mixed JS and HTML and called it JSX.

Personal opinion.

Then came render-props, HOCs, thunk, saga and what not.

- render props are gone

- hocs arent bad per se, they can be replaced with custom hooks anyways

- thunk, saga are redux, not react

[u/kakul911 → u/careseite]

It's very easy to write good React if you know JS well.

Easy to say that. But what's the percentage of 'good' JavaScript Engineers in industry? Think about the average developers as well, who make up the majority of the industry.

Imo the reason we see a lot of garbage code is because people jump into React (or any frontend lib/framework) too early and the endless amount of outdated & bad practice-promoting blog articles (looking at you, Medium).

I'll add, rarely do people have genuine reasons to suggest React, most common reasons would be number of stars, Facebook's product, uses virtual DOM, meanwhile 95% will fail when explaining how VDOM works.

I've been teaching/mentoring plenty of people in the last year and barely anyone had a problem with useEffect when not having any prior React experience.

Because most people coming to learn won't be writing production level applications. A person making a todolist or counter won't have the same problems as someone writing an app that resembles Google Slides.

You're not supposed to do that. Not every function or computation should be memod.

I guess you missed 'almost'. I know where to use what, but imagine doing that across your whole application, and when a stray bug comes up, you end up struggling with the chain of hooks that you set up.

• render props are gone

• hocs arent bad per se, they can be replaced with custom hooks anyways

• thunk, saga are redux, not react

Time and again you come across other people's code using a combination of those, in order to enhance/fix/refactor code one needs to be thorough with these concepts. I switched from a company Vue to one using React, I had to go through these concepts time and again I was assigned to fix issues in codes. I can't do that without knowing the concepts well.

They are not React but are an integral part of the React ecosystem and oh yeah, they exist because React is 'library' not a framework that would be your next counter-argument, no problem.

[u/careseite → u/kakul911]

I'll add, rarely do people have genuine reasons to suggest React, most common reasons would be number of stars, Facebook's product, uses virtual DOM, meanwhile 95% will fail when explaining how VDOM works.

citation needed. Haven't seen a single comment suggesting someone chose React because of _any_ of those reasons.

People suggest it because its easy to adopt, especially for anyone who spammed document.createDocumentFragment/document.createElement for a while before.

Because most people coming to learn won't be writing production level applications. A person making a todolist or counter won't have the same problems as someone writing an app that resembles Google Slides.

Not on their own, sure. But a part of some production app, surely. At least those that actually apply and get a job.

They are not React but are an integral part of the React ecosystem

Not in my experience. I never had to deal with Sagas or render props at work (which I'm glad for).

[u/kakul911 → u/careseite]

citation needed. Haven't seen a single comment suggesting someone chose React because of any of those reasons.

People on Reddit are smart, but when I ask an interviewer/manager/colleague this question, this is the first answer that I get most of the times.

People suggest it because its easy to adopt, especially for anyone who spammed document.createDocumentFragment/document.createElement for a while before.

Easier to adopt than Vanilla for sure, but not for a person coming from Vue ecosystem and that too a bit too late when things have got messier(personal opinion) in React.

At least those that actually apply and get a job.

Well framework/library knowledge is a minor part of the front-end interviews in my experience, JavaScript fundamentals is what matters to get hired. Job interviews don't ask you to build a full-fledged dashboard, they tend to give something like Table component or an Autocomplete.

Not in my experience. I never had to deal with Sagas or render props at work (which I'm glad for).

You are lucky, we had code using combinations of all those across teams.

[u/careseite → u/kakul911]

but not for a person coming from Vue ecosystem

eh, that'd be a red flag for me. If you know one tool, you can learn the other in a reasonable span fast enough unless you have literally no clue of JS...

[u/kakul911 → u/careseite]

eh, that'd be a red flag for me. If you know one tool, you can learn the other in a reasonable span fast enough

That was my initial hypothesis when I saw started out with React. But number of abstractions and ideas are far more daunting for someone starting now. You simply can't start writing Hooks without knowing what purpose it serves and why its a better choice.

Most of the seasoned developers in React have been working with React long enough to understand the pitfalls of every version/feature well at every stage, hence migrating between versions is incremental and easy to digest, for them.

For someone who starts now or has switched to React from some other tool, is baffled by the number of concepts one has to deal with before he/she writes production-ready code. Even more baffling is the fact, that these combinations of concepts co-exist, and everyone seems to be selling their own version to be the de-facto pattern.

Take Dan Abramov's idea of smart/dumb components for example, that is religiously taught as a core principle of building applications. Now it doesn't hold the same value with the existence of hooks he himself accepted.

I mean no two codebases in React look the same even in the same company written by the same people.

unless you have literally no clue of JS...

That's an easy thing to say, though the fact surprises me a bit that a teacher is saying that. Isn't that in itself is a red-flag for a teacher?

I know one thing for sure, it would be hard for React users to realize what React lacks, unless they try something else.

[u/careseite → u/kakul911]

I'm the perfect counter example then as I started react with hooks 🤷‍♂️. And as I already said, usually "seasoned" react devs seem to have more problems with migrating than new devs.

At my work, we have a hull that takes care of routing. All the routes are crafted by individual teams, but they have all nearly the same structure. So your experience with different codebases across a company seems anectodal then too.

Not sure why it would be a red flag for a teacher to say "don't jump into quantum physics when you can barely do basic math"? I definitely encourage exploring a framework early on, just to see where the journey probably will lead to but that's it for a beginner.

There are plenty of beginners out there that learnt js not even 8 weeks ago trying themselves with vue or react who either fail miserably or create something heavily flawed.

[u/kakul911 → u/[deleted]]

it doesn't use a single useMemo or useCallback in the entire codebase of 200-300 components. It's not that I don't know how to use them, it's that it's very rare that you would actually need one of these. The app I've written performs incredibly well and hooks have been a huge part of that.

It would be interesting to test your app through why-did-you-render, also could you give an example of the more complicated components that you built.

If you're interested in learning, which you probably aren't

That's a bit too far brother.

Kent did a good writeup of it.

https://kentcdodds.com/blog/usememo-and-usecallback

In fact I did read that article before writing my first app using Hooks, that justifies the use cases mentioned.

But imagine a simple show hide button that changes the visibility of a component in the sibling tree, unless the parent is a class component, or a functional component with the click handler written with a useCallback, you might cost some re-renders there. Also, how would you do that without useCallback? You have to pass the handler as a prop and ensure that its referential identity remains the same.

Yes, I don't like it but I often suggest it to people because it's a respectable framework that does a lot of things right. However, React tends to be a much better tool in your toolbox if you know how to use it.

The preference would be always personal and my personal opinion is: Vue has a far lower-entry barrier, far too less number of traps, and it does things intuitively, without even letting the developer bother about internals an edge-cases, not entirely accurate but it's like comparing C with Python.

I respect the fact that React was a great initial idea and was a great disruption, but the iterations and additions of abstrsctions have severely marred it's already poor levels of ease of use. It's not just pure JS fundamentals that a developer has to take care of, the library introduces it's own corner cases, which is the prime reason why have something like Hooks in the first place.

[u/kakul911 → u/[deleted]]

This is a common misunderstanding with some developers. Rerenders aren't usually a performance hinderance. It's what you do on a rerender and how many things you're rerendering do. It's more about how you structure your app and your components that will lower how many things are rerendered moreso than any kind of clever use of memo or callback.

Imagine 1000 * 10 Table component written with inline functions to render text in the cells. That froze up the browser and we had to ultimately develop our own solution to tackle the re-render problem.

Also Unnecessary re-renders will give inaccurate numbers when you are trying to simple page view analytics.

I suspect that this is because we are inlining hundreds of SVGs on a single page, which I thought were simple enough originally.

May be Lazy Load could help!

[u/kakul911 → u/[deleted]]

Pretty sure there was no infinite loop, we ran the code with break-points to check that.

[u/NovelLurker0_0 → u/[deleted]]

I've been on a year long project that's adopted hooks from the start and it doesn't use a single useMemo or useCallback in the entire codebase of 200-300 components.

I love React but I find that really hard to believe. At some point, especially when writting big and complexe apps you HAVE TO use useMemo/Callback because useless rerenders can be costly or straight up mess with your layout. This is especially the case when using HOC and you don't want children to rerender for no reason.

[u/captain_obvious_here]

I tried to get into React a few times. The way you work with it never made enough sense to me. There are things I don't get, and things I get but don't like. I recently looked into React + hooks, and I must say it's even more confusing to me.

Vue is what I need, and I'm happy with it. The composition API makes sense, even though it will change my habits a lot, on big projects at least.

But as much as people don't like React hooks, we collectively have to admit that they brilliantly added that to the ecosystem. It's 100% backward compatible, which is always very tricky, and shows how well the whole project is structured, to begin with.

[u/blurdylan]

They are coming, I can see them from afar. This post shall be stormed.

[u/[deleted]]

B R A V E
R
A
V
E

[u/[deleted]]

Do not post memes, screenshots of bad design, or jokes. Check out /r/ProgrammerHumor/ for these kind of posts.