Matt Prokes

[digg=http://digg.com/programming/Why_I_am_on_the_fence_about_jbind_for_jquery] DEJA VU?!?! doesn’t the dom already do this?

So then why are we doing this modeling in jbind?

The history, I was recently introduced to a tool for binding data to a markup template called jbind. While in theory its not a bad idea I get this weird feeling we shouldn’t be using it, ESPECIALLY if you are using jQuery and even more funny its a jQuery plugin .

So let me explain the reasoning for this feeling, in html we have these neat things called classes. Classes allow you to effectivly “tag” markup as being a “grouping” of data. From there you simply just execute a property selector query and wala you got your data. Its very nice from a WYSIWYG perspective. Now jbind is mainly for automatic binding of data to a templated record set, and then the syntactical niceness is created around each record upon population.

That is great and all, except there is a requirement to generate a type of in-script model-view combo. jBind functionality can be effectivly implemented without the requirement of the library if perhaps a bit better judgement is used during the creation of the webapplicaton.

So to prove my point, lets give an example of what jbind would be best applied. A tableset of data.

This effectively says create a parent div, create 2 children, and inject the value of blah and cool into those children. What happens is jbind will runs through all nodes, and identify where to put data. While this is great if you are doing nothing with the data and the nodes that you are binding, it sucks for all other cases.

This is because you need to create a sort of “event callback” if you need to do more to the node upon the data injection, and then do even more work just to pull the data back out again, modify it. We are not even talking about adding events to the dynamically created nodes, which also will require more work.

What if we did this:

What happens here is you var x = $(‘.parent:first’).clone(), and inject the data into the template like this, x.children(‘.blah’).text(value); and x.children(‘.cool’).text(value);

Finally appending it to $(‘.parent:first’).parent.append(x);

This is nice because you do not need event callbacks on node creation; the data manipulation, as well as binding of events to the created nodes can happen on the clone as always. You also have html that has classes on it, and can later be queried for further manipulation, or just seeing what data is within that scope. The idea from what I percieve as far as jbind goes is to remove the need for classes, why, I don’t know classes are great.

So to conclude, I am not saying jBind is bad really, it is more efficient if you want to spit some json data out in the wild without doing anything extra. Prototyping for instance may be served well with this solution. Though I would argue that if you are not doing anything other then that, then maybe you shouldn’t be doing your stuff in js in the first place and maybe just do it through the back end. On the other hand, if you are going to need to modify the data, add events to dynamically created nodes, etc..

Then it is likely jbind will not be for you, and will just end up being more work then it is worth, since dom has a solution to this that is already pretty good, and much lighter and flexible then anything jbind is offering at the moment in many respects.

This entry was posted on Wednesday, February 25th, 2009 at and is filed under Javascript. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.