

Backbone.js: Hacker's Guide - jashkenas
http://dailyjs.com/2012/07/19/mvstar-2/

======
tambourine_man
Could anyone show me what kind of problems Backbone.js solves?

Not a description like “it will replace a lot of your jQuery spaghetti
boilerplate”, but some actual code:

    
    
      //this is what I had to write in jQuery
      …
      …
      //this is how I'd do it in Backbone.js

~~~
ajross
Here's my iconoclast answer (with a further caveat that I'm a systems
programmer who follows web development in my spare time, not an expert on any
of this):

Backbone (or Spine, which is just like Backbone but a tiny bit smaller and
written in CoffeeScript) is Yet Another MVC Framework. So think of it like
Rails, except this time it runs in the client browser. So instead of
translating between SQL and Ruby, you're translating between JSON and DOM.
There's a "Model" abstraction, which is just a data structure but has fancy
features like the ability to "save" it to the server and the ability to listen
for changes. And there are "views", which are just the same old DOM/CSS/jQuery
environment you know, with the single stipulation that they need to be
associated with exactly one Model. And, just like rails, there are
"Controllers" which all the guru's seem to understand just fine but that look
like huge messy piles of logic soup to the rest of us.

And, like all MVC frameworks before and after, it's subject to the framework
disease. You don't "use" MVC, you "port to it". It infects everything you do,
such that you get indoctrinated into the particular MVC subculture you've
chosen and spend your time screaming at other people on the internet instead
of writing code ( _edit: c.f. rimantas below._ ).

Stay away. Or if you must use it, be sane and safe, and stay away from the
culture.

~~~
lazerwalker
Backbone doesn't actually have controllers, only models and views. Even
without that technical distinction, I'd still be hard-pressed to actively
describe Backbone as MVC (especially compared to other JS frameworks like
SproutCore or Ember, which do actively force you into a more traditional MVC
structure).

It doesn't actively encourage you to structure your code in any particular
way, other than "separate your business logic and DOM logic", which you
probably want to be doing anyway if you're building the sort of JS-heavy rich
web application that people tend to recommend Backbone for.

~~~
sophacles
I have a couple apps that use backbone.

* One is just a fancy web page, it uses Backbone in a traditional sort of MVC way. I don't use the router tho, doing my own thing with pushState and gradual enhancement. Lots of views and models keep things separated sanely.

* Another uses it because I wanted an easy mechanism to map between storage and app. I think the only reason I used views in this case was because I had already been using a template, so I just threw it in a view to tie events together.

* The last I don't use any of the "talk to the server" features, but use the event model because it allowed for easier reactive style stuff with events and forms, and tying into canvas frameworks than alternatives. The data model doesn't fit nicely with Backbone, so I did my own thing.

The point is, Backbone keeps it easy to not get sucked into the whole model if
you don't want to.

------
netghost
In case anyone's curious I came across this post about using Backbone for rich
command line app:

<http://tobyho.com/2012/07/19/backbone-charm-text-based-ui>

Pretty neat, I would never have thought of using it outside the browser.

