Choosing a JS MV* framework

JavaScript frameworks these days remind me of early J2EE days. The first headache is sifting through and choosing (hopefully) the right framework. The task is made more difficult since there are several excellent contenders. I narrowed it down to three:

Screen Shot 2013-06-04 at 11.49.37 AM AngularJS

Pros:

  1. Backed by Google and some pretty smart people.
  2. Complete solution with MV*, binding and deep linking
  3. Dependency injection has first class support
  4. Testability is baked into the framework
  5. Web components support via ‘directives’. This is in line with where Google wants to push the web towards. They recently announced Polymer JS @ Google IO and this is probably going to be a W3C spec.
  6. Documentation mostly good, little weak in the directives space but is supplemented with YouTube videos.

Cons:

  1. Directives are complicated, mostly since the browser is not (yet) natively aware of web components. After reading the docs three times I was a bit annoyed. A UI component should not be this much work.
  2. Does not play well with JQuery. JQuery is based on manipulating the DOM. Angular approach is to extend the DOM with new elements. At the time of writing there is the Angular-ui project but it has a work in progress banner. You can integrate with JQuery UI but it is a bit of work.

Screen Shot 2013-06-04 at 11.49.18 AM KnockoutJS 

Pros:

  1. Great balance of simplicity and power. Easy on my birdbrain.
  2. Its probably has the best tutorial of all the frameworks.
  3. The design philosophy is bit like the Java Spring framework. While it’s predominantly a binding framework you can pull in other features like components, routing etc. as plugins or integration with external libs.
  4. It’s a pragmatic framework. It thinks like I would when I am on a time constraint. It favors practicality over theoretical purity. For example, all attributes you want to observe (bind) must be wrapped in KO functions. Not ideal from a pure design sense but work fine in practice.
  5. Extending KO is very easy.
  6. KO is well integrated with JQueryUI via Knockout-JQueryUI bindings.
  7. A github project from the KO team – offers integration with KendoUI.

Cons:

Since KO is not a monolithic framework you have a do about a days worth of work to bring in all extra libs you want. There are sample starter projects on github. I will be sharing mine in the next post.

Screen Shot 2013-06-04 at 11.49.56 AM ExtJS

Pros:

  1. Mature framework backed by Sencha.
  2. Backed by a large widget set including mobile. There are layout widgets which means you probably don’t have to fiddle with html layout tags.
  3. Comes with a decent MVC framework
  4. Covers most things form dev to deployment including build tooling
  5. Good documentation

Cons:

My main gripe with ExtJS is that it acts as an abstraction layer for JS. It does this by declaring its own components. A Hello World example From Sencha ExtJS docs:

Ext.application({
    name: 'HelloExt',
    launch: function() {
        Ext.create('Ext.container.Viewport', {
            layout: 'fit',
            items: [
                {
                    title: 'Hello Ext',
                    html : 'Hello! Welcome to Ext JS.'
                }
            ]
        });
    }
});

While this is cool it takes control away from you as a developer. In my experience this works ok until the day your client asks you to make a tweak or the framework plays up (typically when you push it in your more complicated workflows). Now all the black box semantics go out of the window and you have to figure out what’s going on under the hood. This is usually painful and gives you a few more gray hairs. I think there is value in understanding how <div> are laid out by the browser and what display:inline-block is !

You have to operate in the Sencha walled garden. Since the HTML 5 momentum comes from open source, this is not cool.

UI Widget toolkits

If you are planning on doing a decent sized app for a decent sized company you are going to need some widgets. JQuery UI gives you a decent start and is the de facto standard but it does not go all the way to a sophisticated grid. Hence, UI toolkit interoperability becomes an important dimension in evaluating an MV* framework.

Screen Shot 2013-06-04 at 12.19.35 PM

* Kendo UI Web has a open source version for its web components
* ExtJS also has a open source license and some fine print which I haven’t read
* Infragistics claims to have the ‘fastest jQuery grid on the market’

My recommendation

Use Knockout as MVVM framework + JQuery UI + Kendo UI for advanced widgets like the grid.

  1. This is a first rate, easy to use toolset.
  2. Each of these components is production proven and bindings already exist.
  3. Keeps from any lock in. For example if Kendo grid doesn’t work out you have other options like KOGrid.  You are also free to adopt any innovations/new plugins in the JQuery space.
  4. Just in case Knockout doesn’t work out (highly unlikely) you can move completely into Kendo UI, since its architecturally close.
Advertisements
This entry was posted in Tech bits, Web development and tagged , , , . Bookmark the permalink.

4 Responses to Choosing a JS MV* framework

  1. kylehayhurst says:

    Kendo UI is SUPER expensive, it looks like a lot of the widgets can also be found in jQuery UI and KOgrid looks pretty cool. Is Kendo UI really worth it?

  2. bsandhu says:

    It depends on what you are building. If you are in a rush to get to market you could use the time saving. If mobile is not a part of the strategy yet, Kendo web widgets are open source. jQueryUI widgets + public plugins should suffice for most projects I think. Comes down to a time vs money tradeoff in the end. KO is easy to bind to jQuery widgets so you have options !

  3. Andrey says:

    Baljeet, what do you think about emberjs?

  4. bsandhu says:

    In my mind Backbone, Ember and Knockout are in the same category since they all have some flavor of MV* with templates. Ember was a little confusing to get started but once you get their approach it makes sense. It is more influenced by Rails. You can see ActiveRecord kinda behavior in their Data source. It is also a fairly complete solution out of the box. It leverages naming conventions which I think is smart. People rave about the Handlebar templates but didn’t seem anything special to me.I wasn’t too impressed though since it felt a bit on complicated side.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s