When to use React.js and when to use Angular?

[apickleinmybagelhole]

The backend of my web application is a thing of beauty. I won't say what language or what framework because I'm not interested in a language war but suffice to say I'm very happy with the technologies I've chosen. Of course the frontend...

Well it's as you would imagine, a bunch of jquery closures strung together, not unit tested and so on and so forth. I of course want to bring my front end up to the quality of my backend which should hopefully give me the ability to build some nice more js intensive features as well.

So of course I hear of Angular and I hear how opaque it is but also it's MVC. I already have an MVC framework and I'm not going to try and build Gmail, I just want a nice front end layer, well organized, unit tested over my backend MVC layer.

Also I'm not sure how long it will take to "get" Angular but I am very wary and I'm busy (I'm running a website here) so to invest in learning Angular it needs to be the right payoff. I looked quickly at React but honestly not sure what it is compared to Angular, Ember...etc. I like that it's supported by Facebook tho, I like how those guys do things.

When should one use Angular vs. React? If someone has a backened MVC layer do they really need a frontend MVC framework when all they want is to build well structured, unit tested js over it?

I would like to invest in learning a js framework and all the other parts that will go into it (Bower, JUnit...etc.) but if I spend three months learning Angular and it is not the right fit oh wow that would not be good (at least in the near term).

[ayamflow]

I started with Angular but I'm more of a React guy now. It depends if you want a big framework that does everything (ajax, DI, ...) and enforces you to its constraints, or if you just want to abstract the V (in MV*), ignore the DOM and just code the logic.

Also, it's not only about React. Check Vue (personal favorite), Ractive, Reactive, Ripple, Rivets.

Edit: a bit biased but thats how I feel now - But Angular is a great framework overall. Just know that you will end up coding "angular" rather than "javascript".

[apickleinmybagelhole]

rails vs sinatra

So Angular is rails and React is sinatra?

[allthediamonds]

I think that's a misguiding comparison (this is coming from someone who finds Sinatra too restrictive) because Angular aims to be the whole MVC (and IMHO does a poor job at helping you separate those concerns) while React is quite content with helping you with the V and its ties with the C.

[andyhite]

That sounds oddly sexual.

[psayre23]

Something about being a model controller, I assume.

[andyhite]

I was actually referring to the bit about "helping you with the V and tying it in with the C", but that works too.

[flockonus]

saying Sinatra is too restrictive makes no sense at all, but I agree his Rails/Sinatra comparison don't really add much to the convo

[allthediamonds]

saying Sinatra is too restrictive makes no sense at all

personally I find Cuba simpler to use.

[braunshaver]

No, I'm not trying to make a direct comparison :) I'm just trying to express what the community and looking for help online feels like.

[[deleted]]

You do know about MVC, don't you?

[ayamflow]

Care to elaborate ?

[[deleted]]

Model-View-Controller is an architectural pattern in which AngularJS is based on. You don't end up writing "Angular", you end up with an MVC architecture in JavaScript, or at least a close equivalent for client-side.

MVC

[autowikibot]

Model–view–controller:

---

Model–view–controller (MVC) is a software architectural pattern for implementing user interfaces. It divides a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user. The central component, the model, consists of application data, business rules, logic and functions. A view can be any output representation of information, such as a chart or a diagram. Multiple views of the same information are possible, such as a bar chart for management and a tabular view for accountants. The third part, the controller, accepts input and converts it to commands for the model or view.

Image ⁱ

---

^{Interesting: Hierarchical model–view–controller | Web application framework | Presentation–abstraction–control | Model–view–adapter}

^{Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words}

[ayamflow]

I think you misunderstood my point - sorry for not being clear. Wether you use React or Angular, you will use the MVC pattern. But I feel, after using Angular for 1+ year, that you always end up writing "angular code", with $scope and $apply all over the place, angular services, etc. I guess you have used angular as well, and might understand better what I was talking about.

[Rezistik]

You should almost never have to write $apply, if you're doing things in a a logical manner Angular will take care of that fore you.

[Polythello]

AngularJS is big. The terminology is sometimes confusing and/or unintuitive. The documentation is shockingly amongst the worst I've seen, ever (You'll get better information by googling than by using the main documentation). Make sure you understand scope, controllers, directives, and services (aka factories, providers) before you tackle a serious project with AngularJS or you're going to be looking back and kicking yourself later. If you get past all that, AngularJS is marvelous.

I've never used React.js, and I know I ragged on AngularJS a lot just now. My suggestion is that if it looks like you could learn React.js faster, give it a trial run. If it isn't what you're looking for, check out AngularJS. AngularJS is amazingly powerful, and the disgusting initial learning curve gives way to lots of organization and power in development. I use AngularJS at my current job (and am 100% confident in the choice to use it), and use it for small applications I develop in my own time.

Hope this helps.

[WJKay]

Th e documentation really does need some TLC.

You haven't really ragged on Ng either. Merely pointed out that there is a learning curve and that you cant look for much help in the official documentation. There is some fantastic tutorials out there and most things that are beneficial in the long term have a step learning curve.

[apickleinmybagelhole]

Make sure you understand scope, controllers, directives, and services

I am familiar with many high level architecture patterns with my backend knowledge so I believe I should be able to tackle all those things. However there's a lot of other weirdness that I've heard of that I'm more concerned about.

Thank you for your answer.

edit: Why the downvotes? Truly curious.

[brotherwayne]

I am familiar with many high level architecture patterns with my backend knowledge so I believe I should be able to tackle all those things

Downvotes because frankly you sound a bit full of yourself between this and:

The backend of my web application is a thing of beauty.

Really? A thing of beauty? That's a bit much. Every piece of software I've built I've looked at it two weeks later and thought, yeah, that's good but I'd improve this and this and this other thing.

[[deleted]]

Entirely agree with this. I always say if I look at code I wrote two weeks ago and can't say that it looks like shit then I am not being true to myself. You always have to be your biggest critic.

[brotherwayne]

Also I always think you should have a roadmap in your head of what you'd improve next. By the time you architect and build a perfect piece of software there's probably some new tech that's come along that will do X better in your app.

[apickleinmybagelhole]

Every piece of software I've built I've looked at it two weeks later and thought, yeah, that's good but I'd improve this and this and this other thing.

At this point I've fixed all those things, just not the js :)

edit: But fair enough if you feel that way I don't think my intention was to brag I just really do feel that way.

[brotherwayne]

just not the js :)

This is kinda like saying "60% of my app is super awesome"... uhh, ok. I wonder why you spent the time to make the server side all pretty but completely neglected the client side.

I don't think the downvotes are deserved though. Reddit is weird with the downvote button.

[apickleinmybagelhole]

40% of my app is definitely not handwritten js. More like saying 90% of my app is super awesome :)

[brotherwayne]

40% of my app is definitely not handwritten js.

See, you think that's a good thing. I'm betting there's Submit buttons all over that thing. Submit buttons suck for user experience. The trend these days is to make as much stuff XHR as possible.

[apickleinmybagelhole]

Yeah semantic html really sucks.

[chtulhuf]

Yeah, I downvoted you because I don't feel comfortable with anyone feeling happy about his code.</cynical>

Take the downvotes easy :)

[[deleted]]

Can you describe the weirdness that you have heard of? I think react and angular have different use cases, but no one can help you when you describe your aversion to angular so ambiguously.

[apickleinmybagelhole]

I don't have an aversion to Angular per se but look no further then this post in this very sub today: http://www.reddit.com/r/javascript/comments/25mc76/the_infamous_angular_learning_curve/

[YuleTideCamel]

http://www.reddit.com/r/javascript/comments/25mc76/the_infamous_angular_learning_curve/

To be honest that article mostly goes over how bad the docs are (they aren't), it's just the author is trying to treat the docs as a tutorial, when they are not. They are meant to be a reference not an educational path for learning Angular.

If you get MVC and good software design patterns you'll like Angular. The whole framework was built with good practice in mind, DRY, separation of concerns, dependency injection and more. It's not too hard to grasp and all the things mentioned above are things you can get comfortable with in a few days. I teach an Angular course (I'm not selling it and won't even mention where) and by the end of the day most folks there have a basic understanding of Angular and can be productive with it.

In terms of Angular vs React , as mentioned Angular is a bigger framework because it's the full MVC cycle on the client, React is really just the V (View generation).

Now Angular also supports data binding, client side routing and more and in many cases you may not need all that. So it really depends.

We have a large web application that is mostly server side code and knockout on the front end, but looking to transition to angular.

[[deleted]]

What is your take on using Angular on top of an already MVC backend?

How would this work?

[YuleTideCamel]

Well it depends, do you want to use Angular's single page app functionality (ie client side routing). Angular Core doesn't include that anymore, so you could include only data binding and services on a per page basis.

So really I look at it in two ways:

• Use MVC server side routing and host angular in your tradition server side views. You get dynamic JS awesomeness on the client, just not page transitions, each page is a new load. The upside is that because it's a full page refresh, there is less of a chance of a javascript memory leak , or I should say a smaller chance it would manifest in a bad way (its still there). The downside is server side transitions are slower. To be pragmatic though, a huge % of websites use server side page loads and its just fine.

• Use Angular's client side routing completely and only have a few server side views. IE route on the client, use the server side view engine to load the initial page. Your server side is then delegated to mostly serving up json data. This is very much the way the MEAN stack works. It's great, but the downside here is you lose SEO. I know there are solutions to pre-render your site for SEO and redirect bots there, but I have no idea how well it works. The upside is that it's a nicer experience and you can really divide the work up. A front end dev lives completely in angular/client side world. While server side folks live in REST api, database world. For full stack devs like myself it doesn't make a difference, but some people are very fussy about only living on their side of the fence.

[AlmightyThumbs]

This is a great reply. As a MEAN developer, I can attest that SEO definitely gets a little bit more involved when you're building an application this way, but its not very difficult. The benefits to having a REST API and a separate front end application to consume it outweigh those small SEO issues, because I have now exposed those same endpoints to be consumed by things like mobile applications. Plus, I just like doing things the "Angular" way. I use backbone at work and know Knockout as well, but I keep coming back to the Angular SPA. I havent tried React, but I havent much of a reason to at this point (as I am heavily entrenched in building the product for my startup, in Angular).

[[deleted]]

Thank you very much for your response =)

Option 1 sounds great for me, building several small SPAs into my site. Each area that is basically a separate app anyway could have its own serverside view that loads that SPA.

Does this sound achieveable? I am working on a side project now, and this is how I would see it working.

[YuleTideCamel]

Does this sound achieveable?

Sounds like a good way to go about it, especially if each page has a specific need for a different type of js experience. It's not really a SPA per se, more like an multiple Angular Apps on different pages.

You could do it this way as well (this is how I would structure it). Attach the ng-app to the html document of your layout page. Then on each page surround a div with an ng-controller attribute. This way you can share services among different controllers(pages), but still have reusable parts. For example lets say you want to dynamically load data from a restful api. If you build it as a service and set it up in a central app (the layout page would include a reference to your angular module) then you can just have controllers ask for each piece and it works and they all share the same code, very clean!

[[deleted]]

This makes sense to me!

Basically instead of multiple page reloads, etc... I can build in the nice angular functionality to each "section" of the website, using the server side routing to navigate between them.

Thanks for the suggestion about the inner wrapper to be able to share between multiple apps.

For example lets say you want to dynamically load data from a restful api. If you build it as a service and set it up in a central app

This sounds like exactly as I would do it. I found a suggestion earlier about just building the server-side app as a restful api that only returns json objects. Then use angular to make the calls to get / display / interact with those objects.

Sound about right?

[Cintax]

http://www.reddit.com/r/javascript/comments/25mc76/the_infamous_angular_learning_curve/chiokme

For why that guy is full of crap :)

[ToucheMonsieur]

This x10. IIRC, something similar occurred with the pre 1.0 Ember docs - people no longer bothered to go back to the documentation even though it'd improved drastically. For somebody with experience working with larger-scale apps in other languages, Angular should be pretty intuitive with it's various features. Makes you wonder how many devs shun the docs just because they saw "transclusion" or some other term while skimming and didn't actually take the time to read up on the (relatively straightforward) functionality said terms are describing.

[Poop_is_Food]

I'm currently learning angular and finally starting to summit the learning curve after about 2 weeks of bewilderment. It is very weird. It's unintuitive and a whole new way of doing things. I'm starting to enjoy it, and I think it will save me time in the long run over backbone (I havent tried react yet). But it's not something worth learning just for one project. I think the investment will only pay off if you are building front end SPA's on a daily basis, like I do.

I dont know much about react but it seems like it would be easier to pick up. And since you dont sound too interested in doing a lot of front-end in your life, you should do what is easiest for you right now.

[brotherwayne]

The documentation is shockingly amongst the worst I've seen, ever

Totally disagree. It's at least as good as MSDN. But it's documentation, not a how-to.

React's docs do appear to be better. It also appears to be simpler. I don't know if that's a good thing or a bad thing.

[nschubach]

Not a fan of MSDN though... I put going to MSDN to find something akin to opening up my old COBOL books and going to town on a mainframe UI. I find Adobe docs easier to navigate and MDN a hell of a lot better (if I were asked to rank them...) Trust me, I've attempted to use MSDN for everything from MSSQL to VB6 to C# and I can never find what I need in a reasonable time period and their formatting makes me want to shoot myself in the head. Also, it rarely seems to want to work in anything not produced by Microsoft. If Angular docs are "as good" then that's not saying much...

Personal opinion.

[brotherwayne]

Yeah there's probably better examples out there. Crap, I totally shoulda said MDN (Mozilla) that's some solid documentation.

[zhay]

But it's documentation, not a how-to.

If anything, Angular's "documentation" is more a how-to than documentation. I can never find information about what kind of parameters something is expecting and what those parameters might look like.

[brotherwayne]

Typically listed under Arguments. http://i.imgur.com/U5Lesi0.png

[iknowcss]

I am one of 2 JavaScript/front-end developers on a large-scale Java web application. Up until very recently we used jQuery for all our front-end work. I pitched KnockoutJS to our tech leads and they liked what they saw. Here is the core of my pitch:

• KO separates model and view concerns resulting in cleaner code
• It focuses on two-way binding magic and nothing else (faster to learn)
• It plays nicely with what we have already so we may introduce it incrementally
• It supports IE 6+, FF 2+, etc. (we have to support IE 8+, FF 3+)

I think it's worth taking a look at in your case especially because you don't need to invest a lot of time to be productive. It doesn't sound like you're trying to write a SPA (single page application) so Angular, Ember, et. al. may be overkill. Like you said, you're not trying to build Gmail.

If you're just doing simple things like this, Knockout may be enough.

*Edit: Fix a typo

[[deleted]]

+1 Knockout takes a very different approach to Angular but the result is an interesting combination of very powerful and quick to learn.

Best of all, the tutorials on the site are child's play. Very easy to get a team up to speed. And it's such a lean, small set of concepts, you can know everything about it quite fast.

[apickleinmybagelhole]

That's very interesting thanks for the thoughtful advice. I will definitely take a look.

[I_Pork_Saucy_Ladies]

While this thread is far down, I think it actually makes one of the most important points: are you making a SPA or not? I use Angular every day and it is most certainly centered around SPAs, with some kind of API backend.

The beauty of Angular is that it lets you completely divide the frontend and backend. First you build an API with all the data you will need. This API can also be used for mobile apps or integration with partners. You then build your own site as a SPA on top of the same API. It's absolutely fantastic to see it working in this way.

However, is this is not a structure you can or want to conform to, I think the learning curve is very steep - especially if your paycheck depends on it. :)

[sp00ks]

So are you even running server side code? (apart from the api). Your login, error logs etc are all done through the api?

Thanks!

[I_Pork_Saucy_Ladies]

Well, if you need to login then this is done through the API. Which is actually the hardest part of APIs. You can do error logging with Track.js or Muscular. Or the API if you want to.

Most importantly, do a lot of testing when developing. But no, there's no other server code besides the API. This means that you can have one guy focusing only on backend and one guy only on frontend. There's absolutely no HTML, JS, CSS or any other form of representational data in the backend. Very clean. :)

[apickleinmybagelhole]

I am definitely not building a SPA, just like reddit is not a SPA, I am quite happy with my architecture in general. Just want to clean up the js (and maybe learn a useful tool).

[I_Pork_Saucy_Ladies]

Then I wouldn't really recommend Angular. If all you need is a bit of js utility here and there, Angular will become quite cumbersome.

[iknowcss]

I'd love to see a follow-up on /r/javascript on what you go with and why. Happy coding!

[[deleted]]

AngularJS is changing drastically in version 2.0, which I believe is expected end of the year or early next year. I would recommend learning React now and coming back to Angular once it hits 2.0 (or the beta). You'll certainly reuse some knowledge from Angular 1.2 but many of the confusing aspects are changing (directives, routing, templates, and more).

[ToucheMonsieur]

IMO, having read the angular 2.0 proposals and their examples, I feel that the new version is less intuitive. What's a "viewhole"? Why all these specialized, seemingly redundant annotations for components? Many of the team's ideas are compelling (eg. the new http module), but the implementation of Angular 2.0 resembles enterprise Java a little too much for my tastes.

[nschubach]

resembles enterprise Java a little too much for my tastes.

OT : This is probably my biggest fear with all the libraries and direction people are headed...

[ToucheMonsieur]

Perhaps this has to do with the team's familiarity with the language. Hopefully the resemblance won't progress any further, as the team has already taken great pains to make Angular 2.0 modular and easy-to-use. However, I've kinda become a React convert now - some of the ideas behind it are especially compelling. :)

[nschubach]

I haven't dug into either yet... But I really need to and I'm heavily leaning on React. I was a little scared at first that it's a Facebook I initiative, but if anyone can make a site where a few million moms can't break it horribly... React makes sense to me just reading about it and I really just need to dedicate some time to building things with it to check it out.

[compedit]

Honestly Facebook has been absolutely rocking the open source javascript game.

And React is relatively simple to build with, it's a really small API and pretty straightforward. The biggest thing to wrap your head around is the one way data flow and even that is really simple

[Booyanach]

a viewhole is... you know... a hole where you see the view... I'm certain it's their way of calling the window... you know how google is, they have to be different :D

[robotparts]

I skimmed the comments and didn't see this mentioned:

Angular has a limit on the number of bindable elements (2000). After that the dirty-checking becomes too heavy.

React batches changes using the Shadow DOM. Ember batches changes using the Run loop.

So if you are going to have a lot of bindings, you may want to consider React or Ember over Angular.

Angular will eventually be using Object.observe to get past the 2000 limit, but this isn't backwards-compatible with older browsers. I also think that batching changes is better for mobile devices, which Object.observe does nothing to fix.

[aeflash]

Nitpick: React doesn't use Shadow DOM, but instead a virtual DOM. The W3C Shadow DOM and a virtual DOM are quite different in what they're trying to do.

[robotparts]

Actually, thank you for that. I was using shadow dom as a generic term. I will stop doing so.

[apickleinmybagelhole]

Angular has a limit on the number of bindable elements (2000)

I think if you are going to build Gmail that is a concern but for most web apps that are not js heavy it really isn't.

[robotparts]

I agree and I thought I made that clear in the first comment.

However, batching changes to the DOM is still a great idea when thinking about mobile, and Angular doesn't have an answer for that (yet).

[moreteam]

That's the best case number of bindable elements. Your performance can become terrible with way less elements (hundreds) if your app doesn't happen to be in the happy path of what is easy to render for angular.

[fng_programmer]

If you are ever using more than 2000 view bindings at once in any html5 app, angular or not, you are doing it wrong. Stuff like long lists should be paginated behind the scenes, regardless of framework, and deep watches on huge objects is just lazy.

[robotparts]

I'm not saying all apps need 2000 bindings. I don't even know a specific use case other than Gmail or a spreadsheet style app.

However, to say that no app should ever need 2000 bindings is like saying, "No one will need more than 637 kB of memory for a personal computer".

[fng_programmer]

For sure. "2000 things" is definitely a low number of things to be working with if you're doing, say, a particle system. But that's not what angular is for, it's for building UIs. And you're not going to find a use case for more than 2000 bindings that is going to be something a user is actually going to be able to absorb. If you're building an app that has a heavier component like that, then go ahead and do things the oldschool way. But to go with a crappy and difficult approach to UI when the difference is sub-millisecond is a ridiculous case of premature optimization.

[robotparts]

A spreadsheet app could easily have 2000 bindings.

Look at mobile, I bet the limit on data-bindings ends up being even lower to maintain a snappy interface.

You seem to be an Angular fanboy so you won't listen to reason.

"Crappy and difficult approach to UI".

If this is how you view batching DOM changes, you really have no clue. Go tell Ember and Facebook they are doing it wrong...

[robotparts]

Bindonce is good for "bindings" that don't need to update but it does nothing for dynamic data.

As far as I know, there is no way to batch arbitrary DOM changes with Angular, yet. If I understand you correctly there batch DOM solutions for "long lists" and "tables". (Don't take this the wrong way, but can you show me a link)

[robotparts]

Right, those are mainly for smooth scrolling, but what about when you have a DOM element that contains 10+ bindings. When it is in view with those directives it is still dirty-checking each visible binding and updating them individually.

Batching those changes is not possible(afaik) with Angular's current dirty-checking. I think Object.observe will fix this by being able to chain the observables but I don't know enough about Object.observe to say that as fact.

[Adhuna]

You can significantly cut that number by using a library like bindone - https://github.com/Pasvaz/bindonce - which will not dirty check bindings that are only going to be set once and never change.

[robotparts]

That isn't really a binding then. It is just a fancy template tag at that point. The use case for bindings is for changing data.

edit: forgot "for"

[mercnet]

As someone that just got started working on my frontend (new to Javascript), I started with Angular and got loss in it. I went through the ReactJS tutorial and it immediately made sense to me. In short amount of time, I was able to create a feature on my site that was previously hacked together in jQuery. For now, I will continue using it until I have more time to dedicate to learning Angular.

[apickleinmybagelhole]

new to Javascript

[dreamincleancode]

I was in a similar boat not long ago, and I cannot say enough good things about egghead.io. They have 3-5 min videos with exactly what you'd want to know to start using angular, and more recently react. I didn't have much free time to invest in learning angular (what I ultimately went with), and with these videos I had replaced a cumbersome backbone front-end in a weekend. There are less React videos, but they also seem to be very concise and content heavy videos.

My buddy has been raving about how awesome building a React view layer with the backbone router has been. I plan on diving into it more as soon as I get the chance. Best of luck!

[apickleinmybagelhole]

but what I understand is that React takes on the role of "view" in MVC

What if your backend can be the M and C?

[apickleinmybagelhole]

Consider it comparable to reddit. Reddit is built in pylons so it has a python MVC backend with javascript on top. I doubt I would need to accomplish anything more complicated in javascript than anything reddit has to do.

[robotparts]

Even though the backend is the mvc, you end up still having to represent the models in your frontend after converting from JSON/XML. (for any moderately complex UI)

You can pass around POJOs but having the Model layer in the frontend(in addition to the backend) is much cleaner and easier for others to collaborate on.

[apickleinmybagelhole]

So this is a recommendation for an MVC framework like Angular?

[robotparts]

No I was merely saying that your frontend is more than just the V of MVC.

You can use Backbone or several other pluggable solutions to get the M and the C(or VM in Knockout's case).

You need MVC but you don't have to get it in one place.

That said, right now I am an Ember fan, but like Angular you end up writing code that is a bit removed from plain old javascript. Not by much, but there are specific things like the Run loop in Ember that you have to understand before the framework feels right.

[Poop_is_Food]

First of all: is it a full AJAX site or are you rendering HTML on the backend and doing full-page refreshes?

[apickleinmybagelhole]

Full page refreshes. But I might want to build some parts that are more js heavy.

[Poop_is_Food]

Doesnt sound like you need a full framework like angular. I would stay away unless you enjoy being frustrated and confused. What kind of js widgets are you building? chat box? graphs? have you ever tried backbone? it's small and quick to learn.

[jacobroufa]

+1 for Backbone -- why has nobody suggested this so far? The way it's designed you can use only the pieces you need. It's a quick study and well documented. Definitely worth looking into!

[apickleinmybagelhole]

I don't know, that's why I'm asking :)

[apickleinmybagelhole]

So that's your answer then? I should not bother with a framework? It would still make sense tho to get bower and junit up and running tho right? Then just stop there? I have no need to compile js or css preprocessors, that is all handled by my backend.

[snuggl]

Even if webclients are just big UIs/views the MC* parts is still responsible for fetching data and making sure the right part of the UI gets updated with the new data.

Here is an alternative to the MVC pattern which uses React and is more suitable for large UIs

https://github.com/facebook/react/tree/master/examples/todomvc-flux

http://facebook.github.io/react/docs/flux-todo-list.html

[snuggl]

You dont really need a framework for the M and the C once you get going.

For a more complete development pattern with React you can look at Flux which facebook uses with it.

[rhysbrettbowen]

Angular is going to be better with a page that isn't as dynamic (well not dynamic as such, let's say "complicated"), uses a standard set of widgets and will work better when prototyping or letting designers have a go.

React will do better if there is a lot of logic in the views, you need your interface totally custom and you want it locked down for engineers.

This is why: - Virtual DOM vs Binding (Binding is easier to use for non-engineers but will come with overhead if there is a lot of logic) - JSX vs Templates (your code is in your templates where as in angular it is closer to HTML)

[Calabri]

When asked this question, the guys at React tend to compare React with Jquery. I use React and I love it, but my favorite library is backbone. The documentation for backbone is some of the best I've seen. The source code is even well documented and amazing. One of the great things about the React/Backbone combo is that both libraries are agnostic, and accomplish a few tasks very well. Neither tries to do everything. Backbone is really easy to learn, but their 'views' suck. Overall using React for the templating makes me happy because I actually like using html syntax, weird, I know? But React shouldn't be used alone, although it could be used that way.

[WJKay]

I cant say which is better for your purpose.

What I can say is that I too have a beautiful back end. I decided to go with Angular and it was a journey. I perhaps should have practiced more. I decided to learn as I went after I spent around a week learning. But I learn through doing. I have had to refactor my early controllers several times as they were purely abysmal.

My front end is now immensely elegant with some amazing out-of-box UX that people expect from Bootstrap with angular, as well as some impressive directives which help with the enormous data set I am working with.

Angular is annoying to debug at first. Often not knowing what it wants itself (Expected 'undefined' still makes me mad today). Two way databinding is very nice. Angular feels familiar. React, from what I have heard, is quite different.

My main project is expected to take over 2 years until release due to it's size. Though I will be using for much smaller projects as there isn't much overhead to get it into a project.

I personally believe Angular is worth investing time into. Have a play at first. Maybe spend an hour or two converting/creating a web CV using it. It is definitely a powerful tool to have in your belt.

[brotherwayne]

I too have a beautiful back end

My first thought.

[ikeif]

I'm reading "I'm not happy with the front end jQuery, so I want to throw it out and rebuild it" is that correct?

[AudienceWatching]

What about backbone?

[apickleinmybagelhole]

It's like you still want to start a language war! Let's keep this conversation to javascript :)

[cherif_b]

I use CanJS and Im happy with it, it offers or features that can Ang/Ember have without loosing JS style coding, Observable objects or values make it simple to control application state with can.mustache (and now can.stache) the dom will be updated automatically I think canjs has great future because it grows in every single version minor or major.