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

221–230 of 298 posts

Re: A Critique of React Hooks

#221

Post by hombre_fatal »

hajile wrote: post #184
frank_nitti wrote: post #146

Earlier quoted context omitted.

By this logic, what could ever be considered "huge" departure? Any new language construct "converts" to something lower level unless that language is a set of assembly instructions. I mean, Elm converts to vanilla JS but few would say it's a small departure from it.

That's just reductio ad absurdum claim. JSX is one simple conversion while coffeescript or elm are entire turing-complete languages. It's like claiming a smiley face on the back of a receipt is no different from the Mona Lisa.

Yeah, all of the dynamic parts of JSX are Just Javascript.

You can also look at JSX and know exactly how it will compile to Javascript because it's so simple. (foo && ) -> (foo && React.createElement(Component, props)).

It really is just React.createElement calls. It just isn't a huge departure.

Meanwhile, what Elm compiles to is very nontrivial. The comparison only makes sense if you never actually looked at what JSX does thus mistake it for something much more complex.

Try it out yourself: https://babeljs.io/repl

Re: A Critique of React Hooks

#222

Post by wwright »

stevebmark wrote: post #138
untog wrote: post #137

Earlier quoted context omitted.

> React is great because it's vanilla Javascript What about JSX? It’s very useful but it’s also an absolutely huge departure from vanilla JavaScript and hides a fair amount of complexity behind what your code is actually doing.

My mental model of JSX is that it's vanilla Javascript, and it's helped me appreciate trying to write more expressions and less statements. Like JSX isn't getting transformed into some weird different control flow, it's just a nicer way to write the same expression. And DSLs are a good general computer science principle. Hooks don't seem quite as general of a concept to me as a really well thought out DSL that has a…

Hooks are very similar to applicatives as you’d see them in Haskell, for what it’s worth (it’s where a lot of the rules of hooks come from). They also have some similarity to algebraic effects (as do sagas).

Re: A Critique of React Hooks

#223

Post by azirbel »

I really like hooks. I previously spent a lot of time in HOCs, and I find hooks much simpler. But I also have problems with #5 (control flow):

The main issue I have with hooks is that I can't easily trace why updates are being triggered in my app; this makes it hard to debug performance issues. For example, my app once got really slow, and the profiler told me that a root(ish)-level component was causing a lot of re-renders. Unfortunately, that component used multiple hooks, and the only way I was able to isolate the problem was by binary-searching, deleting hooks until the re-renders stopped.

Anyone have better ways of dealing with this?

Re: A Critique of React Hooks

#224

Post by hombre_fatal »

pacala wrote: post #115
Saaster wrote: post #38

I feel that with class components I have a really good understanding of what is rendering and most importantly, when. componentDidMount, shouldComponentUpdate, PureComponent, etc. With hooks, it's much more magic. And clarity of rendering is literally the one thing I want from React. We have two projects, one using class components and one using hooks, and working on the class components one is unexciting, straightfo…

Memoization is getting me too. I end up memoizing everything, which is more verbose than I'd like. Perhaps we're missing some obvious pattern?

Though note that React.memo(Component) gives you the same behavior as React.PureComponent which is what people were tending to default to anyways.

Re: A Critique of React Hooks

#225

Post by jtdev »

TheCoelacanth wrote: post #106
jtdev wrote: post #69

The universe is stateful; no matter how hard FP zealots try to abstract that out of code, they will never change this fundamental fact.

Nonsense. These are all just techniques for modeling reality, not reality itself. You could model the universe just as accurately as a stateless function of time as you could as a stateful entity that moves through time.

The further you get from the true representation of the thing you’re trying to model, the more difficult reasoning about it becomes. I’m all for abstractions that result in a net positive... I simply believe that FP is less about improving computing and more about ego.

Re: A Critique of React Hooks

#226

Post by pmoleri »

vosper wrote: post #139
stevebmark wrote: post #136

Hooks have unlocked so much power in React but still deserve critiquing. However I think the author only hinted at the major complaint I have about hooks, which is that it's no longer Javascript. It's not a function, it's sort of like type system magic. Hooks can't be nested, order matters, can't be conditionally called, and you have to understand trickier memoization to avoid bugs. It also isn't portable knowledge t…

> I look back on all our HOCs and function as children and shudder compared to how easy it is with hooks. If by "function as children" you're referring to render props, personally I was really happy to see that short-lived fad die out. I don't think render props made things simpler. Now if we can admit we never needed Sagas just to do some data fetching maybe we can burn that stalled-out old bandwagon, too :D (Sagas…

What's the problem with render props? You need a component to provide values to its unknown children, you either do render props or you need to clone the children injecting them the values. I find render props to be a much more clear pattern than clone. It also works nicely in TypeScript doing the proper type checking. Am I missing something?

Edit: I think I missed the point. Hooks do make providing state to children simpler in a lot of cases. I just don't hate render props that much :)

Re: A Critique of React Hooks

#227

Post by desert_boi »

swyx wrote: post #67
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…

> and the "language-likeness" being very obviously a heavy influence from sebmack just a minor correction, you probably mean seb markbage, who works on React, not seb mackenzie, who made Babel and now Rome and i dont think was ever on the React team. i agree that when seb markbage leaves, it will be a big test of React's legacy. I've called it the "Ship of Theseus" moment for React.

Got a link to Rome's docs? Babel is a little easier to google for.

Re: A Critique of React Hooks

#228

Post by kin »

ng12 wrote: post #202
kin wrote: post #195

Earlier quoted context omitted.

Basically every call of a functional component MyComponent() represents a new scope. When you're working with a hook such as useEffect(), you have to pay attention to the dynamic scope so and correctly trigger the useEffect() with the dependency array.

But everything in that dependency array is from lexical scope, correct? Your hooks execute in the scope of that call to MyComponent().

Correct, but the callback passed to useEffect is only scoped to the call stack triggered by the dependency array. So, this makes the callback passed to useEffect dynamically scoped.

Re: A Critique of React Hooks

#229

Post by darepublic »

People talk about the 'good old days' of jquery. I do think it was easier to be a web developer in those days because there weren't as many levels of abstraction. It was just your simple text editor, html and js script, that's it. And you were directly changing the DOM. But writing jQuery for complicated apps can get out of control very fast. I do not miss querying classes on an element to figure out what to do next. Nowadays I meet 'React Developers' who didn't know that you can do document.querySelector(...). They tell me without batting an eye that React makes websites faster.. and that it is faster than plain javascript. And before anyone tells me that it can make things faster through DOM diffing or what have you -- you are wrong. Situationally React could be faster than poorly written js, but in most cases it won't be and that is not its point. It doesn't magically imbue your web application with hyper speed. Quite the opposite! Its like all these layers of node, npm, React, Hooks crud built up and there are actually people junior enough that their only exposure to webdev is through this morass -- and that is sad. Not because these tools/frameworks are bad, but because web dev can be so simple and easy and they are robbed of having that in their back pocket, as a proper foundation.

Re: A Critique of React Hooks

#230

Post by lhorie »

yawaramin wrote: post #217
lhorie wrote: post #172

Earlier quoted context omitted.

Right, I meant that Sebastian is the current maintainer. Not to detract from Dan Abramov etc, but the feel I get is that Sebastian is the one who really sets the pace for where React is going these days (i.e. hooks, suspense, etc). Correct me if I'm wrong.

Well, you're factually wrong. Abramov is the current React maintainer. Markbage is obviously a core team member but contributing good ideas doesn't automatically transform one into being the project maintainer.

Didn't mean it as an XOR. FWIW, looking at the github commit history one might get the impression that acdlite is the main committer in the repo these days, followed by trueadm and bvaughn (gaeron doesn't look all that active recently in comparison). I don't really hear those three core team members talk much about JS since their twitters tend to be less technical. My impressions come mostly from what I see the more technically-vocal react team members say publicly and I feel like gaeron often makes it sound like the bulk of react concepts are other people's contributions. Markbage certainly seems like the "vision" person in the team
Post reply on HN