6 ms·

You do not need to know how `useState` works to understand how to use it to write a React application, it is fairly intuitive to understand how to apply the pat

You do not need to know how `useState` works to understand how to use it to write a React application, it is fairly intuitive to understand how to apply the pattern. If I look at your library, it seems to me like it requires a much more complex mental model to begin to use. Of course, it is better in theory for a developer to thoroughly understand the details of their framework, but empirically, React has been very successful in allowing people to build relatively sophisticated applications while understanding very little of the underlying model.

bakugo 2y ago
You don't need to understand how useState works if you're writing a page with a button that increments a number when pressed, from a beginner's tutorial. As soon as you work on any remotely complex codebase, you will run into problems that require a decent mental model of the underlying "magic" to properly understand and solve. "Building sophisticated applications while understanding very little of the underlying model" is how you end up with gigantic piles of unmaintainable spaghetti code full of awful hacks, which seems to be the standard for React applications.
- lolinder 2y ago
  Is this less true of Web Components? I've worked with a lot of different tech stacks over my career and every single one of them has required understanding the internals once you start using them seriously. I haven't found React to be substantially worse for that than any other tech stack I've used.
  - peebeebee 2y ago
    With webcomponents you are pretty close to the “metal”. If you know how to write good vanilla JavaScript, you can take most of that knowledge into webcomponents. You only need to learn the custom components lifecycle, and shadowDOM, which is knowledge about web-standards. With other frameworks you need to learn template syntaxing, how state propagates, how the compiler works, etc etc. Lot of that knowledge might be obsolete in 10 years. Which isn’t to say it can’t be worth it. Learning multiple frameworks and libraries is also very helpful to skill up because you are learning about different concepts and implementations.
    - Narhem 2y ago
      Another advantage of web components is the syntax is similar enough to Java (especially with JavaDocs) switching between coding a Java spring backend and a Web component based front end is doesn’t need as much of a mental context switch.
InsideOutSanta 2y ago
"You do not need to know how `useState` works" I feel like you eventually do. The issue with React, at least in my experience, is that it's a type of abstraction that seems ill-suited for how the web works under the hood, so it's incredibly leaky. Everything seems to make sense initially, and you get along just fine, but then you run into an edge case, and there's an official workaround for the edge case, but then you run into edge cases for the workaround for the edge case, and suddenly, that's your whole life. Before you know it, you really do have to know how things actually work under the hood.
- djbusby 2y ago
  Seems like that happens with every frameworks I've ever used since 2000 (in Perl, PHP, Ruby, JS, etc). Every framework makes the easy things slightly easier, the boring stuff is included and you get to focus on the fun/hard part - and I think then, naturally, you bump into the edge. But! You get to that point faster. And then you have to know the guts to solve the issue the "framework" way or do some lower-level shit-hack. I feel like it's just a natural law of any general purpose framework. It made the first 80% of the job easy. Now you just have to finish the other 80%.
- dartos 2y ago
  I thought pre-hooks react provided a really nice and simple abstraction over how the web works. FRP is a nice fit for the kind of UI that makes the majority of the web. Hooks ruined the framework imo. Confusing api (useState returning an array for example). Having a class component with hooks for lifecycle behavior made perfect sense. Each component’s state being a field on those classes was easy to understand. Hooks came out of left field and made everything more complex for the worse.
  - kaoD 2y ago
    > Hooks ruined the framework imo. Confusing api (useState returning an array for example). It just returns a tuple. That's not confusing at all and it's a very well established pattern in most modern languages. If there's anything that can be considered complex and footgun-y in React it's useEffect because most of the time you shouldn't use it at all but it can be abused very easily and it kinda works even if you abuse it (but introduces a huge maintenance burden).
jeswin 2y ago
> If I look at your library, it seems to me like it requires a much more complex mental model to begin to use. How so? It has two functions: (1) createElement(jsx): Allows you to use JSX to write HTML markup. Returns Virtual Nodes. (2) applyDiff(parent, vNodes): Merges Virtual Nodes created with JSX into the real DOM efficiently. This is all you need to know. I can keep it simple because I am not doing much in the library. I felt that if I stayed close to the standards, I wouldn't need to do much.
- BoorishBears 2y ago
  Maybe you have the luxury of users who want applications that have all the reactivity of a DMV form, but in my apps at some point I'll need the very simple priciple of "do something complex when this value changes" and reimplement useState/useEffect in an ad-hoc manner anyways. I'm more of a backend/embedded developer than a web developer and I still honestly don't get how people find useState/useEffect as intimidating as your comment makes them out to be.
recursive 2y ago
This hasn't been my experience at all. The implementation details even leak into this crazy thing called "the rules of hooks". It looks like a function but it's actually this new thing called a hook. Which state will you get? That depends on whether the reconciler considers this invocation to be a mount or update. Getting the wrong one? Try restructuring your elements or adding or removing a "key" attribute. People tolerate this because they learned it but I don't think there is anything essentially simple about it.
- phist_mcgee 2y ago
  If you have an understanding of closures, hooks are quite intuitive.
  - recursive 2y ago
    I have a pretty thorough understanding of both. But I can't understand how you'd find them to be similar in any way. Functions forming closures can be called conditionally, in a loop, or even when no react component is even rendering. Most of the complexity of hooks is not addressed at all by closures, and I don't really what part of their behavior is related at all. Maybe just that you can pass a value to one function, and then get it returned from another one. The standard hooks delegate to a dispatcher, which has access to the current fiber. The current fiber has a linked list of memoizedState for the current work node. It's true that a lot of the functions that eventually service the hook calls do contain closures. But that doesn't seem to grant much insight into how to use them or how they work. It's like saying "if you have an understanding of loops, the reconciler is quite intuitive". I mean yes, the reconciler uses loops. But the behavior of reconciliation may still be quite mysterious.
    - kaoD 2y ago
      I'll try to fix the comment you're replying to: I think of React components as not closures but coroutines (and hooks are its yield points). Hooks are implicitly keyed by index which is the most magic-y/surprising part... but I'm sure if you had to manually key them that'd be criticized too (and would be abused to death-by-bugs, so I can see why they went with this design). If you understand both points above, you understand hooks. I still fail to get the (usual) criticism of hooks. They have lots of warts but the API (which is often what gets mentioned) is the most superficial and less annoying criticism. Feels like something that would be mentioned after just skimming the docs. Very shallow. On the contrary: useEffect is a footgun and deserves criticism. useRef being overloaded to mimic instance variables is confusing for newbies (but this is just a naming issue IMO). The difference between normal/layout/insertion effects is complex and subtle. The new stuff that tries to solve some issues with the concurrent mode (like transitions/deferred value/etc.) feels like a huge hack. React 19 will come with its own warts (actions, RSC...) But the API? I don't care at all. Pretty simple, at least for my mental model.
azangru 2y ago
While you do not need to understand how useState, or any other hooks work, you do need to know that this piece of code will behave differently from the rest of your javascript. Painfully, when the calling of (most of the) hooks is concerned, React takes away from the developer the ability to write conditional logic. This is both unintuitive and bonkers, and it requires the developer to come up with convoluted techniques for working around this limitation. This is part of what 'understanding of how hooks work' means.
_heimdall 2y ago
There are a lot of footguns in react if you don't know how use state works. If you don't know what triggers a re-render you can end up in a state where the data was changed but the UI didn't update, or where the data changed once and re-rendered multiple times. In my experience the issues are more noticeable with async state changes, like making network requests or state-driven animations.
bvrmn 2y ago
Aha-ha. Devs constantly try to use dynamic hooks. For example conditionally rendered component which allocates a hook. Yes, React would trigger a warning, that number of hooks was changed. But this implementation detail requires you to have at least a mental model of what hooks actually are to avoid gotchas.

bakugo 2y ago

You don't need to understand how useState works if you're writing a page with a button that increments a number when pressed, from a beginner's tutorial. As soon as you work on any remotely complex codebase, you will run into problems that require a decent mental model of the underlying "magic" to properly understand and solve. "Building sophisticated applications while understanding very little of the underlying model" is how you end up with gigantic piles of unmaintainable spaghetti code full of awful hacks, which seems to be the standard for React applications.

lolinder 2y ago
Is this less true of Web Components? I've worked with a lot of different tech stacks over my career and every single one of them has required understanding the internals once you start using them seriously. I haven't found React to be substantially worse for that than any other tech stack I've used.
- peebeebee 2y ago
  With webcomponents you are pretty close to the “metal”. If you know how to write good vanilla JavaScript, you can take most of that knowledge into webcomponents. You only need to learn the custom components lifecycle, and shadowDOM, which is knowledge about web-standards. With other frameworks you need to learn template syntaxing, how state propagates, how the compiler works, etc etc. Lot of that knowledge might be obsolete in 10 years. Which isn’t to say it can’t be worth it. Learning multiple frameworks and libraries is also very helpful to skill up because you are learning about different concepts and implementations.
  - Narhem 2y ago
    Another advantage of web components is the syntax is similar enough to Java (especially with JavaDocs) switching between coding a Java spring backend and a Web component based front end is doesn’t need as much of a mental context switch.

InsideOutSanta 2y ago

"You do not need to know how `useState` works" I feel like you eventually do. The issue with React, at least in my experience, is that it's a type of abstraction that seems ill-suited for how the web works under the hood, so it's incredibly leaky. Everything seems to make sense initially, and you get along just fine, but then you run into an edge case, and there's an official workaround for the edge case, but then you run into edge cases for the workaround for the edge case, and suddenly, that's your whole life. Before you know it, you really do have to know how things actually work under the hood.

djbusby 2y ago
Seems like that happens with every frameworks I've ever used since 2000 (in Perl, PHP, Ruby, JS, etc). Every framework makes the easy things slightly easier, the boring stuff is included and you get to focus on the fun/hard part - and I think then, naturally, you bump into the edge. But! You get to that point faster. And then you have to know the guts to solve the issue the "framework" way or do some lower-level shit-hack. I feel like it's just a natural law of any general purpose framework. It made the first 80% of the job easy. Now you just have to finish the other 80%.
dartos 2y ago
I thought pre-hooks react provided a really nice and simple abstraction over how the web works. FRP is a nice fit for the kind of UI that makes the majority of the web. Hooks ruined the framework imo. Confusing api (useState returning an array for example). Having a class component with hooks for lifecycle behavior made perfect sense. Each component’s state being a field on those classes was easy to understand. Hooks came out of left field and made everything more complex for the worse.
- kaoD 2y ago
  > Hooks ruined the framework imo. Confusing api (useState returning an array for example). It just returns a tuple. That's not confusing at all and it's a very well established pattern in most modern languages. If there's anything that can be considered complex and footgun-y in React it's useEffect because most of the time you shouldn't use it at all but it can be abused very easily and it kinda works even if you abuse it (but introduces a huge maintenance burden).

jeswin 2y ago

> If I look at your library, it seems to me like it requires a much more complex mental model to begin to use. How so? It has two functions: (1) createElement(jsx): Allows you to use JSX to write HTML markup. Returns Virtual Nodes. (2) applyDiff(parent, vNodes): Merges Virtual Nodes created with JSX into the real DOM efficiently. This is all you need to know. I can keep it simple because I am not doing much in the library. I felt that if I stayed close to the standards, I wouldn't need to do much.

BoorishBears 2y ago
Maybe you have the luxury of users who want applications that have all the reactivity of a DMV form, but in my apps at some point I'll need the very simple priciple of "do something complex when this value changes" and reimplement useState/useEffect in an ad-hoc manner anyways. I'm more of a backend/embedded developer than a web developer and I still honestly don't get how people find useState/useEffect as intimidating as your comment makes them out to be.

recursive 2y ago

This hasn't been my experience at all. The implementation details even leak into this crazy thing called "the rules of hooks". It looks like a function but it's actually this new thing called a hook. Which state will you get? That depends on whether the reconciler considers this invocation to be a mount or update. Getting the wrong one? Try restructuring your elements or adding or removing a "key" attribute. People tolerate this because they learned it but I don't think there is anything essentially simple about it.

phist_mcgee 2y ago
If you have an understanding of closures, hooks are quite intuitive.
- recursive 2y ago
  I have a pretty thorough understanding of both. But I can't understand how you'd find them to be similar in any way. Functions forming closures can be called conditionally, in a loop, or even when no react component is even rendering. Most of the complexity of hooks is not addressed at all by closures, and I don't really what part of their behavior is related at all. Maybe just that you can pass a value to one function, and then get it returned from another one. The standard hooks delegate to a dispatcher, which has access to the current fiber. The current fiber has a linked list of memoizedState for the current work node. It's true that a lot of the functions that eventually service the hook calls do contain closures. But that doesn't seem to grant much insight into how to use them or how they work. It's like saying "if you have an understanding of loops, the reconciler is quite intuitive". I mean yes, the reconciler uses loops. But the behavior of reconciliation may still be quite mysterious.
  - kaoD 2y ago
    I'll try to fix the comment you're replying to: I think of React components as not closures but coroutines (and hooks are its yield points). Hooks are implicitly keyed by index which is the most magic-y/surprising part... but I'm sure if you had to manually key them that'd be criticized too (and would be abused to death-by-bugs, so I can see why they went with this design). If you understand both points above, you understand hooks. I still fail to get the (usual) criticism of hooks. They have lots of warts but the API (which is often what gets mentioned) is the most superficial and less annoying criticism. Feels like something that would be mentioned after just skimming the docs. Very shallow. On the contrary: useEffect is a footgun and deserves criticism. useRef being overloaded to mimic instance variables is confusing for newbies (but this is just a naming issue IMO). The difference between normal/layout/insertion effects is complex and subtle. The new stuff that tries to solve some issues with the concurrent mode (like transitions/deferred value/etc.) feels like a huge hack. React 19 will come with its own warts (actions, RSC...) But the API? I don't care at all. Pretty simple, at least for my mental model.

azangru 2y ago

While you do not need to understand how useState, or any other hooks work, you do need to know that this piece of code will behave differently from the rest of your javascript. Painfully, when the calling of (most of the) hooks is concerned, React takes away from the developer the ability to write conditional logic. This is both unintuitive and bonkers, and it requires the developer to come up with convoluted techniques for working around this limitation. This is part of what 'understanding of how hooks work' means.

_heimdall 2y ago

There are a lot of footguns in react if you don't know how use state works. If you don't know what triggers a re-render you can end up in a state where the data was changed but the UI didn't update, or where the data changed once and re-rendered multiple times. In my experience the issues are more noticeable with async state changes, like making network requests or state-driven animations.

bvrmn 2y ago

Aha-ha. Devs constantly try to use dynamic hooks. For example conditionally rendered component which allocates a hook. Yes, React would trigger a warning, that number of hooks was changed. But this implementation detail requires you to have at least a mental model of what hooks actually are to avoid gotchas.