5 ms·

All of this reads akin to someone criticizing an apple for not being an orange. Every point is an intentional design decision. Learning new things is necessary,

by azhu 6y ago

All of this reads akin to someone criticizing an apple for not being an orange. Every point is an intentional design decision. Learning new things is necessary, leaving class syntax behind was a choice, and imposing limits on (controlling) application design is the point of libraries. The team is pushing a functional declarative pipe method of building UI applications where things are built using a straight-line series of composed functional transformations. Personally, I think supporting this method with the hooks model of handling side effects is an improvement over everything else that exists in "roll your own" UI library land. I find these style libraries more enjoyable to build with, more expressive, and better suited to building things where you need finer grain control than template style libraries like Vue, which provide a stronger degree of predictability and ease of immediate use. That's the thing -- it's a balance. Hooks add a nicely considered and balanced degree of order to the otherwise intentionally uncontrolled-so-you-can-do-the-controlling programming model of React. React identifies as the advanced lego set with the smaller more numerous blocks that you can build the cooler stuff with, and as such will always have a certain threshold of complexity.

jiofih 6y ago
You didn’t actually counter any of the authors’ points. This wonderful functional declarative pipe method of building UI applications where things are built using a straight-line series of composed functional transformations can really suck in real world applications as he tries to demonstrate. Anyone building with hooks now can relate to hooks bringing disorder to the codebase. Has your experience been different? How did you avoid the pitfalls mentioned?
- ng12 6y ago
  Well #2 isn't really a pitfall, for starters. I have a new feature that solved a problem I had but I can't use it in the code I wrote before I had it without refactoring? I don't think that critique really has anything to do with Hooks, just software development. It's also basically a rephrasing of #3.
  - jiofih 6y ago
    Unless you work on anything beyond a small codebase, and suddenly half of your code cannot be composed with the other.
- pacala 6y ago
  1. It's not more stuff to learn, it's different stuff to learn, arguably less. Learning Components is not a prerequisite for learning Hooks. Or perhaps I missed the memo, as I've built an app using Hooks, and still haven't need to learn what 'componentWillMount' is supposed to do. 2. Don't mix Components and Hooks. 3. Agreed, change is hard. It's also the only way to avoid stagnation. In the long term, change wins. Or else we'd be programming in JS1995. 4. Insufficient example. What is the business case for a memoized hook returning hooks? Perhaps there is a simpler design, can't comment. 5. There is no global control flow. There is only per function component control flow, which proceeds from top to bottom. Possibly preempted by a hook/hookfn execution, if my early learning curve is to be believed. Which shouldn't matter if one is thinking in terms of 'pure functions returning jsx', as preempted functions do not return, thus have no observable effect. Tip: Only change hook state from event handlers, never from render function code.
  - viklove 6y ago
    > In the long term, change wins. Or else we'd be programming in JS1995. Change for the sake of change is not a sound argument. The thing about hooks is they don't enable a single thing we couldn't already do with HOCs. They are also much harder to read, because stateful logic is now just sprinkled around your render method rather than being isolated to places you know to look for it. I won't be using hooks ever, as far as I'm concerned.
    - pacala 6y ago
      Of course. * "A Critique of React Hooks" * "A Critique of the Change Costs Induced by React Hooks". Objections to React Hooks are stronger if they don't invoke change costs as the primary three concerns.
      - runawaybottle 6y ago
        He/she gave a very valid critique of state being jammed into your render method, vs state being handled in a predictable pattern in Class components. And lastly, let’s not minimize change-cost. In the real world, it’s a cost. We’re all willing to pay it if it’s necessary, or affordable, but not because someone showed up and said ‘change please’.
lhorie 6y ago
> imposing limits on (controlling) application design is the point of libraries That's the point of _frameworks_. It's very ironic to see this being said in defense of React, given that its original appeal was precisely the opposite stance (i.e. React was "only the v in mvc", in response to the notion that frameworks of the time were imposing).

by azhu 6y ago

jiofih 6y ago

You didn’t actually counter any of the authors’ points. This wonderful functional declarative pipe method of building UI applications where things are built using a straight-line series of composed functional transformations can really suck in real world applications as he tries to demonstrate. Anyone building with hooks now can relate to hooks bringing disorder to the codebase. Has your experience been different? How did you avoid the pitfalls mentioned?

ng12 6y ago
Well #2 isn't really a pitfall, for starters. I have a new feature that solved a problem I had but I can't use it in the code I wrote before I had it without refactoring? I don't think that critique really has anything to do with Hooks, just software development. It's also basically a rephrasing of #3.
- jiofih 6y ago
  Unless you work on anything beyond a small codebase, and suddenly half of your code cannot be composed with the other.
pacala 6y ago
1. It's not more stuff to learn, it's different stuff to learn, arguably less. Learning Components is not a prerequisite for learning Hooks. Or perhaps I missed the memo, as I've built an app using Hooks, and still haven't need to learn what 'componentWillMount' is supposed to do. 2. Don't mix Components and Hooks. 3. Agreed, change is hard. It's also the only way to avoid stagnation. In the long term, change wins. Or else we'd be programming in JS1995. 4. Insufficient example. What is the business case for a memoized hook returning hooks? Perhaps there is a simpler design, can't comment. 5. There is no global control flow. There is only per function component control flow, which proceeds from top to bottom. Possibly preempted by a hook/hookfn execution, if my early learning curve is to be believed. Which shouldn't matter if one is thinking in terms of 'pure functions returning jsx', as preempted functions do not return, thus have no observable effect. Tip: Only change hook state from event handlers, never from render function code.
- viklove 6y ago
  > In the long term, change wins. Or else we'd be programming in JS1995. Change for the sake of change is not a sound argument. The thing about hooks is they don't enable a single thing we couldn't already do with HOCs. They are also much harder to read, because stateful logic is now just sprinkled around your render method rather than being isolated to places you know to look for it. I won't be using hooks ever, as far as I'm concerned.
  - pacala 6y ago
    Of course. * "A Critique of React Hooks" * "A Critique of the Change Costs Induced by React Hooks". Objections to React Hooks are stronger if they don't invoke change costs as the primary three concerns.
    - runawaybottle 6y ago
      He/she gave a very valid critique of state being jammed into your render method, vs state being handled in a predictable pattern in Class components. And lastly, let’s not minimize change-cost. In the real world, it’s a cost. We’re all willing to pay it if it’s necessary, or affordable, but not because someone showed up and said ‘change please’.

lhorie 6y ago

> imposing limits on (controlling) application design is the point of libraries That's the point of _frameworks_. It's very ironic to see this being said in defense of React, given that its original appeal was precisely the opposite stance (i.e. React was "only the v in mvc", in response to the notion that frameworks of the time were imposing).