March 11, 2016 / by Manu Balakrishnan / UX / No Comments

Choosing a Javascript Framework

A couple of days ago, I had a discussion with one of my colleagues about JavaScript frameworks and how to go about deciding on a framework that improves application usability, performance, maintainability.

People who build client-side web applications know the rate at which  JavaScript frameworks are evolving. So in my opinion, it is very critical and important to choose the right framework when you are building large scale application.

Let’s try and figure out which frameworks work better for different applications.

It is important to understand why we use a certain framework.

Let me explain that first –

For instance, you are using jQuery which is a library to build web-based applications.

Let’s consider you have a product list rendered on your DOM and out of stock items in the list is marked in red color. You got a requirement to filter out out of stock items. Since JQuery work closely with HTML and doesn’t have logic to handle data, you need to pass the unique identifier to jQuery.  It iterates through the DOM to identify the class “outofstock” and fade out the element, which is very expensive in large-scale applications.

Eg –

<ul><li>Product 1</li><li class=”outofstock”>Product 2</li><li>Product3</li>….</ul>

If you are using any MVVM/Flux frameworks, you can check for the “out of stock” flag in the product list array and filter that without referring the DOM element.

[{“name” :”Product1″,”outofstock”:false…}{“name”:”Product2″,”outofstock”:true…}….]

Data and DOM(View) can be mapped using binding techniques like  observables, application state or properties.

Let’s choose another example, you have a dashboard which renders a bar chart based on filter criteria.  In jQuery, we require to capture chart’s identifier, and trigger change event when filter changes.

It would be completely data oriented if you are using any MVVM or Flux frameworks. There won’t be any DOM manipulations like we experience in jQuery to render the chart on dashboard.

Frameworks help you to attain the solution in certain ways where Libraries won’t.

But let’s not use a framework for the sake of using it.

Well, here are my two cents:

It should completely depend on the nature of requirements-

  • If the requirements are focused on more data volume and it’s manipulation we should choose a framework that uses less coupling between the View and Model so that browser reflow and repaint can be reduced. Any kind DOM references should be obviated. The business logic should work only on the data and it should have abstract knowledge about the Views.

Flux is an architecture that I would suggest for these requirements. It is a unidirectional pattern that helps to preserve the flow of data and its actions.

It has four major parts – Dispatcher, Stores, Actions and Controller-Views (ReactJS)

Actions – To facilitate data passage to the Dispatcher, the source for Actions is an API

Dispatcher – Takes data from Actions and broadcast the same via callbacks registered with it

Stores – Place for Application’s business logic and state. Callbacks are registered via Dispatcher

Controller-Views – These are HTML components, which take changes from Stores. It’s mainly written ReactJS

 

Flux

  • If the requirements are more focused on a dynamic layout or a dashboard kind of application, the framework should support 2 way binding or bi-directional. In this case we need to be very careful about the binding parameters. Since views have coupling with model (business logic), it always sets watch on the data through “observables”. When data changes it directly impacts views.

In this case we can go ahead with MVVM architecture where View and Model have 2 way binding

Components in MVVM includes – Model, View, View Model

Model – Whole business logic, API calls happen in this layer.

View – It’s going to be HTML templates (Mustache, Handlebars), which keep the observables. The templates can be logic less.

View Model – Data binding between Modal and View are kept in this layer. In some frameworks, it’s called Components. You can define properties, events in this layer. It allow you to couple loosely by just binding it to models and properties you need from a model.

Screen Shot 2016-01-14 at 12.48.36 PM

You can choose any MVVM frameworks like AngularJS, CanJS, Knockout.

ALWAYS ASK 7 IMPORTANT QUESTIONS TO THE FRAMEWORK BEFORE FINALIZING-

  • How do you handle data and component changes dynamically without page refresh
  • How fast you deliver content in Browser (Reflow/Repaint)
  • How easily can I package, integrate with Continuous Integration and deployment
  • How easily can I integrate with third party plugins and test suites
  • How can I do data binding and observing data changes with minimal lines of code
  • What is the impact on Application if any upgrades happen to the framework
  • What is the official support community or forum for the Framework

I would like to conclude this article by highlighting some important point to remember about Frameworks –

Regardless of any Javascript Framework, It is intended to provide a clean separation of complexity between user defined components (views) and its business logic.

What have I missed ?

Please let me know in your comments..

2016 Litmus7. All rights reserved.