Live data from Hacker News

Kind of annoyed at React

blog.cassidoo.co

51–60 of 135 posts

Re: Kind of annoyed at React

#51
post #48
post #42

Earlier quoted context omitted.

Isn't useSyncExternalStore the recommended hook for API requests? And for making API requests I think most people recommend using a library. React-query, RTK or swr for example. For accessing browser apis useEffects are the way to go, but those are usually extremely easy to understand in my experience. Or just use a library that provides the needed functionality.

Per the blog post announcing it, it's not recommended that you use that hook directly, only in libraries: > useSyncExternalStore is intended to be used by libraries, not application code. https://react.dev/blog/2022/03/29/react-v18#usesyncexternals...

I know. So either use an existing library or build your own. But don't useEffect instead.

Re: Kind of annoyed at React

#52
It is ridiculous to suggest that React is worse today than ten years ago. Remember all that time people spent battling their build scripts? Or what about the obtuse 3rd-party state management libraries everyone used to augment class components? It was torturous from the start.

Re: Kind of annoyed at React

#53
post #33

Earlier quoted context omitted.

One of the best things ever invented in component based frontend frameworks. It makes purely functional frameworks like modern react much easier to deal with. Off course it's a violation of some theoretical principals. So what? What I don't get: people complain about not being able to handle all the useEffects, but they probably shouldn't be there in the first place. In my experience most ambiguous use effects can be…

> people complain about not being able to handle all the useEffects, but they probably shouldn't be there in the first place I think this is the crux of the issue. One's view of hooks depends a lot on the sorts of codebases they've worked in. Maybe the sun has always shone on you, and you've only ever worked in projects where hooks have been used sparingly and with great consideration. You're very fortunate if so. I'…

Yeah that's a great point. Nothing makes me start really looking closely at a merge request than when a useEffect shows up.

Re: Kind of annoyed at React

#54

I've been enjoying the simplicity vanilla light-dom custom elements and minimalist express server for the API. Lit-html for near zero-cost dom updates. Been doing it for years, and struggle to understand why anyone would want to put up with the complexity of react.

Also using Lit for personal projects and it reminds me of the time I didn't dislike React.

Re: Kind of annoyed at React

#55

Earlier quoted context omitted.

"useEffect" itself is not what is confusing. What's confusing is when you have many dozens of components with effects all loading state asynchronously. Some of them might even be executing callbacks passed as props from parent components. Oh, and then those effects sometimes re-execute when the effects of parent components complete and pass down updated props! It actually reminds me of programming VHDL.

If you have dozens of components with dozens of uncontrolled side effects executing in unpredictable order, then nothing is going to help you until you get those effects under control. It'll still be bad architecture with or without hooks.

> It'll still be bad architecture with or without hooks

The companies I've worked with had hundreds of engineers contributing to the react codebases and people are just trying to crank out features by the deadline. I'd rather just work with tools that don't require the usage of such obvious footguns. You can code solid-js and svelte and never use effects (even though they do offer them unfortunately).

Re: Kind of annoyed at React

#56

React is fundamentally bad technology. I know there are historical reasons for the virtual dom but the reasons that justified it don't exist anymore. If you want to do anything interesting with react that involves interacting directly with browser APIs you need to deal with these absurd use effect hoops to initiate state with references to dom nodes. I've worked on 4 large react code bases and they always devolve int…

I've worked in many react codebases, some great some not, and the main predictor of the quality tends to be both the dev lead knowledge, the experience of the team and the learning vs churn out features culture. Same thing used to happen with jQuery BTW, only it was a lot easier to shoot yourself on the foot back then. I feel like "X new library/framework's code is a mess" is the new "People don't want to work anymor…

> the dev lead knowledge, the experience of the team and the learning vs churn out features culture

This could be said of any team using any technology. If the team is better at using it, and they are provided more time to use it properly, then they'll make a better product. That's not unique to React.

React sucks because its scope creep makes it difficult to maintain, and there's a pretty low ceiling for the end user's experience. Yes, better teams can make better products with React than worse teams, but that doesn't mean that either end product is any good.

Re: Kind of annoyed at React

#57

React is fundamentally bad technology. I know there are historical reasons for the virtual dom but the reasons that justified it don't exist anymore. If you want to do anything interesting with react that involves interacting directly with browser APIs you need to deal with these absurd use effect hoops to initiate state with references to dom nodes. I've worked on 4 large react code bases and they always devolve int…

[deleted]

Re: Kind of annoyed at React

#58

React is fundamentally bad technology. I know there are historical reasons for the virtual dom but the reasons that justified it don't exist anymore. If you want to do anything interesting with react that involves interacting directly with browser APIs you need to deal with these absurd use effect hoops to initiate state with references to dom nodes. I've worked on 4 large react code bases and they always devolve int…

[deleted]

Re: Kind of annoyed at React

#59
post #53

Earlier quoted context omitted.

> people complain about not being able to handle all the useEffects, but they probably shouldn't be there in the first place I think this is the crux of the issue. One's view of hooks depends a lot on the sorts of codebases they've worked in. Maybe the sun has always shone on you, and you've only ever worked in projects where hooks have been used sparingly and with great consideration. You're very fortunate if so. I'…

Yeah that's a great point. Nothing makes me start really looking closely at a merge request than when a useEffect shows up.

My junior developers started to come to me with the question: how can I do this without useEffect? Because they already know that their PR will be rejected. Usually we can figure it out within a few minutes, and make everything less complicated.

People are just way too much thinking imperatively, like decades of OOP thought them (and many of their educators). Most naive useEffects are just masked derived state.

Re: Kind of annoyed at React

#60

Earlier quoted context omitted.

> they always devolve into these blobs of non-deterministic async state with unpredictable performance Exact same experience here. I've been banging this drum for years. When hooks came around I thought they might make it better, but alas, we are still in a downwards spiral. Building web apps is 10x more complicated today than it was ten years ago, with nothing to show for it. I'm happy to see some known voices in th…

Building web apps with React is just much faster than doing it without, even when using Angular complex apps will always be complex. You can’t have an easy solution when you have tons of interaction and state.

What else have you personally had experience with? Angular would not be in my list of better alternatives.

My comparison is always with Svelte / Vue, and also what we had in previous eras (Backbone, Knockout, etc). HTMx is picking up steam too. We used to push out interactive UI in days/weeks, and mind you, in the past websites did not look all the same. There were no component libraries to start from. Today it seems most React projects are planned in months/quarters despite being built atop a mountain of third-party code, all meant to 'speed things up'.

What we do today is not faster at all, too much time is wasted on tooling and issues that arise from React's architecture (hooks, ssr, data loading, error handling, async issues, black-box performance issues, dependency hell).

Post reply on HN