8 ms·

Kind of annoyed at React

99 points by bpierre 3y ago

yevyevyev 3y 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.
deleted 3y ago
[deleted]
- deleted 3y ago
  [deleted]
qprofyeh 3y 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 3y ago
  For those that are not following very closely, what came after the “hooks” that took it too far?
  - dullcrisp 3y ago
    Next.js and server side components
  - yawnr 3y ago
    Server side rendering / server components / pushing NextJS on everyone
  - karaokeyoga 3y 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.
    - bryik 3y ago
      Create React App is in a strange, pseudo-death state. - It is not listed as an option for starting a new project in the React docs[0]. - The last release was April 12, 2022. - The last time I created a new project with CRA, it printed a console log that claimed CRA was deprecated. However, the message seemed to originate from a dependency rather than CRA itself. All this was enough to convince me to move to Next.js for future projects; though I find Next.js overcomplicated and full of things I will never use. 0 - https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project
      - rmccue 3y ago
        I mentioned this upthread, but the "official" deprecation notice is this comment from Dan Abramov in a GitHub issue: https://github.com/reactjs/react.dev/pull/5487#issuecomment-1409720741 https://github.com/reactjs/react.dev/pull/5487#issuecomment-...
brigadier132 3y 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.
- ricardobeat 3y 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.
  - coolThingsFirst 3y 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.
    - ricardobeat 3y ago
      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).
neya 3y 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 3y 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.
- andix 3y ago
  I miss the good old days without the internet.
- Tommah 3y 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 3y 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-were-a-bad-idea-c48120c5188d https://medium.com/codex/can-we-all-just-admit-react-hooks-w...
- andix 3y ago
  I totally disagree. React hooks are one the best things ever invented.
  - notpachet 3y 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.
    - andix 3y ago
      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 easily removed. They are rarely needed for anything but library code or interaction with browser APIs.
      - notpachet 3y ago
        > 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've seen some truly horrific hooks-enabled messes that have had to be outright abandoned because they became too complicated for anyone to understand or debug.
yawnr 3y 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 3y 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
notpachet 3y 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.
- andix 3y 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.
  - notpachet 3y 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.
    - andix 3y ago
      I have to say that I've seen Redux being abused until insanity (and probably misunderstood) much more often than hooks. And much harder to clean up that mess, because it's a centralized mess. The hook mess is usually decentralized and can be improved incrementally. What kind of frontend stack would you recommend that enforces keeping some meaningful separation of concern, without limiting productivity?
      - notpachet 3y ago
        I will concede your point about horrible Redux codebases. I think I've tried to push that dark era out of my mind. Without limiting productivity, I have no idea. I think you have to limit productivity along some axis or other, otherwise your codebase just turns to quicksand.
rmccue 3y 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-1409720741 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.
- andix 3y ago
  Vite is the new unofficial CRA. Superior in nearly every aspect.
  - ervine 3y ago
    Man I agree with all your comments so far. You get it!
  - rmccue 3y 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.
jongjong 3y 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 3y 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 3y 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 3y ago
  Also using Lit for personal projects and it reminds me of the time I didn't dislike React.
muratsu 3y 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.
- andix 3y 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.
  - muratsu 3y 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.
    - andix 3y ago
      I think it would be great to improve the speed of web applications. Including all the advertisements ;) But I'm really doubting if Next.js is actually solving this problem. They are heavily caching everyting, so it might bring big benefits with slow and weird backend systems.
mentos 3y 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 3y 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.
evantbyrne 3y 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 3y 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.
  - evantbyrne 3y ago
    Same thing.
rickstanley 3y 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 3y 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 3y ago
The only React that should still exist is server side. The vdom has no place client side in 2024.
- cosiiine 3y ago
  Imagine no onClick() events smh…
kennu 3y 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.
- scotty79 3y 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.
  - kennu 3y 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-reactive-dependencies https://react.dev/reference/react/useEffect#specifying-react...
    - scotty79 3y ago
      Just because you can doesn't mean you should. What you should have gotten from this list of every possible use (and misuse) of useEffect is that it's for interaction with external things. And if you are doing a lot of interafacing with external stuff you should use a dedicated service for it, not pollute your code with ad-hoc bits of interaction, each wrapped in their own bespoke useEffect(). And the linked section talks about specifying dependencies of the code block inside useEffect() You don't define dependencies WITH useEffect. You define dependencies OF useEffect. And you don't have much choice in the matter. Any local variable (also parameter) of render function needs to be a dependency of useEffect code. As this section states. Here are some common misuses: https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect
shaunxcode 3y ago
Glad to be swapping ratoms while the hook phase of things resolves itself.
jauntywundrkind 3y 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.
scotty79 3y 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 3y 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 3y ago
Oh hey y'all, thanks for reading!
Rapzid 3y 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 3y 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.

99 points by bpierre 3y 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.

deleted 3y ago

[deleted]

deleted 3y ago
[deleted]

qprofyeh 3y 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 3y ago
For those that are not following very closely, what came after the “hooks” that took it too far?
- dullcrisp 3y ago
  Next.js and server side components
- yawnr 3y ago
  Server side rendering / server components / pushing NextJS on everyone
- karaokeyoga 3y 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.
  - bryik 3y ago
    Create React App is in a strange, pseudo-death state. - It is not listed as an option for starting a new project in the React docs[0]. - The last release was April 12, 2022. - The last time I created a new project with CRA, it printed a console log that claimed CRA was deprecated. However, the message seemed to originate from a dependency rather than CRA itself. All this was enough to convince me to move to Next.js for future projects; though I find Next.js overcomplicated and full of things I will never use. 0 - https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project
    - rmccue 3y ago
      I mentioned this upthread, but the "official" deprecation notice is this comment from Dan Abramov in a GitHub issue: https://github.com/reactjs/react.dev/pull/5487#issuecomment-1409720741 https://github.com/reactjs/react.dev/pull/5487#issuecomment-...

brigadier132 3y 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.

ricardobeat 3y 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.
- coolThingsFirst 3y 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.
  - ricardobeat 3y ago
    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).

neya 3y 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 3y 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.
andix 3y ago
I miss the good old days without the internet.
Tommah 3y 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 3y 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-were-a-bad-idea-c48120c5188d https://medium.com/codex/can-we-all-just-admit-react-hooks-w...

andix 3y ago
I totally disagree. React hooks are one the best things ever invented.
- notpachet 3y 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.
  - andix 3y ago
    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 easily removed. They are rarely needed for anything but library code or interaction with browser APIs.
    - notpachet 3y ago
      > 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've seen some truly horrific hooks-enabled messes that have had to be outright abandoned because they became too complicated for anyone to understand or debug.

yawnr 3y 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 3y 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

notpachet 3y 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.

andix 3y 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.
- notpachet 3y 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.
  - andix 3y ago
    I have to say that I've seen Redux being abused until insanity (and probably misunderstood) much more often than hooks. And much harder to clean up that mess, because it's a centralized mess. The hook mess is usually decentralized and can be improved incrementally. What kind of frontend stack would you recommend that enforces keeping some meaningful separation of concern, without limiting productivity?
    - notpachet 3y ago
      I will concede your point about horrible Redux codebases. I think I've tried to push that dark era out of my mind. Without limiting productivity, I have no idea. I think you have to limit productivity along some axis or other, otherwise your codebase just turns to quicksand.

rmccue 3y 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-1409720741 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.

andix 3y ago
Vite is the new unofficial CRA. Superior in nearly every aspect.
- ervine 3y ago
  Man I agree with all your comments so far. You get it!
- rmccue 3y 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.

jongjong 3y 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 3y 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 3y 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 3y ago
Also using Lit for personal projects and it reminds me of the time I didn't dislike React.

muratsu 3y 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.

andix 3y 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.
- muratsu 3y 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.
  - andix 3y ago
    I think it would be great to improve the speed of web applications. Including all the advertisements ;) But I'm really doubting if Next.js is actually solving this problem. They are heavily caching everyting, so it might bring big benefits with slow and weird backend systems.

mentos 3y 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 3y 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.

evantbyrne 3y 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 3y 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.
- evantbyrne 3y ago
  Same thing.

rickstanley 3y 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 3y 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 3y ago

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

cosiiine 3y ago
Imagine no onClick() events smh…

kennu 3y 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.

scotty79 3y 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.
- kennu 3y 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-reactive-dependencies https://react.dev/reference/react/useEffect#specifying-react...
  - scotty79 3y ago
    Just because you can doesn't mean you should. What you should have gotten from this list of every possible use (and misuse) of useEffect is that it's for interaction with external things. And if you are doing a lot of interafacing with external stuff you should use a dedicated service for it, not pollute your code with ad-hoc bits of interaction, each wrapped in their own bespoke useEffect(). And the linked section talks about specifying dependencies of the code block inside useEffect() You don't define dependencies WITH useEffect. You define dependencies OF useEffect. And you don't have much choice in the matter. Any local variable (also parameter) of render function needs to be a dependency of useEffect code. As this section states. Here are some common misuses: https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect

shaunxcode 3y ago

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

jauntywundrkind 3y 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.

scotty79 3y 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 3y 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 3y ago

Oh hey y'all, thanks for reading!

Rapzid 3y 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 3y 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.