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.
"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
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 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 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.
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)?
We haven't progressed much since then. Or we have, I really like VueJS.
