8 ms·

The more features React adds the less I end up using React. The new additions are just so inelegant, and don't fit my brain. The function useEffect has so many

The more features React adds the less I end up using React. The new additions are just so inelegant, and don't fit my brain. The function useEffect has so many caveats and such a terrible API. A magic "use client" string at the top of a file is just ridiculous. React code is nearly impossible to understand and write without extensive external documentation now. I feel sad for the future developer that has to modify this type of code ten years from now; I hope Google is good at searching decade old documentation to figure out what the hell is going on in old React code.

paulddraper 3y ago
> The function useEffect has so many caveats and such a terrible API. Really? What caveats? The only maybe oddity that I can think of is that if the deps array is omitted it always runs. What API would you prefer? Something more like signals?
- cjcenizal 3y ago
  This page[0] lists many situations in which useEffect shouldn’t be used. Some might seem counter-intuitive. [0] https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect
  - consilient 3y ago
    That's not a bunch of separate caveats, it's a few principles illustrated with lots of examples. - Don't use effects for things that aren't genuinely effectful - Put finnicky state management stuff in reusable utils instead of re-implementing it from primitives over and over again. Neither is React-specific.
  - paulddraper 3y ago
    tl;dr Don't use useEffect if there is an alternative. That's a bunch of examples where there are good alternatives.
  - Scarblac 3y ago
    In particular that it's OK to directly call setState inside functional components was a surprise to me (when I read that some months ago), it does make things simpler.
- SinParadise 3y ago
  Not useEffect specifically, but wiring something very stateful like a map library into the React rendering paradigm while keeping the state management in React via useState etc. can be very difficult to do so in a performant way. I recalling using a lot of useRef to manually tune when to re-render, and in an ideal world I shouldn't be this granular about it. You can certainly use one of the many React map wrapper libraries to lessen the pain, the pain is still very real, just dealt with by someone else.
  - nwienert 3y ago
    But what’s better? In the end you need control over stuff, it’s almost like people want frontend to be magically easy but unfortunately there’s just the reality that either you have high abstraction but less control, or low abstraction and more control (more code, more gotchas, etc) until you get a smart optimizing compiler ofc. Hooks imo are great, as they are pretty explicit and low level. Nowadays signals are the new kid on the block, though mobx and similar have existed since forever in react land, but they have their own crazy edge cases like reactive loops and implicit behavior.
    - SinParadise 3y ago
      I like Svelte. It embraces the fact that UI is stateful and doesn't try to pretend it isn't.
      - nwienert 3y ago
        I do too, I made this [0] 3 years before Svelte existed. But I don't think the "pretend it isn't" makes any sense, I actually like React more than Svelte for many reasons, but magic compilers and templates are two big ones. [0] https://www.youtube.com/watch?v=HHTYHm6qLFY&t=11s https://www.youtube.com/watch?v=HHTYHm6qLFY&t=11s
        SinParadise 3y ago
        Thats a cool project. >But I don't think the "pretend it isn't" makes any sense Well, let me expand a bit more. React's pitch is that view is a function of state, and essentially designed around the idea of an immutable state which re-renders everything when changed. It then offered some APIs to allow fine-tuning of rendering via hooks which either ties with data changes or some rendering life-cycle. To me the API screams of stubborn refusal to let go of the "view as a function of state" mantra: When you encounter a scenario where it breaks the mantra, lets add another lever to handle it. This lever also has to be pulled by you the developer, and it is up to you to know when to do it. >I actually like React more than Svelte for many reasons, but magic compilers and templates are two big ones. I don't really have an issue with compilers. They are the accepted magic that bridges between language for people and language for machines. The ideal language might be something that is functional and immutable language that it is easy for us to read, but compiles to the optimized, imperative updates that machine can run well. I'd probably like React better if it had a compile layer on top of its more functional parts? As for templates, JSX is probably the one great thing that came out of React. It is no wonder that many other frameworks are embracing JSX, but none of them are really forking the idea of hooks.
- foota 3y ago
  Personally, I grew to prefer signals and rx and APIs for heavy things. I wish it were easier to hook up some custom class object to a component to use as state, but it always feels clunky.
- toastercat 3y ago
  The dependency array is a huge footgun. Engineers, experienced and newbie alike, get it wrong all the time (either causing infinite render loops, or skipping necessary re-renders). This affects useCallback and useMemo as well. After a while, I stopped thinking "oh the developers just aren't doing it right" and more "the React team can do better than this." > What API would you prefer? Something more like signals? Yes. Or full tree redraws like Mithril.js did 8 years ago.
  - paulddraper 3y ago
    React does full tree redraws (well, unless you use memo). useEffect is for side-effects.
    - toastercat 3y ago
      It does not. Child components will only render when their parent component re-renders or for example, its state changes. Either way, this is different than what I mean with Mithril.js (it does full tree re-renders on event handler calls or when a manual redraw function is called).
    - Izkata 3y ago
      Class components have "shouldComponentUpdate()" that avoids this entirely.
  - tshaddox 3y ago
    Or you installed the lint rule once 4 years ago and never had a problem again.
    - gyanreyer 3y ago
      Agreed, everyone who complains about dependency arrays almost certainly hasn't used the linting rule. That being said, I'm not sure that an API is well-designed if the only way to use it effectively is by forcing you to even know there is an eslint plugin to begin with, and then once you do know that, that means now you're being forced to add eslint to your project whether you like it or not. And sometimes eslint just stops working for who knows what reason, I have a developer on my team who's constantly dealing with issues where his eslint/prettier setup isn't running correctly.
- danielvaughn 3y ago
  This may be a personal thing, but I really like reading and writing code that feels like it's telling a story. That is, operating sequentially (this happens, then this happens, then this other thing, etc). useEffect breaks the sequential nature of your code and makes it feel like you're reading a script from a Quentin Tarantino movie.
  - littlecranky67 3y ago
    Agreed, but non-sequential execution is the nature of event-driven, async non-blocking code. Event-driven as Web Applications (not Websites!) mostly deal with events (user input or network events). As long as the JavaScript VM and the DOM uses non-blocking async models no framework - being it Vue, Angular, React or whatnot - will ever change that. Sequential, blocking modells like i.e. batch ETL jobs are just not the domain of the browser.
    - SahAssar 3y ago
      > As long as the JavaScript VM and the DOM uses non-blocking async models The DOM is almost entirely sync, all the operations on it are blocking operations (including things like replacing an entire document with innerHTML).
      - littlecranky67 3y ago
        While not strictly on "the DOM", a lot of modern APIs are within the browser's JS VM (Notification, Camera, Audio, QR scanning, etc.) and all of them are async to the core. My argument therefore stands.
        SahAssar 3y ago
        It does not, since most of those APIs are not directly called from the framework. What react and most other JS frameworks do is DOM modification (which is clearly sync) and delegate events (which is usually done via callbacks or binding).
  - 3y ago
- Izkata 3y ago
  It does a shallow compare, not a deep compare. Workarounds tend to involve additional hooks: https://dev.to/vsramalwan/ways-to-handle-deep-object-comparison-in-useeffect-hook-1elm https://dev.to/vsramalwan/ways-to-handle-deep-object-compari...
  - vlod 3y ago
    I heard that immutability libraries like immer.js [0] help with this. Anyone go this way and had good success? Is this 'the way'? [0]: https://immerjs.github.io/immer/ https://immerjs.github.io/immer/
bakugo 3y ago
> I hope Google is good at searching decade old documentation Google isn't even good at searching recent documentation, from my experience.
champagnepapi 3y ago
Agreed. IMO, it all started with Hooks. Things really went downhill from there. useEffect is terrible! Example, how easy it to forget the dependency array?! Because of that, you have to setup linting rules to fix the poor API provided by that hook...
- hotnfresh 3y ago
  Hooks felt like a big make-work project to let folks claim high-impact commits on a project that didn’t really need any of those, anymore.
  - politelemon 3y ago
    What does this expression mean, make-work project?
    - hotnfresh 3y ago
      Digging a hole and filling it back up again. Work for the sake of having something to do.
      - politelemon 3y ago
        Ah I understand it now thanks. Not an uncommon thing in many places!
- paulddraper 3y ago
  HN is a funny place. A useful feature that an insane majority of React devs have come to prefer is "downhill." Kids these days.
  - toastercat 3y ago
    Many folks were criticizing hooks when they were introduced. Of course React devs will "prefer" it; they are the idiomatic way to adding state/triggering effects in React.
johngalt2600 3y ago
Agreed. React is great but I really do not enjoy writing it. Much prefer Vue
fidotron 3y ago
It will turn out to be a great conspiracy where the React team are being encouraged to make it so only LLMs can make sense of React code in future.
vlod 3y ago
I switched to React when jQuery (and particularly storing state in the DOM and lots of custom events called) became a PITA. I don't feel that React has reached that tipped point yet, but when it does I'm hoping we'll all move to Sveltekit or something like it.
- mattgreenrocks 3y ago
  I despise almost every single web framework written in the last decade. They always feel like byzantine monoliths of complexity built from tons of layers over existing libraries. They invent tons of concepts, always require patching, and have an army of sycophants who believe building a web framework is basically rocket science and only a select few are ever capable of such a feat. SvelteKit is the first piece of web tech that I actually enjoy using. It’s the rare piece of tech that knows its lane, stays in it, and excels at it. It is marked by fewer features that work well together vs lots of features that sort of work well together. You can read the docs in an hour or two and then start to get an understanding of what it’s doing. Basically, it feels like it was made by someone who really understands the medium, thought deeply about how to distill that, and iterated to improve on it. (I get same vibes from Vue, but don’t have much experience there)
  - paulddraper 3y ago
    I remember when HN said that about React. Lololol
    - mattgreenrocks 3y ago
      Totally fair comment. Time will tell. Edit: I'm just happy to find something that I like to make web stuff in. Now I can make some apps and actually enjoy the process.
phendrenad2 3y ago
This is how it always goes. JQuery was a response to browsers having poor standardization. Then it became a larger and larger ecosystem, and the code owners started getting megalomaniacal (I'm sorry, "live" is deprecated, please us the function "on" which does the exact same thing, we just liked the name better, thank you for complying). It became an ecosystem. Every 3rd party library was designed to integrate with JQuery. Soon there was JQuery UI, a UI library for adding modal dialogs and tooltips. And then someone realized that browsers had long since reached standards parity, and javascript engines were getting really fast, and re-rendering the DOM was GPU-accelerated, and we just needed a simple little library. And Angular and React were born (and Ember but we don't speak of satan in this house). React feels like it's following the exact same trajectory. It was created out of necessity, it was the best framework for a given point in time, but it's being stretched to handle the changing landscape, and it's feeling very kludgey. I expect that soon, very soon, someone will release the new paradigm. Probably just as soon as WASM is able to manipulate the DOM without JS hacks, which has been on the roadmap since before there was a road.
Exuma 3y ago
How do devs generally feel about Vue 3? So far it seems really amazing even for the most complex apps. I’ve built 5 nontrivial apps with 2 being 2+ year projects I haven’t found a “ceiling” yet

paulddraper 3y ago

> The function useEffect has so many caveats and such a terrible API. Really? What caveats? The only maybe oddity that I can think of is that if the deps array is omitted it always runs. What API would you prefer? Something more like signals?

cjcenizal 3y ago
This page[0] lists many situations in which useEffect shouldn’t be used. Some might seem counter-intuitive. [0] https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect
- consilient 3y ago
  That's not a bunch of separate caveats, it's a few principles illustrated with lots of examples. - Don't use effects for things that aren't genuinely effectful - Put finnicky state management stuff in reusable utils instead of re-implementing it from primitives over and over again. Neither is React-specific.
- paulddraper 3y ago
  tl;dr Don't use useEffect if there is an alternative. That's a bunch of examples where there are good alternatives.
- Scarblac 3y ago
  In particular that it's OK to directly call setState inside functional components was a surprise to me (when I read that some months ago), it does make things simpler.
SinParadise 3y ago
Not useEffect specifically, but wiring something very stateful like a map library into the React rendering paradigm while keeping the state management in React via useState etc. can be very difficult to do so in a performant way. I recalling using a lot of useRef to manually tune when to re-render, and in an ideal world I shouldn't be this granular about it. You can certainly use one of the many React map wrapper libraries to lessen the pain, the pain is still very real, just dealt with by someone else.
- nwienert 3y ago
  But what’s better? In the end you need control over stuff, it’s almost like people want frontend to be magically easy but unfortunately there’s just the reality that either you have high abstraction but less control, or low abstraction and more control (more code, more gotchas, etc) until you get a smart optimizing compiler ofc. Hooks imo are great, as they are pretty explicit and low level. Nowadays signals are the new kid on the block, though mobx and similar have existed since forever in react land, but they have their own crazy edge cases like reactive loops and implicit behavior.
  - SinParadise 3y ago
    I like Svelte. It embraces the fact that UI is stateful and doesn't try to pretend it isn't.
    - nwienert 3y ago
      I do too, I made this [0] 3 years before Svelte existed. But I don't think the "pretend it isn't" makes any sense, I actually like React more than Svelte for many reasons, but magic compilers and templates are two big ones. [0] https://www.youtube.com/watch?v=HHTYHm6qLFY&t=11s https://www.youtube.com/watch?v=HHTYHm6qLFY&t=11s
      - SinParadise 3y ago
        Thats a cool project. >But I don't think the "pretend it isn't" makes any sense Well, let me expand a bit more. React's pitch is that view is a function of state, and essentially designed around the idea of an immutable state which re-renders everything when changed. It then offered some APIs to allow fine-tuning of rendering via hooks which either ties with data changes or some rendering life-cycle. To me the API screams of stubborn refusal to let go of the "view as a function of state" mantra: When you encounter a scenario where it breaks the mantra, lets add another lever to handle it. This lever also has to be pulled by you the developer, and it is up to you to know when to do it. >I actually like React more than Svelte for many reasons, but magic compilers and templates are two big ones. I don't really have an issue with compilers. They are the accepted magic that bridges between language for people and language for machines. The ideal language might be something that is functional and immutable language that it is easy for us to read, but compiles to the optimized, imperative updates that machine can run well. I'd probably like React better if it had a compile layer on top of its more functional parts? As for templates, JSX is probably the one great thing that came out of React. It is no wonder that many other frameworks are embracing JSX, but none of them are really forking the idea of hooks.
foota 3y ago
Personally, I grew to prefer signals and rx and APIs for heavy things. I wish it were easier to hook up some custom class object to a component to use as state, but it always feels clunky.
toastercat 3y ago
The dependency array is a huge footgun. Engineers, experienced and newbie alike, get it wrong all the time (either causing infinite render loops, or skipping necessary re-renders). This affects useCallback and useMemo as well. After a while, I stopped thinking "oh the developers just aren't doing it right" and more "the React team can do better than this." > What API would you prefer? Something more like signals? Yes. Or full tree redraws like Mithril.js did 8 years ago.
- paulddraper 3y ago
  React does full tree redraws (well, unless you use memo). useEffect is for side-effects.
  - toastercat 3y ago
    It does not. Child components will only render when their parent component re-renders or for example, its state changes. Either way, this is different than what I mean with Mithril.js (it does full tree re-renders on event handler calls or when a manual redraw function is called).
  - Izkata 3y ago
    Class components have "shouldComponentUpdate()" that avoids this entirely.
- tshaddox 3y ago
  Or you installed the lint rule once 4 years ago and never had a problem again.
  - gyanreyer 3y ago
    Agreed, everyone who complains about dependency arrays almost certainly hasn't used the linting rule. That being said, I'm not sure that an API is well-designed if the only way to use it effectively is by forcing you to even know there is an eslint plugin to begin with, and then once you do know that, that means now you're being forced to add eslint to your project whether you like it or not. And sometimes eslint just stops working for who knows what reason, I have a developer on my team who's constantly dealing with issues where his eslint/prettier setup isn't running correctly.
danielvaughn 3y ago
This may be a personal thing, but I really like reading and writing code that feels like it's telling a story. That is, operating sequentially (this happens, then this happens, then this other thing, etc). useEffect breaks the sequential nature of your code and makes it feel like you're reading a script from a Quentin Tarantino movie.
- littlecranky67 3y ago
  Agreed, but non-sequential execution is the nature of event-driven, async non-blocking code. Event-driven as Web Applications (not Websites!) mostly deal with events (user input or network events). As long as the JavaScript VM and the DOM uses non-blocking async models no framework - being it Vue, Angular, React or whatnot - will ever change that. Sequential, blocking modells like i.e. batch ETL jobs are just not the domain of the browser.
  - SahAssar 3y ago
    > As long as the JavaScript VM and the DOM uses non-blocking async models The DOM is almost entirely sync, all the operations on it are blocking operations (including things like replacing an entire document with innerHTML).
    - littlecranky67 3y ago
      While not strictly on "the DOM", a lot of modern APIs are within the browser's JS VM (Notification, Camera, Audio, QR scanning, etc.) and all of them are async to the core. My argument therefore stands.
      - SahAssar 3y ago
        It does not, since most of those APIs are not directly called from the framework. What react and most other JS frameworks do is DOM modification (which is clearly sync) and delegate events (which is usually done via callbacks or binding).
- 3y ago
Izkata 3y ago
It does a shallow compare, not a deep compare. Workarounds tend to involve additional hooks: https://dev.to/vsramalwan/ways-to-handle-deep-object-comparison-in-useeffect-hook-1elm https://dev.to/vsramalwan/ways-to-handle-deep-object-compari...
- vlod 3y ago
  I heard that immutability libraries like immer.js [0] help with this. Anyone go this way and had good success? Is this 'the way'? [0]: https://immerjs.github.io/immer/ https://immerjs.github.io/immer/

bakugo 3y ago

> I hope Google is good at searching decade old documentation Google isn't even good at searching recent documentation, from my experience.

champagnepapi 3y ago

Agreed. IMO, it all started with Hooks. Things really went downhill from there. useEffect is terrible! Example, how easy it to forget the dependency array?! Because of that, you have to setup linting rules to fix the poor API provided by that hook...

hotnfresh 3y ago
Hooks felt like a big make-work project to let folks claim high-impact commits on a project that didn’t really need any of those, anymore.
- politelemon 3y ago
  What does this expression mean, make-work project?
  - hotnfresh 3y ago
    Digging a hole and filling it back up again. Work for the sake of having something to do.
    - politelemon 3y ago
      Ah I understand it now thanks. Not an uncommon thing in many places!
paulddraper 3y ago
HN is a funny place. A useful feature that an insane majority of React devs have come to prefer is "downhill." Kids these days.
- toastercat 3y ago
  Many folks were criticizing hooks when they were introduced. Of course React devs will "prefer" it; they are the idiomatic way to adding state/triggering effects in React.

johngalt2600 3y ago

Agreed. React is great but I really do not enjoy writing it. Much prefer Vue

fidotron 3y ago

It will turn out to be a great conspiracy where the React team are being encouraged to make it so only LLMs can make sense of React code in future.

vlod 3y ago

I switched to React when jQuery (and particularly storing state in the DOM and lots of custom events called) became a PITA. I don't feel that React has reached that tipped point yet, but when it does I'm hoping we'll all move to Sveltekit or something like it.

mattgreenrocks 3y ago
I despise almost every single web framework written in the last decade. They always feel like byzantine monoliths of complexity built from tons of layers over existing libraries. They invent tons of concepts, always require patching, and have an army of sycophants who believe building a web framework is basically rocket science and only a select few are ever capable of such a feat. SvelteKit is the first piece of web tech that I actually enjoy using. It’s the rare piece of tech that knows its lane, stays in it, and excels at it. It is marked by fewer features that work well together vs lots of features that sort of work well together. You can read the docs in an hour or two and then start to get an understanding of what it’s doing. Basically, it feels like it was made by someone who really understands the medium, thought deeply about how to distill that, and iterated to improve on it. (I get same vibes from Vue, but don’t have much experience there)
- paulddraper 3y ago
  I remember when HN said that about React. Lololol
  - mattgreenrocks 3y ago
    Totally fair comment. Time will tell. Edit: I'm just happy to find something that I like to make web stuff in. Now I can make some apps and actually enjoy the process.

phendrenad2 3y ago

This is how it always goes. JQuery was a response to browsers having poor standardization. Then it became a larger and larger ecosystem, and the code owners started getting megalomaniacal (I'm sorry, "live" is deprecated, please us the function "on" which does the exact same thing, we just liked the name better, thank you for complying). It became an ecosystem. Every 3rd party library was designed to integrate with JQuery. Soon there was JQuery UI, a UI library for adding modal dialogs and tooltips. And then someone realized that browsers had long since reached standards parity, and javascript engines were getting really fast, and re-rendering the DOM was GPU-accelerated, and we just needed a simple little library. And Angular and React were born (and Ember but we don't speak of satan in this house). React feels like it's following the exact same trajectory. It was created out of necessity, it was the best framework for a given point in time, but it's being stretched to handle the changing landscape, and it's feeling very kludgey. I expect that soon, very soon, someone will release the new paradigm. Probably just as soon as WASM is able to manipulate the DOM without JS hacks, which has been on the roadmap since before there was a road.

Exuma 3y ago

How do devs generally feel about Vue 3? So far it seems really amazing even for the most complex apps. I’ve built 5 nontrivial apps with 2 being 2+ year projects I haven’t found a “ceiling” yet