Choosing a JavaScript framework for my side project

I started looking at JavaScript frameworks to see if I could find something interesting for my event scheduling project. I’m looking to use them to help me show the schedule itself: when a session of an event is modified, it must be updated in two places on the page since the list of sessions for a room is collapsible. I already took a look at SignalR and I will most likely use it to notify the other clients that the schedule has changed, but I wanted to see if there are other tools that could help me update the display of the schedule.

First, I looked at Angular.js, since it’s one of the most popular framework. I ended up not testing this one at all: there is a version 2.0 coming up that is not going to be compatible with the current version, which made a lot of noise in the Angular community. Since the time I have to work on this is limited, I don’t want to write everything in a version that will most likely be dropped in a year or two. I don’t see the advantage in learning how to use it now only to have to start over in a year or two. So, for maintainability reasons, Angular.js is out.

After this, I turned to Backbone.js, another framework that enjoys a great deal of popularity. That one was also ruled out pretty fast, since it enforces a RESTful API, which is not what I’m looking for in a JavaScript framework. I would rather rely on the server knowing what is the right business logic and not the JavaScript: for example, if I want to offer a command to move a session 15 minutes earlier, I’d rather just tell my server via a WebAPI to MoveLater or MoveEarlier, let it enforce all the business logic and just show the results. I’m not looking to redeclare on the client all the model logic that lives on the server, and it cannot be on the client only since you never know what can happen on the client. This is too much of a commitment to the Backbone.js architecture to synchronize a few refreshes only, so it is out too.

I was beginning to feel like the Grinch after rejecting the goodness of all those frameworks, but I decided to give it one last try and find a framework that I could at least test in my prototype. I settled on trying Knockout.js, a small framework with no dependencies. It’s really more of a toolbox to create dynamic UI in JavaScript than a full framework, and it doesn’t need to take over the whole page. Also, older browsers are supported, the documentation is great and the features are pretty stable with no plan for a rewrite on the horizon.

I did the whole interactive tutorial on the Knockout.js site and it convinced me that this library is something I could use. I can create a ViewModel representing the parts of the page I want to update only, and keep the rest of the code simpler for the parts that don’t need to be refreshed. It also integrates nicely with existing markup: I only need to tag the markup that needs to be updated with Knockout.js with a data-bind attribute describing what the library needs to do. So, for more complex views that need to be refreshed like the schedule, I’ll use SignalR to get notifications that the data has been refreshed and Knockout.js to handle refreshing the UI.

Also, I won’t be using it those two libraries everywhere: for simple page like forms to create an event or a session, I’ll use only jQuery, a library for standard controls and some small libraries to solve focused problems. For example, I’m going to use Moment.js to handle times in my application since it’s an important part of the schedule and times are such a mess in JavaScript.