As someone who works on Backbone.js, the level of conversation in the blog post and this thread is a bit disheartening. Client-side libraries aren't just matrices of features to be checked off ... we're talking about the style in which you think about and work with the concepts that construct your user interface.
I'd tend to think that attempts to glom together Backbone.js and Knockout.js will produce something less than the sum of their parts.
Most of Knockout's API deals with binding JavaScript objects to web forms. If all of your web app's UI is essentially a series of web forms, then great! You're all set. The Knockout examples demonstrate this ability: http://knockoutjs.com/examples/
However, if your UI starts to move in interesting directions beyond filling out a series of forms, then Knockout doesn't have much to offer you (see LargeWu's comments on this page).
On the other hand, Backbone's philosophy is that your UI is your business -- jQuery is already great at extracting data from forms and other elements in the DOM, and there are already a large number of wonderful templating libraries for rendering HTML from JS objects. Instead, it focuses on helping you model your data in the browser: providing events you can observe whenever a model changes state, adding essential functions like "map", "filter", "find", "groupBy" and "any" to collections of models, giving you simpler declarative bindings for DOM events in your views, so that you don't have to worry about whether a particular piece of HTML is visible on screen or not, and so on...
But really, the best proof of "UI wizardry" is in the pudding. If you haven't scrolled through it recently, I encourage you to check out some of the amazing apps built with Backbone over the past year: http://backbonejs.org/#examples
I'm a user of Backbone, Coffeescript across several projects - and generally a fan of your work. However, your comment makes me feel like you are missing what your users are saying and falling back on your opinions about code vs considering the actual utility of the library.
You can't say "we're talking about the style in which you think", and then say "the UI is your business", and then be disheartened when developers handle the UI with a library like knockout.js.
I write apps to provide a user experience and backbone only provides a conceptual model for a portion of this (specifically the model, collection / syncing). Its extremely clean and elegant.
However, backbone does not provide an elegant conceptual model for the UI/DOM. Using declarative bindings and JS generated templates is just fine from a coding point of view (I've built a few apps this way), but frankly its not a very powerful mental model - nor is it necessary consistent with the design patterns in backbone that make it shine.
I'll tell you the conceptual model of using a view model to control html templates is more empowering. I don't like the syntax and a lot of things about Knockout - however to me knockout is a nice abstraction on top of jquery event bindings, much like Backbone.sync is a nice abstraction on top of $.ajax.
Hey -- it's great to have the discussion. You describe a "nice abstraction on top of jQuery event bindings"... I'd be very curious to know, without any particular implementation in mind, what would you consider to be an ideal API to work with in JavaScript, to control these pieces of HTML UI? Do you have any (pseudo)code you could share?
1. A conceptual model that describes the input / output between DOM and user.
2. More explicit enumerations of event bindings
3. Explicit link between user interactions/events and constrained DOM manipulation
- to match conceptual model.
4. Defining all viewable elements in HTML templates
5. Round-trip syncing between HTML and data models
Let me know if you think inputs are interesting or would want any more detail around concepts.
disheartened? we've basically said the same thing.
as for the wizardry - it's jquery (or zepto or something else), not backbone that does this. while backbone integrates with and uses jquery heavily in the views, i don't think it's a fair claim to say backbone creates facilitates those user experiences. it helps us organize our code effectively so that we can create those user experiences in a well structured manner.
and come on, Jeremy... you know how much I love backbone! it's 80% of what I blog about these days! :)
Your modelbinding plugin looks like it handles form-model binding really elegantly. Any intention of packaging it as a gem as well? I've been using the backbone-rails gem and modelbinding would go nicely with that..
I thought about that when I first wrote it but decided not to, because it's not a ruby app. The backbone-rails gem provides some convenience generators and other things... but I'm not sure I see the value in packaging the modelbinding plugin as a gem. Is there a specific reason you would like to see that?
Sorry for the late reply. I personally like having gem wrappers as it makes installation, upgrading, checking for upgrades, and removal easier. These are all just little things, but they add up over many plugins.
I'd love to have documentation for this kind of frameworks available in a downloadable PDF. I know it is probably often updated, but so can a PDF be. The reason for me wanting this, is that I usually get into the proper focus on places without a good internet connection, like when I'm travelling (airports, flights, trains, etc).
> and there are already a large number of wonderful templating libraries for rendering HTML from JS objects
Can you list the names of some of these, out of curiosity? I'm building some new stuff and it seems like this is the way to go, but all the ones I've seen have been way too heavyweight.
Sure -- I tend to strongly prefer libraries that simply allow you to interpolate JavaScript, nothing more and nothing less, so our Underscore.js templates work fine: http://documentcloud.github.com/underscore/#template
On the other hand, if you're looking to share templates between the client-side and server-side, and you're not using JavaScript on the server end, there's a strong case to be made for "logic-less" templates that can be rendered (at least in theory), by Ruby or Python just as easily as JavaScript. Check out Mustache: http://mustache.github.com/
There's also HAML, Jade, Eco, Handlebars, and many, many more.
I'd tend to think that attempts to glom together Backbone.js and Knockout.js will produce something less than the sum of their parts.
Here's Knockout's documentation: http://knockoutjs.com/documentation/introduction.html
Most of Knockout's API deals with binding JavaScript objects to web forms. If all of your web app's UI is essentially a series of web forms, then great! You're all set. The Knockout examples demonstrate this ability: http://knockoutjs.com/examples/
However, if your UI starts to move in interesting directions beyond filling out a series of forms, then Knockout doesn't have much to offer you (see LargeWu's comments on this page).
On the other hand, Backbone's philosophy is that your UI is your business -- jQuery is already great at extracting data from forms and other elements in the DOM, and there are already a large number of wonderful templating libraries for rendering HTML from JS objects. Instead, it focuses on helping you model your data in the browser: providing events you can observe whenever a model changes state, adding essential functions like "map", "filter", "find", "groupBy" and "any" to collections of models, giving you simpler declarative bindings for DOM events in your views, so that you don't have to worry about whether a particular piece of HTML is visible on screen or not, and so on...
But really, the best proof of "UI wizardry" is in the pudding. If you haven't scrolled through it recently, I encourage you to check out some of the amazing apps built with Backbone over the past year: http://backbonejs.org/#examples
(with all due apologies for boosterism)