AI’s Healthcare Revolution

Most startups and product development companies nowadays struggle with the idea of choosing the right JavaScript framework for their products. In a few years, Angular has jumped from v2 to v7 (as of 2018 May) and React to version 16 as of March 2018. JavaScript frameworks are developing at a blazingly fast rate. So the question often perplexing the newbie architect or lead UI developer is - “Which JavaScript framework to choose?”

What capabilities does one look for in a JavaScript framework?

Are you looking for MVC capabilities?

“When all you have is a hammer, everything looks like a nail, but then, there are more than one ways to skin a cat!”

Ok! Enough said!

Breaking an application down into layers has been the way server-side code has been written. MVC pattern has been a popular way to write server-side code. The same practice was also carried over to the client side. But smart people find ways to do things differently and efficiently. While your chosen framework may do things the way you want them to, it is worthwhile to look at the non-MVC way of doing things for other benefits which a framework may provide.

Is the framework performant and is it the right tool for your job?

While all frameworks perform well (as their creators claim), when you take an application to scale, the quirks and idiosyncrasies begin to surface. Just because the framework behaves well on a single developer machine is no guarantee that the performance will replicate on a larger system.

While this may look a little strange, but yes, when it comes to getting the business’ buy-in from a technology perspective, a popular framework is much easier for business to say yes to than an exotic one. Albeit, in some cases, an exotic one may be all you need. Deciding on this question is more an art than a skill and is best left to the team to decide.

To assess this question, one may want to have a look at the GitHub contributors, framework downloads, and the number of questions answered on StackOverflow to get a feel for how popular the framework is with the developer community.

Does it make you productive?

This boils down to the question - is the framework easy to use, to write code with, and maintain? Sometimes, the framework in question should make you “productive” enough, else it can be “counterproductive” (ok you get the point!).

In a nutshell, the development “experience” should strive towards optimization of that experience between ease of writing, maintaining code, and having a framework which helps you churn out code quickly. If the framework (however

The point is akin to the urban legend about Python being “slow and non-performant” a decade back yet coming out to being the most “vied for” skill set by developers in 2018. This was primarily because of its “productivity” which helps you dish out production-ready code much faster than other statically typed languages like C# and Java. (This is apart from the fact that there are tons of libraries also being available in Python).

Are you looking to make an SPA or an MPA?

This decision may affect your SEO and digital marketing strategy. Also, if you are trying to get a pre-MVP product churned out quickly or if you have a team which still needs to come up to speed with the SPA paradigm, then you may want to go with MPA frameworks and may choose jQuery or other such frameworks. However, just plugging in a router from most of the SPA frameworks can quickly get you set up and help you migrate to an SPA framework. (Ok! It’s not that easy too!).

In the article below, however, most of the frameworks we are going to compare are based on single-page application architecture.

Is the documentation friendly enough?

Very important. This is going to affect your productivity, especially if your framework is being actively upgraded over time and the way to do things is going to change as new releases are made. You do not want to get into a frustrating experience of coding in the trenches for prolonged periods of time and get battle-weary!

Does the framework have features like templating, form processing & validation, HTTP callbacks, and routers?

While this may seem an obvious requirement, not all frameworks have these by default. You may need third-party libraries in addition to the base framework in case.

Final Word!

Ultimately you have to choose your own poison. Primary facts you want to bear in mind are:

  • What makes most sense for your project?
  • What intuitively makes the most sense to you as a decision-maker?
  • What skill set of developers are readily available to you?

Having said that…

Here are the major frameworks in the JavaScript world today and these are some of their salient features, keeping the above points in mind.

Angular

Salient Features

  • When you need to build an SPA (single-page application), Angular aims to be the go-to framework for developers.
  • It uses bi-directional data binding and dirty checking for data update/propagation.
  • Highly event-driven framework which can take some serious client-side computation at times.
  • It uses the “digest” cycle to check object scope changes. These changes when detected are pushed to all places where they are referenced in the object model. The view updates based on changes in the object model.
  • Angular has a non-trivial learning curve.
  • The documentation, though extensive, is not that trivial to understand.
  • A powerful feature is the directive which syntactically looks like an HTML element decorator.

Pros

  • Very quick to put up application or view prototypes.
  • Angular uses directives which are a unique and powerful feature. They can provide powerful two-way data binding and even create a fully functional web-part component.
  • Angular filters allow data formatting and parsing at runtime which reduces custom JS code significantly.
  • Angular (dependency injected) services allow common “service elements” to be abstracted into a single “service” component. These can talk to each other and provide a “service layer” on the client side itself.

Cons

  • If there are too many watchers, and the scope changes, high number of object scope changes can affect the user experience because Angular does dirty checking and digest re-evaluation of all scope changes. Usually, that is not an issue but this can take time to stabilize if some watcher triggers an update.
  • At large scale, the framework like Angular has certain idiosyncrasies which need to be dealt with.
  • Compared to Vue or even React, needs more effort from a beginner to get the code setup. Learning curve comparatively a little more.
  • It uses TypeScript which is different from JavaScript and hence increases the learning curve. This may be a challenge if you have JavaScript purists in your team.
  • Of late, the Google developers have been pushing a major version release every 6 months or so which means you may always keep falling behind the technology curve.

Ember

Salient Features

  • It uses the MVC architectural pattern and unlike Angular or React, there are no multiple ways of doing things here. You can call it an “opinionated” framework which makes sure developers are “guided” to do things that one right way.
  • Allows two-way data binding which is done via “accessor” methods on objects.
  • Uses route and route handlers for matching the URL to the right template and setting up the application state.
  • Uses templates with “handlebar templates” syntax for producing HTML output.
  • Route handlers render models using classes which incorporate the Ember Data library.
  • Uses components which incorporates a template (JS based) and a source file which defines the component behavior.

Pros

  • A very compact library (almost 8kb) unlike Angular, it’s an excellent framework for rapid prototyping.
  • Because of accessor methods on objects used for data binding, data checking (property checks) become efficient.
  • Ember provides “computed properties” which allows gluing together multiple models, making it cool to work with.
  • Unlike an Angular style digest cycle, the validations are done instantaneously as the property change happens. This makes debugging and seeing data flow easier to visualize.
  • Ember like Angular uses a router, albeit much simpler syntactically and logically to understand. Ember routers are a simple yet powerful feature which very few other frameworks have.
  • Ember has pretty good documentation.

Cons

  • Ember does not do the dirty checking which frameworks like Angular do. You need to call the getters and setters to access, re-evaluate the properties and have them propagate onto the models.
  • Some of the native JavaScript functions are not available immediately in Ember - like map etc.
  • At large scale, the framework supposedly has certain idiosyncrasies one has to deal with.
  • Everything in Ember needs to be wrapped inside Ember objects. All dependencies for computed properties need to be declared manually.
  • The handlebars’ syntax is much limited to something like Vue’s usage of JavaScript expressions.

Backbone

Salient Features

  • An MVC framework which came out in Oct 2010 as an alternative to jQuery when you want to create an application with better design and less code.
  • Uses routers, models, events, views, and collections as the building blocks of the framework.
  • Typically used when you are not sure which framework to use but have inherited a legacy app which has some messy, loose JavaScript code and you need to clean things up.

Pros

  • The library is very compact (8kb gzipped) unlike React or Angular which may go into the 30-65kb (gzipped) range.
  • Models very easy to work with when dealing with RESTful APIs. The framework automatically propagates changes to HTML when models change.
  • Good for organizing JS code.
  • Minimalistic framework and hence performant since it gives the control totally to the programmer in terms of organizing code.
  • Extensible framework which can be used to put in ReactJS views.
  • Lots of plugins available on top of Backbone for specific requirements.
  • Performs well for even large applications.

Cons

  • Has a soft dependency on jQuery and a hard dependency on Underscore.js.
  • Not as easy to prototype applications when compared to Angular or even React.
  • Sometimes the amount of code one has to write is much more than say one would have to write in Angular or React. However, the code is performant and gives more control to the developer.
  • Two-way data binding and all associated wiring has to be done by oneself and is not supported out of the box by Backbone.
  • If you do not know what you are doing, one could develop memory leaks in Backbone inadvertently. Some level of experience and expertise may be needed here.

React

Salient Features

  • React is not an MVC framework. As the documentation mentions, it is a library for creating composable user interfaces!
  • React does not use templates and instead approaches view creation by breaking the view into components where individual component has its own corresponding view logic.
  • The library allows two-way data binding by “providing helpers”.
  • Allows virtual DOM creation and updating only the “diff” with the actual DOM.
  • Uses the JSX approach where the “JavaScript code” is replaced by an HTML and CSS like syntax. React is for developers who like readability of HTML over raw JavaScript.
  • Also, a point to remember is this - React was written with “functional programming” in mind.
  • React uses “Flux” instead of an MVC approach to data binding. This allows data to flow in only “one way” on the client side.

Pros

  • Updating the DOM with the diff allows it to be most performant (when compared to other frameworks) by minimizing the DOM view re-painting. Effectively the paints and re-paints are very efficient.
  • It is agnostic to the data layer. React portrays itself to be the “V” in MVC frameworks.
  • Code is relatively easy to read (and hence code!).
  • React is the only framework which does server-side rendering. It can take “pre-rendered” markup from the server side and work with it (cache, render etc). This is unlike other frameworks which have to work in much more involved way when rendering data received from the server on the client side.
  • Architecturally, data in a React application flows in “one way” (does not use two-way binding because of Flux) and hence it is easy to catch the data operations and view the data flow. It is easier to find where the data could have gone messed up.
  • Has a component-like approach and hence is easy to aggregate them on multiple levels and layers.
  • React is easy to set up (say unlike Angular) and quickly prototype.
  • Functional programming aficionados will feel very familiar and comfortable working with React.
  • Easier to debug since there are not many places where you could go “wrong” with your code (as compared to Angular).
  • A huge advantage learning React is the native rendering of React component model onto the iOS and Android mobile platforms for native rendered apps. The React Native framework built on top of React JS along with the native modules which one can write for iOS and Android make it a unique skill set to learn and be productive from a full-stack engineering perspective.

Cons

  • React has a steeper learning curve compared to something like a Vue because of the need to learn DSLs like JSX and even ES2015+ to understand React’s class syntax.
  • One also needs to understand the build system for production deployment. It is not as simple as just including a JS file in the <script> tag like for Vue.
  • React has a high pace of development updates. One needs to “re-learn” the way to do things since updates could change old ways quite frequently. Not every developer is comfortable with that kind of an ever-changing working environment.
  • Documentation is another challenge with React and could be lagging behind the development as new updates are released.
  • Frameworks like Redux and Reflux are an additional challenge which developers need to learn apart from JSX which is a DSL needed to code in React. This can seriously slow down developer productivity unless one has already mastered one’s tools.
  • Some technology decision-makers may not like the React “patent clause” which they argue makes React not an open-source framework. While this is a debate still going on, you may want to keep this in mind.

Vue JS

Salient Features

  • The library was created with the aim of creating “interactive” interfaces.
  • Uses the Virtual DOM concept (similar to React) and the final changes between the virtual and real DOM are propagated to the real DOM similar to React’s architecture.
  • A very “component"esque framework allowing one to make custom elements. These can then be used inside the HTML.
  • Allows only one-way data flow between components unlike Angular.
  • Uses templates for binding DOM with Vue instance data.
  • Uses directives on HTML elements for data/formatting manipulation (like v-bind, v-model, v-if, v-else).
  • Uses watchers to figure out and fire any events when data changes.
  • Uses routers for navigation between pages.
  • Uses computed properties for performing actions and calculations when changes are made to HTML/UI elements.

Pros

  • Relatively lightweight compared to Angular and performant too. Not as heavyweight a framework (but who knows in future may evolve into) as say Angular.
  • Performance comes from the fact that like React, Vue also uses a similar approach of a virtual DOM whose final diff is updated into the real DOM.
  • Unlike React, uses the HTML, CSS, and JS approach and hence is easier to pick up initially. No DSL learning requirements along the way.
  • Uses directives like Angular which allows two-way data binding and also server-side rendering etc.

Cons

  • Vue is not as popular as React or Angular and hence the developer community and resource support is still building up.
  • For the same reason, Vue also does not have the rich set of plugins which frameworks like Angular and React already have.
  • Another oft-cited issue with Vue is the documentation which quickly becomes outdated - again for the same reasons above!