

State of the Backbone - knowtheory
http://blog.documentcloud.org/blog/2012/06/state-of-the-backbone/

======
jakejake
Cool, that's awesome that backbone.js is building such a strong group of
developers! Apologies for pimping my own OS project but I would love to get
some feedback on my app generator that creates a backbone.js powered app based
on a DB schema. Particularly I'd be interested to know if the way I've
organized the backbone.js code looks ok, what ways could be improved, etc.
<http://phreeze.com/> (you can just look at the live demo to see it running
without downloading anything)

------
jeromegn
I tried alternatives to Backbone after my initial (and collaborative) creation
of Todos, and I could not find anything as light, as "out of the way" as
Backbone.

Loving every moments of using it.

~~~
djbender
Did you take a look at Spine? Just curious what you thought of that.

~~~
jeromegn
Both seem to do the same thing. The syntax differs lightly.

I used it once while working with someone else's code, so it's difficult to
say, but I like the "less modular" and simpler ways of Backbone.

~~~
djbender
Thank you.

------
ender7
First of all, I'm really enjoying my time with Backbone!

Unrelatedly, but in case anyone's listening, there's something I keep wanting
in Backbone, but perhaps my architecture is wrong:

    
    
      // inside my view
      this.model.on('change', this._onChange, this);
    
      // later
      this.model.set({ ... }, null, this);
    

This example uses a hypothetical version of 'set', which won't trigger
'change' events for any listeners whose context is the third argument. So, my
view won't receive a 'change' event after it changes the model.

Currently, when my view wants to change something, it modifies the model and
then waits to receive the 'change' event before updating what the view
actually looks like. However, this feels very indirect and doesn't always work
out too well (sometimes I have to resort to setting a 'ignoreNextChangeEvent'
variable).

~~~
hoprocker
Backbone's philosophy is to keep things very loose, and let you decide how to
couple Model<->View relationships; i.e., just setting a view's model doesn't
explicitly update the view with new model data.

I've had what sounds like a similar situation: I want to display on the view
that the model is being updated. In this case, I set a flag on the current
view when starting an action, then I watch out for 'sync' events on the model;
when the 'sync' message is raised, I perform an action based on the set flags.

------
grabastic
Jeremy's a nice looking guy, but I wish we could see the presentation. Anyone
have an alternate recording?

~~~
jashkenas
I threw up the slides (but not the live code bits) here:
<https://speakerdeck.com/u/jashkenas/p/state-of-the-backbone>

Hope that helps.

~~~
ehutch79
The presentation is mostly live demo... the slides are mostly useless.

~~~
jashkenas
Ah, well ... here's some of the code samples used: <http://cl.ly/H0Ox>

~~~
ehutch79
Thanks

------
mshafrir
Direct link to video <https://vimeo.com/43345876>

------
joshmaker
Backbone has a lot of neat features, but when I used it I really didn't like
that I had to specify the tag name, the class name, etc in a Backbone.View
object. It seems like these are part of the template logic that should be in a
.js file.

Example: [http://stackoverflow.com/questions/9365851/separating-
templa...](http://stackoverflow.com/questions/9365851/separating-template-
logic-from-backbone-view)

~~~
jashkenas
You don't have to specify those things in a View if you don't want to, by
simply telling the View what element to attach to:

    
    
        new View({el: domElement})
    

... but it's part of Backbone's goals -- which are further explained towards
the end of the video -- that a given view has an element _at all times_ , even
before any templates may or may not have been rendered.

Always having an element means that you can worry less about view state. If
all of your DOM events are delegated from the root element, you don't have to
worry about whether the template has been rendered yet, which particular
template might have been rendered, whether the data is available yet, and so
on... The events continue to work regardless.

------
wsbail29
Liked the shout-out to Robert Kieffer. Keep up the good work Jeremy.

------
laundrysheet1
Backbone.js could start getting more opinionated IMHO :)

------
trebuch3t
Backbone has pretty much changed the way I write JavaScript apps.

~~~
willtheperson
Agreed - I had my own implementation of something like Backbone out of a
frustration with all the other frameworks.

BB is just so dead straightforward that it really does get out of the way and
let's you do things the way you want.

