React Still Feels Insane and No One Is Talking About It(mbrizic.com)
mbrizic.com
React Still Feels Insane and No One Is Talking About It
https://mbrizic.com/blog/react-is-insane/
40 comments
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
This is what happens when a V also wants to do the M and the C.
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.
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.
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?
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.
HTML5 as in no JS? So full page loads after every click?
View transition API helps mitigate this.
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.
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.
Progressive. Enhancement.
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.
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.
If by 'nicer' one wants to avoid the flash of blank between clicks, then I don't see how you'd avoid recreating an SPA
This doesn't happen for me when clicking around sites like HN or my blog, both are server side rendered and I'm on a pretty flakey connection right now. Browsers solved this a long time ago with how they deal with page changes.
your connection is not flaky enough. for me the average page load on HN is a full second. i just had one page take 1.8 seconds...
(edit) submitting this comment took 1.5 seconds.
(edit) submitting this comment took 1.5 seconds.
I read the server-side-rendered forums of DLang, and everything happens so fast, in around 200 ms, that I don't feel I am losing anything by the forums not being an SPA.
The View Transitions API (https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...) is intended to let you control transitions between clicks.
I mean, is this really a legitimate problem? Full page reloads don't bother me very much at all, and they actually come with a lot of niceties. Like URLs and the back button working normally.
For me personally, not usually. But having worked on a few different companies with embeddable widgets, yes it is. The page-based (SSG) routing is not an option there. And even in CRUDs the product folks want WYSIWYG and smooth uploads of assets. With more and more bling it's just inevitable that one will need a JS framework eventually.
Browsers haven’t left a flash of blank for decades.
That's what frames are for!
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"
>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"
More likely they don't even need to use useMemo if it's not an expensive calculation. They can just calculate the dependent values during rendering, which is explained in the docs: https://react.dev/learn/you-might-not-need-an-effect#updatin...
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.
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.
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.
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.
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.
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.
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.
HOC with render prop in 2025 https://github.com/TanStack/form/pull/1469
Render props in 2025 https://react-spectrum.adobe.com/react-aria/Dialog.html#aler...
and there's more examples, just couldn't find more without looking
just saying, in general I agree, but they still have their place
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.
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.
This article reads as:
"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
"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
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.
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.
You're right.
It was solved with Silverlight - declarative UIs in XAML. No CSS. Strongly typed C#. The downside was you needed to install the plugin.
So there are better ways than HTML/CSS/JS but we're stuck with them, because they are browser-native. WASM might rescue us!
I've at least managed to almost completely get rid of JS/SPA framework madness in the browser by going back to server rendered pages (adding reactivity where needed with datastar signals). Datastar is a breath of fresh air and might just make all SPA frameworks obsolete (just as they in turn killed jQuery).
It was solved with Silverlight - declarative UIs in XAML. No CSS. Strongly typed C#. The downside was you needed to install the plugin.
So there are better ways than HTML/CSS/JS but we're stuck with them, because they are browser-native. WASM might rescue us!
I've at least managed to almost completely get rid of JS/SPA framework madness in the browser by going back to server rendered pages (adding reactivity where needed with datastar signals). Datastar is a breath of fresh air and might just make all SPA frameworks obsolete (just as they in turn killed jQuery).
My personal take is largely to blame the css/html divide as the biggest hurdle here. Maybe it is the three fold css/html/js divide, more broadly?
It isn't that any one of them is bad. But, having three seems to want to relate to a Conway's Law where you have three different "teams" somewhat collaborating with each other. In reality, far more is done by a single team than otherwise. Even when you have a graphics design team, often they build their first artifacts in other systems and then it is down to that single team to try and bridge them together.
There is also the absurd level of flexibility that was baked into CSS. Somewhat ironic that we are digging our way out of the limitations of CSS by adding more and more flexibility to it.
It isn't that any one of them is bad. But, having three seems to want to relate to a Conway's Law where you have three different "teams" somewhat collaborating with each other. In reality, far more is done by a single team than otherwise. Even when you have a graphics design team, often they build their first artifacts in other systems and then it is down to that single team to try and bridge them together.
There is also the absurd level of flexibility that was baked into CSS. Somewhat ironic that we are digging our way out of the limitations of CSS by adding more and more flexibility to it.
Yes, the original set of web technologies was simply not designed with the kinds of interactive UIs people expect today.
Perhaps in the future UIs can be rendered with WASM, with the common rendering libraries being distributed as a separate WASM module (so users would not have to repeatedly download large files)?
Perhaps in the future UIs can be rendered with WASM, with the common rendering libraries being distributed as a separate WASM module (so users would not have to repeatedly download large files)?
I remember the disaster that was Angular 2. At least for developers.
We haven't progressed much since then. Or we have, I really like VueJS.
We haven't progressed much since then. Or we have, I really like VueJS.
[deleted]