Bye 2k16 and Bye Angular

Yes we had a good time and for a brief amount of time I thought Angular was the best but somewhere around March I started learning React, It confused, It has challenged(or changed) the way I thought about the software but when I started understating it I thought that Angular was over and got to know why React js has won the hearts of dev community why it will continue in the foreseeable future. These are the following reasons why my relationship with Angular is Over.

Component Architecture
JSX
Unidirectional data flow
Virtual DOM
Flux
Functional Programming

Component Architecture:

As the state of the Front end dev. evolved it saw that Component architecture is the way to go as Angular 2 converted to components only. There are many advantages as to why you should only use stateless components in you app. Have a look at this

var ButtonApp = React.createClass({render: function(){return (<input type="submit" />);}});

This is an example of component in React just look at how easy it is to understand what is happening here, but if you had to do the same thing in Angular you will have to make a directive and though Angular team has done a fantastic job with the usability of directives they have also made it very complicated to learn, read and maintain directives.

angular.module('foo').directive('bar', ['$rootScope', function ($rootScope) {return {restrict: 'E',replace: true,templateUrl: 'path of my button's template',//or if you have a simple templatetemplate:'<input type="submit" />',controller : function ($rootScope,$scope) {

},link: function (scope, elements, attrs) {

}};}]);

it is clearly visible that I need to know a completely different API in order to make a component in Angular and that API has so many fricking options that most of the time you will forget what you actually wanted to do as you will lose yourself in the complexity directives has created.

If you want to make something useful with Components

any programmer with just some basic knowledge of JavaScript,HTML would be able to figure out what is happening here, but if you look at the equivalent code in Angular you may need to first learn dozens of other concepts or syntax so you can make sense out of it.

So few advantages of components being:

It’s easy to know how a component is rendered, you just look at the render function
It ensures readability and makes maintainability easier.
It is easy to test.
You can build reusable components that would allow us to share code with your native clients.

JSX:

JSX is an inline markup that looks like HTML and gets transformed to JavaScript.

This was very tough because as far as I have been writing code we keep Javascript, CSS and HTML in different files and to get my head around this was pretty hard, I needed much convincing from multiple tutorials and videos I saw but now I wonder “why the hell I was not using this before”.

Take a look at this snippet:

you have the full power of JavaScript to describe your UI — loops, functions, scope, composition, modules — not a crippled template language.
JSX Event Handlers are NOT Like HTML. JSX events get automatically delegated to the root React node. Actually, it goes a step further. It sets up a single event handler on the root node that handles all your events. What does that mean? Normally when you attach event listeners directly to the element that the user interacts with, you end up with potentially many event listeners in memory for a single page. React creates a single listener automatically, so you never have to think about event delegation again. This is really great for things like infinite scrolling, because you don’t have to worry about infinitely growing memory consumption (memory leaks).
Keeping HTML and JS in same file has a big advantage you can look at one single component and you can see how it will render, how it will behave and it’s styling as well which is separation of concerns done right.

Unidirectional Data flow

Data binding works wonderfully for small examples. However, as your app grows you’ll probably face some of these problems.

Declaring dependencies can quickly introduce loops

The most common problem is having to cope with the side effects of changes in your state

The mess MVC creates

In this scenario, can you predict what changes will happen when one change happens to a single Model? It is very hard to reason about code that can be executed in a completely arbitrary order when any dependency changes.

What’s the role of a View? To present the data to the user. What’s the role of a ViewModel? To present the data to the user. What’s the difference? None!

Templates separate technologies, not concerns ~ Pete Hunt

This is the exact problem I face everyday at work where our entire web-app is written in Angular 1.x. and the solution to this problem takes us to,

Virtual DOM

This is probably why most developers are so attracted to React. React manages its own DOM in memory. The most expensive operation most web apps suffer is mutating the DOM. React’s approach is to maintain a virtual representation of the DOM which allows it to calculate differences in the DOM so that it only mutates the part of the DOM that actually needs to be updated. This is a huge benefit!

React can diff two DOM trees and discover the minimum set of operations it needs to perform. This means two things:

If an input with text is re-rendered and React expects it to have that content, it won’t touch the input. No more state loss!
Diffing the virtual DOM is not expensive at all, so we can diff it as much as we like. When it’s ready to actually alter the DOM, it will only perform the least possible number of operations. No more slow layout thrashing!

For the people who don’t know how this happens in Angular let me tell you,

Digest cycle is the magic sauce of data binding in Angular and the way it works is this,

whenever a browser event or some AJAX request(there can be many cases when it might get called) triggers digest cycle all the variable that have been binded to view or any other watches or any function that is attached to scope(another Angular jargon) is reevaluated not just for that component but for whole fucking application(yes!!)

In summary it results in too many function calls and consequently DOM manipulations, which consequently converts to jittery experience.(If you have a guy with a good experience with Angular and front end then only you will be able to escape this).

So, If you use React all the problems with digest cycle poof GONE!

FLUX

Flux is Facebook’s pattern for React applications that focuses on unidirectional data flow. The basic idea with Flux is that everything happens in one direction. Data flows in as a result of actions. Actions trigger stores (data models) to be updated, which then triggers change events to fire, causing React views to update if needed. The cycle repeats itself as data changes throughout the app.

Advantages:

Stores and actions are just pure functions. They are easily testable in isolation.
Easy transactions. The dispatcher owns the state and has the power to revert the application to any previous state without the programmer implementing something like serialize() or deserialize(). This, combined with hot reloading, enables very powerful developer tools
You can subscribe to the changes at the store level, but the dispatcher may also expose cursor-like functionality for the advanced users who need finer-grained updates.

Maintaining states in React is not only easy but more efficient and readable where as how to do the same thing in Angular took me a while to figure out and it is still not as efficient as this.

Functional Programming

As a programmer I should have known functional programming It’s very useful, though I still have my doubts regarding the usability of functional programming on Backend/ APIs but on front end I can say that

“50% of the problems I have faced were because of not using pure functions or mutating states”

the advantages are:

Simplified data flow through apps.
Removed requirement for defensive copying of data.
Optimisation through data change detection.
Performance enhancement through memoization

so why some people are afraid of immutability?

because they think that always creating a new state is slow but what they don’t know is that

To avoid expensive cloning only the difference to the previous data structure is stored, whereas the intersection is shared between them. This strategy is called structural sharing.