An Intro to Backbone.js: Part 2 - Controllers and Views
liquidmedia.ca
liquidmedia.ca
I have only started to develop something with sammy.js (also a JS framework with routing and so on), and it already seems to me it might not always be a good match. For example sometimes I only want to render a part of the screen/web site again, not the whole thing. What then should be my route? I guess it could work like the AJAX updates in Rails, but still, I wonder if it is too complicated to go through all the routing and so on.
Why not just bind events to actions directly, and update at will from inside the event handler?
What advantage do backbone.js models provide over javascript objects?
I think that the client/server distinction is in a state of flux right now. As we make richer applications on the web, a lot of that server complexity is being moved to the client. The goal of Backbone is explicitly to deal with this.
Backbone is, however, designed to deal with fairly complex applications. If you've got something that's relatively simple, then Sammy might be the way to go.
What Backbone does provide is enough structure to encourage nice, clean, modular designs. Something that JavaScript developers haven't had to think about quite so much in the past. The other options that attempt this are huge, and don't provide a lot of the flexibility that web developers are used to.
If you think you've got a simpler, cleaner idea, then by all means give it a try, but out of the options out there, Backbone is my favorite.
Say you have an onscreen cat picture which can be moved around the screen (it has x,y coordinates). So you create a CatModel with attributes called x and y. You have a CatView which has an associated div - the cat picture. Now you can just bind your view to the "change:x" and "change:y" events of the CatModel, and have it update onscreen whenever the data model changes. Maybe every time you move the CatView with your mouse you call model.save() - that will be sent as a REST request for you. Now call model.fetch() every 5 seconds, and the onscreen cat picture will move to whatever state is held on the server. The code is clean, and tiny.
I guess what I'm saying is that it will only take you 5 minutes to create a massively multiplayer online cat picture moving game, with far less code you might otherwise have needed.
It sounds to me like you're using controllers because it seems logical coming from a Rails background, not because you need to. Take a look at the example Todo app - no controller, entirely atomic screen repaints as needed via collection/model to view bindings.
The models provide a framework for things like validation or presenter methods and keeping data and methods separate as well as a framework for event binding with a really, really nice syntax.
The idea with Backbone is to provide structure for large JS applications that involve manipulating state in the client. Too often, they can devolve into jQuery spaghetti, all updating a nested global JSON object. Backbone models provide a large number of data manipulation functions (map, reduce, filter, reject, any, etc...), RESTful persistence for your data, as well as events you can hook into, so that your models and views are notified whenever the state changes.
In the end, instead of peeking into a blob of JSON, tweaking the DOM manually, and making a $.ajax call, the hope is that you'll be able to write:
note.save({title: "Lorem Ipsum"});
Also, note that Backbone has quite a different philosophy than Sammy. For more on that, see: http://news.ycombinator.com/item?id=1887563
That said, they take a very different approach: less about data modeling and events, and more about binding JSON structures tightly to specific DOM elements. I have my own concerns about if it's possible to build truly high-performance web applications with such a granular scheme -- for example, Knockout.js calls JavaScript's "eval()" on every "data-bind" attribute in your HTML. But without someone taking the time to port the same app to all three libraries, and then evaluating it with benchmarks, it's all just speculation.
Event binding, refreshing to the server, dirty tracking, etc.
Basically, the pattern is: get JSON doc from the server, inflate it into a model, hook in a view, and then as you mutate the model, in code or the UI, the UI and server are updated. Can you write this yourself? Of course. Do you want to? That's up to you.
Personally, I find Backbone's sugar most useful for views. You make a DOM element that represents your thing, and then you program in terms of that thing, and the UI "just works". It's wonderful.
Anyway, Backbone is absolutely not overkill. It's just what many apps need, and you can use as much of it as you want.
(I should point out that I don't do server-side HTML anymore. My web apps are JSON/REST endpoints that also serve a few pieces of static HTML, JS, and CSS. Everything UI-related is done on the client side. Backbone makes this amazingly easy.)
^^^^ THIS
Backbone's advantage over normal javascript objects is Backbone provides events when objects and collections change. I dislike how Backbone achieves that through force use of set() and get() as property accessors. I prefer KnockoutJS models as they look and behave like plain old javascript objects, i.e. you don't have to call model.toJSON() to use a model as an argument for a plain object.