Angular 2 (now the latest version of it is Angular 4) succeeded Angular 1 (now AngularJS) in late 2016. It was a complete re-write and tackled many (performance and other) issues AngularJS had. It embraces TypeScript, a superset to JavaScript, and is all about components and modularity. Angular is developed and maintained by a team at Google.

React.js is another extremely popular JavaScript framework. It was (and still is) developed by Facebook and therefore sees heavy usage on their website. A lot of other web pages use it, too, though. React.js apps are typically written with ES6 instead of ES5 and just like Angular, React apps are all about components.

Vue.js is the trending newcomer. It’s not backed by a big company but developed by a small team led by an ex-Googler. The framework combines concepts from both Angular and React.js - many developers agree that it kind of picks the best parts of both frameworks.

The first dimension is the “Ease of Learning” a framework. Of course you could argue that the quality of a framework is defined about how you build apps with it, how well these apps perform and how they scale. But if a framework is extremely hard to learn, there are not only going to be less developers using it (bad for the framework ecosystem) but also less developers mastering it.

Obviously, the learning curve does not only depend on the framework but also on the person. But there are some things which might make the learning process harder or easier for all (or at least most) people.

This dimension might not matter to you! But if you plan on creating a very big Single-Page-Application (SPA) it’s of course important to understand how well the framework performs, how fast it loads and if performance remains great in very big apps.

Why am I not talking about big fullstack apps here (= NOT Single-Page-Applications)? Because there, the individual “app” run by the framework doesn’t grow that big. It’s only one page of many pages in the end, right? Of course we’re back to this argument if a significant part of your otherwise fullstack app is a Single-Page-App (e.g. the user account backend).

Can you use a framework on the individual pages of a fullstack (or multi-page) app? That’s what “Downscaling” means. Can you just drop in an import and start using the framework? Is the framework then an overkill or can you really enhance your page with it?

This might be important as you’re not always creating Single-Page-Applications. Instead, you might run a significant amount of JavaScript code on the individual pages of your fullstack app (where the pages are rendered by your server-side).

Just as the “Upscaling/ SPA” dimension, this one might of course not be important to you if you’re not building these kind of apps.

Obviously, you want your applications to perform well. That includes having a fast initial loading time (small bundle size!) as well as great runtime performance (how fast does it update the page once it runs?). A framework which is super-fast at runtime but has a very big bundle size might not be the best choice for all kind of apps since it will load for ages when accessed via bad internet connections. Sometimes, this doesn’t matter though. Then, using such a framework might be perfectly fine!

You could also describe this dimension as “the way from development to production”. It might sound trivial, but actually it can be really hard to correctly deploy your finished app. If you miss possible optimization opportunities, this is going to impact your runtime performance without the framework being directly responsible for that.

On the other hand, it’s of course also kind of the framework’s fault if it’s overly complicated to get things right and to deploy an optimized app. That’s why we’ll have a look at this dimension, too.

That’s the last dimension I want to consider. How popular is a framework? This has influence on the ecosystem of that framework and therefore on the quantity and quality of third-party packages you may use together with it. It also affects the amount of support you’ll get on stackoverflow and other pages and how many learning resources you may find.

Job perspectives of course are also related to the popularity of a framework. But even a popular framework (amongst developers) could have bad job perspectives because the industry is not adopting it. If you’re only learning the framework for yourself or you already have a job, this aspect might of course not matter to you.

I came up with a possible learning curve comparison which reflects my opinion. Of course, these curves might not be correct for you. Maybe you found one aspect very easy to learn which I state to be harder. Maybe you struggled with something I found easier.
Angular arguably has the steepest learning curve since it requires you to learn a new language (TypeScript), really leaves everything you might’ve used before in JS development (components, modules), brings features like dependency injection and requires quite a bit of work to optimize your app and take advantage of features like lazy loading or ahead-of-time compilation.

React.js also has a pretty steep learning curve. Whilst it does use JavaScript, it uses ES6. Or at least that is the version which is strongly recommended to be used when developing React.js apps. If you do use ES6, you’ll need a workflow and development environment which allows you to write ES6 code and compile it to ES5 for deployment. This poses an additional challenge, especially for new developers.

It also introduces JSX, a syntax which mixes HTML and JavaScript. All these things kind of make sense once you got them but up to this point, it can be very confusing.

const element =(<div><h1>This is JSX</h1><p>Looks like HTML but is JavaScript in the end</p></div>)

Additionally, “everything is JavaScript”. JSX might look like HTML but it still is JavaScript. This means that the way you manipulate your “HTML” code can be hard to understand at the beginning. State management is another topic which can become problematic. Whilst that’s also partially true for Angular, unlike Angular, React.js doesn’t have any solution baked into it (Angular has services). At least optimizing your React.js app isn’t quite as complex as optimizing an Angular app though.

Vue.js is my clear winner here. It works fine with both ES5 and ES6 (theoretically, you can also get it to work with TypeScript) and it looks and feels like “normal JavaScript” when you start working with it. It separates the template from the JavaScript code, just as Angular does. By using components and directives, it’s easy and intuitive to then manipulate this template and output your data.

It gets a little bit more complicated once you start building more complex apps. Then, you’ll have to learn about workflows using .vue files, basically files which make the creation of components easier in the end. You’ll also have to understand how to create components, connect them to each other and, of course, how to manage application state. With Vuex, it offers an official library which makes that much easier though.

Overall, Vue.js has the easiest (“best”) learning curve in my opinion. That doesn’t make Angular or React.js bad frameworks, in fact I love Angular! But for getting started, Vue.js certainly is the easiest.

All three frameworks allow you to create powerful Single-Page-Applications, that’s the first important takeaway since this kind of web app is very popular and rapidly growing in usage. But are all frameworks equally suited for this kind of app?

Angular focuses entirely on Single-Page-Applications, this is what it was built for. It gives you a lot of tools to build (extremely) large Single-Page-Applications and it’s clearly the focus of this framework. Google is using it internally to rebuild apps like Adwords and Adsense to use Angular.

The modularity, TypeScript, the concept of services, out-of-the-box routing and forms support as well as detailed optimizations options allow you to build well-performing, big Single-Page-Applications. Therefore, Angular can probably be called the winner in this category. It doesn’t mean that React.js and Vue.js are not suited for this kind of application though!

React.js doesn’t have a Single-Page-Application focus as Angular does. But it certainly is capable of hosting big Single-Page-Apps. Facebook uses React.js on its SPA parts of the webpage (e.g. the advertisement console) and there are many other web apps using it out there. You will need third-party packages though, React.js doesn’t come with a router or forms package built into it like Angular does.

Vue.js is pretty similar to React.js. You can absolutely create big SPAs with it but it’s not focused on this type of application. Just like React, Vue requires you to install extra routing or form validation packages, though at least the routing package (just like Vuex for state management) is provided by the official Vue.js team.

Angular probably makes the creation of very big SPAs easiest but React.js and Vue.js are perfectly valid choices, too. Especially for bigger apps, you might encounter some challenges when using React.js or Vue.js which you might not hit when using Angular. Examples would be the organization of your project files or the availability and maintenance of important packages for routing or forms support.

We had a look at how well the frameworks are suited for the creation of Single-Page-Applications. How do they compare when it comes to Multi-Page-Applications (MPAs; fullstack apps)?

Angular just isn’t made for these type of apps, it’s as simple as that. Yes, you could theoretically import the framework packages into your HTML code but that would be very cumbersome and you still wouldn’t be able to really use them as intended. Instead, Angular really embraces TypeScript and trying to use the JS packages (to which the framework in the end of course is compiled) and your own JavaScript code will become a nightware. You could install packages which compile TypeScript on-the-fly but that will be a bad idea since it impacts performance.

React.js may absolutely be used to simply enhance existing HTML pages (views rendered by your backend). Indeed, that’s how Facebook itself uses React.js a lot. Pretty much every page you visit on Facebook uses React.js to a certain extent. You can easily import React and then use it to change parts of your web page, dump in some components and therefore add powerful features driven by JavaScript.

Again, Vue.js is pretty similar to React.js. You can easily import the Vue.js library (like React it’s very lightweight, too!) and start using Vue.js features on your page. You are able to quickly “control” a part of your DOM via Vue.js and start adding nice JavaScript-driven features to it. Of course you can also use advanced concepts like components and quickly add these.

Overall, React.js and Vue.js are both great for enhancing existing views in your fullstack (MPA) application. Vue.js is even a bit better than React in my opinion since it doesn’t force you to use components at all. React.js pretty much does do that.

Of course your web app should load fast (small bundle size, quick startup time) and perform well once it runs (e.g. updating of the DOM). Depending on the type of users you’re going to serve, the startup time might be less important. For example, you might know that only people with good internet connections are accessing your app. In most cases though, you’ll probably want both parts (startup time + runtime performance) to be good.

I could write a lot here but why don’t we just have a look at the numbers? I’m using this JavaScript framework benchmark project on Github. You can find installation instructions on the Github page. I also want to thank the all the contributors of this amazing project at this point! You can of course run the benchmark on your local machine, the key test results can also be found in the following table though.

One important note about this benchmark: It only tests what it tests. This is no super-big application. It’s also not a super-small one. Some frameworks may outperform others for very big apps even though they lose to them in smaller apps. The bundle size refers to the non-gzipped package size of the script file for a very basic project (using Angular CLI, create-react-app and Vue CLI starter projects).

Framework

Size (kb)

Avg. Time for Tests (ms)

Angular 4

391

327

React.js

156

318

Vue.js

73

270

Although being slower than the other two, Angular is a fast framework but it also has a rather big bundle size. This size can be improved a lot but it’s not that easy to get there. This bears the danger of having a non-optimized and therefore too big bundle being shipped to your deployment server. The runtime performance is great. Important: Angular’s performance will be better (compared to React.js or Vue.js) for much bigger and more demanding apps! It’s simply not built for smaller ones and even on mediocre ones (size-wise) it might lose to React or Vue. We’re not talking about seconds of differences though.

React.js is a bit faster than Angular 4 (in this benchmark, can’t stress it enough!) and it also has a significantly smaller bundle size.

Vue.js offers a great performance as the table clearly shows. It has an extremely small bundle size, too. Is it the clear winner then? Well, that depends. For one, as already mentioned, it’s not like it’s 5 seconds faster than the other two frameworks. Additionally, the picture might change for way bigger apps or apps focusing on specific tasks. There might be certain aspects which can be very important in your app, where Vue.js might be slower than the other frameworks. That’s hard to test though.

So is the answer “There is no winner, the results don’t matter”? No! Telling by the table, we got a clear winner. Vue.js. But it is important to put these results into perspective. Even if one framework is faster than the other, the slower framework isn’t automatically bad. All three frameworks have pretty good performance after all! You shouldn’t pick your framework by performance only. You might exclude one if it performs badly but that isn’t the case here. You should also keep in mind that the size and type of applications impacts the performance, therefore the linked benchmark is only one (and not the only one!) way of testing performance.

Why does the “Ease of Deployment” matter? Because you of course want to deploy your app in the end and if you can make a lot of mistakes while doing so, or if it’s overly complicated to optimize your app, you might ship bad and possibly unoptimized code to your server. No one likes that!

Angular makes the move from development to deployment the hardest. Well, kind of. If you’re using the Angular CLI, it’s going to be easier and a lot of the work is done for you. Actually, when using the CLI, the road from development to deployment becomes very easy. But still, writing a “good” Angular application, taking advantage of lazy loading and the module system and correctly using Ahead-of-Time compilation (AoT) can be challenging.

React.js offers an easier way of moving from development to deployment, though you still need a workflow which optimizes your app. Just as with the Angular CLI, example setups can be found online. The lazy loading of components is possible. Since everything is JavaScript in a React.js app, you don’t need to care about compiling and optimizing any templates though. You have no HTML templates after all!

Vue.js also makes the deployment of your app easy. You either just dropped an import into your app, in which case you can’t optimize a lot anyways. Or you have a more complex local setup (potentially created with the Vue CLI) which again will handle most of the code optimizations for you. You may use lazy loading of components and, since Vue.js does use templates, you can pre-compile these templates. That offline-compilation step is much easier than it is with Angular though (although, when using the Angular CLI, it’s super-easy, too).

Overall, Vue.js and React.js are probably the easier two frameworks of these three when it comes to the road from development to deployment. Angular gives you a lot of tweaking possibilities. This can also be an advantage but it also poses the threat of shipping suboptimal code.

Even if you personally love a framework, the popularity amongst other developers as well as the job market for that framework might matter to you. The popularity influences the number and quality of third-party packages built for a framework (e.g. for form validation). And the job market obviously is a very important point if you’re looking for a job.

I’ll use Github stars + contributors to measure the popularity amongst developers and posted jobs on indeed.com to compare job perspectives. Of course there are way more places to find a job but it’s about the relative comparison not the absolute numbers! All data mentioned below was fetched & analyzed on May 17th 2017!

Framework

Github Stars

Contributors

Posted Jobs

AngularJS

55.8k

1,596

12.7k

Angular

24.1k

441

940

React.js

66.9k

1,001

42k

Vue.js

53.7k

104

1,075

Angular is very popular. Angular 1 (now AngularJS) reaches 55.8k Github stars and 1,596 contributors, indicating a very active community. If we have a look at the job market, we’ll see that as of May 17th 2017, 12.7k jobs with “angularjs”, “angular.js” or “angular 1” were listed on indeed.com.

That was Angular 1. What about Angular 2/4? The official Github repo shows us 24.1k stars and 441 contributors. Not too bad but certainly a lot worse than Angular 1. But of course Angular 2 was only finally released at the end of 2016 whereas Angular 1 sticks around since 2010. If we have a look at the job market (keywords “angular 2”, “angular 4”, “angular.js 2”, “angular.js 4”) we can find 940 open job listings, certainly a decent number if we consider the age of Angular 2. Additionally, job perspectives are pretty much guaranteed to improve due to the very popular first part of Angular. Let’s have a look at its competitors then.

React.js has the astonishing amount of 66.9k Github stars and 1,001 contributors. That again is a very active community, something which is reflected in the quantity and quality of available third-party packages. If we turn our heads towards the job market (“react.js”, “react”, “reactjs”), we can find 42k active job listings as of May 17th 2017. Wow! That certainly is a lot! It is, React.js of course is way older than Angular 2 and 4 though. But still, React.js is extremely popular amongst employers!

Let’s have a look at Vue.js then. Having a look at its official Github repository, we can clearly see that developers are loving it! And indeed, even though Vue.js 2 is relatively new (released in fall 2016), there are loads of actively developed third-party packages to be found on npm. The job market (“vue.js”, “vuejs”, “vue”) doesn’t look that bright though. Compared to Angular (Angular 1 + Angular 2/4) and React, there are way less job listings. Whilst the developer community absolutely loves Vue, the industry hasn’t adopted it for the most part. That may change though, especially Asian companies like Alibaba are using it more and more and I’m confident we’ll see improved job perspectives in the future. For the moment it is what it is though.

Overall, React.js offers the best job perspectives as of now (if we leave out Angular 1!). It’s also extremely popular. Popularity is pretty awesome for Vue.js, too. And Angular has it’s famous first part. It really comes down to what you’re looking for. Are you looking for a job right now or in the near future? You’ll have to think carefully about taking Vue.js and even Angular then. React.js might be your safest bet. It’s probable that both Angular and Vue.js offer great job perspectives in the future though.

Do job perspectives not matter to you but a vibrant and active community is important? Again, React.js might be a good choice but Vue.js certainly is very attractive, too. And don’t underestimate Angular, it’s far from being “not popular”!

So what’s the verdict, which framework should you choose? Of course that depends. Carefully go through the compared dimensions and decide for yourself how to weight them. There is no single best or worst framework out of the mentioned three. Actually, all three are pretty awesome and you can’t make a bad choice here.

Don’t forget to also take other dimensions which matter to you into account. It is important how much you like the concept a certain framework implies on you. If you don’t like the style of a framework, you probably won’t be a good developer using it. Maybe I didn’t list some other dimension which might be most important to you!

I do hope that this article gives you some ideas about how you may compare frameworks and about how you may choose one!