Every “Angular 2 vs. React” article out there
medium.com
medium.com
And then they compare the two.
I've said this before - my personal view on this is that if you would descirbe your self as a JS developer you will probably like React more, and if you're coming from a .NET/Java background Angular will be much more familiar.
Having used both and having experience with both functional/dynamic programming with Clojure and enterprise/OOP/static programming with WPF/Silverlight - I prefer Angular - I think the tooling and approach it leverages fall in to a category that's prooven to scale with "enterprise grade" developers.
I like the simplicity and purity of React architecture - using React wrappers in ClojureScript like Reagent is very "satisfying" - the entire language/platform just "fits together" from immutable state management being the core of the language to sexpression DSL being a natural thing for lisp. I very much dislike their implementation and tooling like JSX and flow which has 0 community adoption compared to TS. I feel like their design is heavily influenced by the problems of Facebook - for eg. shoehorning this kind of things on to plain old JS is an ugly mess for the sake of being easy to introduce in to existing code - crucial for a huge project like say FB - completely irrelevant to a new project.
And the fact that you have to merge so much different libraries in the hell that is JS ecosystem of build tools, duplicated libraries, constantly obsolete tech, etc. ads a ton of overhead with very low practical value.
If I needed to migrate an existing JS project to a new framework gradually I would not even consider Angular 2, but if starting a new project it would be my go-to choice.
I think react is proven to scale too and it's being used by a lot more large companies than Angular 2.
Just a few months ago I tried to do the hello world tutorial on the angular 2 web site. I tried to do the javascript version and I couldn't get it to work. I then tried the type script version, still no luck. It wasn't until a while later when I tried again and they had updated the tutorial that I was even able to get hello world to run.
I've programmed some large web apps in angular 1 and while I never fully understood the depths of angular 1 I was still able to leverage the parts of Angular I needed to build fully functional apps.
Now coming from Angular 1 I feel like I'm in a somewhat new world. Then I tried react. It was simple, it didn't require me to completely re-learn everything I know about web dev. I wish I had tried react sooner. If it's good enough for facebook and the hundreds of other big websites that use it, then it's good enough for me.
Sure it's simple as far as hello world apps go, but once you start adding state management, routing, etc. you start seeing that it diverges from conventional architecture approaches. Not saying that's necessarily bad but it does not mesh well with enterprise development - I hope you understand what I mean by this.
And tools that help ensure consistency/quality in that kind of environment like TypeScript are very unsatisfying with React and various libraries, for eg. look how tedious Immutable.js typed records are, and check out typings for Redux related libs - bunch of any typed parameters and return values. Flux basically has no support outside of React and it wouldn't even run on Windows last time I checked.
So like I said - it depends on the context - if we're talking a bunch of JS frontend devs I'd say go for React if it fits what you're trying to do. If you're a .NET/Java shop Angular 2 is probably going to be a better fit, patterns like DI, OOP, etc. are all at the core and it's a full stack framework you just pick up and follow it's conventions/best practices/design decisions - way less decisions than React and way better docs (for the stuff not included in React I mean, React documentation is decent).
I have a pretty good idea of the -- "just following orders", OOP-factory strongly typed except for all the XML and annotations, never heard of FP, idempotent, immutable, nor higher order functions, etc -- kind of developer that "Enterprise" probably implies.
(I understand these people know ways to get some stuff done, and just want to go home, but holy cow it gives me a bad case of "COBOL fingers" and/or eye-strain working on those code bases -- spend some time to learn how to shorten things up, please)
DI in Angular 1 feels different than in C# land and is mostly used due to a missing module system. That exists these days and that makes it easier.
Routing is the same. Most modern Angular guides even recommends you routing to directives and pretty much using them as react components to prepare for Angular 2.
But the biggest thing about Angular is that you need to learn tons of things that are NOT familiar to a .NET developer. scope, transclusion, different types of bindings (represented by strings ...), template language etc.
If they are not feeling familiar enough with the web to learn React then I don't think they can create a large angular application without creating a mess either.
webpack, babel, babel-preset-es2015,
babel-preset-react, babel-preset-stage-2,
react, redux, react-redux, react-router,
react-router-redux, redux-thunk, redux-actions
Those provide the core you need in a react application imho... if you want a "service" abstraction similar to angular, you can use axios. Yes, there is slightly more boilerplate to setup when you get started... and understanding smart/dumb components and higher level abstractions takes a little work. Once you get past that, and understand how Redux's tooling works for building your state management, it gets simpler still.In the end, there are FAR fewer surprises with React + Redux then there are with Angular 1 or 2. One of my single biggest issues with every angular project I've worked on, is that it's hard to find what you're looking for...
I see a string of "foo-class" rendered as part of the output in the browser, I go search for "foo-class", and I find it... It's in a .html file, now I need to find where that is referenced, find it... and now I'm looking at controller/directive for the foo.html... there's an attribute (directive) on one of the elements in the template... WTH does directive-foo come from? I search for "directive-foo"... not found... oh yeah, I have to search for "directiveFoo" to find it, again the templates are separate from the controller/directive, and this ball of mess continues...
In a react app, I find the top component, I want to know where FooComponent comes from, I see the import statement above, and go to that directory... the end. No searching for strings past the first search.
That's just tracing the rendering stuff... as for the logic, there's some disconnect there, but in the end, once you understand the rendering path of the components, vs action creators (which use services, redux-thunk), vs. modyifying the state tree (dispatch) through reducer(s)... in the end it's simple, easy to follow, enhance, extend, modify.
Working in a large (or even relatively small) angular app is an exercise in ever-increasing frustration... doing the same in a well-organized react app, much simpler.
That doesn't even go into the size of the min+gz libraries you start with in either/or. I have a preact+redux module/app that is a standalone datepicker modal control... in the end, 16.2kb min+gz [1] (the demo site, gh-pages wasn't compressed last I checked). The source[2] is pretty clean and well structured.
It's easy to grow a react+redux application organically... the same cannot easily be said for angular (1 or 2). And although Angular 2 is much better, I'd still prefer react + redux any day of the week.
I've used both Angular, played with Angular 2 and React. Plus many other MVC (and MVVM) libraries. I would say that the state managed React model is far more scalable than the traditional MVC 'observable' model. Sure, you can use immutability in Angular-2, but with React you have an architecture built around simplicity with the need to integrate different artifacts.
JSX helps React to scale because it extends type safety of TS or Flow into the UI DSL. JSX allows the developer to deal with the DOM as an object graph expression, right in the language. From a strongly typed perspective, this works much better than templates or embedding code into HTML.
That seems to be required when mentioning React since you can't learn just React, you have to learn React + at least 5 other things to get the same featureset of Angular 2.
The differences to me with React + Redux, is you have far fewer surprises, it's easier to refactor and fewer wtf's per day. I spent a month working on a relatively small ng2 app and only had one single day without a weird "wtf" moment.
I've done several apps with ng1, and can't count the wtf's... with React + Redux, far fewer wtfs, and beyond that, far easier to jump into an existing app and find what I need to change. Can never say the same about ng1 and ng2 isn't much better than ng1 in that regard. In the end, I'd rather start with a boilerplate and build with React + Redux over ng1 or ng2.
Yes, there is webpack + babel (you need a transpiler for ng2, and should use a build tool regardless), the tooling around react + redux isn't too bad, and significantly smaller still than getting started in even a medium complexity app in ng.
Frankly, I must admit he is right. Since React is on the top of the "requirements of the modern JS Developer" [1] the popularity of such articles are really high and mostly there are the same repetitive informations. However I really miss a Ember.js as example of successful story. Is it a a badly designed framework? Or just there isn't any huge company behind it? Personally, I would say it is powerful framework with modern features like server-side rendering (fastboot), ES6-compliant, scaffold-friendly where Flux architecture can be applied [2].
[1]: Based on StackOverflow Jobs (number of occurrences: react: 140, angular2: 1, angular: 220, ember: 38, elm: 3, jquery: 147), LinkedIn, RemoteOk offers for frontend developers.
[2]: https://emberway.io/ember-js-goodbye-mvc-part-1-21777ecfd708
Ember has both. It is not mentioned the purpose of those articles is advertisements, not enlightenment.
I completely disagree. They always have very few and vague info which somehow does not change with time. you know like, angular is slow but has lots of tutorials. etc
Of course that's ridiculous, but whatever is, is right, as the original sadist said.