Which JavaScript framework should I choose in the Enterprise?

July 16, 2017

There are various reasons that modern application developers should be using JavaScript frameworks when developing new applications. The modern browser has become almost a complete application hosting environment runtime. The added responsiveness, the performance, the ability to easily asynchronously request and manipulate data, to build different parts of your page progressively and independently, are only some of the benefits. If you’re going to choose to build an application in the browser, you need structure, you need to deliver features quickly, you need them to perform and you need to provide consistency.

JavaScript alone does not provide this. JavaScript doesn’t provide structure, it doesn’t provide custom UI elements, it doesn’t provide data binding or animations and it doesn’t provide a network communication framework. Everything in JavaScript is done with add-ons, and the time taken to build your own libraries can be prohibitive and a hindrance to actually delivering your own custom application logic.

Even Gartner says that you should be using a JavaScript framework. Gartner’s Research Director Bradley Daley says that 40% of companies are now using JavaScript frameworks heavily in their projects.

But we need to be careful here. It’s very easy to be swept up in hype. It seems to be a systemic problem in the industry that we have a tendency to jump into new technological choices far too quickly. Don’t be swayed or swept up by the hype.

But there are so many JavaScript frameworks! So which framework should you choose, and what are the criteria you should be looking at?

When selecting a JavaScript framework for the Enterprise, there are a number of factors you really need to consider. These include:

1)     Adoption – Does it have the backing of industry leaders? Who is behind it? Who is using it? How many production deployments are there? Is there community and developer support? Are there many jobs for it? Can I get the developers I need?

2)     Opinionated – does it provide you with a ready-made framework where most of the basic structural problems already have solutions, or do you need to put those solutions together yourself?

3)     Learning curve – How hard is it to learn and is it worth the effort to do so?

4)     Future proof – will this framework be around for a while? Is it using web standards and does it have a path towards future web standards? Is there a roadmap for supporting future web standards?

5)     Feature richness – Can I build awesome sites with it?

6)     Productivity – How easy is it to add features? How easy is it to maintain?

7)     Testable – is there a strategy for testing the application components?

8)     Size – does the framework contain a lot of large files? Is it slow to download? Is it heavy?

9)     Performance – does the framework introduce impediments to performance?

10)  Browser support – does the framework support many browsers including older versions?

11)  Licensing – are there any gotchas?


There are only a few JavaScript frameworks that have made it really big. The two biggest are Angular and React. Angular is backed by Google, while React is backed by Facebook. Angular version 1 (AngularJS) was one of the most widespread technologies in use for an exceptionally long time. In fact, the earliest issue on the AngularJS wiki was raised in 2011 and its adoption was about 5 times bigger than React at the time it was deprecated. At the time of writing, Angular version 1 had 56,400 stars on GitHub. That’s a popular base.

But you wouldn’t start a new project in Angular version 1. There is virtually no one recommending people take that path. Bradley Dayley from Gartner certainly doesn’t recommend it, saying “Angular 2 is a much better option than Angular 1” and “Angular 2 is still one of the better frameworks out there”. Rob Eisenberg from Aurelia (and now Microsoft) doesn’t recommend it. Angular 1 has structural problems that cannot be discounted. If you’re on Angular 1, you really need to move forward. Jeremy Likeness, Director of Application Development at iVision made the comment “There will continue to be a long tail for Angular 1 apps, but there is a clear path to Angular 2 and I see people taking that path.”

Angular version 2 (now known as the singular “Angular” and currently at version 4) is a complete rewrite of Angular version 1. It was given the same significant support that Angular 1 was given. Google has backed it all the way, and, in fact, they have completely rewritten Google AdWords with it. That’s over a million lines of code. Angular 2 was started in 2015, and it now has 25,900 stars on GitHub.

React, on the other hand, has grown significantly. React is used by Facebook on Facebook. It currently has 71,033 stars on GitHub and has been around since 2013. Up until the Angular 1 rewrite was announced, it was making reasonable progress, but after the Angular 1 announcement, its popularity shot up as it was the main beneficiary of the doubts around Angular. People say you can’t compare the two, but that’s rubbish. The reality is that you can compare the two, because to use React you will pull in a Router, a Flux implementation, and various libraries. You will build a framework to provide the same functionality that you get from Angular. React probably has the strongest developer advocacy of any of the JavaScript frameworks.

Then, of course, there are other libraries. Backbone and Knockout are on the way out. Aurelia just hasn’t got the take-up, although it certainly has the support of its developers. Polymer is just meh at the moment. Meteor is a bit too rigid and doesn’t have the take-up.

Probably the biggest contender at the moment is VueJs. It’s new and the fastest growing of all the frameworks. It has 60,100 stars on GitHub already, and it’s only been around since 2015. It’s just like React, though, and will require you to put together a whole framework.

In terms of trends, in the last month, Angular 2 has grown by 1016 stars, React has grown by 2,495 stars, but Vue has grown by a staggering 3,546 stars!

For now, though, in the Enterprise, I’d probably say no to VueJs, but it’s certainly worth keeping an eye on and revisit in a year or so.

Because of these factors, in this article, I will focus on the two biggest players in the space, React and Angular.


Probably the biggest argument for and against the frameworks is whether or not they are opinionated. An opinionated framework is prescriptive; It is one where the majority of the structural/infrastructure decisions have been made for you. That is, it provides prebuilt boilerplate code that forces you to structure your code in a particular way. And because a lot of those decisions have been made for you, you can get on and focus on your own custom code, rather than having to work on building up the framework, spending a ridiculous amount of time building the infrastructure before you even get to write your first line of business-related custom application code. Sure, it might be a technically brilliant solution, but apart from some nerd points, who really cares?

Angular 2 is an opinionated framework. Out of the box, you have pretty much everything you need to build an Enterprise application. React, on the other hand, has so few strong opinions. To build something Enterprise ready requires a significant number of decisions. You need to build a foundation. These days, React provides a Router (it never used to) and you need to select one of the 20+ variations of Flux, but you should probably choose the most popular, being Redux. You’ll also need to select an interaction library to get you data from an external repository, something like Thunk. In fact, I would say that React, to me, requires a dog’s breakfast of technologies just to get a foundation up and running. And with putting together such a mix of new technologies, some will be more mature than others, and many are not actually supported by FaceBook.

So of course, it can be done, and many people are doing it. Between the time when Angular 1 was deprecated and Angular 2 was just getting off the ground, that’s what people were doing, as they didn’t really have another choice, and people were quite angry at what was happening to Angular.

If you’re going down the path of React, I would recommend going with all the most popular versions of the React tech stack. Here I recommend that you do a Pluralsight course and put together a framework based on what you learn from that, and build on that learning.

So, in the case of choosing a JavaScript Framework that has everything you need to build an Enterprise application, with all the modules supported, I would have to say Angular 2 wins hands down.

Learning curve

JavaScript frameworks are not the easiest to learn. Both Angular and React require a significant amount of time to get to an intermediate level, which would allow you to build an Enterprise application. I know there are people out there that claim it will take them a few minutes to get going with React and take far longer to learn Angular, but they’re not really talking about learning the full framework. With React, they are usually just talking about how quick they can learn how to use the view layer.

If you want to do something significant and Enterprise ready, my advice is to immerse yourself in a Pluralsight course. Make your entire team do it.

To give you an example of how long it takes to realistically learn Angular vs React, I suggest that you would need to do both a Beginner and an Intermediate course.

Doing John Papa’s Angular: First Look Beginner’s course takes 4.5 hours. Following up with Joe Eames Angular Fundamentals Intermediate course will take a further 10 hours. That’s a 14.5-hour investment.

Doing Cory House’s Building Applications with React and Flux Beginner’s course will take around 5 hours. Following up with Cory House’s Building Applications with React and Redux in ES6 Intermediate course will take a further 6.25 hrs. That’s 11.25 hours.

So, when people tell you React is easier to learn than Angular, my response to them is, not in the Enterprise it’s not! There’s not that much difference between 11.25 hours and 14.5 hours. If you are learning these frameworks from scratch, the investment in these courses is well worth it. You will get significant productivity benefits in doing this from day one. One gotcha here though – to learn a 10-hour course does not take 10 hours. It takes significantly longer to learn and absorb everything from one of those courses. When I started doing those courses, I found it could sometimes take me a whole day to get through one hour of course!

Future proof

We are now past the Angular 1 to 2 hiccup, and both Angular 2 and React will be around for a long time. Here, you need to ask how much each of these frameworks is oriented towards future web standards. In the case of Angular, it is closer to the web standard. React, on the other hand, diverges from web standards and patterns, and that is risky. That’s because they do their own virtual DOM code compilation, which is seen as a benefit in the case of React. Some people say that it would make it more difficult to move away from that towards a different framework that conforms better with the standard, but let’s be serious here, no one ever changes once they’ve decided on the framework until they are ready to completely rebuild the application, and an application’s lifetime is around 5 years, so it won’t be happening for some time.


I have written apps in React and Angular and I have yet to form an opinion on this one. I rewrote an entire C# MVC web app in Angular 2 recently, it took me 2 weeks (just about killed me), but I was able to do it efficiently, and once the patterns were in place, it was pretty easy to cut and paste, and add features.

Also, I am actually more impressed with the separation of html from code, which Angular provides. Because of the way React works, the code and the html are all in one file. They say this is a good thing, but I believe that keeping the UI as separate as possible from the code is better, especially if you have designers on the team, who might want to modify the layout of the html while you are still coding the component.

React does win in one area here – catching more errors at compile time. Because the code and html is represented in the one file, it can detect errors in your html at compile time. Errors found earlier in the development process are cheaper to fix.

Angular also loses some marks here because of it’s ridiculously quirky attributes. Check out some of its ridiculously confusing syntax: *ngFor, [(ngModel)], [model], {{model}}, (click), [hidden], *ngIf, [class.selected]. With a decision process that thought they were acceptable, you certainly understand why Rob Eisenberg ran a mile from those guys and wrote Aurelia!

Feature richness

Both Angular and React are feature rich and there is support for a massive number of add-ons for both environments.


I found it exceptionally hard to verify the claims that React is significantly smaller than Angular. Anton Vynogradenko produced a site that showed some stats obtained from a CDN for various JavaScript framework configurations. They showed that Angular 2 minimised would take 566K out of the box, whereas React with React DOM, Redux and React Router is around 191K. That’s a significant difference, and React would win hands down.

Here’s a link to Anton’s page: https://gist.github.com/Restuta/cda69e50a853aa64912d

The issue with size comes back to how long it takes to transfer the file, and for a large site with significant traffic, it would probably affect data cost as well.

Unfortunately, the stats haven’t been kept up to date, and there is no CDN provided for Angular 2 version 4. Given that Angular 4 was an optimisation release, it would surprise me considerably if the difference was still that great. Without further investigation, I can only form the opinion that React is probably about 1/3rd of the file size. In a corporate environment, it probably wouldn’t matter much, as you’d just wait the extra second for the page to load, put on a significant public site you might want to investigate this more thoroughly.

Edit: I have since learnt about Tree Shaking and Ahead of Time compilation (AOT) in Angular. In tree shaking, webpack strips out any code or files that are not actually being used in your application. If you have a look at the humongous node_modules folder, it could contain hundreds of megabytes of code and content. There’s no way all those files would be delivered to the browser, it just isn’t viable. Tree shaking reduces the code base significantly. Secondly, AOT is used when delivering your production bundle. It precompiles all the code and because of this, it does not need to actually deliver the Angular compiler files to the browser. Compilation happens pre-delivery.


It’s hard to judge performance when all you’ve got to go on is other people’s potentially biased and vested opinions. I don’t need to give you too much of my own opinion here, other than to suggest that you take a look at Stefan Krause’s JavaScript Framework Benchmark site. This site contains a whole lot of benchmark tests for a wide array of JavaScript Frameworks, and he provides a calculated score (slowdown geometric mean) for framework speed. The benchmark was up to Round 6 at time of writing.

According to that site, Angular 2 (version 4) gets a speed score of 1.31 at its most efficient, and React with Redux gets a score of 1.41 at its most efficient. Certainly not enough to make a decision one way or the other.

In terms of memory performance, Angular 2 (version 4) and React (with Redux) are also very close. After adding 1000 rows, Angular 2 (v4) uses around 10.88 MB, while React with Redux uses 10.76 MB

Stefan’s site is here: http://www.stefankrause.net/js-frameworks-benchmark6/webdriver-ts/table.html

Browser support

Both Angular 2 and React take advantage of polyfills. Polyfills are JavaScript libraries that provide backward compatibility with older browsers. But seriously, any organisation that is still on IE9 really should have its head checked. Either way, transpilers these days are exceptional and you should be able to find a solution to produce what you need for either Angular or React.


I don’t really see much difference in the time taken to maintain React or Angular 2. Both environments are similarly componentised, so shouldn’t be a problem to maintain.


Both Angular 2 and React have a similar testing setup. I don’t see much difference here.


Angular 2 is released under the MIT licence. You can use it pretty much however you like. You can modify it. You can on-sell it.

React is released under a modified BSD licence. The “FaceBook” licence. There is an odd clause in the FaceBook licence. Basically, there’s a non-compete clause in there. I don’t want to interpret it for you, but you should take a look yourself if you think you might have an issue. Here is the text:

“The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software.”

Hiring people

When hiring people, you want them to be able to hit the ground running. If you are using Angular 2, and you hire a trained Angular 2 person, you would expect that they would already know the complete tech stack, and anything else is a bonus. When hiring React people, its a lot more complicated because there’s no consistent framework and so even if you hire a trained React person, there’s no guarantee that they will know the various libraries that were chosen in your environment.

Hot module replacement

Both React and Angular enable Hot Module Replacement. What this means is that you can be coding in your IDE, and the moment you hit save, behind the scenes it will detect that the code has changed, recompile it, and update the browser. In most cases, you won’t need to actually restart your browser, it does an in-place replacement. Out of the box, if you change something in an Angular application, the code is changed and the browser is updated, but it resets the state. Say you have a counter label on a page with an increment button. You click the button and the counter increases, 0, 1, 2, 3. Then you change the code on that page to double the increment each time, and hit save. The page will be updated and the counter will be reset back to zero. That’s how it works in Angular. Under React with Redux, the counter does not actually get reset, it just continues on where you left off! But Angular people need not despair; you can add Redux to your applications and achieve the same thing, just not out of the box. (Note, I haven’t actually achieved this myself but intend to soon.)


There are a whole lot of reasons why you might choose one of these frameworks over the other, and I hope I have provided you with a few more issues to consider. If your application is small, or you want a more traditional application with only a JavaScript-based view, you might straight away choose React, or even Vue. In small applications, it probably doesn’t really matter.

If you’re building a large application and you have a highly sophisticated team that enjoys investigating and evaluating new technologies, are happy to make the specialised decisions and put in the hard work required to build a foundation, and you’re not worried about the patent clause, then by all means, go with React. But if you’re writing a large application and you need the enforced structure out of the box, I would recommend that you go with Angular.