Angular 2.0 RC.5 was just released last week and is now really close the long-awaited 2.0 release.
After the success of Angular 1.0, it is normal to expect a huge success for Angular 2.0. However, we feel that there are reasons to believe that Angular 2.0 will not be as successful as its predecessor.
We believe this because we have been observing the front-end development trends.
Let’s learn what this “shift” is about.
Note: JavaScript transpilers like Babel, TypeScript or Elm are out of the scope of this article. But you should really try Elm.
A little bit of history
JavaScript is a multi-paradigm programming language. On its early days, it was mostly used as a scripting programming language. As the complexity of front-end application increased, the JavaScript community shifted towards a more object-oriented (prototype-based) style.
We can take a look to the API of many of the early single-page application (SPA) frameworks like Backbone.js to observe that they were heavily based on inheritance:
var Note = Backbone.Model.extend({ initialize: function() { ... }, author: function() { ... }, coordinates: function() { ... }, allowedToEdit: function(account) { return true; } });
At the time ES6 wasn’t around and many developers demanded a class-based object-oriented API. After some time the class-based API became a reality:
JavaScript classes are introduced in ECMAScript 6 and are syntactical sugar over JavaScript’s existing prototype-based inheritance. The class syntax is not introducing a new object-oriented inheritance model to JavaScript. JavaScript classes provide a much simpler and clearer syntax to create objects and deal with inheritance. MDN
However, when the class-based API arrived it was already too late and many influential developers didn’t want it anymore:
Why? What happened between the arrival of the first SPA frameworks and the arrival of ES6?
The answer is simple: the JavaScript community is shifting towards a more functional programming style.
The rise of functional programming
Functional programming has its roots in lambda calculus, a formal system developed in the 1930s.
FP is a “scary topic” because languages (especially purely functional ones) have largely been emphasised in academia rather than in commercial software development. However this is changing. JavaScript is a very accessible programming language and, as a result, FP in JavaScript is much more accessible than learning Haskell.
Many developers with a background on FP languages have started to work on SPA frameworks and today we can enjoy libraries like React, Redux, Cycle.js, MobX, Ramda or Immutable.js in our JavaScript applications. Some of these libraries have a more FP style API than others but they all share one thing: they try avoid OOP style on their APIs.
When we say “OOP style” we are referring to:
- Inheritance over composition
- Internal class state
- Imperative state mutations
We all know that it is better to use composition over inheritance but when a framework gives you a classes that you can extend it means that the framework promotes inheritance over composition. Angular 2.0 is a bit “weird” because it seems to prefer the decorator pattern over inheritance. However the decorator pattern should not be not necessary in non-dynamic situations.
Some elements of the React API promote inheritance over composition. For example, we can extend the React.Component class:
import React from 'react'; class Contacts extends React.Component { constructor(props) { super(props); } render() { return ( ); } } export default Contacts;
Get AngularJS best online training from Mindmajix! Free Demo here! https://mindmajix.com/angularjs-training