State of the Backbone

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

by knowtheory • 14 years ago

110 26 14 years ago

blog.documentcloud.org

grabastic2• 14 years ago

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

jashkenas3• 14 years ago

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.

grabastic2• 14 years ago

Thanks! I'll click along as I listen.

ehutch792• 14 years ago

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

nilliams• 14 years ago

Looks like the slides from all talks (including this keynote) are on the BackboneConf site: http://backboneconf.com/#schedule

Edit: Ah beaten to it!

knowtheory• 14 years ago

just found that @krunkosaurus has a handheld recording:

http://www.youtube.com/watch?v=yDmRRJzTo38

mshafrir• 14 years ago

Direct link to video https://vimeo.com/43345876

trebuch3t• 14 years ago

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

willtheperson• 14 years ago

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.

amackera• 14 years ago

Agreed, Backbone is great! I haven't looked much at the alternatives, though.

jeromegn2• 14 years ago

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.

djbender2• 14 years ago

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

jeromegn2• 14 years ago

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.

ddet• 14 years ago

Try AngularJS, that thing is truly a miracle.

wsbail29• 14 years ago

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

joshmaker• 14 years ago

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

masklinn• 14 years ago

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

You don't have to do it if you don't want to. Simplest way to not do it is just implement your custom `render`, and you'll have everything in an empty `div` (the default). If you want your template root to be the element's root (el/$el) as well, you can quite trivially do so by calling View#setElement from View#render:

    render: function () {
        return this.setElement($(renderTemplate()));
    }

There you are, stick that in your parent View class and now you don't "have" to specify anything in your view (which, again, you don't have to anyway).

Also, there's no logic in that part, it's just a declarative mapping of your DOM root.

(the caveats of the guy who answered on SO still apply, this will not handle re-rendering as-is and a broken template generating multiple roots will not work correctly)

jashkenas3• 14 years ago

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.

jakejake• 14 years ago

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)

ender72• 14 years ago

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• 14 years ago

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.

ender72• 14 years ago

[Addendum] A common use case where this crops up is with animations. If the user directly interacts with my view and causes the model to change, I may want the view to play an animation or otherwise respond in a context-sensitive manner. However, I usually don't want to do this if some other view has changed the model (because it wouldn't make sense or because it's off-screen).

laundrysheet1• 14 years ago

Backbone.js could start getting more opinionated IMHO :)

State of the Backbone

Related Stories