7 ms·

Hooks have unlocked so much power in React but still deserve critiquing. However I think the author only hinted at the major complaint I have about hooks, which

Hooks have unlocked so much power in React but still deserve critiquing. However I think the author only hinted at the major complaint I have about hooks, which is that it's no longer Javascript. It's not a function, it's sort of like type system magic. Hooks can't be nested, order matters, can't be conditionally called, and you have to understand trickier memoization to avoid bugs. It also isn't portable knowledge to other systems, like vanilla Javascript is. React is great because it's vanilla Javascript, expressions all the way down, and lifecycle methods, which everyone is used to. Hooks are a new non-vanilla-javascript paradigm with special and sometimes tricky rules. Other than, there's no reason to write React unless you're using hooks, and I wonder what the next major paradigm shift will be. I look back on all our HOCs and function as children and shudder compared to how easy it is with hooks.

untog 6y ago
> React is great because it's vanilla Javascript What about JSX? It’s very useful but it’s also an absolutely huge departure from vanilla JavaScript and hides a fair amount of complexity behind what your code is actually doing.
- stevebmark 6y ago
  My mental model of JSX is that it's vanilla Javascript, and it's helped me appreciate trying to write more expressions and less statements. Like JSX isn't getting transformed into some weird different control flow, it's just a nicer way to write the same expression. And DSLs are a good general computer science principle. Hooks don't seem quite as general of a concept to me as a really well thought out DSL that has a minimal surface area but still turns out to be super useful.
  - wwright 6y ago
    Hooks are very similar to applicatives as you’d see them in Haskell, for what it’s worth (it’s where a lot of the rules of hooks come from). They also have some similarity to algebraic effects (as do sagas).
- lucasmullens 6y ago
  > an absolutely huge departure from vanilla JavaScript Doesn't it just convert to React.createElement? I wouldn't call it absolutely huge.
  - frank_nitti 6y ago
    By this logic, what could ever be considered "huge" departure? Any new language construct "converts" to something lower level unless that language is a set of assembly instructions. I mean, Elm converts to vanilla JS but few would say it's a small departure from it.
    - TomMarius 6y ago
      For example Angular templates, stuff like Razor in .NET, etc?
      - frank_nitti 6y ago
        Perhaps I have missed the point, then. I see the same magnitude of departure of Razor from pure C#, QML from pure Qt C++, and JSX from pure DOM JS. All of the above move the developer from procedural native code, to declarative markup. If the assertion is just that `var div = document.createElement('div')` is quite similar to `var div = React.createElement('div');` then of course I agree. In this sense, JSX+React is to DOM what XAML+WinForms is to win32. I had assumed we were discussing conceptual leap between native and framework-based UI implementations. From a UI standpoint, it would be virtually just as hard for a JSX dev to implement a React app with purely `React.createElement()` as it would be to just write a native DOM application.
        TomMarius 6y ago
        The point is that <Component prop={0} /> is equivalent to React.createElement(Component, {prop:0}, []) - it's a static, typed descriptor, and you imported the Component from somewhere because it's just another function/class. There is no such equivalence in magical templates of Angular or Razor - the JSX won't break as long as JavaScript can call functions, and will behave exactly in that way. Yes, it's a move to declarative code from procedural one, that's right; what's important for my distinction is how is the move done. The question we're answering with React (as opposed to Vue, Angular, Razor...) is not declarative/procedural, but magical/not magical. P.S. I heard that templates in Angular are not just templates anymore, they're converting them to function calls - I don't know the specifics, last Angular i saw was version 2.
- TomMarius 6y ago
  The JSX is just a bunch of function calls, all the complexity is in React the library - you can do a very light JSX to DOM library with zero of that complexity.
- sibeliuss 6y ago
  <Foo bar="baz"/> = Foo({ bar: "baz" })
  - kansface 6y ago
    <Foo bar="baz"/> = React.createElement(Foo, { bar: "baz" })
    - lhorie 6y ago
      Technically, it depends on what babel plugin and configuration you use (e.g. it compiles to `h(Foo, {bar: "baz"})` for a preact setup and to completely different code w/ a Solid.js setup)
    - JMTQp8lwXL 6y ago
      I don't understand how people claim this is hiding huge levels of complexity. It's trivial syntactic sugar. If stylistically, you don't like it, oppose it on those grounds. But complexity? It is syntactic sugar for a function call.
      - kansface 6y ago
        I agree with you - so much so that I don’t use source maps to debug stuff. It’s also the same reason I strongly dislike hooks (they aren’t really JS) while at the same time, they solve a problem I very rarely have (shared behavior without shared state).
      - kls 6y ago
        The opposition to it on fundamental grounds is born out of wrongheaded and misapplied best practices and quite frankly it needs to die. Dijkstra is credited with the idea of separations of concerns which is a valid application of code organizational management. The problem is, somewhere along the way (in the dawn of the web) we conflated separation of technology with separations of concerns. Thinking that separating technologies for technologies sake somehow made code more maintainable but the reality is, that it was dogma, if a snippet of JS, a snippet of CSS and a snippet of HTML will only ever be used as a black box component and only ever be reused as that black box component in total, separation of technology only leads to more complexity in interfile dependency and mental compos-ability of the whole solution in ones mind. There is an argument that separation of technology leads to simpler build management, but I personally will take a little more complexity in my build over complexity in the code base as usually a build becomes fairly static as a project matures.
- greatwhitenorth 6y ago
  JSX is 99% map/filter and boolean expressions. It's written between curly braces to be evaluated as a JavaScript expression. I don't understand how it's different from regular JavaScript.
  - untog 6y ago
    It uses tag syntax, which regular JavaScript doesn’t at all. Browsers cannot parse it. These are meaningful differences.
    - greatwhitenorth 6y ago
      None of that matters to a React developer. If you know JavaScript, you know JSX.
      - untog 6y ago
        I don't understand how that is relevant to the quote I was replying to: "React is great because it's vanilla Javascript". Vanilla Javascript works in a browser with zero transpiling. That's important. (also, "if you know JavaScript you know JSX" is objectively untrue! There are plenty of JS developers that don't work with JSX)
        greatwhitenorth 6y ago
        We're talking two different things. I'm talking about the developer perspective. You're talking about browser. If a JS developer doesn't work or understand JSX, they don't understand the fundamental concept of JavaScript which is what an expression is. "if you know JavaScript you know JSX" - JSX is just a JavaScript expression. There is nothing more to it.
        untog 6y ago
        > We're talking two different things. I'm talking about the developer perspective. You're talking about browser. I'm not. I'm talking about a programming language. It has a spec. "if you know JavaScript you know JSX" - JSX is just a JavaScript expression. This is nonsense. Where is JSX in the JavaScript spec?
vosper 6y ago
> I look back on all our HOCs and function as children and shudder compared to how easy it is with hooks. If by "function as children" you're referring to render props, personally I was really happy to see that short-lived fad die out. I don't think render props made things simpler. Now if we can admit we never needed Sagas just to do some data fetching maybe we can burn that stalled-out old bandwagon, too :D (Sagas are a powerful pattern, I'm sure someone here is about to reply about how they're making good use of them. But I'd bet 99% of people using the redux-sagas library could be doing something simpler).
- stevebmark 6y ago
  I have never fundamentally understood sagas and I've tried a few times. I'm able to wrap my head around redux-loop though https://github.com/redux-loop/redux-loop https://github.com/redux-loop/redux-loop
  - shoulderfake 6y ago
    They're just redux middleware implemented with generators, so you can do some nifty things with it if your use case requires. I've used sagas on a several projects and they all actually did need that type of tool but I've chosen thunks on other projects when fetching logic was simple.
    - kls 6y ago
      I tend to use Sagas now as my go to but I am comfortable with them. I would agree with most of the sentiment on here that they are more complex, though not because of Saga's API but because one really has to understand the core workings of the framework to not screw the pooch. For many their first exposure to generators is via Saga and that is just the tip of the iceberg. One really needs to understand what all the takes are doing as well as how Saga utilizes async and await style logic. To me, Saga's a very readable and very easy to debug but some dragons lie below the API and one has to understand that those dragons are doing magic a lot differently that other frameworks do magic. It's just not a framework where you get to ignore what the magic is doing for you as you will create nasty bugs due to lack of understanding about what the framework is trying to do and it becomes easy to fight against it out of ignorance. That being said, my general opinion is that I like Saga and we generally choose to use it as a team.
orange8 6y ago
> the major complaint I have about hooks, which is that it's no longer Javascript Are you saying that hooks are implemented in a way that needs a compiler (e.g. like CoffeeScript or TypeScript) for them to work? I've always assumed they were implemented using closures or a similar pattern.
- lucasmullens 6y ago
  It is JavaScript, but it doesn't feel like JavaScript. What looks like a pure function isn't actually, and can do a different thing depending on where and when you run it, all hidden in some magic within the React library.
  - orange8 6y ago
    JS is one of the most un-opinionated, flexible language around, I do not believe there is a one true way™ of doing JS. For example, React and Angular have very different approaches (functional vs OPP) on how to JS. I do agree that having something do a different thing depending on where and when can be counter-intuitive.
- Sophistifunk 6y ago
  Meaning that instead of using existing JavaScript structures to provide instance state, it's re-implemented in an abstruse way that creates a whole bunch of constraints on your code and new rules to keep in your head at at all times that are react-with-hooks-specific.
JMTQp8lwXL 6y ago
If you oppose JSX, then you should doubly oppose Angular Templating language, since that's an entire language construct that gets compiled to JS function calls. Broader point: We need some syntactic sugar on top of JavaScript for writing UIs. JSX is about as simplistic of an abstraction you can get it. It's incredibly easy to reason about its pre and post-compiled syntax. Not the case with other paradigms.
coffeefirst 6y ago
Yes, I honestly wonder if, with a few minor changes to make it more conventional js, you could address a lot of the criticism. Suppose you replace: const [count, setCount] = useState(0); with const [count, setCount] = this.useState("count", 0); I'm just speculating idly, but if you use `this`, it's clear how the function knows it's component. If you pass an explicit key, I don't think you need the order to matter. And if the order doesn't matter, well, conditional logic ought to work normally, even if it's a bad idea? I have no idea if there's a compelling reason this wouldn't work, but if it would, it seems like it could take a lot of the magic and nonstandard behavior out of the API.
deleted 6y ago
[deleted]

untog 6y ago

> React is great because it's vanilla Javascript What about JSX? It’s very useful but it’s also an absolutely huge departure from vanilla JavaScript and hides a fair amount of complexity behind what your code is actually doing.

stevebmark 6y ago
My mental model of JSX is that it's vanilla Javascript, and it's helped me appreciate trying to write more expressions and less statements. Like JSX isn't getting transformed into some weird different control flow, it's just a nicer way to write the same expression. And DSLs are a good general computer science principle. Hooks don't seem quite as general of a concept to me as a really well thought out DSL that has a minimal surface area but still turns out to be super useful.
- wwright 6y ago
  Hooks are very similar to applicatives as you’d see them in Haskell, for what it’s worth (it’s where a lot of the rules of hooks come from). They also have some similarity to algebraic effects (as do sagas).
lucasmullens 6y ago
> an absolutely huge departure from vanilla JavaScript Doesn't it just convert to React.createElement? I wouldn't call it absolutely huge.
- frank_nitti 6y ago
  By this logic, what could ever be considered "huge" departure? Any new language construct "converts" to something lower level unless that language is a set of assembly instructions. I mean, Elm converts to vanilla JS but few would say it's a small departure from it.
  - TomMarius 6y ago
    For example Angular templates, stuff like Razor in .NET, etc?
    - frank_nitti 6y ago
      Perhaps I have missed the point, then. I see the same magnitude of departure of Razor from pure C#, QML from pure Qt C++, and JSX from pure DOM JS. All of the above move the developer from procedural native code, to declarative markup. If the assertion is just that `var div = document.createElement('div')` is quite similar to `var div = React.createElement('div');` then of course I agree. In this sense, JSX+React is to DOM what XAML+WinForms is to win32. I had assumed we were discussing conceptual leap between native and framework-based UI implementations. From a UI standpoint, it would be virtually just as hard for a JSX dev to implement a React app with purely `React.createElement()` as it would be to just write a native DOM application.
      - TomMarius 6y ago
        The point is that <Component prop={0} /> is equivalent to React.createElement(Component, {prop:0}, []) - it's a static, typed descriptor, and you imported the Component from somewhere because it's just another function/class. There is no such equivalence in magical templates of Angular or Razor - the JSX won't break as long as JavaScript can call functions, and will behave exactly in that way. Yes, it's a move to declarative code from procedural one, that's right; what's important for my distinction is how is the move done. The question we're answering with React (as opposed to Vue, Angular, Razor...) is not declarative/procedural, but magical/not magical. P.S. I heard that templates in Angular are not just templates anymore, they're converting them to function calls - I don't know the specifics, last Angular i saw was version 2.
TomMarius 6y ago
The JSX is just a bunch of function calls, all the complexity is in React the library - you can do a very light JSX to DOM library with zero of that complexity.
sibeliuss 6y ago
<Foo bar="baz"/> = Foo({ bar: "baz" })
- kansface 6y ago
  <Foo bar="baz"/> = React.createElement(Foo, { bar: "baz" })
  - lhorie 6y ago
    Technically, it depends on what babel plugin and configuration you use (e.g. it compiles to `h(Foo, {bar: "baz"})` for a preact setup and to completely different code w/ a Solid.js setup)
  - JMTQp8lwXL 6y ago
    I don't understand how people claim this is hiding huge levels of complexity. It's trivial syntactic sugar. If stylistically, you don't like it, oppose it on those grounds. But complexity? It is syntactic sugar for a function call.
    - kansface 6y ago
      I agree with you - so much so that I don’t use source maps to debug stuff. It’s also the same reason I strongly dislike hooks (they aren’t really JS) while at the same time, they solve a problem I very rarely have (shared behavior without shared state).
    - kls 6y ago
      The opposition to it on fundamental grounds is born out of wrongheaded and misapplied best practices and quite frankly it needs to die. Dijkstra is credited with the idea of separations of concerns which is a valid application of code organizational management. The problem is, somewhere along the way (in the dawn of the web) we conflated separation of technology with separations of concerns. Thinking that separating technologies for technologies sake somehow made code more maintainable but the reality is, that it was dogma, if a snippet of JS, a snippet of CSS and a snippet of HTML will only ever be used as a black box component and only ever be reused as that black box component in total, separation of technology only leads to more complexity in interfile dependency and mental compos-ability of the whole solution in ones mind. There is an argument that separation of technology leads to simpler build management, but I personally will take a little more complexity in my build over complexity in the code base as usually a build becomes fairly static as a project matures.
greatwhitenorth 6y ago
JSX is 99% map/filter and boolean expressions. It's written between curly braces to be evaluated as a JavaScript expression. I don't understand how it's different from regular JavaScript.
- untog 6y ago
  It uses tag syntax, which regular JavaScript doesn’t at all. Browsers cannot parse it. These are meaningful differences.
  - greatwhitenorth 6y ago
    None of that matters to a React developer. If you know JavaScript, you know JSX.
    - untog 6y ago
      I don't understand how that is relevant to the quote I was replying to: "React is great because it's vanilla Javascript". Vanilla Javascript works in a browser with zero transpiling. That's important. (also, "if you know JavaScript you know JSX" is objectively untrue! There are plenty of JS developers that don't work with JSX)
      - greatwhitenorth 6y ago
        We're talking two different things. I'm talking about the developer perspective. You're talking about browser. If a JS developer doesn't work or understand JSX, they don't understand the fundamental concept of JavaScript which is what an expression is. "if you know JavaScript you know JSX" - JSX is just a JavaScript expression. There is nothing more to it.
        untog 6y ago
        > We're talking two different things. I'm talking about the developer perspective. You're talking about browser. I'm not. I'm talking about a programming language. It has a spec. "if you know JavaScript you know JSX" - JSX is just a JavaScript expression. This is nonsense. Where is JSX in the JavaScript spec?

vosper 6y ago

> I look back on all our HOCs and function as children and shudder compared to how easy it is with hooks. If by "function as children" you're referring to render props, personally I was really happy to see that short-lived fad die out. I don't think render props made things simpler. Now if we can admit we never needed Sagas just to do some data fetching maybe we can burn that stalled-out old bandwagon, too :D (Sagas are a powerful pattern, I'm sure someone here is about to reply about how they're making good use of them. But I'd bet 99% of people using the redux-sagas library could be doing something simpler).

stevebmark 6y ago
I have never fundamentally understood sagas and I've tried a few times. I'm able to wrap my head around redux-loop though https://github.com/redux-loop/redux-loop https://github.com/redux-loop/redux-loop
- shoulderfake 6y ago
  They're just redux middleware implemented with generators, so you can do some nifty things with it if your use case requires. I've used sagas on a several projects and they all actually did need that type of tool but I've chosen thunks on other projects when fetching logic was simple.
  - kls 6y ago
    I tend to use Sagas now as my go to but I am comfortable with them. I would agree with most of the sentiment on here that they are more complex, though not because of Saga's API but because one really has to understand the core workings of the framework to not screw the pooch. For many their first exposure to generators is via Saga and that is just the tip of the iceberg. One really needs to understand what all the takes are doing as well as how Saga utilizes async and await style logic. To me, Saga's a very readable and very easy to debug but some dragons lie below the API and one has to understand that those dragons are doing magic a lot differently that other frameworks do magic. It's just not a framework where you get to ignore what the magic is doing for you as you will create nasty bugs due to lack of understanding about what the framework is trying to do and it becomes easy to fight against it out of ignorance. That being said, my general opinion is that I like Saga and we generally choose to use it as a team.

orange8 6y ago

> the major complaint I have about hooks, which is that it's no longer Javascript Are you saying that hooks are implemented in a way that needs a compiler (e.g. like CoffeeScript or TypeScript) for them to work? I've always assumed they were implemented using closures or a similar pattern.

lucasmullens 6y ago
It is JavaScript, but it doesn't feel like JavaScript. What looks like a pure function isn't actually, and can do a different thing depending on where and when you run it, all hidden in some magic within the React library.
- orange8 6y ago
  JS is one of the most un-opinionated, flexible language around, I do not believe there is a one true way™ of doing JS. For example, React and Angular have very different approaches (functional vs OPP) on how to JS. I do agree that having something do a different thing depending on where and when can be counter-intuitive.
Sophistifunk 6y ago
Meaning that instead of using existing JavaScript structures to provide instance state, it's re-implemented in an abstruse way that creates a whole bunch of constraints on your code and new rules to keep in your head at at all times that are react-with-hooks-specific.

JMTQp8lwXL 6y ago

If you oppose JSX, then you should doubly oppose Angular Templating language, since that's an entire language construct that gets compiled to JS function calls. Broader point: We need some syntactic sugar on top of JavaScript for writing UIs. JSX is about as simplistic of an abstraction you can get it. It's incredibly easy to reason about its pre and post-compiled syntax. Not the case with other paradigms.

coffeefirst 6y ago

Yes, I honestly wonder if, with a few minor changes to make it more conventional js, you could address a lot of the criticism. Suppose you replace: const [count, setCount] = useState(0); with const [count, setCount] = this.useState("count", 0); I'm just speculating idly, but if you use `this`, it's clear how the function knows it's component. If you pass an explicit key, I don't think you need the order to matter. And if the order doesn't matter, well, conditional logic ought to work normally, even if it's a bad idea? I have no idea if there's a compelling reason this wouldn't work, but if it would, it seems like it could take a lot of the magic and nonstandard behavior out of the API.

deleted 6y ago

[deleted]