Does Angular remain king, or will one of the others take its place on the throne?
The main reason for Angular's popularity is that it's quite easy to create a robust single page app. Various modules can contain various assets, like controllers, services, factories etc. and the 'separation of concerns' principle is applied to great effect, i.e. when using directives to create custom components.
As such, Angular has proven to be a refreshing alternative to other frameworks from the 'jQuery era', which didn't advocate a clean division between logic (JS), representation (HTML DOM) and layout (CSS). The simplicity of doing two-way data binding is another big advantage of the framework. But all that glitters is not gold.
For starters, getting to know Angular may take some time. It's extremely solid once you know how to use it properly, but you're facing a steep learning curve to get to that level.
Secondly, you may run into performance issues because of a high number of watches, filters, a complex DOM structure and so on. Larger applications are of course more susceptible to these performance issues. The Angular team made some modifications to address these issues in recent versions, but it still isn't smooth sailing throughout.
And then there's the confusion that may be caused by the addition of new concepts such as one-time data binding, controllerAs and bindToController next to older concepts like $scope that have been kept alive for backwards compatibility purposes.
Angular was initially released in 2009. Six years is an eternity, especially in the front-end world, and the lack of a thorough update began to show. Whereas Angular was quite progressive upon release, many of its concepts have since become part of the HTML5 standard. For example, it is now possible to create pure HTML5 custom (web) components, there's the concept of shadow DOM that limits your DOM size and you can do two-way data binding using Object.observe.
Using modules isn't something new either; they're now also available in the new EcmaScript standard (ES6, Harmony, ES2015 or whatever you want to call it).
If HTML5 and ES6 are all that jazz, do we still need a framework that seamlessly 'glues' together all of the spare parts?
Spoiler alert: the answer is yes, because besides creating amazing applications, developers also should enjoy the creation process instead of simply glueing different pieces together manually. It's important though that the framework isn't stubborn or restrictive.
The new version of Angular has thrown many of the first version's concepts overboard and starts with a clean slate. Bye-bye backwards compatibility.
This sounds like a big disadvantage, but there are positives to it as well. Starting from scratch allowed the AngularJS team to do away with many of the extra features and hacks that had crept into the Angular 1 source code.
Confusing and complex syntax and concepts are a thing of the past. The framework is also future-proof because it relies on HTML5 standards and because it uses Typescript and ES6 (you can opt out from using these two, but I wouldn't recommend doing so).
Granted, you'll need a while to adapt to the specific syntax, but there are many advantages to it, although everything could've been made even simpler and with less boilerplate code.
Originally, the Angular team wanted to release yet another language, AtScript, based on TypeScript by adding annotations to it. Luckily, now you can just use plain TypeScript as it now supports annotations as well. However, to use custom Angular 2 annotations, additional code is needed since these annotations must be 'manually transpiled' by the developer.
The fact that general controllers have been taken out in favor of Components also takes some time getting used to. Components now only talk to each other directly, fully in line with the web-components philosophy. That's a plus.
We already knew the basics of this method (because of the 'require' property of a directive for example), but now we no longer need to know what the relationship is between Component X and Component Y in the DOM. Angular 2 will find the directives for you.
From Angular 1.5 onwards, an upgrade path to v2 will be included, but that doesn't mean you should expect to see many existing web apps be converted from Angular 1 to Angular 2. That decision will largely be made on new projects.
All in all, I'm cautiously optimistic about Angular 2, though I'm keeping my final verdict until the release of the first stable version. Since it's still in development, a lot of breaking changes are introduced on every update and the available documentation is rather limited, it's best to hold off on using v2 in your projects.
React is a lightweight framework developed by Facebook that focuses a great deal on performance. A good move, because performance is still a sore spot of Angular 2.
There's also no way you can compare React to Angular because the latter is a much more complete framework that offers solutions for Models, Views and Controllers. React on the other hand is a lightweight library that only focuses on the 'View' part and performance. Plus, it presupposes you combine it with other libraries such as JQuery. There are, however, several extra React libraries available that address other parts of the MVC approach, such as react-router.
A clear advantage of React's lightweight approach is the ability to choose which module type you use (AMD, CommonJS, ES6) whereas Angular largely makes this decision in your stead.
React is also closer to standard JS than Angular and the learning curve is a lot less steep. It's much easier to replace too, but if you want to test your code you need to use a program like Jest, a layer on top of Jasmine. In that sense, React is not so easy to shake loose from.
Using Node, you can use React directly on the server, allowing you to follow the hybrid (isomorphic JS) approach that offers solutions for performance and SEO.
React makes use of a lightweight implementation of DOM and event system. This increases performance and manipulating the in-memory representation of the DOM is way faster than manipulating the real DOM. Their event system implements all events in a cross browser way, including bubbling. So you can even get some HTML5 events in IE8.
React's one-way reactive data flow (a.k.a. Flux architecture) is supposedly easier than traditional data binding and uses a functional programming style, which results in increased performance. Angular v1's dirty checking is a lot less performant because of the time it takes to compare states. But it does work out of the box. Dirty checking is a thing of the past in Angular 2 as it uses Object.observe(). Both approaches have their pros and cons.
Aurelia is a framework that has a lot in common with Angular 2. That's because it's being developed by Rob Eisenberg, the man behind Durandal. Durandal's a framework very much in line with Angular 1, but a lot less popular and for that reason no longer actively maintained. Eisenberg was also part of the team behind Angular 2 before certain decisions made on the project made him jump ship.
With this in mind, it comes as no surprise there are a lot of similarities between the two. Aurelia offers ES6-support out of the box and supports all forms of alternative abstraction syntax such as TypeScript and CoffeeScript. Migration documentation about migrating from Angular 1 and 2 have been put on the roadmap.
Something you'll notice immediately is that the syntax is much simpler and more explicit (i.e. self-explanatory) than Angular 2 and looks a lot like standard JS syntax. ES6 and JSPM are used by default and a gulp file with a custom-built system to transpile ES6 to ES5 using the Babel transpiler is included in the standard package.
Aurelia also uses conventions instead of its own syntax and boilerplate code. No special characters like the ones in Angular 2 (*, (),  en #) here.
Two-way binding is provided out of the box and the framework does so very precisely. By default, 1-way databinding is used except for form controls, a clear plus when compared to React. Do keep in mind that two-way data binding can only be done through explicit syntax, as is the case in Angular 2.
The learning curve for Aurelia is comparable to that of Angular 2 and thus a lot steeper than React's. Luckily, the extensive documentation makes up for that a great deal.
Aurelia is built in a modular way making it very pluggable. You can plug in internationalization, routing, virtualization, anitmation, ... Besides that, third party plugins are available as well such as the aurelia-flux plugin adding the Flux dispatcher to Aurelia.
Aurelia's beta 1 version was released this past November, so we're close to a promising stable release. Another thing that may be interesting is that Aurelia is backed by a company with a long-term vision (Durandal Inc). They will also provide both commercial and enterprise support.
I've been a longtime proponent of Angular, because it's a complete framework covering all aspects of MVC. I like that, though I'm aware that it may create some sort of 'vendor lock-in'. Luckily, Angular 2 will be more standard-based (for modules, data binding and the like) making 'doing it the Angular way' a thing of the past, but still adds its own syntax on top.
Angular 1 has a big user base and hence there's a lot of community support. Projects using Angular 1 may be likely to migrate to Angular 2 as the Angular team will provide a clear upgrade path. It's already possible to migrate parts of your app from Angular 1 to Angular 2 as is running both versions next to each other.
React focuses merely on performance by using in-memory DOM, its own event system and the Flux architecture. Performance is indeed a big sore point of Angular 1. But, it also implies that React has positioned itself much more as a competitor of Angular 1 than 2.
Although I can't verify it yet, I expect performance of both Angular 2 and Aurelia to be much better than that of Angular 1.
React is very lightweight and easily pluggable so there's a lower chance of vendor lock-in. Do keep in mind though that React only covers the View aspect of MVC, which forces you to combine the framework with other libs. I also don't really like React's syntax. JSX, HTML in a JS-file... I don't think so. That's a thing of the past.
There's a lot of fuzz about React and the adoption rate is growing rapidly so community support won't be an issue as well.
Aurelia looks a lot like Angular 2 in the sense that it's a complete framework that relies on the web standards. It's as pluggable as React is and as Angular 2 will be.
A clear pro in Aurelia's favor is its use of conventions vs extra code and configuration, leading to a much simpler syntax compared to Angular 2's. But Angular is still in developer preview mode while Aurelia already released a first beta and will release a stable version very soon.
That's why opting for Aurelia based on the syntax-argument alone isn't a fair choice - yet.
Aurelia is new to the market while Angular has a big user base because it's already been around for 6 years. On the other hand, Aurelia has great documentation available, it's an official product of Durandal Inc, and the company has a long term vision for the product, something the Angular team doesn't seem to have and is blamed for a lot. While Angular was created by Google and React by Facebook they don't provide commercial or enterprise support, something that Aurelia will do.
In the end, I'm favoring Aurelia: there's solid documentation available and it has the same overall philosophy as Angular 2, but better choices in terms of syntax and execution. Having seen the breaking changes between different releases, it seems the vision of the Aurelia team about architecture and syntax is more clear than the vision of the Angular team. The company and enterprise support of Aurelia is also a big pro.
One more thing...
When talking about next-gen JS frameworks and asking whether there’s “a king that rules them all", it’s important to note that there is in fact a framework that actually can wrap ALL of the aforementioned ones. This über-framework is called Meteor.js.
Meteor is an isomorphic JS framework that plays on a completely different level. This one:
In short, Meteor is a full-stack framework, built on top of NodeJS and MongoDB (only MongoDB for now, more databases later), where the client side seamlessly integrates with the back end.
It has its own build process, package management system and tool sets and it proclaims itself as 'developer friendly' by abstracting many of the configuration details you don't want to spend your time on. Grunt or gulp files for example no longer exist within the Meteor framework: all configuration is built within Meteor’s build system itself. That's great, but be careful as this may introduce vendor lock-in.
Configuring the build system is mostly adding or removing packages from the Meteor package management system (atmospherejs.com).
You can use either Angular, Aurelia or React within meteor.js:
The above schema shows the official supported 'client side templating systems' for Meteor: Blaze, Angular and React. Aurelia is also available for use within Meteor, but is not officially supported for now.
So, when using Meteor, you’re free to choose which framework suits you best – Angular, React, Aurelia – as the rest of your application architecture is not affected.
Want to know which front-end technologies are the best fit for your business? Contact one of our experts.
Special thanks to Thomas Anciaux and Andries Van Humbeeck for their help with this article.