Rationale for developing the Iugo one-way binding library

Recently I built a new Javascript library for binding objects to the DOM. It’s called Iugo and you can find it here: http://iugojs.com. Now, clearly, there are other binding libraries out there, so I wanted to produce a quick post to summarize my thought process going into this project…

I first started to think about this kind of project around two years ago when I first started using Angular.js. If you are not familiar with Angular , it’s a Javascript framework which includes two-way data binding (i.e. objects are bound to the DOM and changes to those values in the DOM are bound back to the object) and a bunch of other features. It’s a great framework and my initial reaction was very positive; I quickly became a fan.

After getting a little deeper into a fairly complicated Web application, however, I frequently found myself frustrated with the framework’s complexity. In order to understand why I believe there is a place for a new data binding library I need to give a quick review of Angular:

Things I like in Angular

Two way data binding

For me, the data binding feature is the core of Angular (I expect its developers would agree). Without data binding developers often use Javascript to inject HTML segments into a document. There are numerous problems with this approach. In the same way that decoupling style and content is a good idea, decoupling markup and data should be considered a very high priority best practice.

Imaging a designer who is employed to improve the UI of your app is looking at a div elements in their browser’s inspector and they really want to change them to be an unordered list (ul/li elements). The designer also notices inline CSS is applied when a user clicks on one of the divs and they want to change that into a semantic class. The designer looks in the HTML but there that section is just missing. The actual HTML for the divs is injected in a loop in a Javascript file and the click handler which adds the inline CSS is somewhere else in the file. Would you want a designer who doesn’t know the code to make those kind of changes? Would they even find where to make them? The whole situation is a mess.

Using templating or other data binding techniques makes your code much more accessible. Designers work on HTML and CSS and can see everything. Logic can  deal purely with data and just update the model behind the UI.

That said, two way binding is an interesting thing. In one direction data binding is an easy thing to achieve. If a user updated an HTML form input it is easy for a piece of Javascript to update a model – it can just listen for the change event to be fired from the input. The difficult part is binding the model to the HTML – there is no event that fires when an object is changed. That became the functional core of Iugo – it’s a library which fires events when objects are changed.

Things I dislike about Angular


The idea behind Angular scopes sounded fairly simple when I first read about them – basically a scope is a model and it is bound to a part of the DOM. In simple Angular applications there is often only one scope, bound to the whole HTML document. When my application became more complex than that I continually found myself confused and wasting hours debugging my code to work out how to get two scopes to interact. Sure, you should design your scopes to be independent (that’s what a scope is!) but  a couple of times I realized further down the development process that I had some unforeseen need to access two scopes; at that point my options were to redesign my application from a fairly fundamental standpoint or to deal with mounting difficulties and hacks used to get around the scope system.

One mandatory feature for Iugo was the ability to access namespaced models at any point in the DOM. Not to mension a lighter touch so objects don’t need to be treated in a special way if you are using them as a model.

Being a framework

If you need a framework then check out Angular. If you have a requirement for data binding and templating then you may want to consider your options (including Iugo). Angular includes ajax helpers, scenario testing, localization, URL management, dependency injection, event listeners, test helpers (such as angular.isArray()) and a host of other features. Those features may well be useful to you but they add up to 80k minimized – about the same as jQuery; if you already use a framework like jQuery do you really want duplicate HTTP helpers, &c? Personally, I prefer smaller, modular, libraries. Iugo is 5.8k minified, less than a tenth of the size.

Not being HTML5 complient.

For the record, I think Angular may have fixed this with some kind of compatibility mode but their website is littered with examples of non-compliant code. Take the example on the homepage. They use the “html” doctype but have an attribute called “ng-app” in the document’s html tag. That’s not allowed; try it in the W3C’s validator.

Introducing Iugo

So, this those points in mind, I set about creating a simple data binding library. Iugo is:

  • Small, less than 2k minified and gzipped
  • light touch – it will complement other frameworks like jQuery
  • standards compliant, no namespaces or invalid attributes
  • modular, as it is based upon an event system for objects

I’d love any feedback anyone has, so please check out the site.

2 Responses to “Rationale for developing the Iugo one-way binding library”

  1. greg says:

    I am looking at your iugo. Do you have any additional examples that I can review? I like your simple approach and I too am looking for an alternative to the likes of Angular. I have looked at the two examples on your git repository.

    Well thank you.


  2. admin says:

    Try having a play with this JSFiddle http://jsfiddle.net/chrismichaelscott/fF4GD/. You can build out some more complex examples from there.

Leave a Reply

Your email address will not be published. Required fields are marked *