Live data from Hacker News

React vs. Angular 2

docs.google.com

21–30 of 87 posts

Re: React vs. Angular 2

#22

Isn't this like comparing apples to a fruit salad? Quoting from the React website, "Lots of people use React as the V in MVC," whereas Angular is the whole kit `n' kaboodle. I thought React was supposed to be used in tandem with a Flux-like component that stores the state of the application, thereby allowing the developer to adopt the functional reactive programming style. Anyways, I think React will be short lived,…

From my experience, it is not about the FRP kool-aid. It's about the robustness of the concepts of React (DOM diff-ing, favor immutability, declarative views etc.)

Adopting something like elm might have its advantages, but also comes with practical disadvantages that, depending on your team and your project might be simply too big make the jump.

React got a lot of things right in my opinion. So much that to go from apple to fruit salad, you need roughly 200-300 additional LOCs, and you have a very robust Frontend system that, once you wrapped your head around React, has a very low knowledge barrier.

However, the good traits of React are not attributable to one concept like "FRP" but are simply "good concepts" that seem to influence other Frameworks to do "the same, a little different".

The adoption, the somewhat small API, the support from a large company, the possibility to integrate it easily in existing codebases that use other frameworks and react native has a much stronger pull than FRP in my opinion.

Re: React vs. Angular 2

#23

Isn't this like comparing apples to a fruit salad? Quoting from the React website, "Lots of people use React as the V in MVC," whereas Angular is the whole kit `n' kaboodle. I thought React was supposed to be used in tandem with a Flux-like component that stores the state of the application, thereby allowing the developer to adopt the functional reactive programming style. Anyways, I think React will be short lived,…

React only covers the V of MVC, true, but in practice it influences heavily the rest of your app. So comparing Angular and React is useful, most people will have to pick one or the other when they start their next project.

The difference is that React is much less opinionated. You can tie it into your existing Backbone app or you can use Flux (or one of the many Flux-like libraries out there) or you can use Redux (which is in many ways exactly like React, but for state) or you can use something like Relay or Falcor or even something entirely different.

Angular wants to own your project. That's not necessarily a bad thing because it also means you don't need to evaluate the relative pros and cons of lots of tools doing what it already gives you for free and you're more likely to find help because there are more people with your specific combination. But it also limits how much you can adapt Angular to your specific application's needs.

The more you deviate from the defaults, the more you lose the benefits of using a full-featured framework in the first place and the more you have to muck around trying to bend all the parts into the shape you want.

Plus you actually CAN use React inside Angular (or vice versa) if you really want to. It's probably not a good idea because React doesn't do anything Angular can already do (but differently), but it's entirely possible (just like how people already used Angular with Polymer or Backbone or what have you).

I wouldn't say React influences the rest of your app as much as Angular (or Ember) necessarily does but saying that a tool will influence the rest of the app is almost tautological -- every decision affects other decisions, even if it's only because of the mental models it may bring with it.

The truth is, it's not a decision between Angular or just React. You're not going to simply use React. You're going to use React plus something else. That's simply a set of decisions choosing a framework won't require you to make.

The comparison isn't meaningless because there is no either-or choice. The comparison is meaningless because it's incredibly hard to compare just React with all of Angular (or Ember or whatever).

Re: React vs. Angular 2

#24

Isn't this like comparing apples to a fruit salad? Quoting from the React website, "Lots of people use React as the V in MVC," whereas Angular is the whole kit `n' kaboodle. I thought React was supposed to be used in tandem with a Flux-like component that stores the state of the application, thereby allowing the developer to adopt the functional reactive programming style. Anyways, I think React will be short lived,…

I think FRP is one of those technologies where going full-hog (all the things are event streams!) results in confusing code and a dogmatic, difficult, and unpleasant development experience. However, if you apply it just enough, you'll have coherent one-directional dataflow, effortless propagation of state changes, and a nice testable push architecture as a free side-effect. It's a way to tame the state-monster. And there will be numerous small isolated parts of your codebase that are unrelated to the aforementioned goals, where sticking to FRP would be masochistic and pointless.

A major part of mastering a technology or paradigm is knowing when to apply it and when the costs of it outweigh the benefits. Then again, I prefer hybrid-friendly languages like scala, so maybe the haskell and clojure people are onto something that I'm missing.

Re: React vs. Angular 2

#25

What is this FRP thing JS developers talking about? What I should read to learn more about it?

It's a way to write applications as declarative code that defines the UI in terms of sequences of events and streams.

Basically: something incredibly powerful and clever that will not be adopted by the wider developer community until someone figures out how to present it in a way that makes it accessible to someone who isn't deeply interested in academia.

Re: React vs. Angular 2

#26

Isn't this like comparing apples to a fruit salad? Quoting from the React website, "Lots of people use React as the V in MVC," whereas Angular is the whole kit `n' kaboodle. I thought React was supposed to be used in tandem with a Flux-like component that stores the state of the application, thereby allowing the developer to adopt the functional reactive programming style. Anyways, I think React will be short lived,…

>Anyways, I think React will be short lived, because anyone who really wants to hop on the FRP bandwagon will pick up something like http://elm-lang.org in order to fully achieve Satori

Lot of ppl do server side rendering with react so elm is not going to cut it.

Re: React vs. Angular 2

#27

For someone who hasn't had to do much work on the front end JS technologies like Ember, Angular, React, etc. What is a good resource to start learning Angular 2 (even though its not out yet)? I came across ng-book2 [0] but I've heard mixed reviews about their first book. [0] https://www.ng-book.com/2/

I, myself, tried to learn it by generating a sample project with Yeoman. Only to find myself in a project where so many things were already done for me that I couldn't make sense of all the pieces that allowed it to work correctly. I would make a couple of changes and if one of them broke something, I was not able to quickly identify what I had done that was a problem. I'd recommend that you go step by step a build a…

Absolutely agree, I have just started a new project which is the first time I have used React beyond a "toy" project (along with Typescript and Redux), and have found by far the best approach is to start off with just the basics (i.e. React alone), and only add in additional libraries when you start hitting problems you feel could be solved in a more optimal manner (e.g. Redux when state management starts getting messy, then redux-form when you realise form onChange handlers etc. are a bit tiresome to write, etc.).

It does help to have a good awareness of what libraries are being released and are becoming popular before you start needing them however, so you can realise when you are facing a problem that has already been solved - it helps if you read the React-related stuff that appears on HN and follow a few of the "key players" on Twitter.

The big starter projects are a great resource for code examples of how pieces fit together and for pointing you in the direction of other interesting libraries, but are just too overwhelming to work with if you aren't already familiar with the core components of the stack.

One thing I am enjoying a lot about the React world (compared to the Angular world, in my case) is that each library/component tends to be pretty simple (for example, the APIs are pretty small) and you can reason about what it is doing in your head; but the way they fit together can make solving complicated problems feel really easy once you get your head around the React/Redux (or whatever) approach to breaking things down. I feel like I have a much better understanding of what is going on under the hood with the application than I did with Angular, and this makes solving hard problems much easier, even if it means more setup and lines of code initially.

Re: React vs. Angular 2

#28
post #19

Earlier quoted context omitted.

> Anyways, I think React will be short lived, because anyone who really wants to hop on the FRP bandwagon... I don't think most front end developers even care. React will stick around because it's backed by Facebook and if Facebook says this is the way to go with front-end development then that is all the convincing most folks need. They'll go on to learn React and not think twice about the minutiae of "FRP" or whate…

> React will stick around because it's backed by Facebook and if Facebook says this is the way to go with front-end development then that is all the convincing most folks need. Not just that. Facebook uses it for their flagship website (and as React Native for their mobile apps). So does Instagram. So does Netflix. If you have the React developer tools installed you can literally go to facebook.com or netflix.com and…

> Google (who is backing Angular) doesn't have nearly as much skin in the game as Facebook (who is backing React).

Excellent point. Here's another "smell" with angular: http://angularjs.org versus https://angular.io/. The former is AngularJS 2.0 and the latter is AngularJS 1.0... they maintain two websites for two versions of the same framework.

It boggles my mind.

Who thought it would be a good idea to separate versions of the framework onto two different domain names? While they're still owned by the same company? Why? Unfortunately, the only sensible answer that comes to mind is "AngularJS 1.0 was such a colossal, terrible mistake that we need to move away from it not just from a code perspective, but from a marketing perspective as well."

Normally, I avoid framework/language wars but I had ( and will soon again have ) the misfortune of developing in Angular. Consulting out-of-date documentation on their quick-and-dirty bootstrap site, fervently wishing that the devs didn't rage-delete the comments section which corrected the incorrect documentation... yuck.

Re: React vs. Angular 2

#29

Isn't this like comparing apples to a fruit salad? Quoting from the React website, "Lots of people use React as the V in MVC," whereas Angular is the whole kit `n' kaboodle. I thought React was supposed to be used in tandem with a Flux-like component that stores the state of the application, thereby allowing the developer to adopt the functional reactive programming style. Anyways, I think React will be short lived,…

> because anyone who really wants to hop on the FRP bandwagon will pick up something like http://elm-lang.org Elm is awesome, but also look into Cycle[1]. [1] http://cycle.js.org

When evaluating techs to make our frontend evolve, I looked at cycle. It seems genuinely interesting, and much more FRP than React+Flux, but it doesn't seem to have a lot of traction.

Re: React vs. Angular 2

#30
post #24

Isn't this like comparing apples to a fruit salad? Quoting from the React website, "Lots of people use React as the V in MVC," whereas Angular is the whole kit `n' kaboodle. I thought React was supposed to be used in tandem with a Flux-like component that stores the state of the application, thereby allowing the developer to adopt the functional reactive programming style. Anyways, I think React will be short lived,…

I think FRP is one of those technologies where going full-hog (all the things are event streams!) results in confusing code and a dogmatic, difficult, and unpleasant development experience. However, if you apply it just enough, you'll have coherent one-directional dataflow, effortless propagation of state changes, and a nice testable push architecture as a free side-effect. It's a way to tame the state-monster. And t…

I agree with you. I also like being "closer to the machine" so to speak. One day, my dev browser will support ES6/7 and I won't need babel + webpack/browserify while doing locally development, debugging will be done on unmunged code and TDD will be easy to practice as the feedback loop will be back to normal.
Post reply on HN