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.
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.
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.
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.
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.
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.
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.
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.
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):
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.
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?
