8 ms·

This article hits on something I've felt for a long time. The idea that "hooks are superior" to me is ridiculous. If a linter is required to tell me when I'm wr

This article hits on something I've felt for a long time. The idea that "hooks are superior" to me is ridiculous. If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges! Solid is nice and _seems_ to fix the issues with hooks, but as another comment mentioned, the challenge is with building at scale. It's unclear to me how this scales and where the sharp edges are. React IMO trades off performance in exchange for ergonomics. These ergonomics bear fruit early on, but you start dealing with this debt very quickly. As "nice" as Redux is, I shouldn't need it so early. React is designed in a way that results in pretty terrible performance. I once wrote a React app, and discovered perf issues 2 weeks in. Any UI framework I used in the past would have scaled beyond this point without having to have the data layer rewritten. Frameworks of the past also had what seemed like way less "magic". I totally accept that it's seriously nice to write, but how many trees has React alone burnt?

ipnon 5y ago
React would work well as a compiled to metal language. Instead we end up with React on Typescript on ES6 on ES5 on the browser that still only has one language targetable. We're shackled to a rocketship in motion desperately monkey patching the engines.
- mwcampbell 5y ago
  We can at least eliminate ES5 now that IE is dead.
oaxacaoaxaca 5y ago
I have the same complaint about hooks. Most people seem to ignore that tidbit, but to me it's really frustrating. Plus I recently hit more hook issues when putting a setInterval inside a useEffect. There's no way to do a normal didMount/willUnmount workflow without other hacks (i.e. useRef) just to set up a simple timer. Maddening! Edit: after writing this I went and read the article. Same scenario I was bitching about lol
- littlecranky67 5y ago
  People always use the setInterval() issue as a footgun. The real footgun is people not reading the documentation for the framework they use, because the exact example is handled in the official react docs [0]. I always advice aspiring react devs to understand why this exact setInterval() doesn't work (and why there is the need for the rule-of-hooks), because it will automatically create an understanding how hooks and react itself works. [0]: https://reactjs.org/docs/hooks-faq.html https://reactjs.org/docs/hooks-faq.html
  - toshk 5y ago
    When I started with classes, I hardly had to read the docs, few hours and was good to go. For many developers I worked with at the time this was the case. React was easy coming from jQuery, Backbone other frameworks at the time. With effects, i've read the docs many times. I still don't fully understand how it's supposed to work. I don't seem to get the feeling / abstract concept behind it and it still surprises me at times when it fires / or not. Too much magic for me. But maybe im getting old :).
    - littlecranky67 5y ago
      Well if you do not want to read the docs, go with vanilla JS ;) Seriously, no matter what you use, read the docs. Arguing that a library should not require you to read the docs is just nonsense - cause any library makes decisions about abstractions for a reason. If you do not want/need those abstractions, do not use the library blindly. It is always the case that you should now and agree with those, that is why you use the library in the first place. So, read the docs, please.
      - furyofantares 5y ago
        The post you're replying to says they've read the docs many times.
        a2800276 5y ago
kccqzy 5y ago
Hooks triggered my code smell detector so bad that I didn't even bother finishing the tutorial. That said, I still preferred React.createClass so I guess I'm somewhat off the beaten path when it comes to React.
- Tade0 5y ago
  Back when they were initially released my teammate started rewriting everything in them. Little did he know, if you're not careful with hooks, you can severely damage performance. My take is that if a feature requires a linter to be properly implemented then it's obviously giving the developer too much rope to hang themselves with. Also it appears that they were introduced mainly for performance, but for some reason sold as the new "better" way of writing applications. I actively avoid React and its ecosystem, because I believe there's just too much FOMO and "fashion"(for lack of a better word) in what drives its development and not enough meritocracy.
- brimble 5y ago
  Read the implementation of Hooks (in the React codebase) if you want a big LOL. They're a slower, partial re-implementation of objects with bizarre custom syntax. In a language that's already so heavily OO that the functions are objects.
deckard1 5y ago
React traded one set of footguns for another set. This is also after they fudged with the class component lifecycle methods before tossing in the towel on that entire API. > If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework yep. They also commandeered the entire use* namespace just so they could get lint to warn when you put a hook outside the start of a function. Hacks on top of hacks.
sbergot 5y ago
Yes hooks are not great. They violate too many functional programming rules that the react team pretend to care about. I still like using them however. I had a few issues when trying to do more abstract code.
- jameshart 5y ago
  I don’t understand why people think react hooks are meant to be ‘functional’. They are highly, deliberately, emphatically procedural. The order they are called matters! The time of when they are called matters! The number of times they are called matters! You get a different result from calling the same hook with the same arguments at different times! You get different results if the call site for them is in different places! They do enable you to do some things in JavaScript that are more easily enabled with higher ordered function stuff in functional languages, but there is nothing ‘functional’ about how hooks work or how they are used. And that’s okay! ‘Functional’ doesn’t automatically mean ‘better’ and ‘procedural’ doesn’t mean ‘worse’. For what they do, hooks (considered as the entire hooks ecosystem including linting extensions that help enforce the rules as if they were syntax errors) are a very clever extension within JavaScript syntax that let you pull off some very neat separation of concerns in a reactive code model. ‘Functionalness’ has very little to do with whether hooks are good or bad.
  - Izkata 5y ago
    > I don’t understand why people think react hooks are meant to be ‘functional’. Because when function components first came along that's what the whole of React was supposed to be: "functional" UI, using things like redux or mobx for state. Plenty of guides still use that terminology even though React's homepage now uses "declarative". That said I think they were always misusing the term, I remember this because I used to complain to people that react itself was declarative, not functional, and just gave the option of writing in a functional style.
    - svachalek 5y ago
      I'm not sure what happened over there but they completely lost the plot with hooks. And now you're not "correct" or "modern" if you don't use them. They're ... fine, I guess. Most of the time. But not at all in line with the fairly clean and consistent vision of early React.
_0w8t 5y ago
React hooks is another attempt to gain ergonomics. The idea is to try to spread the virtual DOM into native effects. In theory the code specifies or declared the effects once and the framework takes care about subscribing/unsubscribing as necessary. But in practice this became so messy that in any complex cases one better stick to classes and explicit subscribe/unsubscribe. The right way to do that exists in Elm. But I do not think there is a way to translate that into JS without requiring either a lot of boilerplate or very messy code
- neoberg 5y ago
  I agree that hooks "can" be messy but in my experience they are quite useful and nice to maintain. That is if the code is written with maintainability in mind - which applies to any code really. I've been working on a quite complex React codebase for 5 years now - it's not the biggest but still not so small. I was there on day 1. The team that works on it now full time is ~15 devs + 10-15 doing some minor stuff from time to time. We've started using hooks about 1 year after they introduced them. Before we were very deep into redux and redux-saga. Now most of our codebase uses only hooks for most of the things we did with redux before - there are still some redux but most major parts are migrated to using hooks and contexts. It is probably the best decision we made after switching to TS. Most of our codebase is still very easy to maintain. Last year I went on a paternity leave for 6 months and I was pleasantly surprised how easy it was to adapt back. Edit: forgot to write about Elm. I like elm a lot -even though I don't agree with how it's managed-. I even organized a local elm meetup :) But I think while it is very good in theory, it's not too easy to scale especially if you plan on hiring more devs. Also the way effects and data is completely separated from the view is not very ideal for bigger projects. You either end up having to touch too many files for a single feature or have incredibly big files.
  - _0w8t 5y ago
    For us the problem with hooks is that we have a lot of complex state that can be shown in different components. So global stores are a must. But then bugs in the hooks can be hard to debug. Also lack of forceUpdate for hooks causes to use artificial state counters complicating the code. Basically with external state class components are more straightforward to write and easier to maintenance .
leonardopainter 5y ago
>If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges! Those linter warnings with React hooks show just how much of a disaster it is. All of the "simplicity" that comes with hooks is just complexity that is now completely out of sight, and only appears once the code is run in a linter. That is even worse than having the complexity in the code.
cies 5y ago
I like Elm. :) On the JS/TS planet there's https://cycle.js.org https://cycle.js.org , which comes close. Looks even better than Solid IMHO.
toshk 5y ago
With Class components it was often easier to create Pure components, or do a shouldcomponent update check to optimize performace. They later introduced memo for functional components.
apatheticonion 5y ago
After working with React for years it is something I would not recommend and can only think of limited use cases to use. You can write really performant software in React, but ergonomic (beyond stockholm syndrome) I would not call it. It's also difficult to implement quality software engineering principles in a React application such that an application is maintainable, glacable and easy for someone new to a project to pick up. The flexibility in its toolchain is nice, however
- chrisweekly 5y ago
  > "glacable"?
  - apatheticonion 5y ago
    Opps, "glanceable"
deleted 5y ago
[deleted]
nobleach 5y ago
>"If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges". I do not want this handled at the framework level though. There are plenty of times in my day-to-day where that linter is wrong. If I were to add one of the dependencies (it's sure I should add) my component would re-render over and over. Sure, one could argue, "well, then you've poorly architected your code"... but THAT is where I feel like the failure occurs. Having to do write my code to please a paradigm. What that means is I only "sorta agree" with the design trade-offs. And much like Ruby on Rails, you either go all in, or spend your days hating the framework. I do worry that Solid also has these "If you know, you know" edges though. So I'm trading looking at a function and assuming it'll run over and over with, looking at a function and thinking, "how can I make this thing run again when it needs to?" I'm not saying it's wrong, it's just another piece of tacit knowledge one has to learn when adopting a new framework.
- joshribakoff 5y ago
  Read the hooks FAQ, the linter is not wrong, you are :) https://reactjs.org/docs/hooks-faq.html#is-it-safe-to-omit-functions-from-the-list-of-dependencies https://reactjs.org/docs/hooks-faq.html#is-it-safe-to-omit-f...
  - draw_down 5y ago
  - nobleach 5y ago
    Did you see my comment about "yes I could rearch my code but..." The fact that I'm writing in some very specific way to please a linter IS the problem... regardless of whether we tell someone beforehand. If I know I have a dependency I want to ignore, to achieve a certain result. Then I have a way to achieve a particular data flow. One can _say_, that's wrong but it's a deterministic way to achieve that result. Calling it "wrong" delves into the weirdness of hooks. Love them or hate them, they create patterns which must be learned and mastered. And even then... they can still be confusing. Except for on the internet obviously, here we find people who never have problems with them :)
schwartzworld 5y ago
> If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Isn't the point of static analysis (including linters) that they catch those kind of bugs? Having that little red underline (or console warning) saves a lot of pain. Hooks have completely changed the way I write React code. It's so much easier to test and reason about. Really the only problem is that the guardrails aren't more heavily enforced.
joshribakoff 5y ago
The idea with hooks is a compiler could generate the dependency array. The flaw isn’t with the hooks paradigm
- ryansolid 5y ago
  But those dependencies would be static. This goes beyond that. I won't call hooks flawed, they are suitable for React's model, but looking at what reactivity does is a different sort of thing. It is a subtle difference at first.
jameshart 5y ago
I don't think complaining about needing a linter makes sense. JSX is already a compiled language, so you have a compile and build step (doubly so if you're also using Typescript). Think of ESLint rules-of-hooks as just a plugin to your compiler that further modifies the syntax of JavaScript to include rules about when and how you can call certain functions. Hooks are a syntactic element of react code. Calls to them aren't legal inside conditionals or loops. Full linting support smooths over that rough edge just as effectively as babel handling ?. syntax smooths over its absence in certain JS runtimes.

ipnon 5y ago

React would work well as a compiled to metal language. Instead we end up with React on Typescript on ES6 on ES5 on the browser that still only has one language targetable. We're shackled to a rocketship in motion desperately monkey patching the engines.

mwcampbell 5y ago
We can at least eliminate ES5 now that IE is dead.

oaxacaoaxaca 5y ago

I have the same complaint about hooks. Most people seem to ignore that tidbit, but to me it's really frustrating. Plus I recently hit more hook issues when putting a setInterval inside a useEffect. There's no way to do a normal didMount/willUnmount workflow without other hacks (i.e. useRef) just to set up a simple timer. Maddening! Edit: after writing this I went and read the article. Same scenario I was bitching about lol

littlecranky67 5y ago
People always use the setInterval() issue as a footgun. The real footgun is people not reading the documentation for the framework they use, because the exact example is handled in the official react docs [0]. I always advice aspiring react devs to understand why this exact setInterval() doesn't work (and why there is the need for the rule-of-hooks), because it will automatically create an understanding how hooks and react itself works. [0]: https://reactjs.org/docs/hooks-faq.html https://reactjs.org/docs/hooks-faq.html
- toshk 5y ago
  When I started with classes, I hardly had to read the docs, few hours and was good to go. For many developers I worked with at the time this was the case. React was easy coming from jQuery, Backbone other frameworks at the time. With effects, i've read the docs many times. I still don't fully understand how it's supposed to work. I don't seem to get the feeling / abstract concept behind it and it still surprises me at times when it fires / or not. Too much magic for me. But maybe im getting old :).
  - littlecranky67 5y ago
    Well if you do not want to read the docs, go with vanilla JS ;) Seriously, no matter what you use, read the docs. Arguing that a library should not require you to read the docs is just nonsense - cause any library makes decisions about abstractions for a reason. If you do not want/need those abstractions, do not use the library blindly. It is always the case that you should now and agree with those, that is why you use the library in the first place. So, read the docs, please.
    - furyofantares 5y ago
      The post you're replying to says they've read the docs many times.
      - a2800276 5y ago

kccqzy 5y ago

Hooks triggered my code smell detector so bad that I didn't even bother finishing the tutorial. That said, I still preferred React.createClass so I guess I'm somewhat off the beaten path when it comes to React.

Tade0 5y ago
Back when they were initially released my teammate started rewriting everything in them. Little did he know, if you're not careful with hooks, you can severely damage performance. My take is that if a feature requires a linter to be properly implemented then it's obviously giving the developer too much rope to hang themselves with. Also it appears that they were introduced mainly for performance, but for some reason sold as the new "better" way of writing applications. I actively avoid React and its ecosystem, because I believe there's just too much FOMO and "fashion"(for lack of a better word) in what drives its development and not enough meritocracy.
brimble 5y ago
Read the implementation of Hooks (in the React codebase) if you want a big LOL. They're a slower, partial re-implementation of objects with bizarre custom syntax. In a language that's already so heavily OO that the functions are objects.

deckard1 5y ago

React traded one set of footguns for another set. This is also after they fudged with the class component lifecycle methods before tossing in the towel on that entire API. > If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework yep. They also commandeered the entire use* namespace just so they could get lint to warn when you put a hook outside the start of a function. Hacks on top of hacks.

sbergot 5y ago

Yes hooks are not great. They violate too many functional programming rules that the react team pretend to care about. I still like using them however. I had a few issues when trying to do more abstract code.

jameshart 5y ago
I don’t understand why people think react hooks are meant to be ‘functional’. They are highly, deliberately, emphatically procedural. The order they are called matters! The time of when they are called matters! The number of times they are called matters! You get a different result from calling the same hook with the same arguments at different times! You get different results if the call site for them is in different places! They do enable you to do some things in JavaScript that are more easily enabled with higher ordered function stuff in functional languages, but there is nothing ‘functional’ about how hooks work or how they are used. And that’s okay! ‘Functional’ doesn’t automatically mean ‘better’ and ‘procedural’ doesn’t mean ‘worse’. For what they do, hooks (considered as the entire hooks ecosystem including linting extensions that help enforce the rules as if they were syntax errors) are a very clever extension within JavaScript syntax that let you pull off some very neat separation of concerns in a reactive code model. ‘Functionalness’ has very little to do with whether hooks are good or bad.
- Izkata 5y ago
  > I don’t understand why people think react hooks are meant to be ‘functional’. Because when function components first came along that's what the whole of React was supposed to be: "functional" UI, using things like redux or mobx for state. Plenty of guides still use that terminology even though React's homepage now uses "declarative". That said I think they were always misusing the term, I remember this because I used to complain to people that react itself was declarative, not functional, and just gave the option of writing in a functional style.
  - svachalek 5y ago
    I'm not sure what happened over there but they completely lost the plot with hooks. And now you're not "correct" or "modern" if you don't use them. They're ... fine, I guess. Most of the time. But not at all in line with the fairly clean and consistent vision of early React.

_0w8t 5y ago

React hooks is another attempt to gain ergonomics. The idea is to try to spread the virtual DOM into native effects. In theory the code specifies or declared the effects once and the framework takes care about subscribing/unsubscribing as necessary. But in practice this became so messy that in any complex cases one better stick to classes and explicit subscribe/unsubscribe. The right way to do that exists in Elm. But I do not think there is a way to translate that into JS without requiring either a lot of boilerplate or very messy code

neoberg 5y ago
I agree that hooks "can" be messy but in my experience they are quite useful and nice to maintain. That is if the code is written with maintainability in mind - which applies to any code really. I've been working on a quite complex React codebase for 5 years now - it's not the biggest but still not so small. I was there on day 1. The team that works on it now full time is ~15 devs + 10-15 doing some minor stuff from time to time. We've started using hooks about 1 year after they introduced them. Before we were very deep into redux and redux-saga. Now most of our codebase uses only hooks for most of the things we did with redux before - there are still some redux but most major parts are migrated to using hooks and contexts. It is probably the best decision we made after switching to TS. Most of our codebase is still very easy to maintain. Last year I went on a paternity leave for 6 months and I was pleasantly surprised how easy it was to adapt back. Edit: forgot to write about Elm. I like elm a lot -even though I don't agree with how it's managed-. I even organized a local elm meetup :) But I think while it is very good in theory, it's not too easy to scale especially if you plan on hiring more devs. Also the way effects and data is completely separated from the view is not very ideal for bigger projects. You either end up having to touch too many files for a single feature or have incredibly big files.
- _0w8t 5y ago
  For us the problem with hooks is that we have a lot of complex state that can be shown in different components. So global stores are a must. But then bugs in the hooks can be hard to debug. Also lack of forceUpdate for hooks causes to use artificial state counters complicating the code. Basically with external state class components are more straightforward to write and easier to maintenance .

leonardopainter 5y ago

>If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges! Those linter warnings with React hooks show just how much of a disaster it is. All of the "simplicity" that comes with hooks is just complexity that is now completely out of sight, and only appears once the code is run in a linter. That is even worse than having the complexity in the code.

cies 5y ago

I like Elm. :) On the JS/TS planet there's https://cycle.js.org https://cycle.js.org , which comes close. Looks even better than Solid IMHO.

toshk 5y ago

With Class components it was often easier to create Pure components, or do a shouldcomponent update check to optimize performace. They later introduced memo for functional components.

apatheticonion 5y ago

After working with React for years it is something I would not recommend and can only think of limited use cases to use. You can write really performant software in React, but ergonomic (beyond stockholm syndrome) I would not call it. It's also difficult to implement quality software engineering principles in a React application such that an application is maintainable, glacable and easy for someone new to a project to pick up. The flexibility in its toolchain is nice, however

chrisweekly 5y ago
> "glacable"?
- apatheticonion 5y ago
  Opps, "glanceable"

deleted 5y ago

[deleted]

nobleach 5y ago

>"If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges". I do not want this handled at the framework level though. There are plenty of times in my day-to-day where that linter is wrong. If I were to add one of the dependencies (it's sure I should add) my component would re-render over and over. Sure, one could argue, "well, then you've poorly architected your code"... but THAT is where I feel like the failure occurs. Having to do write my code to please a paradigm. What that means is I only "sorta agree" with the design trade-offs. And much like Ruby on Rails, you either go all in, or spend your days hating the framework. I do worry that Solid also has these "If you know, you know" edges though. So I'm trading looking at a function and assuming it'll run over and over with, looking at a function and thinking, "how can I make this thing run again when it needs to?" I'm not saying it's wrong, it's just another piece of tacit knowledge one has to learn when adopting a new framework.

joshribakoff 5y ago
Read the hooks FAQ, the linter is not wrong, you are :) https://reactjs.org/docs/hooks-faq.html#is-it-safe-to-omit-functions-from-the-list-of-dependencies https://reactjs.org/docs/hooks-faq.html#is-it-safe-to-omit-f...
- draw_down 5y ago
- nobleach 5y ago
  Did you see my comment about "yes I could rearch my code but..." The fact that I'm writing in some very specific way to please a linter IS the problem... regardless of whether we tell someone beforehand. If I know I have a dependency I want to ignore, to achieve a certain result. Then I have a way to achieve a particular data flow. One can _say_, that's wrong but it's a deterministic way to achieve that result. Calling it "wrong" delves into the weirdness of hooks. Love them or hate them, they create patterns which must be learned and mastered. And even then... they can still be confusing. Except for on the internet obviously, here we find people who never have problems with them :)

schwartzworld 5y ago

> If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Isn't the point of static analysis (including linters) that they catch those kind of bugs? Having that little red underline (or console warning) saves a lot of pain. Hooks have completely changed the way I write React code. It's so much easier to test and reason about. Really the only problem is that the guardrails aren't more heavily enforced.

joshribakoff 5y ago

The idea with hooks is a compiler could generate the dependency array. The flaw isn’t with the hooks paradigm

ryansolid 5y ago
But those dependencies would be static. This goes beyond that. I won't call hooks flawed, they are suitable for React's model, but looking at what reactivity does is a different sort of thing. It is a subtle difference at first.

jameshart 5y ago

I don't think complaining about needing a linter makes sense. JSX is already a compiled language, so you have a compile and build step (doubly so if you're also using Typescript). Think of ESLint rules-of-hooks as just a plugin to your compiler that further modifies the syntax of JavaScript to include rules about when and how you can call certain functions. Hooks are a syntactic element of react code. Calls to them aren't legal inside conditionals or loops. Full linting support smooths over that rough edge just as effectively as babel handling ?. syntax smooths over its absence in certain JS runtimes.