5 ms·
Rivets.js - Binding data to views
- lylejohnson 14y agoWhy would I choose Rivets over competing options, such as Knockout?
- ansman 14y agoYou'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.
- tptacek 14y agoI'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"?
- ansman 14y agoWell, 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.
- tptacek 14y agoWhat "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.
- mikeryan 14y agoMy 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.
- nestlequ1k 14y agoLooks like a pretty nice little alternative to Handlebars/Ember.js for really simple data bindings. I could see myself using this quite often.
- bdfh42 14y agolots 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.
- ansman 14y agoThis 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.
- zimbatm 14y agoAfter a quick glance it seems that it doesn't support iterations. How would you use it with a list of users ?
- mgcross 14y agoLooks like it would be possible with a formatter and the data-html binding.
- 1qaz2wsx3edc 14y agoThis is most similar to AngularJS. `data-hide` <=> `ng-hide`
- swah 14y agoHow 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?
- ansman 14y agoDon't think you can have dependencies. It just updates the specified part (data-value updates the value, data-html updates the innerHTML etc)
- joshontheweb 14y agoI'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.
- ansman 14y agoBut 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.
- joshontheweb 14y agoThis 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.
- ansman 14y agoHehe, it's not actually my code, I just found this gem and I liked it :)
- amccloud 14y agoI'm had the same exact thought. That's why I created https://github.com/amccloud/backbone-bindings https://github.com/amccloud/backbone-bindings
- joshontheweb 14y ago
- nateabele 14y agoHow is this different from/better than Angular?
- jashkenas 14y agoTake 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.coffee 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).
- jarek-foksa 14y agoIt 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.
- pantsbird 14y agoEvery 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.
- ansman 14y agoSo 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?
- netghost 14y agoNeat 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/ https://adamsanderson.github.com/ivy/ Lots of people are looking for better ways to deal with data in their views :)
- arunoda 14y agoGreat idea. I like it. I'm looking at this as a template engine? Or am I missing something?
- ansman 14y agoIt 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.
- arunoda 14y agookay. I got it. Actually this replaces separate templates (at least for some cases) for your app. How about the browser compatibility? Have you tested?
- arunoda 14y agoCan you please describe what is the use of the adapter? How can it be useful?