Hacker News Reader

Comment by BilalBudhani | Hacker News Reader

Hooks seem to be a drastic change in how we're going to write React components in the future. I'm quite satisfied with the current way of writing components which is to me is very explicit (with no magic). With Hooks React is taking a different direction from their original motto of explicit design patterns. From the looks of it, Hooks seems like a counter-intuitive design pattern but traditionally that's how most of the JS concepts were before they went mainstream.

I'm going to wait and see for some production success stories become giving it serious thought.

View on HN

In case you’re curious, I recently wrote up a deep dive on React from first principles that includes Hooks.

https://overreacted.io/react-as-a-ui-runtime/

Personally I don’t see them as being either “magic” or “implicit”. You might find my post helpful for conceptualizing how they fit into the picture.

(Warning: it is a longread. But it also explains 90% of React on a single page.)

what a coincidence I just finished reading this article yesterday (and even Tweeted about it https://twitter.com/BilalBudhani/status/1092784595756556294).

TBH, After reading the article I'm definitely putting effort to understand the thought process behind this change. Thank for writing up such a detailed & informative explanation on concepts in React.

I'm fairly new to the React world, but the content of that article was really interesting!

Thanks for writing this. Really enjoy your writing style and hope you continue to write more!

I'm learning React and even though you prefaced it with "not beginner friendly", that was very helpful for understanding what goes on. Thanks!

That’s a great read.

"on a single page" - I see what you did there.

Hooks make a lot more sense from a traditional FRP perspective. The code you write with hooks is basically identical to the code you'd write with early FRP systems. For instance, useState is called newWire in FranTk. The difference is that hooks have various limitations about where you can create them and how you can pass them around, which those FRP systems don't have. That's the result of React using plain old data as state, instead of having a signal abstraction as in FRP. In React the component function gets re-executed every time the state changes, whereas with FRP the component function gets executed once and builds up a dataflow graph that deals with the changes. That makes hooks very natural because they're just nodes in the dataflow graph.

Glad to read that as the top comment, because when they came out, I expressed strong doubts about this new features, and I mostly received mad comments in return. The alienated react fans stated that I didn't understand what modern code was, what a great idea those were and how from now on, everything will be better.

Now hooks are certainly a technically interesting pattern. I can see why it can be desirable by some. But I can't shake the feeling it has too of a big potential for misuse and could add a lot of complexity to a react, a tool that already has a big cognitive load with an ecosystem letting easily creep technical debt.

Besides, an important part of the JS community, up to now, has let me inconvinced about its ability to do the right thing, not to mention learning from other's past mistakes or even admitting when something is a problem at all.

> Glad to read that as the top comment, because when they came out, I expressed strong doubts about this new features, and I mostly received mad comments in return. The alienated react fans stated that I didn't understand what modern code was, what a great idea those were and how from now on, everything will be better.

Your post boils down to "Seems like it might be nice, but there might be bad sides, too" which seems fair, but the rest of your post is dressed up in a weird gloating dismissiveness and an exaggerated narrative about you, the epic heroic, fighting back the baying React Fans like in Doom's cover art.

I wouldn't celebrate your skepticism just yet, especially not just because you found someone else on HN to commiserate with.

There have been what I think are some convincing arguments for it in the comments and linked urls like https://overreacted.io/react-as-a-ui-runtime/.

"weird gloating dismissiveness" could summarize most top comments on HN

No my answer boils down to:

- hooks are technically interesting, but make it easy for humans to screw up. It's a precise critic.

- the JS community has bad habits that can catalyse this, and above all, may lead them to avoid seing what's wrong

- they get angry when we say it, and dismiss it as nonsense.

Case in point.

The behavior that you see from a system is the behavior that that system encourages. I guess the proof will be in the pudding as to what hooks actually encourage.

I find a healthy dose of 'gloating dismissive' skepticism is usually a good thing. Because it stands in stark contrast 'gloating dismissive' dismissals of criticisms as 'nonsense' that usually come in the form "nah you just don't get it".

UI paradigms in particular warrant a good deal of skepticism in general. Every time it's "this is way!!!" and there are a whole slew of issues people regret wading into eventually down the line. Then new stuff comes out to fix those issues and "THIS is the way!!!" with the assumption that the new way doesn't have it's own problems (or at least the optimism is just ignoring them as they aren't salient enough yet to impact thinking). This just keeps playing out over and over. No reason its different this time.

So, I think it's absolutely fair to say "I wonder what nastiness come along with hooks that we are accepting as a trade-off for the potential benefits of Hooks?". At the same you can't compute the actual result as an intellectual exercise, so a healthy degree of optimism is warranted too in which we also ought to say "I'm excited to see if this really is the way and maybe we wont arrive at front-end utopia just yet, but hopefully we will get one step closer through the learnings".

That's a fair answer. And for the record, I don't thing we should not give a try to hooks, I just emit doubts.

`hooks are technically interesting, but make it easy for humans to screw up. It's a precise critic.`

You just haven't tried it, right? I love when people talking big but in fact they have 0 exp on some topic.

As one who has adopted hooks in production for 2 projects, one is med-big size.

You CAN NOT screw up. Because if you did, it even won't work or won't build.

And how it helps to decouple logic and code sharing is fantastic.

I don't expect bugs as a screw up, i expect technical debt.

“Commiserate with” is an English expression I’ll enjoy using in the future!

> could add a lot of complexity to a react, a tool that already has a big cognitive load

I don't understand how hooks add complexity or cognitive load. Simple cases stay simple (even more so, and it's harder to mess up with useEffect than with lifecycle methods, for example), and complex cases are less so.

From the point of view of someone with years of experience writing large applications with React, hooks are a very pragmatic move that solves real problems precisely by simplifying what was already possible. The more complex the scenario, the more obvious the gain is. I venture to say the same thing about the upcoming suspense and related features.

I don't think React itself has a big cognitive load anyway. You might be attributing to it the difficulty some aspects of functional programming might present to some, or of some libraries you might have been using with React. I found this to be the case often. Forgive me if I'm guessing incorrectly.

I don't know a big react project that doesn't bring in a massive ecosystem with it. Standard is at least a complex webpack setup with a store and a routing lib.

But more than that, react based code has a lot of indirections, requires a lot of pieces of the puzzle to figure out what's going on, and projects have so many different styles and layout you never feel at home when you switch.

The best exemple is jsx. Not only you need a transpiler, not only do you mix in the same place representation and behavior, but the code looks like either spagetthi inlines, or, if you are lucky, a list of many references you suddenly gotta check up somewhere else.

The thing is, with classes, you have a little guidance on where goes what, and people still manage to screw that up. With hooks it's free for all, with caveats, so reading somebody else's code is going to get extra fun.

I have the exact opposite perception. Previously, I used to convert a function/stateless component, just because I need one transient state and it felt very verbose to switch to class components, while all it needed was one state and corresponding setState. With Hooks, all of them just become more transparent (you explicitly have to hook all the states, not just use one state and add later add more states to track). Though I admit I felt uncomfortable initially, it just feels right once you start working with them. I really like hooks!!!

My litmus test for technology is whether it results in a) fewer lines of code b) simpler code and c) does it make me more productive. My experience with using hooks is that I rip out lots of cruft and it is easier for me to get my head around how to write things so I am more productive. The cost is learning a new paradigm, but the benefit for me was very high.

I strongly recommend you temper your criterion `a` by how much the abstractions help or impede your understanding of the code later on, especially when trying to diagnose a bug.

I suppose that's b)

I thought the same at first, but Dan Abramov and his blog[1] has changed my mind.

[1]: https://overreacted.io/why-do-hooks-rely-on-call-order/

Hooks fix some of the composition headaches you get from render props, which is the current standard for composition (the heritage being HOCs -> render props -> hooks). They're basically mixins with weird syntax.

The syntax isn't even that weird? It's just function calls.

The only "weird" bit is using array destructuring for multi-return and that's been in ES/JS for some time now, and definitely shouldn't look that weird to anyone that has worked in Python, as one example (and C# now supports destructuring even).

The weirdness is because the state or context seemingly comes from thin air - there's no explicit location for the data.

That's not really a syntax problem, though.

Also, hidden state/context is also not that weird? Do you need to know the exact location of the memory/stream that `console.log()` writes to in order to log the console? The physical details of how `navigator.compass.getHeading()` gets its information to use a compass heading? Both of those trampoline off into native code and the details of what the actual "explicit" locations for them is both irrelevant and highly variable depending on browser and system.

Unless you are looking at the namespace "objects" such as `console` or `navigator.compass` as "explicit locations", but you can add namespaces to your imports if that helps you feel like things are more "grounded". Import it and use it as `React.useState()` instead, for instance.

Alright, weird semantics then.

The hooks calls are unusual compared to normal Javascript code. If you read the other comments on this thread you'll see that I'm not the only one saying that. It comes down to the fact that it's a call, inside a render function, that has different behaviour on each call to said parent function. It's very magical - and the React team admit that, so I'm not sure what exactly you are arguing against.

It's not like I'm new to Javascript either - I've been coding in JS for over 10 years. I understand how it works, but it's still weird-looking code. You can hack up the language to make stuff like the new hooks library, even without the unique quirks of React's internals. But libraries that intentionally do that to generate magical effects are generally considered "weird" too.

I appreciate something about it feels weird to a number of people, and it feels that way to me at times, too. I'm just pointing out:

In JS call order always matters (it's an imperative language full of side effects), and many calls have side effects that very much differ based on the order you call them.

Even if the gut reaction to hooks is that they "feel" magical or quirky, it's not that different from how a lot of black box function calls already work in the language, it's just maybe more obvious with hooks because they are more explicit in the rules on when you should call them.

Which isn't to denigrate feeling weird about hooks. Again, even I still feel weird about them sometimes. Just that it is less unusual than that initial gut reaction seems to think it is.

Maybe you just don’t understand them yet.

Edit: this is one reason I don’t do the social media thing. I read that in a totally different frame of mind than you wrote it in, probably. I am not one to get all preachy. I personally get caught up in analysis paralysis sometimes because everyone has convincing arguments. It’s because there are many right answers. There’s probably some deeper psychology there... dunno but it’s on me.

No offense, but it would sometimes be good to remember that quote about sufficiently advanced technology being indistinguishable from magic when taking such an authoritative tone.

There are probably some other equally talented developers who do ‘get it’ who might be a little unsure of themselves and continue to hold back and feel like an imposter.

Anyway, that’s not really a call to change or anything. You do you.

But I did want to remind everyone else, especially those unsure of themselves, that those are, like, their opinion... you also do you.

Reply on news.ycombinator.com