4 ms·

I have this doubt as well. Hooks will allow people to use "class like" features and behavior, but with none of the conventions forced by syntax, plus some pitf

I have this doubt as well. Hooks will allow people to use "class like" features and behavior, but with none of the conventions forced by syntax, plus some pitfalls. To me it seems a good way to ensure most devs (espacially unexperienced casual ones, which are legions in JS by nature of the market) will dump their logic wherever it works with as little structure as it allows. It's a technical debt catalyser, and will make sure nobody feels at home in someone else's code. The community will pay the price in a year. It's also yet another way to do the same thing, and JS has already a lot of those. React as well. Documentations, tutorials and examples will suffer from it. But again, it's very common in JS land where learning anything requires gathering scattered puzzle pieces then assembling them, hoping they are from the same set this time. It allows me to bill more, so I'm not complaining, but it's not fair to newcommers. Note that I can see some nice things about hooks. I just strongly think they don't outweight the cost by an order of magnitude. FB idea of ergonomics and user friendliness, in API and UI, has always been to force their way into things, until it blocks, back down, and fix things when possible or use a workaround. Having been training people in web tech for years, the consequences of such policy show in the classroom. But, hey, more money for me :) Plus when I dev, I have the experience to avoid the pain, mostly knowing when not to do or use things. But I can tell than many of my younger colleagues don't, and a few of my not so young ones too. Still, I wish they gave a bit more though to this aspects of their products: their are brillant technicians, so it's not that they can't, it's just a matter of culture.

victor106 8y ago
I agree with this thinking. One of the key reasons for choosing a framework/library is to enforce (reasonable) constraints. These constraints help in making sure that the framework takes a longer term view of things than just making it easy in the short term.
ergothus 8y ago
> will dump their logic wherever it works with as little structure as it allows. It's a technical debt catalyser, and will make sure nobody feels at home in someone else's code. The community will pay the price in a year. I don't want to downplay your concerns, but I will say that this is already a problem. Part of the goal with hooks (and I can't say if it achieves that) is to encourage the separation of a lot of state-interaction OUT of the components. Today it is much too easy (arguably it is easiest) to write a component that is basically untestable - basically a mini-application in itself, which is the opposite of good React design. I'm hopeful that Hooks will help, and I think the original demonstration focused too much on state and not enough on other interactions external to the component, which is where the real pain today exists. I've not played with the alpha at all to have a feel for how realistic my hopes are.
- nojvek 8y ago
  I read the hooks documentation. Why would someone find this pattern better than a pre-defined state object ? I don’t get it. React seems like it’s getting more complicated every single day. I loved it due to its simplicity but now i’m not so sure.
  - nfRfqX5n 8y ago
    mostly because you can encapsulate and reuse some state logic. allows for easier testing too.
    - sametmax 8y ago
      You could already do that with regular functions, class inheritence, mixin, prototype inheritence, composition, event dispatching or stores. If preventing people from being confused and doing the wrong thing was the goal, I'm not sure adding one new way to the mix is going to make things clearer. Besides, while I agree tooling help with applying good practices, including encapsulation, it's no substitute for a good initial API design. React and JS API are confusing, because they have been designed this way from the start. We are now adding things on top of it, again and again, without ever fixing anything at the bottom. This creates problems at the same time it solves others. Another issue is that the JS community wants to professionalise without aknowledging that a huge part of it doesn't have the skill to do so yet. It's a community that includes many young devs with little experience, people that are not programmers but ends up doing so, devs born in a culture of instant results... It's important to address this as well, by talking to them in tutorials and documentation, by creating API shaped with them in mind, so that they can grow in empowering directions. Instead, we create monster trucks, and they put ads on youtube to tell everyone how "easy it is to drive" and "you should do it too right now". For me, hooks are a monster truck. And most JS devs I work with are not capable of driving that safely.
      - bennyg 8y ago
        Sure, but if you can drive hooks safely, they seems to make some things _very_ clean. I'm going back through and rewriting a toy app I haven't launched yet to use hooks and it's been a joy to work with them so far.
lioeters 8y ago
I've also had doubts about hooks since its proposal, and I agree with the points you raised. From the Rules of Hooks section in the documentation[0]. - React relies on the order in which Hooks are called. - Only call Hooks at the top level. Don’t call Hooks inside loops, conditions, or nested functions. - Only call Hooks from React function components. Don’t call Hooks from regular JavaScript functions. This design decision doesn't sit well with me, and I won't be using it. However, the community seems to have already welcomed it, so I'm forced to learn the intricacies to be able to understand React codebases and keep up with the latest trend.. The addition of this feature is sure to increase cognitive load and technical debt. There are already countless variations of state management libraries and patterns that encourage pure functional components and decoupled logic. Hooks seem to be yet another opinionated strategy - and not for the best, in my view. --- [0] https://reactjs.org/docs/hooks-rules.html https://reactjs.org/docs/hooks-rules.html
- sametmax 8y ago
  > However, the community seems to have already welcomed it, so I'm forced to learn the intricacies to be able to understand React codebases and keep up with the latest trend.. That's one thing that no many realizes: the JS community is special and you should take that in consideration when adding a new features. When I say special, I mean it reacts (puns intended) in a way no other programming community does: - it jumps on novelty with very little afterthoughs or regards for consequences. - it has an habit of disregarding lessons from the past. - it seldom fix problems, but add a new layer of solution on top of it. Knowing this, the way hooks are released is too me like giving matches to children with the only advice "look how cool it is, I can make fireworks". Yes, I'm exagerating for the argument sake. But still, react is now a software used everywhere, I'd welcome a switch from "move fast and break things" to "let's think this true" once in a while.
  - grasshopper2218 8y ago
    This is a good way to summarize the javascript community. Not learning from the past is possibly a side effect of being dominated by young and/or inexperienced programmers and being less inclined to research established concepts before making something up. Although there are plenty of benefits to younger programmers (I hope, I'm one myself), but there are drawbacks to everything.

victor106 8y ago

I agree with this thinking. One of the key reasons for choosing a framework/library is to enforce (reasonable) constraints. These constraints help in making sure that the framework takes a longer term view of things than just making it easy in the short term.

ergothus 8y ago

> will dump their logic wherever it works with as little structure as it allows. It's a technical debt catalyser, and will make sure nobody feels at home in someone else's code. The community will pay the price in a year. I don't want to downplay your concerns, but I will say that this is already a problem. Part of the goal with hooks (and I can't say if it achieves that) is to encourage the separation of a lot of state-interaction OUT of the components. Today it is much too easy (arguably it is easiest) to write a component that is basically untestable - basically a mini-application in itself, which is the opposite of good React design. I'm hopeful that Hooks will help, and I think the original demonstration focused too much on state and not enough on other interactions external to the component, which is where the real pain today exists. I've not played with the alpha at all to have a feel for how realistic my hopes are.

nojvek 8y ago
I read the hooks documentation. Why would someone find this pattern better than a pre-defined state object ? I don’t get it. React seems like it’s getting more complicated every single day. I loved it due to its simplicity but now i’m not so sure.
- nfRfqX5n 8y ago
  mostly because you can encapsulate and reuse some state logic. allows for easier testing too.
  - sametmax 8y ago
    You could already do that with regular functions, class inheritence, mixin, prototype inheritence, composition, event dispatching or stores. If preventing people from being confused and doing the wrong thing was the goal, I'm not sure adding one new way to the mix is going to make things clearer. Besides, while I agree tooling help with applying good practices, including encapsulation, it's no substitute for a good initial API design. React and JS API are confusing, because they have been designed this way from the start. We are now adding things on top of it, again and again, without ever fixing anything at the bottom. This creates problems at the same time it solves others. Another issue is that the JS community wants to professionalise without aknowledging that a huge part of it doesn't have the skill to do so yet. It's a community that includes many young devs with little experience, people that are not programmers but ends up doing so, devs born in a culture of instant results... It's important to address this as well, by talking to them in tutorials and documentation, by creating API shaped with them in mind, so that they can grow in empowering directions. Instead, we create monster trucks, and they put ads on youtube to tell everyone how "easy it is to drive" and "you should do it too right now". For me, hooks are a monster truck. And most JS devs I work with are not capable of driving that safely.
    - bennyg 8y ago
      Sure, but if you can drive hooks safely, they seems to make some things _very_ clean. I'm going back through and rewriting a toy app I haven't launched yet to use hooks and it's been a joy to work with them so far.

lioeters 8y ago

I've also had doubts about hooks since its proposal, and I agree with the points you raised. From the Rules of Hooks section in the documentation[0]. - React relies on the order in which Hooks are called. - Only call Hooks at the top level. Don’t call Hooks inside loops, conditions, or nested functions. - Only call Hooks from React function components. Don’t call Hooks from regular JavaScript functions. This design decision doesn't sit well with me, and I won't be using it. However, the community seems to have already welcomed it, so I'm forced to learn the intricacies to be able to understand React codebases and keep up with the latest trend.. The addition of this feature is sure to increase cognitive load and technical debt. There are already countless variations of state management libraries and patterns that encourage pure functional components and decoupled logic. Hooks seem to be yet another opinionated strategy - and not for the best, in my view. --- [0] https://reactjs.org/docs/hooks-rules.html https://reactjs.org/docs/hooks-rules.html

sametmax 8y ago
> However, the community seems to have already welcomed it, so I'm forced to learn the intricacies to be able to understand React codebases and keep up with the latest trend.. That's one thing that no many realizes: the JS community is special and you should take that in consideration when adding a new features. When I say special, I mean it reacts (puns intended) in a way no other programming community does: - it jumps on novelty with very little afterthoughs or regards for consequences. - it has an habit of disregarding lessons from the past. - it seldom fix problems, but add a new layer of solution on top of it. Knowing this, the way hooks are released is too me like giving matches to children with the only advice "look how cool it is, I can make fireworks". Yes, I'm exagerating for the argument sake. But still, react is now a software used everywhere, I'd welcome a switch from "move fast and break things" to "let's think this true" once in a while.
- grasshopper2218 8y ago
  This is a good way to summarize the javascript community. Not learning from the past is possibly a side effect of being dominated by young and/or inexperienced programmers and being less inclined to research established concepts before making something up. Although there are plenty of benefits to younger programmers (I hope, I'm one myself), but there are drawbacks to everything.