#Indico client-side MVC It's time to go full MVC in Indico!
We all want our architecture to be simple, yet beautiful.
When developing applications using just jQuery, the piece missing is a way to structure and organize your code. It’s very easy to create a JavaScript app that ends up a tangled mess of jQuery selectors and callbacks, all desperately trying to keep data in sync between the HTML for your UI, the logic in your JavaScript, and calls to your API for data.
A number of modern JavaScript frameworks provide developers an easy path to organizing their code using variations of a pattern known as MVC (Model-View-Controller). MVC separates the concerns in an application into three parts:
- Models represent the domain-specific knowledge and data in an application.
- Views typically constitute the user interface in an application. They observe Models, but don’t directly communicate with them.
- Controllers handle input (e.g., clicks, user actions) and update Models.
Thus, in an MVC application, user input is acted upon by Controllers which update Models. Views observe Models and update the user interface when changes occur. Backbone merges the responsibility of the Controller into the View, therefore it's called MV*.
- For complex user interfaces
- When trying to reduce the number of HTTP requests
Indico's Registration Form serves as a prototype of MVC implemented with Backbone. The current task is to refactor the code and interface to comply with our standards.
Some tasks:
- Templating engine: UnderscoreJS mini templates
- It simply embeds JS into the HTML
- Migrating to Nunjucks (port of Jinja for JS)
- Logic is found in templates:
- Moving it to Views (quite hacky)
- Would require some rethinking in how the models hold the information coming from the back-end
Let's compare Backbone because it's the current prototype and Angular because it seems the most promising framework.
Things we should be looking for in a MVC framework:
- Observables: Objects that can be observed for changes.
- Routing: Pushing changes to the browser url hash and listening for changes to act accordingly.
- View bindings: Using observable objects in views, having the views automatically refresh when the observable object change.
- Two way bindings: Having the view push changes to the observable object automatically, for example a form input.
- Partial views: Views that include other views.
- Filtered list views: Having views that display objects filtered by a certain criteria.
Clear winner:
- Angular have all of these by default.
- Backbone is able to do most of them with a lot of manual code or plugins.
- Angular is very opinionated and you must find how to do things its way. Avoids taking decisions but can be more difficult for specific cases.
- Backbone is more flexible as it is less opinionated. You are required to make a lot of decisions.
- Angular is easy at the beginning. After learning the basic stuff the curve gets steeper. Has lots of peculiarities.
- Backbone is easy to learn but requires knowing 'best practices' to make good design decisions. Usually, it needs other libraries (Marionette) to get things done. This increase the difficulty.
- Angular is the winner here thanks to all built-in features.
- Backbone requires a lot of boilerplate code or libraries.
- Angular is starting to get interesting with Angular UI.
- Backbone has tons of plug-ins.
- Angular: 80k
- Backbone: 18k
However, Backbone requires Underscore and probably a template engine (Nunjucks).
- Backbone: 18k + 14k + 19k = 51k
- Angular is declarative
- Backbone follows unobtrusive principles
There is bit of controversy regarding this point. Unobtrusive principles say that the HTML should not mix functionality and presentation. However, declarative principles applied on web development aim for freeing the developer from low level DOM manipulation tasks as it describes how the UI should change as your application state changes.
Some discussions to throw in more insight:
- Is 'ng-click' a good practice?
- Don't the data-attribute options conflict with Unobtrusive Javascript principles?
Angular (doc)
<!doctype html>
<html ng-app>
<head>
<script src="http://code.angularjs.org/1.2.0-rc.2/angular.min.js"></script>
<script src="script.js"></script>
</head>
<body>
<div ng-controller="HelloCntl">
Your name: <input type="text" ng-model="name"/>
<hr/>
Hello {{name || "World"}}!
</div>
</body>
</html>function HelloCntl($scope) {
$scope.name = 'World';
}<html>
<head>
<title>Hello world using a Backbone.js view!</title>
</head>
<body>
<div id="main">
</div>
</body>
</html>$(function(){
//Backbone code - begin
var HomeView = Backbone.View.extend({
id: "hello-world-id",
tagName: "div",
className: "hello-world",
template: null,
initialize: function() {
_.bindAll(this);
this.template = _.template('<div>Hello <strong>world!</strong></div>');
},
render: function() {
this.$el.html(this.template());
return this;
}
});
//Backbone code - end
var test = new HomeView();
$('#main').append(test.el);
test.render();
})AngularJS is way bigger, provides a much higher level of abstraction and is very opinionated on how you should develop your app. It's a complete solution, with testing environment and philosophy behind it... That means, building an app is super fast, but it doesn't have to fit everyone nor every app. -- Vojta
Backbone trumps ultimate flexibility over developer convenience. Suffers of a serious lack of features and developer productivity. There are lots of plug-ins to compensate for this, but then you will be learning Backbone and something else on top. Backbone can also be very tempting because of its big community and the ecosystem, but this advantage will disappear as the other frameworks become more popular. -- sporto
Other interesting articles:
- Experience with AngularJS (Interesting discussion in comments)
- HackerNews: AngularJS intrusion
Web Components seems to be The Next Big Thing. It is a W3C draft for the time being, but it's supported by Google and Mozilla.
Google is working on Polymer, a preview-like library to give developers a way to play around with the upcoming features of of Web Components API.
Angular is already providing what Web Components is aiming for. As the Web Components API become standardized, their plan is to substitute its implementation for native calls in order to improve efficiency and provide retro-compatibility with old browsers via polyfills123. It will then be a sort of jQuery level of abstraction plus an opinionated framework and test environment.
Backbone seems to be left out of the picture if Web Components really is the next big thing, or at least I was not able to find any relevant information on their plan towards the new API.
The situation is the following:
- The Registration Form will be the first component using MVC
- It should serve as a guide for future implementations
- Regardless of the technology used it must be a seamless implementation
- It will probably require a major refactor of the current prototype
Since we should anyway invest quite some time improving the Registration Form, we might as well go for the most convenient framework for Indico in the long run, which may not be Backbone. Backbone is not so much a framework but a Library. It's lighter and more flexible, but it means that YOU have to write the code and take decisions. It can be empowered with Marionette, but it increases the size and increases the complexity of the solution.
The lack of flexibility of Angular may play against us in the beginning as we'll feel tempted to find workarounds with jQuery, but its opinionated approach and built-in functionalities will surely improve our efficiency and make the front-end less bug-prone. As for the cost of exit, it might be more difficult to go away from Angular, but I think that's only because we are assuming that the popular technologies in 4~5 years will still be based on jQuery and templating engines instead of declarative HTML.