React or AngularJS?


React shines when you have lots of dynamic content changing within the view. Most client-side solutions on the web today struggle with rendering large lists of items within a single view. This “struggle” may be on the order of milliseconds, but in this increasingly digital world, a half a second delay is all it takes to kill your user experience. It’s why sites that have a lot of dynamic, constantly changing, data-intensive content like Instagram or Facebook choose to power their applications with React.

As a library, you can also use React as the view component of AngularJS or other frameworks, because it does not tie you to a specific technology stack. That said, there’s a quickly growing community and a number of existing libraries and add-ons that can help you build an app from scratch. 


Development time is at a premium, and you need a full, comprehensive framework that will get you running quickly out of the box. As we mentioned earlier, comparing a library to a framework isn’t really a valid question, as you can always use one with the other.

The real question to ask is when shouldn’t you use React? React is not backwards compatible with browsers older than IE8. Also, the community is young, so it’s possible you’ll have to do a lot of “reinventing of the wheel” in order to get the specific features you’re looking for. It’s also up for debate whether or not installing React is worth the trouble if your project is either a simple webpage or if AngularJS is already more than capable of rendering your view.

With the recent releases of Angular, Angular devotees have another reason to stick with their framework of choice. Angular shipped with a huge performance boost, including support for server-side rendering and a similar approach to using one-way data binding to only manipulate the parts of the DOM that need to be changed. However, Angular also involved a major rewrite of the framework, so whether you choose to install React or upgrade to the next generation of Angular, there’s still going to be a learning curve to overcome.

Roadmap of AngularJS


Some of the features that Angular is looking to roll out in upcoming releases include:

Typescript compatibility

The Typescript team has been working on a number of improvements including:

Creating smarter compilers which handle errors better and give better error messages.
Implementing strictNullChecks to provide extra type safety
This means the Angular compiler (ngc) will be faster since they will be taking advantage of the optimizations of Typescript

Backwards compatibility with Angular v2

It will be able to successfully use interfaces and data from applications made with Angular v2

Better Angular compiler errors

The compiler will be much smarter in terms of error handling


The ngc will be faster in terms of runtime speed and parse time. It will also be smaller

They are more productive this way and can get more stuff done
out in upcoming releases include:



AngularJS with or without ASP.NET MVC

If you’re building a single page application (SPA), then you probably don’t need the “MVC” in ASP.NET MVC. Views, especially dynamic views, are likely delivered/manipulated client-side. Angular handles that just fine.

But maybe you don’t want a complete SPA. Then what? Imagine instead 10 pages, but 10 pages that are very dynamic. After a user logs on, there’s a little user’s info up in the right-hand corner. It just shows a few things like the user’s “points”. You cache it  so they can be easily retrieved. Now, you can go two ways with this. If you’re a client-side MVC purist, you just fetch the badge data after the initial HTML payload is delivered, just like all the other data. But maybe you’re not a purist. Maybe you’re the opposite of a purist. So, instead of delivering the initial HTML, delivering some JavaScript that will post back to your server, post via JavaScript to grab user’s info data, and then ultimately merge that data into a view via client-side MVC, you simply decide to merge the data already in your cache into a view on the server and then deliver that as your initial HTML. After your initial HTML is delivered, you proceed with your typical client-side MVC code.

MVC on the server and on the client is just a convenient way to organize code. The more you do after that initial HTML is delivered, the less you need server-side MVC and no matter how you deploy Angular, you’re going to need a way to deliver that initial HTML, the templates, and most importantly the data. You can make the initial HTML and external Angular templates the result of an MVC action, but better yet, you can use .NET’S Web API to deliver the data. 


Copyright © All Rights Reserved - C# Learners