>Sigh. Yes, Angular is a framework, React is a library. Some say this difference makes comparing them illogical. Not at all!
Agree. This BS "oh, it's like comparing apples to oranges" knee jerk reaction should stop.
For one, even if Angular is a superset, we can always compare the parts that both have: component model, templating, etc.
Second, when we say React we almost ALWAYS mean React + Router + some Flux lib, etc. -- so all the same things you get with Angular, just cherry picked.
Third, we can just as well compare Angular (or any framework) with building something from scratch with vanilla JS too. Nobody said we have to compare them "as frameworks". We can compare them as different "ways get a web app done" (with/without framework, without framework but with x lib, etc).
Fourth, we can always compare apple's to oranges. Here's a comparison: oranges have more vitamin C than apples, and are better for scurvy (haven't checked the actual vitamin C stats, but you get my point).
If you're comparing flux + react + router to angular, then I feel like your missing huge aspects of what makes react valuable. I feel like when people talk about the awesomeness of react, they talk about the ecosystem around it.
It's the fact that Facebook has broken up react and all the surrounding architecture in a new way that is modular and logical for sharing code efficiently across various elements of a project or across projects. When I get excited about react, its because of things like Graphql coming out which is an entirely new way of interacting with your server that makes client side development significantly better.
They are creating entirely new ways of how you interact with the server side from the client side. This is why I love react and everything surrounding it. Not because it compares well to some random JS MVC that is completely tied to the DOM like angular, ember, or polymer.
When I say React, I mean just React - I already have a large complex app with persistence, routing, legacy components with multi-year investment in development etc. - I just want to be able to add performant componentized rendering to problem areas of the app.
And that's what React is able to do, because it's a library, not a framework.
Can you use Angular's components & templating outside of the rest of its MVC architecture? Despite the insistence on HN that React = React + Router + Flux, I've been using just React with plain js objects for models, and I like it exactly because it's an easier way of writing simple interactive views.
What if it can't? (I don't develop apps using Angular, so I really don't know the answer...)
Then it's just a con for Angular, but also a pro for providing a default MVC architecture to rely on. It's a design choice that can be both good and bad.
> Second, when we say React we almost ALWAYS mean React + Router + some Flux lib, etc. -- so all the same things you get with Angular, just cherry picked.
This premise is quite silly. Not every programmer is looking to create or adopt a framework in the beginning of a project. Some people just pick and choose libraries as they see fit and as the code evolves. I've worked on more than a few React projects and none of them use a Flux library or a routing library, simply because they were not needed.
Hence: "cherry picked". You don't have to pick ALL the parts if you don't want. You can still compare a full framework and the 2-3 items you cherry picked though as methods of getting web apps done.
Who said those who use Angular will just use Angular only as it comes upstream and won't pick and/or substitute a few libs for third party ones either?
Of course it's not forbidden. It's just confusing to say you're comparing React to a framework, when you implicitly include things other than React in the definition of React.
Agree. This BS "oh, it's like comparing apples to oranges" knee jerk reaction should stop.
For one, even if Angular is a superset, we can always compare the parts that both have: component model, templating, etc.
Second, when we say React we almost ALWAYS mean React + Router + some Flux lib, etc. -- so all the same things you get with Angular, just cherry picked.
Third, we can just as well compare Angular (or any framework) with building something from scratch with vanilla JS too. Nobody said we have to compare them "as frameworks". We can compare them as different "ways get a web app done" (with/without framework, without framework but with x lib, etc).
Fourth, we can always compare apple's to oranges. Here's a comparison: oranges have more vitamin C than apples, and are better for scurvy (haven't checked the actual vitamin C stats, but you get my point).