Rationale for developing the Iugo one-way binding library
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
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.
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.
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.