BackboneJS vs JavaScriptMVC vs KnockoutJS

10,589

Solution 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.

Solution 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!

Share:
10,589
Drew
Author by

Drew

Updated on June 06, 2022

Comments

  • Drew
    Drew almost 2 years

    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?

  • RyanW
    RyanW about 13 years
    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.
  • Tomasz Zieliński
    Tomasz Zieliński over 12 years
    @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 :)
  • AlexGad
    AlexGad over 12 years
    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.
  • Prisoner ZERO
    Prisoner ZERO about 12 years
    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.
  • Alastair Maw
    Alastair Maw almost 12 years
    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.