Agnostic Data Binding with Rivets.js

Agnostic Data Binding with Rivets.js

For a long time I’ve been against the idea of data-binding. Like many people I started using it with Flex, then used it with AngularJS, and Knockout.

I’ve been opposed to using data-binding for a long time, until recently when I found a data-binding library that makes data-binding optional, easy to write, and framework agnostic.

What is Data-Binding?

A data-binded system keeps the data model layer and the presentation layer of your code in sync with each other. For example: if a variable, containing the user’s name, changes the UI updates automatically to reflect that change.

You might say “that sounds great” and for some things it is very useful. My problem with it is when a framework forces (or nearly forces) a developer to use it to update the Interface/DOM. Flex and AngularJS are both force (or nearly) data-binding to be used.

What is Rivets.js?

Rivet.js is a data-binding library very similar to AngularJS’s data-binding library but because it’s an external library using it is optional.

You create a variable that will represent a UI element in your front end code. This variable may be an array of objects, a string showing the user’s name, or a boolean that represents if a part of the page should be shown or hidden. When this variable’s value is changed, the interface changes automatically. This is called one way data-binding.

The system also works the other way. When a UI element’s value changes the variable holding the change is updated. This is called two way data binding.

How is it Better than Libraries like Knockout?

Other data binding libraries exist and are often built into frameworks, like Flex, AngularJS, and Ember.js. Some libraries are standalone.

Knockout is probably the most used standalone data-binding library. While it’s a nice data-binding framework it’s not as easy to learn as Rivets.js.

Example Models

Building a model layer in Knockout is much harder than building one in Rivets.js.

This is a simple model layer in Knockout.

var ViewModel = function() {
	this.firstName = ko.observable('Alan');
	this.lastName = ko.observable('James');

	this.fullName = ko.computed(function() {
        	return this.firstName() + " " + this.lastName();
	}, this);
ko.applyBindings(new ViewModel());

This is a model layer in Rivets.js.

var user = {

		return this.firstName + ' ' + this.lastName;

rivets.bind($('body'), {
	'user': user

Between the two I can more easily follow the Rivets.js example.

Not only is it easier to read, it also integrates better with existing frontend model libraries like JS-Model or Marilyn.

DOM Attributes

Both Knockout and Rivets.js also add custom attributes to the DOM, which are used as flags to tell the libraries where and how to bind.

Knockout’s custom attributes are sometimes harder to follow than Rivets.js’s.

Here is a Rivets.js binded HTML view.

<div rv-each-item="collection">
	<input rv-value="" />

Notice the rv-each-item. This is a way that Rivets.js loops and names the iterated item in the array it’s looping over. It’s the data binding equivalent of

	// item is now the iterated variable

On the other hand here is the Knockout equivalent view.

<div data-bind="foreach: collection">
	<input data-bind="value: name" />

It doesn’t name the variable being looped over. You just use properties of it. While this is understandable, to me it’s harder to follow.

Bigger Differences

Bigger differences are harder to talk about because they involve how the data-binding works behind the scenes.

Knockout seems to alter the prototype of any variable it’s binding to. This means you have to treat variables in Knockout like functions that can get and set values. This changes the way you interact with code, which means Knockout can’t be dropped into a project without making changes to how object properties are accessed.

Lastly knockout doesn’t easily work well with Pub/Sub libraries. This is because of how Knockout alters the prototype. Knockout basically wants to be your only model layer, data-binding is a secondary thought.

By contrast Rivets.js can be dropped into a project without any major alterations to code not relating to data-binding. It has only one job, it’s just a data-binding library that doesn’t get in your way.

I love when libraries can be summed concisely.


  1. +1 on this… Angular and all other frameworks get too much hype than I think they deserve. Honestly rivetjs is the best thing since sliced bread when it comes to clarity of code and also just plain-ol’ getting the job done.

    I start to wonder why UX applications are getting so much investment when UX is like any other aesthetic design (building, art, music, or otherwise) it’s only meant to be around for 1-2 years tops before you throw it away and create better leaner experiences.

  2. Thank you for a clear and easy to understand overview of Rivets js! 🙂

Leave a Reply