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.
Yes, it needs to work, fully, without CSS or JS. Then, use CSS to make it look nicer, and use JS to make it behave nicer.
The total failure of most people who build professional web sites to follow standards and make them pain-free continues to baffle me, when it’s not that hard to do right and helps ensure the site is maintainable going forward, regardless of which new JS library or framework becomes popular.
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.
I'll point out that just on this comment string from telmac are 3 different interpretations of what is wrong with the code and what should be done instead.
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.
Readit News
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.
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?
But datastar (they just released v1 2 days ago) is even better.
MPA, server-rendered, but with client-side reactivity pushed from the server via SSE.
It's pretty impressive - better than HTMX imho.
Yes, it needs to work, fully, without CSS or JS. Then, use CSS to make it look nicer, and use JS to make it behave nicer.
The total failure of most people who build professional web sites to follow standards and make them pain-free continues to baffle me, when it’s not that hard to do right and helps ensure the site is maintainable going forward, regardless of which new JS library or framework becomes popular.
>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.
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.
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.
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 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.
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.
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.