4 ms·

If you think Svelte is magic, wait until you see how hooks work.

by dham 5y ago

nightski 5y ago
Svelte changes the semantics of your code. It's great to show off to-do apps and simple examples. But I'd be very wary of buying into a framework that relied on compiler modifications to the semantics of code to make it work. I'm also not a fan of pub-sub style change notifications. It's hard to reason about what a change in state is going to cause since you don't know what's subscribed. With hooks at least I am able to have a mental model around what happens when I call a change function since it flows top down (instead of bottom up).
- dmitriid 5y ago
  > Svelte changes the semantics of your code. So do hooks. Suddenly regular function calls can't be put in if statements or require "dependency lists" to make them work properly.
  - Spivak 5y ago
    Ehh it really doesn't change the semantics of your code, hooks are just iterables and you access them by calling next(). In an alternative world they would be a mapping that you give unique names like useState("mystate", ...) and then order and if statements would be irrelevant. Also you're just just passing a callback function to React and then giving it some pointers to data used as part of the conditional on when it should run. Like it's janky and reaches through layers but it's not up and rewriting your code.
    - dmitriid 5y ago
      > hooks are just iterables and you access them by calling next() In Javascript, "just iterables" can be put in conditional statements, and they don't cause the outer function to be called again. > Also you're just just Ah yes. That "just" again Edit: > just passing a callback function to React and then giving it some pointers to data Thing is, in plain JavaScript if it was a callback function, it could be called anything and live anywhere. However, these functions have to be named with a `use` prefix and have limitations on how they can be called.
      - charcircuit 5y ago
        Nothing is stopping you from putting useState in an if statement. You just have to be careful since it's an "iterator." For example if you put it in an if branch you will want to also use it in the else branch so "next" is called the same number of times.
        Osiris 5y ago
        In my experience I get a React error if the number of hooks changes between renders, meaning you can't have hooks in a conditional.
        dmitriid 5y ago
        So, let me get this straight. - These are "just function calls" - Except they are "iterators" - Except if you have them in a conditional, you must provide an `else` branch so that `next` is called the same number of times None of this is in the semantics of the language where I don't have to provide an else branch to an iterator, and function calls are not iterators ;)
        Spivak 5y ago
        Like I really don’t know how to explain this any clearer. * React stores the state for your hooks in a list which is iterable. * useBlah is just a normal function that internally calls next() on that list to get the next hook state which is why order matters. * React checks that the iteratior on the list is at the end to see if you’ve consumed all the hooks and throws an error if not because it’s indicative of a bug in your code. Like at this point the only thing I can recommend is try writing a toy implementation of hooks and see that they’re not magic, they’re just normal JS, and that the restrictions flow naturally from the implementation. Like why do you want so bad for hooks to be weird?
        dmitriid 5y ago
        > is just a normal function that you keep showing isn't a normal function :) > Like why do you want so bad for hooks to be weird? I don't want them to be weird. They are weird already. https://news.ycombinator.com/item?id=30801466 https://news.ycombinator.com/item?id=30801466
  - deleted 5y ago
    [deleted]
jitl 5y ago
You can implement a hooks like interface in an afternoon. I don’t think I could do the same for Svelte’s compiler-oriented approach. Using a compiler means that Svelte is essentially a dialect of EcmaScript, which appears to be mutually intelligible but isn’t always. React used a compiler for JSX which also introduced a dialect, but JSX is optional and very straightforward sugar for a simple function call. The Svelte dialect is not so simple.
- dmitriid 5y ago
  > Using a compiler means that Svelte is essentially a dialect of EcmaScript So are hooks. The fact that you can't put regular function calls (which hooks look like) in an if statement, or have to provide custom "dependency lists" to some of them, or that data returned from them suddenly re-renders (aka calls again) the function they are in tells you that this is no longer regular Javascript.
  - deleted 5y ago
    [deleted]
  - dham 5y ago
    Exactly, I don't get the React is just Javascript. It's not. You're tied to React just as much as Svelte or anything else. The Facebook propaganda machine is clever I will say.
    - jitl 5y ago
      There’s a wide difference between learning the semantics of an API and learning the semantics of a custom language with a compiler. There are alternate implementations of the React API, like Preact. The semantics of the React API might be complex, but you could implement them in essentially any programming language with function pointers and variable length arrays. You can’t say the same thing for Svelte; which we know is impossible to implement in pure JavaScript, which is why it needs a compiler. This is all anyone in this thread is arguing - it’s an argument about semantics but for some kinds of environments semantics are very important. I’ve helped teams pilot out of own-the-world frameworks like Backbone and Rails before (both of which substantially distort the runtime they’re embedded in); but it was much harder to deal with Backbone + Coffeescript together. For Backbone w/ vanilla JS or Rails, we could use standard static analysis tools, Coffeescript added a big extra wrinkle to our migration.
tehbeard 5y ago
A fair point, and I haven't dove into react's inner workings to see how the sausage (I was more discussing the compiled code of the app), but one can reason "how" hooks work after observing them. - They're tied to the lifecycle of the component, so they must reach "up" into whatever just called our component function. - They do not like being moved about/conditionally executed, so hook's likely use an array for metadata storage and position rather than needing explicit "hook keys". Honestly they are weird, but I can reason about them with a "good enough" mental model to get paid. I've no clue what svelte does behind the scenes, much the same way as I can't reckon what WASM or assembly do. So I guess I just have to blindly trust the compiler?
- thatswrong0 5y ago
  Agree with you completely - hooks really aren't magical at all. The only thing that's "magical" is that React takes hook data and embeds it somewhere in the component instance behind the scene.. something that also necessarily must happen with class components. The state has to live somewhere.
thatswrong0 5y ago
I'm always confused by this comment about hooks. You can sus out the basics of how hooks work under the hood by just looking at their relatively simple rules that govern their usage. More from Dan Abramov: https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889#44b2 https://medium.com/@dan_abramov/making-sense-of-react-hooks-... I think they are actually _more_ explicit than classes about how the state is stored. IMO `this` in class based components isn't as straightforward (e.g. https://overreacted.io/why-do-we-write-super-props/ https://overreacted.io/why-do-we-write-super-props/)

If you think Svelte is magic, wait until you see how hooks work.

by dham 5y ago

If you think Svelte is magic, wait until you see how hooks work.

Svelte changes the semantics of your code. It's great to show off to-do apps and simple examples. But I'd be very wary of buying into a framework that relied on compiler modifications to the semantics of code to make it work. I'm also not a fan of pub-sub style change notifications. It's hard to reason about what a change in state is going to cause since you don't know what's subscribed. With hooks at least I am able to have a mental model around what happens when I call a change function since it flows top down (instead of bottom up).

dmitriid 5y ago
> Svelte changes the semantics of your code. So do hooks. Suddenly regular function calls can't be put in if statements or require "dependency lists" to make them work properly.
- Spivak 5y ago
  Ehh it really doesn't change the semantics of your code, hooks are just iterables and you access them by calling next(). In an alternative world they would be a mapping that you give unique names like useState("mystate", ...) and then order and if statements would be irrelevant. Also you're just just passing a callback function to React and then giving it some pointers to data used as part of the conditional on when it should run. Like it's janky and reaches through layers but it's not up and rewriting your code.
  - dmitriid 5y ago
    > hooks are just iterables and you access them by calling next() In Javascript, "just iterables" can be put in conditional statements, and they don't cause the outer function to be called again. > Also you're just just Ah yes. That "just" again Edit: > just passing a callback function to React and then giving it some pointers to data Thing is, in plain JavaScript if it was a callback function, it could be called anything and live anywhere. However, these functions have to be named with a `use` prefix and have limitations on how they can be called.
    - charcircuit 5y ago
      Nothing is stopping you from putting useState in an if statement. You just have to be careful since it's an "iterator." For example if you put it in an if branch you will want to also use it in the else branch so "next" is called the same number of times.
      - Osiris 5y ago
        In my experience I get a React error if the number of hooks changes between renders, meaning you can't have hooks in a conditional.
      - dmitriid 5y ago
        So, let me get this straight. - These are "just function calls" - Except they are "iterators" - Except if you have them in a conditional, you must provide an `else` branch so that `next` is called the same number of times None of this is in the semantics of the language where I don't have to provide an else branch to an iterator, and function calls are not iterators ;)
        Spivak 5y ago
        Like I really don’t know how to explain this any clearer. * React stores the state for your hooks in a list which is iterable. * useBlah is just a normal function that internally calls next() on that list to get the next hook state which is why order matters. * React checks that the iteratior on the list is at the end to see if you’ve consumed all the hooks and throws an error if not because it’s indicative of a bug in your code. Like at this point the only thing I can recommend is try writing a toy implementation of hooks and see that they’re not magic, they’re just normal JS, and that the restrictions flow naturally from the implementation. Like why do you want so bad for hooks to be weird?
        dmitriid 5y ago
        > is just a normal function that you keep showing isn't a normal function :) > Like why do you want so bad for hooks to be weird? I don't want them to be weird. They are weird already. https://news.ycombinator.com/item?id=30801466 https://news.ycombinator.com/item?id=30801466
- deleted 5y ago
  [deleted]

jitl 5y ago

You can implement a hooks like interface in an afternoon. I don’t think I could do the same for Svelte’s compiler-oriented approach. Using a compiler means that Svelte is essentially a dialect of EcmaScript, which appears to be mutually intelligible but isn’t always. React used a compiler for JSX which also introduced a dialect, but JSX is optional and very straightforward sugar for a simple function call. The Svelte dialect is not so simple.

dmitriid 5y ago
> Using a compiler means that Svelte is essentially a dialect of EcmaScript So are hooks. The fact that you can't put regular function calls (which hooks look like) in an if statement, or have to provide custom "dependency lists" to some of them, or that data returned from them suddenly re-renders (aka calls again) the function they are in tells you that this is no longer regular Javascript.
- deleted 5y ago
  [deleted]
- dham 5y ago
  Exactly, I don't get the React is just Javascript. It's not. You're tied to React just as much as Svelte or anything else. The Facebook propaganda machine is clever I will say.
  - jitl 5y ago
    There’s a wide difference between learning the semantics of an API and learning the semantics of a custom language with a compiler. There are alternate implementations of the React API, like Preact. The semantics of the React API might be complex, but you could implement them in essentially any programming language with function pointers and variable length arrays. You can’t say the same thing for Svelte; which we know is impossible to implement in pure JavaScript, which is why it needs a compiler. This is all anyone in this thread is arguing - it’s an argument about semantics but for some kinds of environments semantics are very important. I’ve helped teams pilot out of own-the-world frameworks like Backbone and Rails before (both of which substantially distort the runtime they’re embedded in); but it was much harder to deal with Backbone + Coffeescript together. For Backbone w/ vanilla JS or Rails, we could use standard static analysis tools, Coffeescript added a big extra wrinkle to our migration.

tehbeard 5y ago

A fair point, and I haven't dove into react's inner workings to see how the sausage (I was more discussing the compiled code of the app), but one can reason "how" hooks work after observing them. - They're tied to the lifecycle of the component, so they must reach "up" into whatever just called our component function. - They do not like being moved about/conditionally executed, so hook's likely use an array for metadata storage and position rather than needing explicit "hook keys". Honestly they are weird, but I can reason about them with a "good enough" mental model to get paid. I've no clue what svelte does behind the scenes, much the same way as I can't reckon what WASM or assembly do. So I guess I just have to blindly trust the compiler?

thatswrong0 5y ago
Agree with you completely - hooks really aren't magical at all. The only thing that's "magical" is that React takes hook data and embeds it somewhere in the component instance behind the scene.. something that also necessarily must happen with class components. The state has to live somewhere.

thatswrong0 5y ago

I'm always confused by this comment about hooks. You can sus out the basics of how hooks work under the hood by just looking at their relatively simple rules that govern their usage. More from Dan Abramov: https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889#44b2 https://medium.com/@dan_abramov/making-sense-of-react-hooks-... I think they are actually _more_ explicit than classes about how the state is stored. IMO `this` in class based components isn't as straightforward (e.g. https://overreacted.io/why-do-we-write-super-props/ https://overreacted.io/why-do-we-write-super-props/)