BackboneJS vs JavaScriptMVC vs KnockoutJS [closed]

Question

I want to use a JavaScript framework for a complex web application. I have been looking at Backbone.js, knockout.js and JavaScriptMVC. Being pretty new to client side JavaScript heavy web apps, I'm not sure which one to pick. Each one has a pretty different approach to separate the concerns. Model/View/Controller vs Model/View/ViewModel vs Model/View/Collection.

What do you guys think? What are the deciding factors? Which one would be the easiest to pick up? What has your experience been like?

Elisavetpol

possible duplicate of Knockout.js vs Backbone.js (vs ?) – Callous

Sorry, but I feel like this is subjective and will solicit discussion rather than be a good Q&A, so I'm voting to close as not constructive. I'd love to see a blog about this sort of thing, but I don't think it's a good fit for Stack Overflow. – Frediafredie

Answer 1

You can't go wrong either way especially if you are building a complex javascript UI. If you choose not to use either, you will likely wind up with a lot of difficult to debug code. I personally like Backbone but they are both lightweight and allow you freedom in your templating language (I use JQuery templates). I think what made me choose Backbone was the way Knockout mixed its components in with your html:

<span data-bind="text: myItems().count"></span>

You may be able to avoid using constructs like the above with Knockout but that was enough to throw me toward Backbone. I also liked the fact that backbone has dependencies on both underscore and jquery which were already in use in my projects.

Phooey

I'm with you up to a point on using a framework here. For big apps where complex javascript ui is everywhere, I think it's worth trying out. But for either apps that only do complex ui in a couple places, or small teams with limited client-side expertise, I'd say no, don't do a complex javascript ui, or just roll it yourself, since it will be easier to debug. – Rhizocarpous

@HostDude: The funny thing is that one half of users say that such declarative bindings are The Right Way, whereas at the same time the other half says it's evil. Both are right :) Personally I think that everything is more than ok provided you don't use any attribute lookups, just plain&simple "text: myItemsCount". In other words, I'm quite convinced that data-bind attribute is as evil as class, i.e. not at all :) – Wieldy

Agree with Tomasz, my view on it is more personal than anything else. I just get a headache looking at html code to find javascript. I like having separation, but as I said, its my own personal peccadillo and nothing more. – Phooey

IMO inline "declaration of bindings" is bad because it obfuscates and muddies the HTML. In fact, I remember the day when everyone put TONS of inline-onclick JavaScript in the HTML. Then...jQuery came along and really opened-up the idea of non-obtrusive-separation...and people began touting the idea as sacrosanct. So now...how am I supposed to believe that obtrusive-HTML-attributes are somehow okay or better? The answer is...they aren't! Let's face it...unofficial markup takes-away-from the REAL HTML...which is the definition of obtrusive. – Galen

Why do you care about mixing simple expressions into your view? Often being a separation Nazi just isn't as easy & practical. You have to tie your model to the view somehow, either directly in the view (Knockout), or in the code by somehow referring to bits of the view. Doing it all in the code-behind via class/attribute bindings is more verbose, as you now have the model's field, a view label and a binding expression, all of which you must keep in sync. You also end up with very view-specific JS functions to bind to for stuff like element visibility, which you could just mix-in with Knockout. – Gissing

Answer 2

To build on HostDude's comment - it's a feature, not a bug :) Part of the concept of knockout is that there's a layer inbetween your Controller/Model and the View. This lets us modularize our HTML into small components that include the data mapping.

So yes the JS bindings are mixed in, but they are not mixed into raw HTML - rather they are added to tiny modularized Jquery templates. By adding those data bindings in explicitly at the jQuery template level, we have total control over what's mapped to what -- without disturbing our underlying application data model at all :) I love Knockout!

Fatherhood