Both React and Angular are poorly designed frameworks that require writing a fragile boiler plate. Try $mol - it is strikingly different from these two for the better. It continues the jQuery philosophy (write little, do a lot), but is optimized for creating truly large, but architecturally simple projects. There are many high-tech articles in the encyclopedia on the framework's website. For example, an article about React problems: https://mol.hyoo.ru/#!section=docs/=lre14i_zd4xlz
I'm struck thinking that this doesn't have to be the case, though? I see things like Mario Maker and struggle to understand why that sort of interface isn't doable in the workflows so many of us force ourselves into.
Even taking it to the abstractions you are using, manipulating a tree structure doesn't have to be slow. Indeed, you can manipulate a graph like structure representing millions of data points in very little time. Why is it that the tree structures we are talking about are so unnecessarily big and flow out their updates out in such a way that it takes so long?
You can make a perfectly effective UI in vanilla HTML5 and it will work forever, just like you can roll up for your date wearing practical clothes driving a 2002 Honda Civic, but you’re not guaranteed to look impressive enough to snare the targets. I think the point of all this JavaScript library evolution is not to be a good coder or a practical husband.
I was like "gosh I feel like he's just complaining about the organic complexity in the domain" and then he says it at the end:
>So, this entire rant about React... it's not even React's fault. Neither is Angular's, or jQuery's. Simply, whichever tech you choose will inevitably crumble down under the impossible complexity of building a reactive UI.
and then he's like "ok the solution is to just not make big interactive software" and I'm like bro that is the opposite of a solution
separately, and I'm not sure how much this is really a nitpick: the bit where he complains about the two useEffects, that's indeed disgusting but that's because whoever wrote it is an idiot, that should be useMemo, and then it would be obvious to read etc. (well, maybe besides dependency arrays being at the end) -- more broadly I'm a bit like "I think you spent <10 hours using a framework, found it confusing, and got buttmad", which, whom among us, but also once again "bro if you just actually read the docs and spend time with it it's fine"
If `getLinkedCats` calls an external API, then the calculation can instead be all in the same useEffect.
The number one mistake I see people inexperienced with React doing is using too many useEffect's in their code, which is both hard to read and hurts performance, since it results in more renders than necessary.
Yes, it's bad code, and aren't we all having fun laughing at the anonymous dev who wrote it.
However, I've seen this kind of code in the wild, and I'd be shocked if you hadn't, too. _Who_ wrote it matters a lot less than the fact that _so many people_ write it. I think that React has optimized for developer velocity, but the primitives make it so easy to shoot yourself in the foot, that in a large codebase with lots of devs, it becomes hard to avoid.
> the bit where he complains about the two useEffects, that's indeed disgusting but that's because whoever wrote it is an idiot, that should be useMemo, and then it would be obvious to read etc.
Given that of the three dependency items between the two useEffects, only one is actually used in the useEffect where it is listed as a dependency, there are deeper problems than using useEffect where they should probably be using useMemo there, but, yeah, it definitely looks like code written by someone clueless about React basics.
Coming from Angular, too, I never really liked React.
Angular had dependency injection and that made things so nice to work with.
React ended up with Redux and then contexts, which imo are both hacks in reaction to realising who in the fuck wants to pass down a singleton service component which maintains say a db connection down from the root of the project through all the damn layers of the app.
Define it at root, use in leaves via dependency injection. With Angular it was that simple.
Jsx/tsx was always hella cool though, I appreciate writing the v in the c, often with m. Angular from what I can recall was still very much mc, v.
Context is pretty much DI, but it works with the component tree - I can wrap different subtrees in different providers. This is much more powerful than angular style dependency injection and there have been several times where I was really grateful for it.
So, if I were to try to convince you just how wrong you are, what I would do is start with a React project that uses React-Router v7 with the data routers, including the `loader`. That one thing alone, even above and beyond what others are saying about React Query, just blows the whole complexity of API communication out of the water.
And then, if you are doing anything full stack or have a middleware/backend-for-frontend, for god's sake, look into tRPC and let your mind be blown.
Putting these two together, in a simple vite project (no full stack "framework" needed"), it will seriously just change the way you look at data, loading, and API interactions.
It just feels somewhat like the OP's problems with React are all skill issues and a lack of desire to explore and learn correctly.
I don't know, he made a great point about `useEffect` and its data flow and composability problem, which I've known for some time. The part about top down state being one giant mutable variable is true, but it's also how functional programming languages do it with a state-monad-esque runtime, like Elm. It's mostly a footgun when you're irresponsible cutting across many redux state machines in a single component.
I think the author is kind of a mediocre frontend eng but it's also true that modern react + hooks are full of footguns that can get very ugly. It's the opposite outcome of what react was originally designed for, to make it easy to do the right thing.
Redux is a simple and elegant idea from functional programming, but rather than build up more expressive composable abstractions, most things just ended up larding it up with more and more boilerplate. As for React, virtually every one of the footguns people complain about with regard to hooks was solved in Vue's reactivity system. I'm not so partisan as to suggest Vue is superior for all purposes, but there are just so many developers who seem willfully unaware that there is anything else out there other than React.
This article makes ME feel like I'm going insane. Have you even read the React docs?
The article you linked about "patterns" in React is explicitly referencing patterns that are 7+ years out of date. Hooks were built to REPLACE those patterns, and they did a phenomenal job.
90% of this article is immediately invalidated by introducing a simple, 20loc "useQuery" hook (or, god forbid, looking at ANY of the libraries that provide similar. Shoutout React Query)
I really wish we could get more valid critique of React from people who actually understand the framework, instead of this drivel from devs who spend more time complaining in blog posts than reading the docs.
When I saw the setState in useEffect, I immediately knew why the person hates react. That's a horrible antipattern used by people who refuse to read the few articles about useEffect and when to use it.
I agree about that specific patterns post being a bad example... but if you google for "react patterns" you won't be starved for examples of more terrible drivel. That's just what's out there, people repeat it ad nauseam. So _good luck_ to anyone who really does want to learn the right thing. From that standpoint, that article is as good or bad as most others out there (old man shakes fist at dev.to).
Even the venerable libraries like useQuery introduce as many surprises as they do benefits. The complexity cost of understanding what is going on under those 20 LOC is quite high – you need to understand "stable values" (which is only relevant to React components), re-renders and how they're triggered, maybe need to understand how graphql fragments are collated into one query document... maybe need to know when useRef is the right way to memoize over useMemo.
I agree with the author, that it feels insane. I would even add to the insanity the lack of quality when searching for help, and the weird rabbit holes that GPT can send you down if you don't already know what "good" looks like.
"I'm an incompetent frontend developer and don't know how to use React, so I just think project managers should not give tasks that make me do hard things because I just don't know how to do it... probably React's fault cause I'm perfect"
I would be interested in seeing a legit back and forth between this view and alternatives. Advocates of react, in particular, would be a good read after this.
The failure of every new solution seems to always come back to the fact that html, css, and js are just too poorly suited for building the complex UIs people want today. And the sad reality is that there isn't an engineer out there building these things that has any agency to come up with an alternative.
It would take Google, Apple, and Microsoft coming together to define a new system of building as an alternative. Think things like, new client, new protocol, new language, perhaps not having to write anything resembling markup at all (the joy!),
Obviously the chances of this happening are nil. So we shuffle along adding yet another layer of transformation on top of these broken technologies, hoping it will be enough.
nin-jin|7 months ago
beders|8 months ago
But I would say most front-end libraries are insane: Their job is to manipulate a tree structure which is kinda slow (still?).
Who would have thought that this problem has such a crazy solution space!
From jQuery to Knockout.js to Angular to Vue to React to Svelte and many many others.
Only a couple of those understand that V = f(state) is only half the equation.
taeric|8 months ago
Even taking it to the abstractions you are using, manipulating a tree structure doesn't have to be slow. Indeed, you can manipulate a graph like structure representing millions of data points in very little time. Why is it that the tree structures we are talking about are so unnecessarily big and flow out their updates out in such a way that it takes so long?
hyperhello|8 months ago
paulryanrogers|8 months ago
telmac|8 months ago
>So, this entire rant about React... it's not even React's fault. Neither is Angular's, or jQuery's. Simply, whichever tech you choose will inevitably crumble down under the impossible complexity of building a reactive UI.
and then he's like "ok the solution is to just not make big interactive software" and I'm like bro that is the opposite of a solution
separately, and I'm not sure how much this is really a nitpick: the bit where he complains about the two useEffects, that's indeed disgusting but that's because whoever wrote it is an idiot, that should be useMemo, and then it would be obvious to read etc. (well, maybe besides dependency arrays being at the end) -- more broadly I'm a bit like "I think you spent <10 hours using a framework, found it confusing, and got buttmad", which, whom among us, but also once again "bro if you just actually read the docs and spend time with it it's fine"
mehagar|8 months ago
If `getLinkedCats` calls an external API, then the calculation can instead be all in the same useEffect.
The number one mistake I see people inexperienced with React doing is using too many useEffect's in their code, which is both hard to read and hurts performance, since it results in more renders than necessary.
colinta|8 months ago
dragonwriter|8 months ago
Given that of the three dependency items between the two useEffects, only one is actually used in the useEffect where it is listed as a dependency, there are deeper problems than using useEffect where they should probably be using useMemo there, but, yeah, it definitely looks like code written by someone clueless about React basics.
fennecbutt|8 months ago
Angular had dependency injection and that made things so nice to work with.
React ended up with Redux and then contexts, which imo are both hacks in reaction to realising who in the fuck wants to pass down a singleton service component which maintains say a db connection down from the root of the project through all the damn layers of the app.
Define it at root, use in leaves via dependency injection. With Angular it was that simple.
Jsx/tsx was always hella cool though, I appreciate writing the v in the c, often with m. Angular from what I can recall was still very much mc, v.
penguibird|7 months ago
eslachance|7 months ago
And then, if you are doing anything full stack or have a middleware/backend-for-frontend, for god's sake, look into tRPC and let your mind be blown.
Putting these two together, in a simple vite project (no full stack "framework" needed"), it will seriously just change the way you look at data, loading, and API interactions.
It just feels somewhat like the OP's problems with React are all skill issues and a lack of desire to explore and learn correctly.
lorenzq|7 months ago
I think the author is kind of a mediocre frontend eng but it's also true that modern react + hooks are full of footguns that can get very ugly. It's the opposite outcome of what react was originally designed for, to make it easy to do the right thing.
chuckadams|8 months ago
theobr|8 months ago
The article you linked about "patterns" in React is explicitly referencing patterns that are 7+ years out of date. Hooks were built to REPLACE those patterns, and they did a phenomenal job.
90% of this article is immediately invalidated by introducing a simple, 20loc "useQuery" hook (or, god forbid, looking at ANY of the libraries that provide similar. Shoutout React Query)
I really wish we could get more valid critique of React from people who actually understand the framework, instead of this drivel from devs who spend more time complaining in blog posts than reading the docs.
penguibird|7 months ago
CanRau|7 months ago
colinta|8 months ago
Even the venerable libraries like useQuery introduce as many surprises as they do benefits. The complexity cost of understanding what is going on under those 20 LOC is quite high – you need to understand "stable values" (which is only relevant to React components), re-renders and how they're triggered, maybe need to understand how graphql fragments are collated into one query document... maybe need to know when useRef is the right way to memoize over useMemo.
I agree with the author, that it feels insane. I would even add to the insanity the lack of quality when searching for help, and the weird rabbit holes that GPT can send you down if you don't already know what "good" looks like.
pablomayobre|7 months ago
"I'm an incompetent frontend developer and don't know how to use React, so I just think project managers should not give tasks that make me do hard things because I just don't know how to do it... probably React's fault cause I'm perfect"
Author is just plain bad lol
taeric|8 months ago
cline6|8 months ago
It would take Google, Apple, and Microsoft coming together to define a new system of building as an alternative. Think things like, new client, new protocol, new language, perhaps not having to write anything resembling markup at all (the joy!),
Obviously the chances of this happening are nil. So we shuffle along adding yet another layer of transformation on top of these broken technologies, hoping it will be enough.
Shorel|8 months ago
We haven't progressed much since then. Or we have, I really like VueJS.
FireSquid2006|8 months ago
rmcsharry|7 months ago
unknown|8 months ago
[deleted]