9 ms·

React started as a nice rendering library. Then it was infected with all sorts of Functional Programming paradigms grafted on top of Javascript. At the same tim

by dexwiz 5y ago

React started as a nice rendering library. Then it was infected with all sorts of Functional Programming paradigms grafted on top of Javascript. At the same time people wanted React to be a framework for client side rendering, not the thin layer it was. Stateless components are a good idea, but their implementation as functions and hooks leaves any JS programmer not familiar with React scratching their head. Throwing Promises for Suspense is basically Algebraic Effects. Redux and a million other libraries tried to solve data management, none of them doing it in a classical K/V store. Now every app I touch I have to find its special version of reducers and selectors. I like front end programming and Javascript overall. Components are a nice abstraction, and life cycle hooks make sense in real life contexts. But React reeks of developers who think they are too smart for their day job and want to redefine UI programming just to render a button with an event handler.

handrous 5y ago
Yeah, I started going "well, time to look at the rest of the ecosystem for the Next Thing" with Hooks. Given requirements that meant, to progress, they were going to need to either: 1) Tell devs that sometimes they would simply have to use classes/objects for some components, because certain performance enhancements or state-management would only be available there, or; 2) Partially re-implement objects with really bizarre declaration syntax, in a language that already has objects—shit, its functions are objects, and maybe it's changed but I read the hooks code when it was added and it was just some FIFO property/method queues, rather than tables, tied to a damn object representing your component in React's core state-machine; They chose #2. [EDIT] yes I'm aware that one reason they prominently gave for hooks was that inheritance hierarchies could cause problems in React codebases, but that seems woefully insufficient as a motivation for writing a crippled version of objects/classes that lack the features they had problems with, rather than just telling people "maybe stop hitting yourself?" and continuing to use what the language already provided, which everyone already understood.
- dexwiz 5y ago
  The thing that blew my mind was React gave a decent abstraction for externally set values vs internally managed values in props/state. And then the community immediately declared State as evil, and boiled the ocean to replace it. All UIs need state. Yes state is bad in most cases and makes programming harder. No abstracting it into 4 different files doesn't make it any clearer. There was an issue with composition in React. HOC didn't scale very well, and Inheritance is almost always Bad (TM). That said, I do think hooks were an esoteric choice versus a more explicit service registration/DI pattern.
flowerlad 5y ago
> Then it was infected with all sorts of Functional Programming paradigms grafted on top of Javascript. Except it is not really functional. See: https://mckoder.medium.com/why-react-is-not-functional-b1ed12a41323 https://mckoder.medium.com/why-react-is-not-functional-b1ed1...
mixedCase 5y ago
> Then it was infected with all sorts of Functional Programming paradigms grafted on top of Javascript The whole thing has been functional programming from the start, if you know what algebraic effects are then the functional underpinning should be obvious to you as well as anyone with the slightest brush with FP. Hell, the original React prototype was in Standard ML, later ported to OCaml and then JavaScript. > Throwing Promises for Suspense is basically Algebraic Effects The fact that you disregard Suspense as a head-scratching algebraic effect, instead of using simple "Promises" goes to show how much the JavaScript ecosystem seems to be about fooling people into doing functional programming without triggering their gut reaction of "FP is spooky unproven thing, but Node enterprise ready!". Imagine for a second that a Promise's .then is called .bind, put it in a thunk if you want to be extra precise and tell me what it is. Hint: It starts with "M" and it's just a monoid in the category of endofunctors.
- flowerlad 5y ago
  > The whole thing has been functional programming from the start, if you know what algebraic effects are then the functional underpinning should be obvious to you as well as anyone with the slightest brush with FP. That's a lot of hot air. There is nothing functional about React. Algebraic effects represent impure behavior in a functional programming language, such as input and output, exceptions, nondeterminism etc. all treated in a generic way. Impure behavior, including algebraic effects, is best avoided in functional programming. Sorry to post the link again, but please read this: https://mckoder.medium.com/why-react-is-not-functional-b1ed12a41323 https://mckoder.medium.com/why-react-is-not-functional-b1ed1...
  - Grimm1 5y ago
    So what would you call this style of programming? Saying there is nothing functional about it seems like hyperbole. It's just not as pure as you'd like. I say as someone in the world of people who need to get things done, why do we/I care? I read the article FWIW, it didn't particularly convince me. I think even writing things in the style of functional programming, if that's what we want to call it, still makes it easier to reason about the code. Confining side effects to hooks also means there's only one place we have to reason about having non pure consequences.
lhorie 5y ago
> Throwing Promises for Suspense is basically Algebraic Effects I wish Dan Abramov hadn't made this analogy[0], they're nothing like algebraic effects. The core idea behind algebraic effects is more similar to something like dependency injection if it was generally possible to "deasync"[1] things in JS, except it leverages dynamic scoping instead of lexical scoping. The Suspense thing is closer to those jokes where the punchline is something along the lines of the programmer saying "have you tried to restart it?" [0] https://overreacted.io/algebraic-effects-for-the-rest-of-us/ https://overreacted.io/algebraic-effects-for-the-rest-of-us/ [1] https://www.npmjs.com/package/deasync https://www.npmjs.com/package/deasync
- azangru 5y ago
  > I wish Dan Abramov hadn't made this analogy[0], I bet it wasn't Dan who came up with this analogy. My bet is on Sebastian: https://twitter.com/sebmarkbage/status/941214259505119232 https://twitter.com/sebmarkbage/status/941214259505119232
  - Zababa 5y ago
    Further evidence of this in this blog post by Dan Abramov https://overreacted.io/algebraic-effects-for-the-rest-of-us/ https://overreacted.io/algebraic-effects-for-the-rest-of-us/
oaxacaoaxaca 5y ago
Very well said. I've been using React since it came out, and have been pushing back on Hooks since they came out. Class components are dead simple. A class, a setState method, this.props, this.state, and some lifecycle methods. SO easy for anyone to understand. Function components with hooks are not. A whole new (and unnecessary) paradigm; some mysterious hooks engine that needed new ESLint rules to be created just so people can keep the weird, delicate balance in place; hooks having their own timing problems, requiring usage of useRef which the React team tries to get people to avoid; etc. Frontend codebases used to have several layers, with React just being one of the thin ones. Now, nearly the entire frontend codebase is inside React world. I'm not a fan of this direction.
snuser 5y ago
I think it's alright, the real problem that I've noticed is that a lot of developers tend to misconstrue what they need and bloat their projects in amazingly unmanageable way because it 'the way to do things according to random source x' which could be some weird abuse of state management systems like or redux or general application design FWIW I've seen it in many projects outside of the react/js world as well IMO there's been a general drought in books/material on reasoning/thinking about software in general in-favor of the framework/library centric mania we have now which focus on the least interesting aspects of the field -- the cynic in me thinks this is due to how we hire people but there's likely more to it than that
phendrenad2 5y ago
1) New fast, easy framework bursts into the scene. 2) "Hey it doesn't work with edge case X, let's graft on more features to cover it" 3) Repeat step #2 a few dozen times 4) The framework is now neither fast nor easy, invent a new one and go to step #1
nsonha 5y ago
There is nothing wrong with functional programming. It's a bit sad that redux and hooks give it a bad rap. Those things are NOT functional programming.
dcgudeman 5y ago
I have found that Redux Toolkit solved most of the pain with vanilla redux.

by dexwiz 5y ago

handrous 5y ago

Yeah, I started going "well, time to look at the rest of the ecosystem for the Next Thing" with Hooks. Given requirements that meant, to progress, they were going to need to either: 1) Tell devs that sometimes they would simply have to use classes/objects for some components, because certain performance enhancements or state-management would only be available there, or; 2) Partially re-implement objects with really bizarre declaration syntax, in a language that already has objects—shit, its functions are objects, and maybe it's changed but I read the hooks code when it was added and it was just some FIFO property/method queues, rather than tables, tied to a damn object representing your component in React's core state-machine; They chose #2. [EDIT] yes I'm aware that one reason they prominently gave for hooks was that inheritance hierarchies could cause problems in React codebases, but that seems woefully insufficient as a motivation for writing a crippled version of objects/classes that lack the features they had problems with, rather than just telling people "maybe stop hitting yourself?" and continuing to use what the language already provided, which everyone already understood.

dexwiz 5y ago
The thing that blew my mind was React gave a decent abstraction for externally set values vs internally managed values in props/state. And then the community immediately declared State as evil, and boiled the ocean to replace it. All UIs need state. Yes state is bad in most cases and makes programming harder. No abstracting it into 4 different files doesn't make it any clearer. There was an issue with composition in React. HOC didn't scale very well, and Inheritance is almost always Bad (TM). That said, I do think hooks were an esoteric choice versus a more explicit service registration/DI pattern.

flowerlad 5y ago

> Then it was infected with all sorts of Functional Programming paradigms grafted on top of Javascript. Except it is not really functional. See: https://mckoder.medium.com/why-react-is-not-functional-b1ed12a41323 https://mckoder.medium.com/why-react-is-not-functional-b1ed1...

mixedCase 5y ago

> Then it was infected with all sorts of Functional Programming paradigms grafted on top of Javascript The whole thing has been functional programming from the start, if you know what algebraic effects are then the functional underpinning should be obvious to you as well as anyone with the slightest brush with FP. Hell, the original React prototype was in Standard ML, later ported to OCaml and then JavaScript. > Throwing Promises for Suspense is basically Algebraic Effects The fact that you disregard Suspense as a head-scratching algebraic effect, instead of using simple "Promises" goes to show how much the JavaScript ecosystem seems to be about fooling people into doing functional programming without triggering their gut reaction of "FP is spooky unproven thing, but Node enterprise ready!". Imagine for a second that a Promise's .then is called .bind, put it in a thunk if you want to be extra precise and tell me what it is. Hint: It starts with "M" and it's just a monoid in the category of endofunctors.

flowerlad 5y ago
> The whole thing has been functional programming from the start, if you know what algebraic effects are then the functional underpinning should be obvious to you as well as anyone with the slightest brush with FP. That's a lot of hot air. There is nothing functional about React. Algebraic effects represent impure behavior in a functional programming language, such as input and output, exceptions, nondeterminism etc. all treated in a generic way. Impure behavior, including algebraic effects, is best avoided in functional programming. Sorry to post the link again, but please read this: https://mckoder.medium.com/why-react-is-not-functional-b1ed12a41323 https://mckoder.medium.com/why-react-is-not-functional-b1ed1...
- Grimm1 5y ago
  So what would you call this style of programming? Saying there is nothing functional about it seems like hyperbole. It's just not as pure as you'd like. I say as someone in the world of people who need to get things done, why do we/I care? I read the article FWIW, it didn't particularly convince me. I think even writing things in the style of functional programming, if that's what we want to call it, still makes it easier to reason about the code. Confining side effects to hooks also means there's only one place we have to reason about having non pure consequences.

lhorie 5y ago

> Throwing Promises for Suspense is basically Algebraic Effects I wish Dan Abramov hadn't made this analogy[0], they're nothing like algebraic effects. The core idea behind algebraic effects is more similar to something like dependency injection if it was generally possible to "deasync"[1] things in JS, except it leverages dynamic scoping instead of lexical scoping. The Suspense thing is closer to those jokes where the punchline is something along the lines of the programmer saying "have you tried to restart it?" [0] https://overreacted.io/algebraic-effects-for-the-rest-of-us/ https://overreacted.io/algebraic-effects-for-the-rest-of-us/ [1] https://www.npmjs.com/package/deasync https://www.npmjs.com/package/deasync

azangru 5y ago
> I wish Dan Abramov hadn't made this analogy[0], I bet it wasn't Dan who came up with this analogy. My bet is on Sebastian: https://twitter.com/sebmarkbage/status/941214259505119232 https://twitter.com/sebmarkbage/status/941214259505119232
- Zababa 5y ago
  Further evidence of this in this blog post by Dan Abramov https://overreacted.io/algebraic-effects-for-the-rest-of-us/ https://overreacted.io/algebraic-effects-for-the-rest-of-us/

oaxacaoaxaca 5y ago

Very well said. I've been using React since it came out, and have been pushing back on Hooks since they came out. Class components are dead simple. A class, a setState method, this.props, this.state, and some lifecycle methods. SO easy for anyone to understand. Function components with hooks are not. A whole new (and unnecessary) paradigm; some mysterious hooks engine that needed new ESLint rules to be created just so people can keep the weird, delicate balance in place; hooks having their own timing problems, requiring usage of useRef which the React team tries to get people to avoid; etc. Frontend codebases used to have several layers, with React just being one of the thin ones. Now, nearly the entire frontend codebase is inside React world. I'm not a fan of this direction.

snuser 5y ago

I think it's alright, the real problem that I've noticed is that a lot of developers tend to misconstrue what they need and bloat their projects in amazingly unmanageable way because it 'the way to do things according to random source x' which could be some weird abuse of state management systems like or redux or general application design FWIW I've seen it in many projects outside of the react/js world as well IMO there's been a general drought in books/material on reasoning/thinking about software in general in-favor of the framework/library centric mania we have now which focus on the least interesting aspects of the field -- the cynic in me thinks this is due to how we hire people but there's likely more to it than that

phendrenad2 5y ago

1) New fast, easy framework bursts into the scene. 2) "Hey it doesn't work with edge case X, let's graft on more features to cover it" 3) Repeat step #2 a few dozen times 4) The framework is now neither fast nor easy, invent a new one and go to step #1

nsonha 5y ago

There is nothing wrong with functional programming. It's a bit sad that redux and hooks give it a bad rap. Those things are NOT functional programming.

dcgudeman 5y ago

I have found that Redux Toolkit solved most of the pain with vanilla redux.