State of the Backbone | Hacker News Reader

State of the Backbone

blog.documentcloud.org

110 pointsknowtheory26 comments

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)

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.

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

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.

Thank you.

Try AngularJS, that thing is truly a miracle.

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

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.

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

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

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.

Thanks! I'll click along as I listen.

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

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

Thanks

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

Edit: Ah beaten to it!

just found that @krunkosaurus has a handheld recording:

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

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

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

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.

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

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

Backbone.js could start getting more opinionated IMHO :)

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

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.

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

Reply on news.ycombinator.com