Rivets.js - Binding data to views(rivetsjs.com)
rivetsjs.com
Rivets.js - Binding data to views
http://rivetsjs.com/
14 comments
I've never been able to get behind defining data relationships in the DOM. I do like the idea of not having to re-render the entire view or explicitly update individual elements on data change events, but i wish there was a better way. Perhaps a view could contain a hash associating data change events with element selectors. Then the view knows which element to update. That way the html clean and ignorant of the underpinnings of the app.
I'm had the same exact thought. That's why I created https://github.com/amccloud/backbone-bindings
Nice, This is cool, pretty much what I had in mind with some cool additional features. It seems like you could just pass the template to bindModel, fire a change, and have it do the initial render and cut out _.template altogether.
Template markup is generally more complex than that and certainly more complex than your bindings. The ability for designers to edit and change the markup without having to look at code is a plus for using templates. Not to mention as a backbone convention it is expected so it makes things more portable.
But on the other hand the view has to know about the template.
Change a tag name or class name (which I think is far more common than attribute names) would then break the relationship.
Change a tag name or class name (which I think is far more common than attribute names) would then break the relationship.
This is true. However, the view already has to know about the template. The only difference is the how much it knows. It will add some extra responsibility if you change your classes a lot but I think I might prefer that over muddying the html with attributes and filters. Another thing that would be cool about a hash in the view is you could apply filters and presentation logic to the values there in a DRY way. Hope my tone doesn't come across as combative or dismissive. Thanks for taking the time to open source your code. I've just been thinking a lot about this recently.
Hehe, it's not actually my code, I just found this gem and I liked it :)
Why would I choose Rivets over competing options, such as Knockout?
You're comparing apples and oranges, Knockout is a lib for structuring your app while this is a small lib that doesn't do anything more than data binds.
This could be used with backbone or any other lib that doesn't have data binds.
This could be used with backbone or any other lib that doesn't have data binds.
I'm not sure that's true; KO is mostly data binds too, and doesn't impose much of any structure on your application.
Since it would make no apparent sense to use both KO and Rivet, the original question seems germane.
Is the answer then "because Rivets does less"?
Since it would make no apparent sense to use both KO and Rivet, the original question seems germane.
Is the answer then "because Rivets does less"?
My answer would be yes.
But thats for us, we do development on a framework we've built thats based on Backbone's elements (but thats just a part) one of the attractive things about Knockout has been its data-binding. So we'll look at this to see if we can add it to our stack.
One thing we really like about Backbone is you can rip out the component parts (Models, Views, Events etc) and add them to your own stack/framework, this seems like an extension of that model, which works well for us. Not that knockout does "too much" we could likely switch to using knockout, but that would likely be a big change to the stack we use. This is something smaller that we can add to our existing code without worrying too much.
But thats for us, we do development on a framework we've built thats based on Backbone's elements (but thats just a part) one of the attractive things about Knockout has been its data-binding. So we'll look at this to see if we can add it to our stack.
One thing we really like about Backbone is you can rip out the component parts (Models, Views, Events etc) and add them to your own stack/framework, this seems like an extension of that model, which works well for us. Not that knockout does "too much" we could likely switch to using knockout, but that would likely be a big change to the stack we use. This is something smaller that we can add to our existing code without worrying too much.
Well, they do have different goals. Rivets wants to be a small plugin that works with any framework while knockout is also designed to bring structure to the party.
For me it's like comparing an engine with a car.
One big upside to knockout is that the lib is a little under 3KB minified while knockout is 40KB minified.
I prefer having smaller libraries that are really good at what they do.
One big upside to knockout is that the lib is a little under 3KB minified while knockout is 40KB minified.
I prefer having smaller libraries that are really good at what they do.
What "structure" are we talking about with KO? I've been using it for a couple weeks just to do binding, and I haven't noticed it introducing any particular structure to my applications.
It is nothing like Backbone, which really seems to want you to write a "Backbone" app.
It is nothing like Backbone, which really seems to want you to write a "Backbone" app.
Take a peek at the implementation if you haven't already -- it's easy to browse through in a minute or two:
https://github.com/mikeric/rivets/blob/master/src/rivets.cof...
... although one thing to note is that it looks like it doesn't currently support IE (< 9).
https://github.com/mikeric/rivets/blob/master/src/rivets.cof...
... although one thing to note is that it looks like it doesn't currently support IE (< 9).
How is this different from/better than Angular?
Every time we move away from this ugly logic embedded in the view idea some Rube Goldberg fan (probably with a java struts or other such messy room coding) stacks this stuff back into the world. The fact of the matter is program problems are never difficult enough to merit this kind of abstraction and if in some future where this is necessary it certainly won't be this version or in this syntax.
To summarize; Not only do I think this is excessive beyond MVC, but it is also jumping the gun by a decade minimum. I don't need smarty templates, I don't need overloaded HTML attributes and I don't need this. Good day to you.
To summarize; Not only do I think this is excessive beyond MVC, but it is also jumping the gun by a decade minimum. I don't need smarty templates, I don't need overloaded HTML attributes and I don't need this. Good day to you.
So how would you solve updating a view after rendering? Do you want your view to know about the markup in your template.
I'm really curious, is there a better way?
I'm really curious, is there a better way?
It would be great if we could just have Object.watch('property', callback) or similar method defined in ES.next.
I don't want to wrap my models with ugly frameworks, all I need is a way to fire a callback when my model changes.
There is a lot of talk on various MVC frameworks, but lets not forget that manual syncing of views and models has some advantages, e.g. you can improve performance by combining many subsequent DOM operations or by temporarily detaching the parent from DOM tree.
I don't want to wrap my models with ugly frameworks, all I need is a way to fire a callback when my model changes.
There is a lot of talk on various MVC frameworks, but lets not forget that manual syncing of views and models has some advantages, e.g. you can improve performance by combining many subsequent DOM operations or by temporarily detaching the parent from DOM tree.
Looks like a pretty nice little alternative to Handlebars/Ember.js for really simple data bindings. I could see myself using this quite often.
Neat idea, I like that it's agnostic about the model layer. I have to admit that I'm fiddling around with a very similar library (still a work in progress):
https://adamsanderson.github.com/ivy/
Lots of people are looking for better ways to deal with data in their views :)
https://adamsanderson.github.com/ivy/
Lots of people are looking for better ways to deal with data in their views :)
This is most similar to AngularJS. `data-hide` <=> `ng-hide`
How do you work when you have two or more of those depending on each other?
Also, when a data value changes do you re-render the whole thing, of just the affected node?
Also, when a data value changes do you re-render the whole thing, of just the affected node?
Don't think you can have dependencies.
It just updates the specified part (data-value updates the value, data-html updates the innerHTML etc)
It just updates the specified part (data-value updates the value, data-html updates the innerHTML etc)
lots of knowledgeable comments being made here already so clearly this is an interesting area but - what is the use case for this? I don't understand why I might need it.
This is pretty much only useful for JS apps.
The problem comes when you have data changing after a view has been rendered.
Rendering the whole view again can be expensive. As well as this the user might have interacted with the page in which would probably make the user loose his changes.
Rendering the whole view again can be expensive. As well as this the user might have interacted with the page in which would probably make the user loose his changes.
Great idea. I like it.
I'm looking at this as a template engine? Or am I missing something?
It template agnostic, once you've rendered your view you give rivets your DOM element and it will find the data attributes. You could use handlebars, haml or any other templating engine with rivets.
okay. I got it.
Actually this replaces separate templates (at least for some cases) for your app.
How about the browser compatibility? Have you tested?
Can you please describe what is the use of the adapter? How can it be useful?