Sorry, but the very first comment in every single React vs Angular article is always: “React is not full MVC, it is just the View, wheras Angular is MVC so you should not even compare the two.”
React isn't full MVC but there is a whole ecosystem out there tailored around it and it winds up being full MVC in practice - but you have to do the legwork of figuring out what to add in and how to glue it together.
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.
You are obviously a thoughtful person who knows a lot about the subject than I do.
I didn't mean to disparage the articles that make these claims. In most instances they go on to say some of the things that you just did.
They do almost all start out by pointing out the V vs MVC distinction though, and I was just trying to point that out in the jokey spirit of the article.
>I think the tooling and approach it leverages fall in to a category that's prooven to scale with "enterprise grade" developers.
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.
I put "enterprise grade" in quotes on purpose. React stack (not React alone) being used successfully by a 9-5 Java or C# shop is not something I'd be willing to bet on.
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).
Enterprise? Beam me up, Scottie, there's no intelligent life here :-)
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)
That's not fair :) But it's true a lot of people just don't give a shit and will spend more effort avoiding learning than it would take to learn something so you're forced to cater to lowest common denominator.
I agree but I will just note that knowing about FP, idempotent, immutable and higher order functions does not mean a developer is able to create maintainable applications in a reasonable time frame.
I introduced React (alt as flux implementation) to a C# shop that develops internal tools within a large enterprise. We had one application before in Angular but people seem to like React much more and the uptake has been fast.
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.
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 understand the feeling. I've had 13 years of experience with web apps and most of those were not SPAs, but I did get to build something with an early version of Angular 1. Recently I was looking at Angular 2 and React for a new project, but fortunately I stumbled upon Aurelia which feels far more natural to me based on all my web app experiences over the years. Having just the view portion of React was not enough for my needs and Aurelia isn't lacking anything I need for this project compared to Angular 2, plus I could eventually even use React with Aurelia if I ever felt the need. Aurelia plays nicely with lots of other tools.
JSX has zero community adoption? Or was there a missing comma in there? Of the React code I see, I would estimate that JSX adoption is high 90s.
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.
And Angular 2 is 10x the size, so again, you have to learn a lot to be effective in either.
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.
As a mainly backend developer who dabbles in front end, there seems to be a lot of overlap between these JS framewors and backend frameworks. You are likely going to need a backend framework to serve JSON and do data validation and authentication, so I don't see the need for having so much functionality on the frontend frameworks. The View part seems to be the part I need. It gets really confusing as to where the logic should end up going (and a lot of it seems to make more sense on the back end anyway - why do I need routing in the front end for example?).
Might as well jump in here. I started with Angular 1 and am slowly migrating into React while having looked at and played around with a lot of Angular 2's beta releases. And when I say React I guess what I really mean is (React + ReactDOM + Babel/JSX + Webpack + ES6 + Redux) My point being there is a lot of tooling and setup and config you need to do before truly getting into building something great or efficient with it. It seems Angular 2 is going this route as well and they also throw in their special Angular ways of doing things. Their documentation is good but the product right now seems a bit rushed to compete with React and is sort of this weird middle-ground between the ease of use that Angular 1 was and the dependencies/component break-up mess with React. I went into React with a bunch of comments saying it's "simple" and just the view and everything we've heard of already. Well React is "simple" in the way that Arch Linux is the simplest Linux distro. And building the "just the view" part somehow takes two or three times longer than it should compared to building out the entire application using a full MVC or whatever pattern you want (Granted this probably has to do with the complete architectural design pattern shift more than anything else). With React you're encouraged to adopt a sort of top-most level state management with Redux when designing it but I suppose you don't have to do it that way. Maybe it's just the functional reactive programming side of it that makes it so difficult to grasp at first. I'm still sticking with it. I've spent a good chunk of time on it so far and need to adopt it for a large-scale application and with React it does seem like there's going to be a lot of work initially in the design + component breakdown/layout phase before getting into the actual building but I'm just hoping it pays off in the end. I'm keeping an eye on Angular 2 to see how it matures but it does feel a bit limited in scope in a similar way that Angular 1 did in that you have to do things the Angular way and just hope you run into someone who has the same problem or uploaded their sample code for you to look at and adopt into your project or use one of the many popular UIs and addons etc. React has a bunch of those too and it's probably more difficult to find a good component since there's just so many of them out there at this point, but the main takeaway from React is that it's pretty much pure Javascript and you sort of build from scratch there. It's getting pretty frustrating now trying to look up guides or tutorials for React since it's likely to be outdated if they're not using Webpack or ECMA2015 or even ReactDOM since they separated it in version 14 or something so all guides/tutorials prior to around November or December 2015 is pretty much outdated and you're not getting best practices or approaches there. There is no "Angular way" around here it's just a lot of Javascript everywhere. Sorry for the large block of text.
After reading I think the author is probably tired of all articles with clickbait title about these two frontend frameworks where readers may find a lot of marketing gibberish.
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.
> 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?
Ember has both. It is not mentioned the purpose of those articles is advertisements, not enlightenment.
>Lots of outdated information about old versions of the frameworks.
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
36 comments
[ 1.8 ms ] story [ 68.5 ms ] threadAnd 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.
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.
[1] http://tracker1.github.io/md-datepicker/
[2] https://github.com/tracker1/md-datepicker/
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.
Of course that's ridiculous, but whatever is, is right, as the original sadist said.
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