Backbone.js Tips : Lessons from the trenches | Hacker News Reader

Backbone.js Tips : Lessons from the trenches

devblog.supportbee.com

95 pointsprateekdayal22 comments

This is a very useful post -- unfortunately, it describes an all too common occurrence: treating a single example as gospel truth. I've gone ahead and added an explicit "There's More Than One Way To Do It" section to the FAQ.

http://documentcloud.github.com/backbone/#FAQ-tim-toady

Edit: Also, for folks looking for useful patterns, I'd recommend scrolling through and viewing source on a few of the increasingly lengthy list of example apps:

http://documentcloud.github.com/backbone/#examples

Pandora, Trajectory, and SeatGeek were added recently, and there are more that are waiting for a blurb, including Sky+ and GroupOn:

http://skyplustv.sky.com/tv-guide

http://www.groupon.com/now

Hi Jeremy,

Thanks for the comment. Also, thanks a lot for Backbone, underscore, coffee and jammit. Half of our stack is your code :)

Excellent annotation!

'Collections should keep track of their views' seems badly explained. You're not keeping references to views on a collection, you're keeping a reference to subviews inside a view that uses a collection. The code is correct, and agnostic to whether the collection is local to the view, or a shared collection.

Thanks for the feedback. I will update the post.

Yes, collection should keep track of the subviews. Not the view that initializes the collection

indexOfTicket and prevTicket are unused in your collection's addOne() function.

</nitpick>

Sorry about that. Actually they are used in the real code but I removed a lot of other stuff when I copied over. I should have deleted more carefully

Actually I goofed up while typing out the post a bit. Views that contain subviews should keep a track of the sub-views. Not collections. I have updated the post. Sorry for the confusion

Just like to add that Jashkenas has updated the Todo example code that this article refers to (3 hrs ago at the time of this comment).

The link in this article in the first section "Models should not know about Views" should link instead to http://bit.ly/pfnFYu

(gotten from the github history)

To summarize: MVC, MVC, and more MVC.

Keep things decoupled with abundant usage of events.

For somebody new to MVC in JavaScript, how are models commonly implemented? Some kind of AJAX?

AJAX will be the lowest layer. Think of it as the database calls in an ORM like activerecord. You have an object, you do some validations or perform some logic and when you want to persist it on the server, you make an ajax call. In backbone you will call save on the model and it will do a POST or PUT request based on whether this is a new or already existing model.

Would this be a good MVC framework for Javascript: http://javascriptmvc.com/ ?

Yes. It is a popular one. You should also look at http://knockoutjs.com/ and http://maccman.github.com/spine/

Client-Side MVC isn't that widespread yet, so I'm not sure you could speak of a "common implementation" per se.

But models are generally just objects. They know how to handle and manage data. Nothing spectacularly complex.

As far as saving state goes there are different ways of doing it, the vanilla way backbone uses however seems to simply be making REST requests to the server.

When building apps on Node.js, we use the same Backbone models and collections on both client and server. The difference is the Backbone.sync implementation:

* On client Backbone.sync does AJAX calls

* On server Backbone.sync talks to database

In some cases we also do Backbone.sync via socket.io

Note: Backbone.sync is the method all I/O operations on Backbone.js models and collections call. You can either use the default AJAX-based implementation that Backbone.js ships with, or override it with your own.

Except I think it's more like MVVM in client-side JS code.

You don't really have a request dispatcher on the client side (a controller). Instead, you have a View Model, which is basically a representation/manager of the View in JS code (where the View itself is HTML).

One could easily argue that Backbone is the controller. Or even the EventEmitter.

The View itself is a javascript object with certain behaviours, the HTML is merely the representation of said object ... or conversely, it could be thought of as yet another model, with CSS being the view and what JavaScript considers a View being the controller for the actual rendering.

... it gets complicated.

most of these is applicable to any MVC framework.

After studying backbone and other such Javascript MVC frameworks, I realized that they are not necessary.

JS has a wonderful MVC architecture built-in. all JS objects are models by defaults, all views (HTML elements) are models too, and JQuery has a lot of helper functions to simplify events.

These frameworks give you a good idea of how to organize your code better and help you standardize implementation, but if you know what you are doing, you can do it anyways.

Edit: typo

Attitudes like this are what cause giant, unmaintainable spaghetti-code front-end applications to be born.

Code becomes unmaintable when it is not object oriented, ESP for front end applications. Nothing to do with using slick looking syntax, IMHO

Reply on news.ycombinator.com