5 ms·

Unbelievable that they’ve gone ahead launching this, going all in on hooks, while the fundamental problem with them, which was raised in 2018 is still unsolved:

Unbelievable that they’ve gone ahead launching this, going all in on hooks, while the fundamental problem with them, which was raised in 2018 is still unsolved: https://github.com/facebook/react/issues/14099 https://github.com/facebook/react/issues/14099 And they just handwave it away in the docs with an imaginary future API. Embarrassing.

aidos 4y ago
I’ve not read through the thread but I wonder how much of it is effective replaced by the upcoming useEvent hook https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md https://github.com/reactjs/rfcs/blob/useevent/text/0000-usee...
- nayroclade 4y ago
  It might have, but that RFC has been withdrawn.
  - danabramov 4y ago
    The quick version is we're looking at this from two different sides: - To avoid re-triggering stuff from Effects, we _are_ adding a Hook. It has the same API as the original `useEvent` proposal but is more tightly scoped to this particular use case (and different semantics). We'll submit a new RFC for it after some more testing, but it's available (as `useEffectEvent`) in experimental builds, and the docs mention it: https://react.dev/learn/separating-events-from-effects#declaring-an-effect-event https://react.dev/learn/separating-events-from-effects#decla... - To improve rendering performance, we are working on an automatic compiler that analyzes your code and makes rendering much more granular. It's still in active R&D but we hope to share an update on it soon. We think these two things together will likely be able to mostly address the issue. If not, we'll look at the specific gaps and work on them more closely. In general though, people have shipped huge apps with Hooks, and it's definitely production-ready. Always an opportunity for improvement, sure.
    - nayroclade 4y ago
      Yeah, I’ve helped build some of those huge apps, and I’ve ran in these issues and wasted countless hours debugging and working around them in all of them. And what do we get from the React team? After five years? More vague promises. More RFCs. More blog posts. More tweets. More docs mentioning nonexistent APIs. No actual shipped solutions. Forgive me, but I just don’t believe you anymore at this point. Five years.
      - aidos 4y ago
        I mean, with that attitude? You’re obviously a bit frustrated but as someone who has done a lot of React over the years I don’t quite get what you’re running into that would make you that upset.
      - danabramov 4y ago
        Can you be a bit more specific about which issues you've ran into? That would help me know whether we're addressing them or not. (The linked issue is very broad so it's not super clear which part of it you're referring to. We think it conflates a few unrelated things.) I think it's fair criticism we've been slow on shipping this Hook. We try to take a very cautious approach to introducing new APIs, so we are currently testing it in our internal codebase. Once we feel confident the approach makes sense, we will make a stable release with it.
      - kristiandupont 4y ago
        What an incredibly entitled attitude.
    - aidos 4y ago
      Thanks for the update. There’s always a lot of complaining about hooks but honestly I think they’re generally pretty wonderful. Occasionally you need to do some gymnastics but more recently I’ve lent on the useEvent pattern to detach reactive and non-reactive code and it’s working nicely. Is there something I should know about useEffectEvent vs useEvent? We use the pretend / poly fill version and I understand it behaves slightly differently. But in general we just want a function that doesn’t change that always calls the latest version of the real function. Mostly we’re passing it down to other components that use it as an event handler or sometimes in a useEffect themselves. As ever, thanks for the work on React.
ajkjk 4y ago
What are you talking about? Hooks are fine and are out there working fine for everybody. They have some rough edges but it's not, like, some catastrophe.
spencerchubb 4y ago
I think you're a few years too late to criticize for going all in on hooks. Sure, there may be deep rooted problems, but there's a lot of inertia.
abxytg 4y ago
Can you elaborate on what this issue prevents you from doing? I write production react code that is used in medical devices every single day and I have never had this problem stop me from developing a particular screen or piece of functionality, and I use pretty much every niche edge web API that there is. Hooks has made me 3-4x more productive. If a technicality is stopping you from enjoying it, that is such a shame.
martpie 4y ago
How is that an actual _fundamental_ problem? The world has embraced hooks, for better or worse. The fact is React still works well, and the React team has always been clear that performance is (somewhat) an implementation details. For example, they often advertise to use inlined functions and to use `useCallback` only if you're facing performance issues. So `useCallback` invalidation is definitely not "fundamental" (imho)
- wetpaws 4y ago
  JS world has a long running tradition of embracing things that in retrospect they should've not.
whakim 4y ago
This is certainly an issue/annoyance (along with other things I don't care for about React), but calling it a "fundamental problem" and "embarrassing" ignores the vast, vast majority of React users who manage just fine.
hummus_bae 4y ago
This may come across as naive, but could you expand on the significance of this issue for people who don't use React every day? I see that lots of people think this way about Hooks, so I'm honestly just curious about what React users think is such a big deal
- abxytg 4y ago
  its not naive. this isn't a problem you're likely to run into or have to work around. It is a thing that pedantic people bring up to justify the trouble they have keeping up with the pace of change in front end dev.
chatmasta 4y ago
And yet, entire startups have been created and acquired during that time, many using React and many using hooks. It appears this "fundamental problem" is far from a show-stopper. Ultimately, that's why people like React: it gets the job done. The API is small and extremely stable. The last major breaking change was hooks, and that wasn't really even a breaking change - just a new paradigm that you should move to eventually (class components do still technically work!) Honestly, by the time class components are fully deprecated, you'll probably be able to ask ChatGPT to rewrite your codebase to use hooks instead...
- epolanski 4y ago
  The api is anything but small.
  - christophilus 4y ago
    It’s pretty small compared to most UI frameworks I’ve seen.
  - selfmodruntime 4y ago
    React features 13 top level functions and 11 hooks. That remains an extremely small API for a frontend framework.
    - epolanski 4y ago
      It's a library, not a framework. Add a router like react-router and you have another 20 apis. Add on top of that a state manager, even small ones, and you're adding another 10/15 apis.
      - chatmasta 4y ago
        That's irrelevant to your original claim that React is not a small API. btw, have you seen the DOM API? It's huge!
  - JoeyJoJoJr 4y ago
ojkelly 4y ago
> Unbelievable that they’ve gone ahead launching this I hope the irony of criticising a team for launching something early, on HN _of all places_ isn’t lost on you. > going all in on hooks They went all in on hooks in 2018 when they rewrote the internals with React Fiber. Hooks are how react works, class components are more of an abstraction—not less. > while the fundamental problem with them, which was raised in 2018 is still unsolved If it was a showstopper it would have been fixed by now.
klysm 4y ago
It's odd that sooo many things are still successfully built on top of react.
davidatbu 4y ago
I've had to write my own `useCallbackOne()` hook that is guaranteed to not be recomputed if it's dependencies don't change. export function useMemoOne<T>(valueProducer: () => T, deps: unknown[]) { const [initialValue] = useState(valueProducer); const memoizedValue = useRef(initialValue); const memoizedDeps = useRef(deps); if ( deps.length != memoizedDeps.current!.length || _.zip(deps, memoizedDeps.current!).some( ([dep, memoizedDep]) => dep != memoizedDep ) ) { memoizedValue.current = valueProducer(); memoizedDeps.current = deps; } return memoizedValue.current; } // eslint-disable-next-line @typescript-eslint/no-explicit-any export function useCallbackOne<T extends (...args: any[]) => unknown>( fn: T, deps: unknown[] ) { return useMemoOne(() => fn, deps); } FWIW, for this and other reasons, I've recently been looking into "actually reactive" frameworks (like Solid/Svelte), and I think I vastly prefer their paradigm to react's. Specifically, I used sycamore-rs to build a Rust/WASM UI, and it's great (once you get the hang of dealing with lifetimes in sycamore).
- bmikaili 4y ago
  if you like sycamore check out dioxus.
  - davidatbu 4y ago
    But isn't dioxius also using a vDOM like react? I'm curious, what do you think are the advantages of dioxius over sycamore?

aidos 4y ago

I’ve not read through the thread but I wonder how much of it is effective replaced by the upcoming useEvent hook https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md https://github.com/reactjs/rfcs/blob/useevent/text/0000-usee...

nayroclade 4y ago
It might have, but that RFC has been withdrawn.
- danabramov 4y ago
  The quick version is we're looking at this from two different sides: - To avoid re-triggering stuff from Effects, we _are_ adding a Hook. It has the same API as the original `useEvent` proposal but is more tightly scoped to this particular use case (and different semantics). We'll submit a new RFC for it after some more testing, but it's available (as `useEffectEvent`) in experimental builds, and the docs mention it: https://react.dev/learn/separating-events-from-effects#declaring-an-effect-event https://react.dev/learn/separating-events-from-effects#decla... - To improve rendering performance, we are working on an automatic compiler that analyzes your code and makes rendering much more granular. It's still in active R&D but we hope to share an update on it soon. We think these two things together will likely be able to mostly address the issue. If not, we'll look at the specific gaps and work on them more closely. In general though, people have shipped huge apps with Hooks, and it's definitely production-ready. Always an opportunity for improvement, sure.
  - nayroclade 4y ago
    Yeah, I’ve helped build some of those huge apps, and I’ve ran in these issues and wasted countless hours debugging and working around them in all of them. And what do we get from the React team? After five years? More vague promises. More RFCs. More blog posts. More tweets. More docs mentioning nonexistent APIs. No actual shipped solutions. Forgive me, but I just don’t believe you anymore at this point. Five years.
    - aidos 4y ago
      I mean, with that attitude? You’re obviously a bit frustrated but as someone who has done a lot of React over the years I don’t quite get what you’re running into that would make you that upset.
    - danabramov 4y ago
      Can you be a bit more specific about which issues you've ran into? That would help me know whether we're addressing them or not. (The linked issue is very broad so it's not super clear which part of it you're referring to. We think it conflates a few unrelated things.) I think it's fair criticism we've been slow on shipping this Hook. We try to take a very cautious approach to introducing new APIs, so we are currently testing it in our internal codebase. Once we feel confident the approach makes sense, we will make a stable release with it.
    - kristiandupont 4y ago
      What an incredibly entitled attitude.
  - aidos 4y ago
    Thanks for the update. There’s always a lot of complaining about hooks but honestly I think they’re generally pretty wonderful. Occasionally you need to do some gymnastics but more recently I’ve lent on the useEvent pattern to detach reactive and non-reactive code and it’s working nicely. Is there something I should know about useEffectEvent vs useEvent? We use the pretend / poly fill version and I understand it behaves slightly differently. But in general we just want a function that doesn’t change that always calls the latest version of the real function. Mostly we’re passing it down to other components that use it as an event handler or sometimes in a useEffect themselves. As ever, thanks for the work on React.

ajkjk 4y ago

What are you talking about? Hooks are fine and are out there working fine for everybody. They have some rough edges but it's not, like, some catastrophe.

spencerchubb 4y ago

I think you're a few years too late to criticize for going all in on hooks. Sure, there may be deep rooted problems, but there's a lot of inertia.

abxytg 4y ago

Can you elaborate on what this issue prevents you from doing? I write production react code that is used in medical devices every single day and I have never had this problem stop me from developing a particular screen or piece of functionality, and I use pretty much every niche edge web API that there is. Hooks has made me 3-4x more productive. If a technicality is stopping you from enjoying it, that is such a shame.

martpie 4y ago

How is that an actual _fundamental_ problem? The world has embraced hooks, for better or worse. The fact is React still works well, and the React team has always been clear that performance is (somewhat) an implementation details. For example, they often advertise to use inlined functions and to use `useCallback` only if you're facing performance issues. So `useCallback` invalidation is definitely not "fundamental" (imho)

wetpaws 4y ago
JS world has a long running tradition of embracing things that in retrospect they should've not.

whakim 4y ago

This is certainly an issue/annoyance (along with other things I don't care for about React), but calling it a "fundamental problem" and "embarrassing" ignores the vast, vast majority of React users who manage just fine.

hummus_bae 4y ago

This may come across as naive, but could you expand on the significance of this issue for people who don't use React every day? I see that lots of people think this way about Hooks, so I'm honestly just curious about what React users think is such a big deal

abxytg 4y ago
its not naive. this isn't a problem you're likely to run into or have to work around. It is a thing that pedantic people bring up to justify the trouble they have keeping up with the pace of change in front end dev.

chatmasta 4y ago

And yet, entire startups have been created and acquired during that time, many using React and many using hooks. It appears this "fundamental problem" is far from a show-stopper. Ultimately, that's why people like React: it gets the job done. The API is small and extremely stable. The last major breaking change was hooks, and that wasn't really even a breaking change - just a new paradigm that you should move to eventually (class components do still technically work!) Honestly, by the time class components are fully deprecated, you'll probably be able to ask ChatGPT to rewrite your codebase to use hooks instead...

epolanski 4y ago
The api is anything but small.
- christophilus 4y ago
  It’s pretty small compared to most UI frameworks I’ve seen.
- selfmodruntime 4y ago
  React features 13 top level functions and 11 hooks. That remains an extremely small API for a frontend framework.
  - epolanski 4y ago
    It's a library, not a framework. Add a router like react-router and you have another 20 apis. Add on top of that a state manager, even small ones, and you're adding another 10/15 apis.
    - chatmasta 4y ago
      That's irrelevant to your original claim that React is not a small API. btw, have you seen the DOM API? It's huge!
- JoeyJoJoJr 4y ago

ojkelly 4y ago

> Unbelievable that they’ve gone ahead launching this I hope the irony of criticising a team for launching something early, on HN _of all places_ isn’t lost on you. > going all in on hooks They went all in on hooks in 2018 when they rewrote the internals with React Fiber. Hooks are how react works, class components are more of an abstraction—not less. > while the fundamental problem with them, which was raised in 2018 is still unsolved If it was a showstopper it would have been fixed by now.

klysm 4y ago

It's odd that sooo many things are still successfully built on top of react.

davidatbu 4y ago

I've had to write my own `useCallbackOne()` hook that is guaranteed to not be recomputed if it's dependencies don't change. export function useMemoOne<T>(valueProducer: () => T, deps: unknown[]) { const [initialValue] = useState(valueProducer); const memoizedValue = useRef(initialValue); const memoizedDeps = useRef(deps); if ( deps.length != memoizedDeps.current!.length || _.zip(deps, memoizedDeps.current!).some( ([dep, memoizedDep]) => dep != memoizedDep ) ) { memoizedValue.current = valueProducer(); memoizedDeps.current = deps; } return memoizedValue.current; } // eslint-disable-next-line @typescript-eslint/no-explicit-any export function useCallbackOne<T extends (...args: any[]) => unknown>( fn: T, deps: unknown[] ) { return useMemoOne(() => fn, deps); } FWIW, for this and other reasons, I've recently been looking into "actually reactive" frameworks (like Solid/Svelte), and I think I vastly prefer their paradigm to react's. Specifically, I used sycamore-rs to build a Rust/WASM UI, and it's great (once you get the hang of dealing with lifetimes in sycamore).

bmikaili 4y ago
if you like sycamore check out dioxus.
- davidatbu 4y ago
  But isn't dioxius also using a vDOM like react? I'm curious, what do you think are the advantages of dioxius over sycamore?