Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Critique of React Hooks

dillonshook.com

Post reply on HN
Print view View original

91–100 of 298 posts

Re: A Critique of React Hooks

#91

Post by lhorie »

kiliancs wrote: post #84
lhorie wrote: post #48

Earlier quoted context omitted.

It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language". It really shows the biases of the maintainers (the "just a library" thing being a philosophy I liked from vjeux, and the "language-likeness" being very obviously a heavy influence from sebmarkbage). The thing w/ "language-ness" (as opposed to "library-ness") is that additions and c…

Was it sold as "just a view library" from official sources? I understand "just a view library" might have been used to contrast it to full framworks that dictate a lot more than React, but it's important to note that the key React feature compared to other view libraries is precisely that it's not "just a view library": state is at its core. It's hard to disagree with the the pain of React having to leave the comfort…

> Was it sold as "just a view library" from official sources?

Yes, the "V in MVC" term came straight out its main page:

> JUST THE UI

> Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project.

https://web.archive.org/web/20140321012426/http://facebook.g...

Re: A Critique of React Hooks

#92

Post by parley »

deckard1 wrote: post #42

Hooks elucidate everything I've felt wrong about React, but have not been able to put my finger on it until recently. Hooks reveal two major things with React: 1) React developers did not understand the component paradigm that they originally went with. If they did, then they would understand how silly it is that components cannot reuse logic. This was an entire debate many years ago. Composition vs. inheritance. You…

> React developers do not understand functional programming

As some sibling comments note, this is not a fair conclusion to draw. And not that it disproves your statement, but Reacts original creator Jordan Walke wrote the first React prototype in SML. Not understanding functional programming is not on the list of things I would ascribe to him. He's a smart guy.

On a slightly different note, I'd recommend anyone try out Reason. It's slowly maturing and can be a real joy, at least compared to JS/TS.

Re: A Critique of React Hooks

#93

Post by zodiac »

jtdev wrote: post #72
zodiac wrote: post #20

I personally don't use hooks (or functional components) at all, but recently read this post from Dan Abramov about algebraic effects which makes a point (among others) the hook mechanism is a pretty simple way to implement state/effects/context in a language with algebraic effects. https://overreacted.io/algebraic-effects-for-the-rest-of-us/

Yay, just what we all needed to help us write clean, maintainable code... algebraic effects??

Honestly? Maybe it is, maybe it isn't. Imagine replacing "algebraic effects" in your question with "exceptions" - theres no clear answer. What do you think?

Re: A Critique of React Hooks

#94

Post by pacala »

deckard1 wrote: post #42

Hooks elucidate everything I've felt wrong about React, but have not been able to put my finger on it until recently. Hooks reveal two major things with React: 1) React developers did not understand the component paradigm that they originally went with. If they did, then they would understand how silly it is that components cannot reuse logic. This was an entire debate many years ago. Composition vs. inheritance. You…

Huh? You can treat state as arguments to your function. For a given function evaluation, the state is stable. The fact that state can be changed during event handling is 100% irrelevant to the evaluation. There is no dynamic scoping.

Re: A Critique of React Hooks

#95

Post by petilon »

efdee wrote: post #4
tenaciousDaniel wrote: post #3

IMO, we've traded the complexity of `this` with the complexity of hooks. Maybe I'm weird, but I never really wrote JS that caused scoping issues, so I never found `this` to be a problem. At the very least it's a complexity that is internal to the language itself. Hooks just feel so weird and alien to JS. I find them very, very difficult to reason about. - difficult to reason about except for a few simple use cases .…

Hooks weren't invented because of 'this' complexity though, but rather as a better way to handle reuseable code (somewhat) akin to mixins.

But that took the simplicity away. Everyone that knows modern JavaScript knows classes. Now they have to learn this alien concept called "hooks".

Now regarding reusability: I have been doing UI code for many many years and I have rarely felt that logic inside UI components need to be reusable. First move all business logic out of UI components into model-layer objects. This eliminates most of the need for reusable logic in components. Then decompose your mega-components into simpler components. This removes all remaining need for reusable logic. If you still have reusable logic inside your component -- this is very rare -- allow some duplication of code, this is better than creating monstrous code that nobody understands.

Re: A Critique of React Hooks

#96

Post by petilon »

genezeta wrote: post #25
tenaciousDaniel wrote: post #7

Earlier quoted context omitted.

I'll see if I can find the link, but I recall seeing some references in the official docs, naming `this` complexity as a key inspiration for looking to hooks as an alternative to stateful classes.

It's right there in their intro to hooks in the section "Classes confuse both people and machines" [0]. [0] https://reactjs.org/docs/hooks-intro.html#classes-confuse-bo...

I am far more confused by hooks than by classes and 'this'.

Re: A Critique of React Hooks

#97

Post by lpage »

> The problem with learning about hooks is that they're not generally applicable knowledge about computing or programming.

That's true of the hooks API specifically, but not true of the underlying abstraction. Hooks are (informally) algebraic effects - one of the coolest and most general abstractions for inspecting and manipulating a program's control flow [1, 2]. Algebraic effects are still somewhat niche and most programmers haven't encountered them in name or in practice, so in that regard, hooks are actually one of the fun cases when learning a new API is mind expanding.

[1] https://github.com/ocamllabs/ocaml-effects-tutorial#1-algebr...

[2] https://overreacted.io/algebraic-effects-for-the-rest-of-us/

Re: A Critique of React Hooks

#98

Post by karatestomp »

Saaster wrote: post #49

My biggest worry with React is that it has restless developers with idle hands. I have (a lot of) component code that will never be converted to hooks. Can I rely on you not to flake out and pull an Angular on me?

> My biggest worry with React is that it has restless developers with idle hands.

That’s exactly what I take hooks as a sign of. I read the papers and the code when they came out. I still don’t get why they exist except to provide churn to work on. A half-reimplementation of objects with a super weird syntax in a language that already has objects seems like misguided make-work on a project that’s already basically “done” except for the boring, non-flashy work of maintenance and subtler improvements.

Re: A Critique of React Hooks

#100

Post by pattrn »

It's a unfortunate that he doesn't include the equivalent class-based implementations of his logging quiz. Event lifecycles notoriously obscure order of execution, so I'm not sure the alternative is any clearer -- especially not with contrived examples. In my experience with both hooks and classes:

- Hooks require substantially less boilerplate than classes.

- Rendering optimization problems with hooks tend to take more time to identify and to fix.

There are other pros/cons, but these are the ones that affect my work most frequently.

Post reply on HN