Kind of annoyed at React

https://blog.cassidoo.co/post/annoyed-at-react/

by bpierre • 3 years ago

99 129 3 years ago

blog.cassidoo.co

yevyevyev• 3 years ago

Good point on the two Reacts. Call me old-fashioned, but I still prefer being able to serve a React app over a CDN instead of needing a Node.js server. Might be in the minority these days though.

qprofyeh• 3 years ago

Share the same sentiment. React has gotten weird. It feels like they took a perfectly done design and awkwardly pushed it over its boundaries. (They got away with hooks, but this time it’s different)

Funny thing is they say it’s for the DX to become more like PHP. But the PHP I remember was practical.

noncoml• 3 years ago

For those that are not following very closely, what came after the “hooks” that took it too far?

dullcrisp• 3 years ago

Next.js and server side components

yawnr2• 3 years ago

Server side rendering / server components / pushing NextJS on everyone

karaokeyoga• 3 years ago

Server components, which are in Next.js (using React's canary branch). Server components are not yet in official (i.e. non-canary) React, and the React team supports this move (as do I). I just wish that the tool that was so helpful with the "other" (100% client-side) React, "Create React App", was better supported these days.

brigadier1326• 3 years ago

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 into these blobs of non-deterministic async state with unpredictable performance.

I actually like JSX and the component model so I just use solid-js which is everything I like about react but with effortless performance and you can actually get away with never using effects so your code can actually be deterministic.

ricardobeat3• 3 years ago

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 the community realizing this, but also sad that this is how things work now. The rise and fall of React will have been both a product of social media / developer celebrities.

coolThingsFirst4• 3 years ago

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.

leeeeeepw• 3 years ago

Some big apps are actually unusable slow for me on crazy fast hardware, I'm talking typing on textboxes not having good fps on Facebook... Fml

franciscop• 3 years ago

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 anymore" trope (that older workers have been saying for over 100 years).

ryukoposting• 3 years ago

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.

brigadier1326• 3 years ago

Technology ages, I remember liking React a lot way back in the day. Things improve and circumstances change. Things like the virtual dom are just not needed anymore and I just want my frontend code to be deterministic, it's not like I'm writing a distributed system, it's a client ui. So calling React "fundamentally bad" is harsh but I think given the state of the world today it's true.

piva00• 3 years ago

Coming from the assumption that Facebook should have tons of experienced people using React, their implementation on Facebook.com just plainly sucks after 7+ years. The UI is slow, breaks back button navigation often, loads completely different views in case a tab goes into background and gets reloaded (I have multiple tabs open from FB Groups that interested me, many of them default to opening my Home feed or the Groups main page after a background reload).

If Facebook.com cannot get it right, who actually can?

"No True Scotsman" is also a trope going on for > 100 years, yet you are appealing to it.

vinniepukh2• 3 years ago

React was a massive improvement over Ember.js, Backbone.js and their ilk, which at the time as a young dev I couldn’t grasp by myself.

React, however just clicked. f(state) = UI just makes sense

shutupnerd00002• 3 years ago

Which is not at all how it works in practice. In a large React codebase you have state scattered throughout contexts, GraphQL caches and complex hook dependency trees.

Throw in SSR and component memoization and you really have no idea what caused a UI change to occur.

Mandatum• 3 years ago

Hence, Redux.

neya• 3 years ago

Maybe, it's just me - I miss the good old days when sites didn't have anything to do with react or similar. Everything was just plain old hyperlinks and some basic JS. I am not even talking about the 90s, just look at what Facebook used to be in its early days - such a simple UI, just based off of hyperlinks, very basic JS. That simplicity alone made it such a joy to use.

Today, I don't even feel like logging into Facebook, because a fucking dropdown menu for a post (which barely has 4-5 options) is a Component that is loaded via AJAX. This is not even an overstatement.

I miss the simplicity of the web.

lancesells• 3 years ago

I don't think it's just you. Plain hyperlinks coupled with modern connections and equipment feels fast and easy. You click and a page appears. With JS apps they just feel heavy and almost buggy even when it is just a page of text with links.

Maybe I'm just in adt and marketing ech too much but it's almost like I can't be too fast on clicking thing otherwise things get fucked up and lose their states.

andix13• 3 years ago

I miss the good old days without the internet.

Tommah• 3 years ago

I was always surprised that a bunch of people looked at Facebook's website and said, yeah, I want their code to be the next big JS framework. Facebook has behaved for me for the past year or so, but for years prior to that, visiting their site was just an exercise in frustration for me. It was mainly because of components that remained in the gray loading state but never loaded. The messaging window used to do that for me about 50% of the time. Whenever I visited Facebook, I used to instinctively put my fingers over Ctrl-R in case I had to reload.

Also, one time, they managed to deploy code that broke form submissions under Firefox but not Chrome. I would be more understanding if it dealt with some cutting-edge features of HTML, but these are HTML forms. Mosaic had support for them in 1993.

breadwinner• 3 years ago

it’s not clear/an easily understandable mental model for most people

That's already the case, thanks to hooks. Hooks are weird, and should not be taught to junior programmers because it will confuse them for the rest of their careers. Hooks are weird because it doesn't align with functional programming paradigm or with OOP paradigm... it is a new paradigm and it is like nothing else.

More on that: https://medium.com/codex/can-we-all-just-admit-react-hooks-w...

andix13• 3 years ago

I totally disagree. React hooks are one the best things ever invented.

notpachet5• 3 years ago

one the best things ever invented

Fire? The wheel? Penicillin?

Maybe it's just because I'm getting older, but I'm increasingly annoyed when people use these sorts of over-the-top hyperboles.

ervine5• 3 years ago

I'll never understand the "hooks are bad" people. I don't find useEffect confusing, creating custom hooks is a breeze, life is so much better than old class components.

When I read complaints about hooks I'm either missing something fundamental about why they're bad, or the people complaining are missing it.

artdigital• 3 years ago

Yeah I never found them difficult and they’re making my life so much easier

Curious what specifically about them is difficult or hard to understand?

danielvaughn2• 3 years ago

Some people find the mental model to be very confusing. I've been writing hooks for years so intuitively, the behavior has sunk in. But I still admit that it's mind bending to try and understand how it actually works. The original commenter is absolutely correct that it diverges from both functional and OOP, and while that's not necessarily a bad thing, it's reasonable for people to consider it a net negative.

brigadier1326• 3 years ago

"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.

ramoz• 3 years ago

From my experience (picked up react when it came out) hooks are not objectively better than class components in a standard web app. In the more reactive scenarios hooks are great, and your app is already complex and in its own world of mental models.

Hooks enable complex patterns too easily and I think this causes a lot of breakdown in what would otherwise be simple applications.

vinniepukh2• 3 years ago

the problem with useEffect is how much it gets used when it doesn’t have to be

its overuse makes it evident that hooks (or React in general) is poorly understood

lopatin• 3 years ago

As someone who was into higher order components but left front end work before hooks were a thing, I’m wondering how the programming experiences are different are different between the two. It seems to me like more or less the same thing but hooks have more magic? Is it just a syntactic difference or are hooks a paradigm shift even further than HOC?

ok_dad2• 3 years ago

Hooks are a new paradigm? That’s news to me, hooking is at least as old as two decades when I first started programming. Hooks are, like most programming ideas, hard to understand at first but easier as time passes and you see more of them.

scotty7913• 3 years ago

It's fairly new to react and has a very specific meaning there. I don't think they are similar to any generic concept of hook.

rmccue8• 3 years ago

I agree. Up until Hooks, you could make your own toy React pretty easily if you wanted to - creating a basic, unoptimised version took a few hours. That made the whole system pretty understandable, especially for junior developers - obviously, you'd always pick the battle-hardened, optimised real React for anything serious.

Hooks fundamentally altered the contract about the API that React provided, and suddenly magic was popping up everywhere. Thankfully suspense never really caught on, because that was even more magical.

I do quite like the developer ergonomics of hooks, but it does make me wonder about whether there was a world in which we could have had both the ergonomics _and_ something less magical.

(Aside: that Medium article is available to members only.)

ervine5• 3 years ago

But all the lifecycle methods were magic that needed to be understood... hooks just let you co-locate related logic in one place instead of scattered across 3 or 4 lifecycle methods.

danpalmer2• 3 years ago

I don't think new paradigms are a bad thing, I think the problem with hooks is that they are a "clever trick" to work around the fact that the language/runtime does not have the necessary features to support the developer experience that they would ideally have.

What's sad is that the class-based component system did have those necessary features, it also had a nice distinction between components and their lifecycle and the rest of your code. Now with hooks, everything is React lifecycle code, unless you're really smart about your API boundaries, and in my experience no one makes good re-usable hooks that are nicely isolated from business logic.

drewcoo• 3 years ago

they are a "clever trick" to work around the fact that the language/runtime does not have the necessary features to support the developer experience that they would ideally have

I'd call that a pretty good definition of a "design pattern."

In this case, it's also magic framework code.

yawnr2• 3 years ago

I sorta feel the same way. I used to be excited to spin up a react project, and loved working with it daily for 8+ years. It really was wonderful. Junior devs used to be able to write clear, performant, bug free code in react without a ton of hand holding. One of its greatest testaments. Now you need to spend 20 minutes figuring out what someone is trying to accomplish with a useEffect hook with 10 dependencies and if it’s running as expected or if that dependency should be wrapped in a useCallback. :) And that’s without even getting into the deep end of server components and bifurcating your frontend into static server and client components and hydrating the dom and using next router and blah blah blah. And we are told to use a framework by a VC backed company because create react app isn’t maintained anymore? Ok. Gonna go write some erb in rails or something.

ryandetzel• 3 years ago

I think is because boot camps pushed out bad developers. You can write bad code in any language framework, react isn't any different. We now just have a ton of front end devs that don't understand how to write good software

notpachet5• 3 years ago

The React ecosystem has been trying very hard for a long time to enable developers to write code that is objectively bad, vis-a-vis colocation of concerns all in a single bigass, hard-to-understand function. Hooks were last straw for me, but the trend began before that.

React components should be simple stream transformers, nothing more. Accept props as input, produce deterministic HTML as output. All that other crap? Calling the API, massaging the data, business logic? That belongs somewhere else, outside of your component.

andix13• 3 years ago

What you're proposing sounds nice in theory. But interactive UI code is always kind of a mess. In my experience react is a very good middle ground.

And nobody is forcing react developers to mix too many responsibilities into one component.

notpachet5• 3 years ago

Nobody's forcing them, no. But often there isn't anyone preventing them, either. React happily hands these developers enough rope to hang themselves.

To be clear: I don't mind React per se. Some of the best UI codebases I've worked in were React -- they just had a very strict separation of concerns and one-directional data flow via something like MobX or Redux. All the business logic was kept separate from the UI. But that's not fashionable these days.

rmccue8• 3 years ago

Alongside the work on server components, they also deprecated Create React App, which was previously the official way to create new apps for development, and which had pretty good ergonomics. However, you won't find that documented on the actual CRA site - when you go looking for why your dependencies are out of date, you'll find references in obscure GitHub issues: https://github.com/reactjs/react.dev/pull/5487#issuecomment-...

As much as I like the React team and appreciate their willingness to try things (and hooks have grown on me a little), they are human, and I think some of the decisions and direction they've taken things is a mistake.

I was part of the team who deliberated on the decision to use React over Vue in WordPress, and one of the reasons for my personal preference towards React was that it embraced JS rather than inventing a whole bunch of new things - yes, there was the funky syntax of JSX, but aside from that all the statements were regular JS, and it was much easier to conceptually understand than learning a new language. Hooks started taking us away from that, with weird functions that magically encapsulate state, and things like suspense and server components have strayed further from the light.

Making things like Next the official pathway to getting started with React is great and all for people building Node SPAs, but there's a whole wide world of software outside of that bubble, and I hope the React team peers out a little more often.

andix13• 3 years ago

Vite is the new unofficial CRA. Superior in nearly every aspect.

ervine5• 3 years ago

Man I agree with all your comments so far. You get it!

rmccue8• 3 years ago

That may be the case, but the communication on the changes is terrible. I only noticed CRA was even deprecated after needing to dive deep into upgrading a dependency, and eventually stumbling over the GH issue comment.

Like the original article, I’m just kind of annoyed at React about this. There’s probably great reasons to change (albeit, I don’t really think even that comment communicates them well), but it’s annoying.

Rapzid4• 3 years ago

But they pretty much snubbed Vite because it's not a "framework".

Similar to how Tanstack Query doesn't even mention MobX as a state management library. It's crazy how many people use MobX for beefy apps(even Microsoft use it) but how little attention it gets.

Rapzid4• 3 years ago

I'm not even sure what the deal is with suspense and the massive wait on it. They make it sound like it's some super advanced functionality you should never have to touch(because framework! so we'll not even tell you how to use it).. Yet Vue has had async component mounting forever and it just works. And it's so easy to understand they even explain it to you; you just return a promise that resolves to a component.

Totally agree with your point about node backends. So much of the world doesn't and is not going to have their backend entirely or partially on node. But to the authors point, Vercel is Reacts daddy now and daddy needs to sell some hosting(for a new pair of shoes).

jongjong• 3 years ago

React is overengineered. I guess it may have been worth it at some point in the past but the reality of browser tech has changed significantly and now there exist simpler ways to get superior results.

xeckr• 3 years ago

Has anything really changed since around 2021? That's when I started using it. And I never looked back, except for very simple projects where I use vanilla HTML/CSS/JS.

claytongulick• 3 years ago

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.

000ooo000• 3 years ago

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

muratsu2• 3 years ago

Nextjs is pushing for the server components and I don't really blame them for doing so. Netlify is trying to back anything that's not nextjs. If anything I'm kind of surprised that big cloud players are completely ignoring this market right now.

andix13• 3 years ago

The more I get into RSC I have the feeling their main purpose is to pump up Vercel bills. A reason to buy more of their expensive compute resources.

They are nice in theory, but I don't see that many benefits over simple SSR, or the more traditional concept of server generated HTML with interactive islands.

Next.js applications often feel way less responsive than SPAs with proper pre-rendering on first load.

muratsu2• 3 years ago

The speed problem imo is completely fabricated and is an angle to sell you their cloud offering. The mobile web is already unusable thanks to cookie banners, various popups, and ads. Loading spinners are the equivalent of Don Quixote's windmills.

mentos• 3 years ago

I’ve never gotten into web development but enjoyed developing iOS apps in Obj-C or Android in Java.

Anyone recommend a website framework that might allow me to completely avoid html/css/javascript?

dimitrisnl• 3 years ago

There's nothing wrong with html/css/js. They are a joy to use really. We're just discussing the abstraction of React here. No need to completely disregard them. You can't eitherway.

evantbyrne2• 3 years ago

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.

yCombLinks• 3 years ago

I don't see where that was suggested. He's been using it 10 years. He doesn't like the way things are currently going.

evantbyrne2• 3 years ago

Same thing.

rickstanley• 3 years ago

We use Preact nowadays. It feels so much better and intuitive having first class support for ESM and use the browser's technologies for events, for instance. The TSX to JS transpilation is a bonus.

In general, for us: the Vite + Preact team feels just right.

bluedevil2k• 3 years ago

It’s frustrating that diversity efforts visibly took a backseat with React leadership

Who cares?!? Imagine trying to justify your decision to choose a framework to a manager by talking about their diverse leadership.

pard68• 3 years ago

The only React that should still exist is server side. The vdom has no place client side in 2024.

cosiiine• 3 years ago

Imagine no onClick() events smh…

kennu7• 3 years ago

A couple of things make React extremely valuable to me:

- The functional programming model (State => UI) allows building very complicated interfaces in a very simple way, by defining dependencies with useEffect() and other hooks. It can take years to master it, but when you develop complex apps where all kinds of state needs to update when some other state changes, you really appreciate how simple it is to do with React.

- React is very backward compatible and allows you to migrate codebases to newer React features slowly over the years, while already using those new features in other parts of the code. (I still have some class-based components here and there.)

- There is a huge ecosystem of existing React components and tools you can use in your applications. They make it a very productive environment to get stuff done quickly. Frameworks like Next.js make it a breeze to develop and deploy static apps e.g. to S3.

- You can apply your existing React skills to React Native when you need native apps.

scotty7913• 3 years ago

defining dependencies with useEffect()

Please don't. useEffect() is for pluging 3rd party DOM components into react. Not for doing anything else. Definitely not for any state manipulation or dependencies.

kennu7• 3 years ago

React documentation lists a lot of other use cases for useEffect() than just that:

- useEffect is a React Hook that lets you synchronize a component with an external system.

- Connecting to an external system

- Wrapping Effects in custom Hooks

- Controlling a non-React widget

- Fetching data with Effects

- Specifying reactive dependencies

- Updating state based on previous state from an Effect

- Removing unnecessary object dependencies

- Removing unnecessary function dependencies

- Reading the latest props and state from an Effect

- Displaying different content on the server and the client

https://react.dev/reference/react/useEffect#specifying-react...

shaunxcode• 3 years ago

Glad to be swapping ratoms while the hook phase of things resolves itself.

jauntywundrkind• 3 years ago

Everyone fucking off & writing frameworks that oh just so happen to be server side is incredibly bold self dealing. Now front and back end are deeply conflated, and instead of finding consistent controlled paradigms to tackle async on the front end we've just made an even bigger soup of what-renders-where-when.

We have been deeply mislead these past couple years. React ecosystem should have been working on better faster front end systems that integrate data better. Redux should just have been a start. Instead, managing data has gotten more complex and worse.

scotty7913• 3 years ago

Comments here show me that useEffect() is apparently incredibly hammer-shaped. And all things related to state and network look like nails in the eyes of frustrated React users.

I think those people would be better served by frameworks that hold fine grained reactivity as a virtue. If you have appetite for spaghetti at least use real pasta instead of trying to roll steak into thin stripes to tangle it.

nojvek• 3 years ago

No new releases since June 2022 is a good thing. At some point you declare React complete and you put it in maintenance/optimization mode. No new api surface. Full backwards compatibility.

React is darn good. Don’t mess with it and go into enshittificaion.

cassidoo• 3 years ago

Oh hey y'all, thanks for reading!

Rapzid4• 3 years ago

I feel like the lack of understanding comes from not communicating properly with the community

"Don't load data in useEffect!"

Okay, but [this and that and this] so how should you actually do this?

"Oh, use useEffect duh! We meant.. Don't, like, use it too much."

"And React function components should always be pure!"

Wait, aren't the hooks storing and mixing states into the function in a way that's almost creating a sorta sudo object? How is that pure?

"No, we mean 'they are pure!' when we want to be dismissive. Of course they are not really "pure".."

Edit: The one weird trick they don't want you to know and will have all the React CRUD kiddies screeching; Use useMemo to kick off work early ;)

AngeloAnolin• 3 years ago

Many people tend to gain a good understanding of React by building on top of it. Unfortunately, majority of the tutorials, lessons, recommendations, and paid courses usually start off using a framework where a lot of stuff have already been added. The effort to simply understand a complex setup as compared to starting React with the bare minimum and slowly adding whatever packages / libraries are needed.

React should start by a simple initialization: -> Setup React -> CSS library -> State management

And then, other packages or libraries can be considered to be added whenever the current needs of the application exceeds what the bare minimum setup has provided.

While in the end the set of packages and configurations performed may tantamount to what a framework already provides easily, the cognitive load starts on a piece that is well understood and grows alongside the evolution of the software product being delivered.

Kind of annoyed at React

Related Stories