Hacker News Reader

Comment by simon83 | Hacker News Reader

I guess when you say "aging" team then I imagine your team members mostly spent their time in the OOP world, and Angular is definitely a better fit in this case.

React and Redux promotes a more functional style (even though React components are classes...), and a lot of OOP people I personally met were not so comfortable with it.

Personally I love the functional concepts that it taught me, and I would never want to use a framework like Angular again. I'd rather make the leap and look into a real functional language for the frontend, like Elm, ClojureScript, PureScript,...

View on HN

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?

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.

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).

>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.

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/

> "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?

I understand it as: OO hides the distinction between a standalone value and a service connected to a bunch of hidden state.

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-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.

Are you referring to this article? http://harmful.cat-v.org/software/OO_programming/why_oo_suck...

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.

Looking at that article, it seems nearly every complaint is about inheritance. But it is quite possible to use objects with composition. In fact, I think 'composition over inheritance' has been a commmonplace since the late 1990s.

The "Mostly Adequate Guide" is a tremendous intro to functional programming for any frontend/JS developer. I challenge anyone who knows a bit of JS and is not convinced of functional programming's advantages to read the guide.

My only regret after becoming comfortable with functional programming in JS (and eventually, even more robust techniques in Haskell, OCaml, and Scala) is not pushing harder for a functional approach in work projects that could have really benefited from the functional paradigm.

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.

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.

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

More often than not, yes, I find it is.

But in a nontrivial number of cases it isn't, and then I use methods.

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.

I agree that is the logical consequence. Elm even more so than ClojureScript, imo.

Absolutely agree, I forgot to mention elm.

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.

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.

I actually really liked Redux, but given the size of my team, I would choose Angular every time now. It's just more complete.

You might like NGRX, then. It's basically Redux for Angular 2.

http://onehungrymind.com/build-better-angular-2-application-...

Will this ever end? How deep must the stack go? God, I give it 10 seconds for someone to pop out of the woodwork and say "Why don't you just use NGRX v3 'cute name'? Here's a link to my 10 star GitHub"

> even though React components are classes...

Since 0.14, React components can be functions, too: https://hackernoon.com/react-stateless-functional-components...

Reply on news.ycombinator.com