5 ms·

Agreed. Last year, for instance, I tried Svelte. I had a great time for a while, everything was fairly simple...but then I hit a specific scenario. I can't reca

Agreed. Last year, for instance, I tried Svelte. I had a great time for a while, everything was fairly simple...but then I hit a specific scenario. I can't recall what it was, but it led to me digging as deep as I could into their docs to try and understand how Svelte was doing that whole $ thing. I nearly melted my brain trying to understand it. That's not to say hooks are much better, but I find the overall mental model to be fairly simple to understand, and I don't often find myself bumping up against React's edges.

deleted 4y ago
[deleted]
alex504 4y ago
That's the thing about react, there basically are no edges or very very few edges left. There were edges in like 2018, but the team has made it relatively easy to do anything you want to do, while writing scalable and maintainable code.
BigJono 4y ago
Hooks are much better. The only problem with hooks is that people don't get them. But once you get them, every other approach looks like a complicated pile of shit. I think the dev community does really poorly with these kinds of abstractions that are very simple but completely unintuitive. I place a lot of the blame on the React team too. When hooks came out, their docs were absolutely terrible. They probably still are. They were full of shitty editorialising like "we created hooks because we found classes were too difficult for people to understand!", which made every dev I worked with feel insecure for not immediately knowing how to write super awesome clean code.
- danielvaughn 4y ago
  I'm a big fan of hooks, but I'm still not completely sold on them. I like code that reads in logical sequence, like you're telling a story. When you use `useEffect` to coordinate side effects from prop changes, it makes me feel like I'm reading a story written by Quentin Tarantino. That being said, it's a relatively small complaint.
  - imbnwa 4y ago
    >I'm a big fan of hooks, but I'm still not completely sold on them. I like code that reads in logical sequence, like you're telling a story. When you use `useEffect` to coordinate side effects from prop changes, it makes me feel like I'm reading a story written by Quentin Tarantino. I actually read this as a compliment considering Tarantino himself spoke in an interview about how his non-linear storytelling style comes from the way novels he'd read were written.
- localvoid 4y ago
  > The only problem with hooks is that people don't get them. But once you get them, every other approach looks like a complicated pile of shit. No, some people actually get them and there are way much better alternatives[1]. 1. http://intelligiblebabble.com/compose-from-first-principles/ http://intelligiblebabble.com/compose-from-first-principles/
apd_ 4y ago
I believe you're referring to $ not being fired when another $ below it updates the variable the first $ subscribes to. This is an expected behavior. In Svelte the order of $ matters to prevent infinite loops. In this example the second $ won't trigger the first $: let a = 1; let b = 1; $: if (a > 0) { b += 1 } $: if (b > 0) { a += 1 } With React's useEffect one can easily falls into the trap of an infinite re-rendering: let a = 1; let b = 1; useEffect(() => { b += 1; }, [a]); useEffect(() => { a += 1; }, [b]); Great framework are supposed to prevent this kind of loophole.
- jcheng 4y ago
  I haven't done much playing around with Svelte so don't have any business injecting myself into this subthread, but your explanation piqued my curiosity. https://github.com/sveltejs/svelte/issues/6730 https://github.com/sveltejs/svelte/issues/6730 https://github.com/sveltejs/svelte/issues/6732 https://github.com/sveltejs/svelte/issues/6732 So basically, reactive blocks are only allowed to run once per tick; if a dependency changes after a block has run, too bad, the block won't run again. That is really shocking to me. (I won't say more due to my inexperience with Svelte...)
  - danielvaughn 4y ago
    This is all triggering my memory, I had forgotten how it actually worked so couldn't explain the issue I was having. But it was related to this exact behavior. I found it so unintuitive and difficult to grasp that I literally abandoned the project and decided to build it from scratch in React. It's a shame because it's an otherwise lovely framework.
- phist_mcgee 4y ago
  What happens if you do want effects to update each other's dependencies, but only conditionally? eg. A certain number of cascading updates?
- unconed 4y ago
  Novice react developers reach for useEffect way too often, because they are still thinking in terms of state transitions instead of declarative states. I have spent a lot of time teaching people not to do that. They always end up very happy once they get it, because now they can build complex UIs and have a solid strategy for compartmentalization, which makes bug whack-a-mole go away. It's not a fault in the framework, it's a fault in their understanding, where they don't know how to implement features in O(N) lines of code instead of O(N^2). The hint is in the name: you're supposed to think in terms of formal functional Effects that mount and unmount independently and compose orthogonally. The result will be a code base that remains maintainable even though you've kept on adding more nuanced features over months and months. Also, your snippet doesn't cause an infinite loop at all because modifying local variables does not trigger a rerender. If you had written setA / setB, sure, it would... but I think this perfectly illustrates the explicit vs implicit distinction. Great frameworks don't trap developers in local maxima.

deleted 4y ago

[deleted]

alex504 4y ago

That's the thing about react, there basically are no edges or very very few edges left. There were edges in like 2018, but the team has made it relatively easy to do anything you want to do, while writing scalable and maintainable code.

BigJono 4y ago

Hooks are much better. The only problem with hooks is that people don't get them. But once you get them, every other approach looks like a complicated pile of shit. I think the dev community does really poorly with these kinds of abstractions that are very simple but completely unintuitive. I place a lot of the blame on the React team too. When hooks came out, their docs were absolutely terrible. They probably still are. They were full of shitty editorialising like "we created hooks because we found classes were too difficult for people to understand!", which made every dev I worked with feel insecure for not immediately knowing how to write super awesome clean code.

danielvaughn 4y ago
I'm a big fan of hooks, but I'm still not completely sold on them. I like code that reads in logical sequence, like you're telling a story. When you use `useEffect` to coordinate side effects from prop changes, it makes me feel like I'm reading a story written by Quentin Tarantino. That being said, it's a relatively small complaint.
- imbnwa 4y ago
  >I'm a big fan of hooks, but I'm still not completely sold on them. I like code that reads in logical sequence, like you're telling a story. When you use `useEffect` to coordinate side effects from prop changes, it makes me feel like I'm reading a story written by Quentin Tarantino. I actually read this as a compliment considering Tarantino himself spoke in an interview about how his non-linear storytelling style comes from the way novels he'd read were written.
localvoid 4y ago
> The only problem with hooks is that people don't get them. But once you get them, every other approach looks like a complicated pile of shit. No, some people actually get them and there are way much better alternatives[1]. 1. http://intelligiblebabble.com/compose-from-first-principles/ http://intelligiblebabble.com/compose-from-first-principles/

apd_ 4y ago

I believe you're referring to $ not being fired when another $ below it updates the variable the first $ subscribes to. This is an expected behavior. In Svelte the order of $ matters to prevent infinite loops. In this example the second $ won't trigger the first $: let a = 1; let b = 1; $: if (a > 0) { b += 1 } $: if (b > 0) { a += 1 } With React's useEffect one can easily falls into the trap of an infinite re-rendering: let a = 1; let b = 1; useEffect(() => { b += 1; }, [a]); useEffect(() => { a += 1; }, [b]); Great framework are supposed to prevent this kind of loophole.

jcheng 4y ago
I haven't done much playing around with Svelte so don't have any business injecting myself into this subthread, but your explanation piqued my curiosity. https://github.com/sveltejs/svelte/issues/6730 https://github.com/sveltejs/svelte/issues/6730 https://github.com/sveltejs/svelte/issues/6732 https://github.com/sveltejs/svelte/issues/6732 So basically, reactive blocks are only allowed to run once per tick; if a dependency changes after a block has run, too bad, the block won't run again. That is really shocking to me. (I won't say more due to my inexperience with Svelte...)
- danielvaughn 4y ago
  This is all triggering my memory, I had forgotten how it actually worked so couldn't explain the issue I was having. But it was related to this exact behavior. I found it so unintuitive and difficult to grasp that I literally abandoned the project and decided to build it from scratch in React. It's a shame because it's an otherwise lovely framework.
phist_mcgee 4y ago
What happens if you do want effects to update each other's dependencies, but only conditionally? eg. A certain number of cascading updates?
unconed 4y ago
Novice react developers reach for useEffect way too often, because they are still thinking in terms of state transitions instead of declarative states. I have spent a lot of time teaching people not to do that. They always end up very happy once they get it, because now they can build complex UIs and have a solid strategy for compartmentalization, which makes bug whack-a-mole go away. It's not a fault in the framework, it's a fault in their understanding, where they don't know how to implement features in O(N) lines of code instead of O(N^2). The hint is in the name: you're supposed to think in terms of formal functional Effects that mount and unmount independently and compose orthogonally. The result will be a code base that remains maintainable even though you've kept on adding more nuanced features over months and months. Also, your snippet doesn't cause an infinite loop at all because modifying local variables does not trigger a rerender. If you had written setA / setB, sure, it would... but I think this perfectly illustrates the explicit vs implicit distinction. Great frameworks don't trap developers in local maxima.