Hacker News Reader

Comment by jamra | Hacker News Reader

This reads as react fanboyism to me. I used React/Redux on a project and was unable to bring people up in my aging team. Now we are fully Angular 2+. It is much better for my newly grown team of 15. The action creator approach of Redux isn't very readable or maintainable. The module system in Angular is better for us.

You can use webpack with Angular. RxJs is a great addition that will eventually be removed when Observables become implemented in JS. The declarative style of templates are different than JSX, but are not hard to deal with in practice. Native script allows for mobile dev, although I don't personally use it.

Before I switched to Angular, I preferred React. Now that I use this framework approach, I am much happier and have more faith that my code base will be consistent. I read somewhere that google used Angular for adsense so I think it is good enough for production use for us.

View on HN

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

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"

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.

> even though React components are classes...

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

> You can use webpack with Angular.

That is a bit of an understatement. Using the angular CLI the default is setting up a project with webpack with a single command. Webpack is wrapped in the "ng ..." commands for building and running. With "ng eject" the webpack config file is exposed and webpack is in the driver seat. It is not just "can" but it is really easy these days.

There may be reasons not to like Angular but articles focusing on AngularJS 1.x are not shining the light on relevant weaknesses.

Angular may be too late if one buys into the view that the growth in the JavaScript ecosystem has peaked or is peaking soon. My personal view is that the growth has been stunted by severe UX problems before ES6/Typescript and we are just at the beginning of an explosive growth phase with no end in sight.

React + MobX is my goto when it comes to teams like that. Much easier to get up to speed with than Redux and often a more familiar programming model for people.

I'll take a look at that. Never knew about MobX. In general, loyalty to one framework only boxes off our minds to what could be a better way of accomplishing our goals. It's a great world out there that we have so many options.

plus one for Mobx. It really is very simple compared to redux. I do have many apps using redux, but for newer ones i now prefer mobx.

I've used Redux, but have never used MobX. How's MobX compared to Redux in terms of debugging experience ? I've looked at a couple MobX examples, and felt like the obserable stuff, while help reduce boilerplate code, could hide too many things which could make debugging a bit difficult.

I've had some problems with mobx. Works great on smaller projects, but can be hard to debug when something goes wrong.

Observable objects are tough to read in the debugger.

The main gotcha I found [1] was dereferencing property of an observable didn't trigger rendering. Didn't feel very intuitive to me.

Also, occasionally, I would insert a row into an observable array and nothing would happen, and I could never figure out why.

Using redux now, it's more explicit and full of boilerplate and ceremony, but I understand all the code, and there is far less magic.

[1] https://mobx.js.org/refguide/observer-component.html

>dereferencing property of an observable didn't trigger rendering

For real!? This seems like either a critical bug or huge design mistake on the part of the MobX author.

I also cannot understand why you cannot make a Set an observable. It's such a fundamental part of programming!

> You can use webpack with Angular.

In fact, Angular CLI uses Webpack by default.

> The action creator approach of Redux isn't very readable or maintainable.

Can you elaborate on this? I've been working on an Angular 2+ application that I think could benefit from a redux like state container a la ngrx/store. I'm curious if some of the issues you outline might also be applicable here.

> You can use webpack with Angular.

Ionic, the mobile framework based on Angular mentioned in the article, actually does by default in it's `@ionic/app-scripts` that are used to build these applications.

AdWords, AdSense and internal Google CRM are written in Dart - namely AngularDart:

https://webdev.dartlang.org/angular according to: http://news.dartlang.org/2017/06/a-stronger-dart-for-everyon...

>This reads as react fanboyism to me

Why isn't your comment Angular fanboyism?

Full disclosure: I prefer neither.

It reads like React fanboyism to me too. Very one sided, and seems light on actual knowledge of Angular.

Full disclosure: I am not a web dev at all so my opinion is more valid.

Couldn't have said it better myself.

Reply on news.ycombinator.com