5 ms·

Honest question: why are React developers so fixated on functional programming? Why are objects - bundles of state and action that represent entities in the pro

Honest question: why are React developers so fixated on functional programming? Why are objects - bundles of state and action that represent entities in the problem domain - automatically painted as an antipattern?

pavlov 9y ago
Because they're not old enough to remember what '80s GUI code looked like when the "Global god object + functions" pattern was last popular? That's a snarky reply, but there is a kernel of truth. OO was practically invented for GUIs (Smalltalk). Throwing it out entirely on principle just makes large programs harder to understand, IMHO.
- simon83 9y ago
  True, I'm not old enough with my 33 years to remember that ;) But I do have quite a few years of experience in OOP and GUI programming (not just web stuff).
- pikzen 9y ago
  >Because they're not old enough to remember what '80s GUI code looked like when the "Global god object + functions" pattern was last popular? Funnily enough, React + Redux is "Global god state + functions", with a bit of dispatch sprinkled in. Not too far away really. I definitely see the benefits of having a functional approach to defining UIs. My code is _somewhat_ clear, clearer than what it would have been with say, WinForms or something of the like. Going purely functional everywhere is just devs cargo culting.
simon83 9y ago
I had no real clue about functional programming prior to React. I always did OOP before. Once I got in touch with React, I got interested in FP. Then I read the "Mostly Adequate Guide to Functional Programming" [1] and it was kind of an revelation for me. I still do OOP, and I'm far, far away from being an FP expert, but I think if I'd take the effort to learn a real FP language then I probably wouldn't want to go back to OOP, and that's something I fear :) I've read a few blog posts from people who stated that learning FP kind of made them "unemployable", because they suddenly saw all the problems and annoyances that OOP brings with it (unfortunately I can't find the link anymore). This quote regarding OOP by Joe Armstrong, the creator of Erlang, is quite fitting: "You wanted a banana, but what you got was a gorilla holding the banana, and the entire jungle." [1]: https://drboolean.gitbooks.io/mostly-adequate-guide/ https://drboolean.gitbooks.io/mostly-adequate-guide/
- jbreckmckye 9y ago
  > "You wanted a banana, but what you got was a gorilla holding the banana, and the entire jungle." When you say that, what exactly do you mean by it?
  - lmm 9y ago
    I understand it as: OO hides the distinction between a standalone value and a service connected to a bunch of hidden state.
  - simon83 9y ago
    Joe Armstrong said that in the context of code re-usability in OOP. At first it took me a while to understand what he actually meant with that, because OOP is about making code re-usable, after all. But then I read an article that explained this quote in great length and other potential pitfalls of OOP, and then it all started to make sense. I would write all of this in my own words, but it would become really long and I don't have the time at the moment. I tried to find the original article I read, but I'm unable to, but here is a similar article I just found: https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53 https://medium.com/@cscalfani/goodbye-object-oriented-progra... I'd understand if the inflammatory writing style and the memes are not yours, but I skimmed through it and I think it does explain some of the problems well. I'm sure there are better written articles on this subject, but I have to leave now unfortunately.
    - mattferderer 9y ago
      Are you referring to this article? http://harmful.cat-v.org/software/OO_programming/why_oo_sucks http://harmful.cat-v.org/software/OO_programming/why_oo_suck...
      - simon83 9y ago
        I definitely also read that one back then (I keep stumbling upon this website every now and then, it contains some really interesting articles), but I remember that it was too vague for me to understand his point about why OOP sucks. I searched further until I found the article I mentioned, it was much longer and more detailed than this one, and not by Joe himself.
lewisl9029 9y ago
I don't think bundling of state and action is inherently an antipattern (even in functional programming there is an implicit coupling between the shape of the app state and functions that operate on the app state), but in a system with countless individual units of tightly coupled state and actions interacting with eachother, it's all too easy to fall into the real antipattern of overusing in-place state mutations and neglecting deliberate management of state transitions across the entire system. Functional approaches to frontend development tend to encourage patterns like the single immutable app state tree and writing state transitions as pure functions, which helps minimize this source of complexity.
vbezhenar 9y ago
Are you sure about that? Main React use-case is class extending React.Component with its own state, so it's certainly very OOP. You can use functions, but even in that case they are not considered pure (and there's a good reason not to use functional components at all, unless some higher-order-component manages updating). There's certainly Redux movement, because it solves few important problems almost for free. But React isn't bound to Redux in any way.
ashark 9y ago
Because obviously "function(this, arg1, arg2)" is better than "method(arg0, arg1, [this])"
- mercer 9y ago
  More often than not, yes, I find it is. But in a nontrivial number of cases it isn't, and then I use methods.
mmargerum 9y ago
Follow up honest question. If they are so fixated in functional programming why not use ClojureScript? Trying to use react with immutability in JS looks like pure pain. I'm a swift / go guy mainly but I've been looking at this space for a while and the only sane approach to me looks like ClojureScript with reagent / reframe or something along those lines.
- erokar 9y ago
  I agree that is the logical consequence. Elm even more so than ClojureScript, imo.
  - mmargerum 9y ago
    Absolutely agree, I forgot to mention elm.
SamBam 9y ago
Two points: 1. It's not. React has had classes and states from the very begining. In fact, purely functional only views came in React 0.14. 2. That said, it really does make coding, debugging, and reasoning about views so much easier. When I have a bug in my React/Redux app, I can look at the Redux state, and figure out the cause of the bug right then and there. I'm not looking for some variable that accidentally got changed five steps ago. My bug is either in: (a) How I went from application state n-1 to n, or (b) How my current application state is rendered in my views Both of these are very fixable. ...of course, I do also have stateful React views in my app, and code with side-effects, because being "pure" all the time isn't always practical. If the bug is in those places, I'm in for a much longer debug.
qudat 9y ago
Being able to unit test every single part of our stack through composition of pure functions makes for a nicely decoupled architecture. We have a strictly defined state object that is used throughout our entire application. Because we made a contract with redux, every transaction is readable and transparent. Writing tests for our UI layer has never been easier with React. While we do have local state inside some react components, when we use redux to pass state to our react components, they become extremely easy to test, because they turn into pure functions. When using something like jQuery, you wouldn't just look at each frame of your state to determine how the UI would look, you would also have to look at the transitional states between A and B. Transitional states are much more difficult to understand because of the contextual implications. Our UI layer is completely separate from our business logic and we get it automatically. Without any code modification we were able to target our large application into a CLI app just by adding a new UI layer.

pavlov 9y ago

Because they're not old enough to remember what '80s GUI code looked like when the "Global god object + functions" pattern was last popular? That's a snarky reply, but there is a kernel of truth. OO was practically invented for GUIs (Smalltalk). Throwing it out entirely on principle just makes large programs harder to understand, IMHO.

simon83 9y ago
True, I'm not old enough with my 33 years to remember that ;) But I do have quite a few years of experience in OOP and GUI programming (not just web stuff).
pikzen 9y ago
>Because they're not old enough to remember what '80s GUI code looked like when the "Global god object + functions" pattern was last popular? Funnily enough, React + Redux is "Global god state + functions", with a bit of dispatch sprinkled in. Not too far away really. I definitely see the benefits of having a functional approach to defining UIs. My code is _somewhat_ clear, clearer than what it would have been with say, WinForms or something of the like. Going purely functional everywhere is just devs cargo culting.

simon83 9y ago

I had no real clue about functional programming prior to React. I always did OOP before. Once I got in touch with React, I got interested in FP. Then I read the "Mostly Adequate Guide to Functional Programming" [1] and it was kind of an revelation for me. I still do OOP, and I'm far, far away from being an FP expert, but I think if I'd take the effort to learn a real FP language then I probably wouldn't want to go back to OOP, and that's something I fear :) I've read a few blog posts from people who stated that learning FP kind of made them "unemployable", because they suddenly saw all the problems and annoyances that OOP brings with it (unfortunately I can't find the link anymore). This quote regarding OOP by Joe Armstrong, the creator of Erlang, is quite fitting: "You wanted a banana, but what you got was a gorilla holding the banana, and the entire jungle." [1]: https://drboolean.gitbooks.io/mostly-adequate-guide/ https://drboolean.gitbooks.io/mostly-adequate-guide/

jbreckmckye 9y ago
> "You wanted a banana, but what you got was a gorilla holding the banana, and the entire jungle." When you say that, what exactly do you mean by it?
- lmm 9y ago
  I understand it as: OO hides the distinction between a standalone value and a service connected to a bunch of hidden state.
- simon83 9y ago
  Joe Armstrong said that in the context of code re-usability in OOP. At first it took me a while to understand what he actually meant with that, because OOP is about making code re-usable, after all. But then I read an article that explained this quote in great length and other potential pitfalls of OOP, and then it all started to make sense. I would write all of this in my own words, but it would become really long and I don't have the time at the moment. I tried to find the original article I read, but I'm unable to, but here is a similar article I just found: https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53 https://medium.com/@cscalfani/goodbye-object-oriented-progra... I'd understand if the inflammatory writing style and the memes are not yours, but I skimmed through it and I think it does explain some of the problems well. I'm sure there are better written articles on this subject, but I have to leave now unfortunately.
  - mattferderer 9y ago
    Are you referring to this article? http://harmful.cat-v.org/software/OO_programming/why_oo_sucks http://harmful.cat-v.org/software/OO_programming/why_oo_suck...
    - simon83 9y ago
      I definitely also read that one back then (I keep stumbling upon this website every now and then, it contains some really interesting articles), but I remember that it was too vague for me to understand his point about why OOP sucks. I searched further until I found the article I mentioned, it was much longer and more detailed than this one, and not by Joe himself.

lewisl9029 9y ago

I don't think bundling of state and action is inherently an antipattern (even in functional programming there is an implicit coupling between the shape of the app state and functions that operate on the app state), but in a system with countless individual units of tightly coupled state and actions interacting with eachother, it's all too easy to fall into the real antipattern of overusing in-place state mutations and neglecting deliberate management of state transitions across the entire system. Functional approaches to frontend development tend to encourage patterns like the single immutable app state tree and writing state transitions as pure functions, which helps minimize this source of complexity.

vbezhenar 9y ago

Are you sure about that? Main React use-case is class extending React.Component with its own state, so it's certainly very OOP. You can use functions, but even in that case they are not considered pure (and there's a good reason not to use functional components at all, unless some higher-order-component manages updating). There's certainly Redux movement, because it solves few important problems almost for free. But React isn't bound to Redux in any way.

ashark 9y ago

Because obviously "function(this, arg1, arg2)" is better than "method(arg0, arg1, [this])"

mercer 9y ago
More often than not, yes, I find it is. But in a nontrivial number of cases it isn't, and then I use methods.

mmargerum 9y ago

Follow up honest question. If they are so fixated in functional programming why not use ClojureScript? Trying to use react with immutability in JS looks like pure pain. I'm a swift / go guy mainly but I've been looking at this space for a while and the only sane approach to me looks like ClojureScript with reagent / reframe or something along those lines.

erokar 9y ago
I agree that is the logical consequence. Elm even more so than ClojureScript, imo.
- mmargerum 9y ago
  Absolutely agree, I forgot to mention elm.

SamBam 9y ago

Two points: 1. It's not. React has had classes and states from the very begining. In fact, purely functional only views came in React 0.14. 2. That said, it really does make coding, debugging, and reasoning about views so much easier. When I have a bug in my React/Redux app, I can look at the Redux state, and figure out the cause of the bug right then and there. I'm not looking for some variable that accidentally got changed five steps ago. My bug is either in: (a) How I went from application state n-1 to n, or (b) How my current application state is rendered in my views Both of these are very fixable. ...of course, I do also have stateful React views in my app, and code with side-effects, because being "pure" all the time isn't always practical. If the bug is in those places, I'm in for a much longer debug.

qudat 9y ago

Being able to unit test every single part of our stack through composition of pure functions makes for a nicely decoupled architecture. We have a strictly defined state object that is used throughout our entire application. Because we made a contract with redux, every transaction is readable and transparent. Writing tests for our UI layer has never been easier with React. While we do have local state inside some react components, when we use redux to pass state to our react components, they become extremely easy to test, because they turn into pure functions. When using something like jQuery, you wouldn't just look at each frame of your state to determine how the UI would look, you would also have to look at the transitional states between A and B. Transitional states are much more difficult to understand because of the contextual implications. Our UI layer is completely separate from our business logic and we get it automatically. Without any code modification we were able to target our large application into a CLI app just by adding a new UI layer.