War of JavaScript Frameworks

Web development is fun and Javascript is awesome. Over the years, JavaScript has changed tremendously and mostly for the better. Few of the things I loved about JavaScript are:

• Loosely typed variables, no need to think about the type during declaration (Assign what you want).
• Functions as first class objects: They can be passed around like any other object. They can be assigned to variables, passed as arguments, and even returned. Few of other interesting facts about functions are: with no signature, yet being able to handle any number of arguments being passed in, you can return a function without even naming it.
• Closures: A closure is an inner function that has access to the outer function’s variables. The closure has three scope chains: it has access to its own scope (variables defined between its curly brackets), it has access to the outer function’s variables, and it has access to the global variables.
• Hoisting: Within its current scope, regardless of where a variable is declared, it will be, behind the scenes, hoisted to the top. However, only the declaration will be hoisted. If the variable is also initialized, the current value, at the top of the scope, will initially be set to undefined.
• And many more features like:
  == is not transitive,
  Self-executing functions and Block scope,
  the debugger statement: which can act like breakpoint etc etc

These, along with some other cool features made JavaScript really an interesting development language for modern web development. But it didn’t stop here, there comes some of JavaScript libraries like JQuery, Underscore, require etc… These libraries are helping hand for the ease of development along with other features of JavaScript.

Ahhhh when we were feeling settled by getting a hand full of experiments on all these things, then there comes the evolution of UI Frameworks (MVC, MVVM, MVP, V ?????). Almost as powerful as X-Men characters:

• Backbone : Storm
• Knockout : Cyclops
• Angular 1.0 : Professor X
• ExtJS : Forge
• Ember : Magneto
• React : Beast
• VueJS : Mimic
• Angular 2.0 : Wolverine

All of them have some unique powers, abilities, and are good in one another way. With all these powers available now the problem is to choose which framework for your app development, on which we can back upon. It’s very hard to say which one is the best framework, anyone can be a good fit depending upon the need of the hour and the way the application is architected (but yeah preference may var from person to person).

Below are the some highlights about the good and bad parts about few of them.

Angular 1.0:

Professor X of this story, it really captured the mind of most of the developers, and is still favourites of many. It’s a great JavaScript framework based on MVVM architectural pattern, it makes easy to develop Single Page Applications (SPAs) and removes most of the pain regarding data binding, requests and routing.

• The most important factor which Angular brings is “Separation of concerns”.
  Architecture (Structure to Javascript): For the architecture, It provides an “app-driven” pattern, where each app is [almost] self-contained and has its own modules (Controllers, Services, etc).
  Modular development, Controllers, Directives, Filters and Services,
  REST API Support:Angular $http service is nice. I mean, its simple enough and does most of what is expected from it.
• Templating
• Two-way data binding
• Dependency management
• Routing
• Localisation
• Hybrid mobile app development
• Highly testable products
• Development is fast and simple once you are familiar with it, faster than knockout, backbone, react.
• Very expressive, therefore need less code for similar result compared to other libraries.

But at the same there are few pain points too with it:

• Complexity of some its best features: Directives are difficult to use too. In addition, many AngularJS features like dependency injections and factories can be problematic for the more traditional developers.
• Scopes are easy to use but hard to debug, scopes can be complex entities to handle if it is your first experience with Angular.
• Two-way binding can act like curse also, each time a Model is updated, either through user input in the View, or via service input to the controller, Angular runs something called a $digest cycle. When we create data-bindings with AngularJS, we’re creating more $$watchers and $scope Objects, which in turn will take longer to process on each $digest. As we scale our applications, we need to be mindful of how many scopes and bindings we create, as these all add up quickly — each one being checked per $digest loop (There are ways to optimise the performance).
• Possible time consumption to render the DOM.
• Difficult learning curve: basics are easy but you may have to face great difficulty to understand some advanced features.
• Documentation is not up to the par, though day by day extending community is making it easier.

React JS:

Here comes the Beast, so powerful and agile being light weight. One of the modern era’s highly popular name for single page applications. It’s just a library for rendering your views (V). Few of the good parts about ReactJS are:

• React uses unidirectional flow which is much simpler than two-way binding and one-way binding is more efficient than two way binding.
• Its component-based, which helps to write more loosely coupled code.
• It helps achieving immutability and functional programming.
• It helps to write stateless components (state makes components difficult to test and difficult to share information to other parts of the app).
• propTypes for components, which offer an easy way to add a bit more type safety to our components.
• Provides ability to create Virtual DOM, React creates an in-memory data structure cache, computes the resulting differences, and then updates the browser’s displayed DOM efficiently.
• Learning curve is easy and also provides React-Native for building IOS-Android apps within same learning curve.

Some of the feel bad factors are:

• Writing HTML code becomes complex, since JS and HTML are tightly coupled as a single component.
• It's just a library, not a framework. To achieve MVC it needs to join hands with others like Redux, Flux etc…
  Learning a framework to build a quick SPA is much easier than learning all the technologies to build a toolchain thorough enough to do the same with just React.

In simple words, it acts like an assembled computer, in which you borrowed various parts from various vendors. This can lead to better performance, but at the same time maintenance may become little painful, as we need to chase various resources for various problems.

VueJS:

This the newest member. I referred it Mimic of this framework war since it is build by picking best features out of other frameworks/libraries. It is a library built with a goal to provide the benefits of reactive data binding and composable view components with an API that is as simple as possible. Some of its good parts are:

• This is not a full-blown framework, it is focused on the view layer only. It is therefore very easy to pick up and to integrate with other libraries or existing projects. On the other hand, when used in combination with proper tooling and supporting libraries.
• Reactive data-binding: This makes it extremely simple to keep your data and the DOM in sync. It embraces the concept of data-driven view, special syntax is used in HTML templates to “bind” the DOM to the underlying data.
• Component-based design: It also focuses on designing small, self-contained and reusable components.
• Routing: It also provides its official Vue-router library, which is currently in technical preview.
• Communication with server: Vue-resource plugin which provides an easy way to work with RESTful APIs.
• There isn’t any dirty checking, it uses a transparent dependency-tracking observing system with async queueing — all changes trigger independently unless they have explicit dependency relationships.

Nothing is perfect, this applies to VueJs also. Few lagging areas for this framework are:

• This is also not a framework, it also requires a help from other libraries to act like a framework similar to ReactJs.
• Since its a pretty new framework, community support is also not as rich as React and Angular but it's constantly growing.

Angular 2.0:

Seems to be a Star even before its launch and gathering so much of buzz. Wolverine of this story, assuming it will have a self healing power from all the wounds of Angular. Lets have some insight about its features:

• Components: after React and Vue, one more framework having component based paradigm as its core value. An application will always have a root component that contains all other components basically will act like a component tree.
• Directives are still there and are much simpler and straightforward. In Angular 1 we had the DDO (directive definition objects) which we used to develop our directive. There are lots of confusion around that approach like:
  transclusion: What does that word even mean?
  controller vs link: When to use link and when to use a controller?
  compile: What should I do in there?
  scope: scope: false, scope: true, scope: {}. Which one to use and why?
• No need to worry about $apply() to update the DOM.
• No more $scope, there’s no such thing as $scope in Angular2. Yes you got it right, there is no scope. Instead of binding to properties in the scope inside our templates, we can directly bind to properties of our “components”.
• Services and Filters will be there, but in a more improved way.
• Properties, Events, References and few more cool things introduced.

Few things which can be against Angular 2.0 :

• No backward compatibility for Angular 1.0 apps.
• Complete new start in terms of learning.
• Have to learn TypeScript.

In short complete efforts are logged to overcome the pain areas of Angular 1.0, by keeping performance optimization in mind. Its completely a new framework just inheriting the name Angular, but yeah, all the new things seems to be pretty cool to make impact once again.

Every framework has some values , this article is not to justify which framework is better. Whatever framework you choose, it’ll end up helping you somehow. We cannot deny the fact that the UI Development is very dynamic and things will keep changing, so be ready to Learn Unlearn & Relearn.

This is just an attempt to unfold the story about all these frameworks. Apologies if I did some injustice to any of the framework or X-Men character. Corrections and suggestions are really welcomed and appreciated. Hope you like the content.

Happy coding and Happy writing.

— Robin