I think one of the things that Backbone really needs is some opinions on how to organise projects. Coming from Ruby on Rails, I really appreciate how that framework recommends (or forces) you to structure your stuff in a certain way (they even structure how to use Backbone inside a Rails project). Backbone feels more like a loosely connected set of tools (View, Router and Models), without a clearly expressed vision of how to use them together.
I have started to standardize the way I use Backbone, though, with app directory structure, naming conventions, etc. I've also started using require.js which also provides the benefit of forcing you to write modular code.
I found myself writing the same stuff over and over and created a generator that has all these things I've learned over the last few projects: generating a 'shell' application, generating some models/collections/views with boilerplate code (along with some specs to go with them) putting everything in the corresponding directory.
I used Ben Nolan's `capt` as a starting point and added a bunch of stuff that suits my needs.
This may help you out :)
Example of an app generated using this tool:
I'm not entirely clear what you'd be mixing and matching.
Backbone has concepts of Models, Views and Collections (groups of Models) vs Spine that has concepts of Models and Controllers.
Both additionally have client side routes.
Spine abstracts away prototypal inheritance a little more regarding "super".
Spine has localStorage support natively.
* Lack of documentation. Every time, when i want to do something more than "todo app", i have to read the source code. Well, it's OK and a programmer has to read the source code to understand whats going on under the hood, but a little bit more good documentation can be really helpful.
* Examples are so simple. In a read world app it's more complicated. I have model ( persons ) and this model has collections ( contact datas, invoices etc. ) to find a way to handle all the mess i spend a weekend and read useless tutorials. In the end i gave up, read source code and my builded app on events. A better example could save my time and if there was a "best practices" guide, i could be sure that i'm on the right track.
It would be great to have a more step-by-step in-depth tutorial available on Backbonejs.org, and if I don't get a chance to built one out soon, I'd be glad to merge a branch that adds one.
Tutorials aside, is there something more in the way of API documentation you'd like to see, that you aren't finding on Backbonejs.org?
Finally, there is a long list of real-world apps available, many of which have viewable source code that you can examine and learn from:
edit/note: its been about 6-8 months since I was looking at backbone hard, so this may have improved.
But I wish the Backbone docs would talk about how to structure larger applications. Yes, I agree with the philosophy of "There's More Than One Way To Do It" but I don't think that's a good reason for the fact that there is no recommended best practice for how to modularize and organize code for a Backbone app that's larger than the trivial to-do example. Some discussion of architecture for larger apps, along with some example code, would be great.
At present it's an annoying contrast to see the small to-do example and the screenshots of elaborate examples that have many models, collections, routes, etc. Would be great if the docs could do a better job bridging the two.
explains in a paragraph that it updates the object and fires a 'change' event. Right below in
the text explains how the backbone.sync handles the save function. What's sets me back is that the backbone.sync strings "change" and "update" are both quoted and highlighted just like an "event". It is not apparent from the method call if an event is ever fired. Upon careful inspection you notice it also calls set if the values are passed or values are returned differently. The set method triggers a change event.
Eventually these things become second nature and you just know them. The tricky part is finding a good place to start from. Maybe a list of good practices, maybe a good up to date tutorial showing a simple app that uses models, collections, views, routes, and a real backbone.sync.
We should fix the Model#save paragraph to make it clearer that the strings are the potential values of the "method" parameter.
Thanks for all the great work! I use and love BB, CS and _ everyday.
* Some important gotchas with backbone isn't documented ( or somehow i missed ), one example :
from document :
Convenience function for removing the view from the DOM.
Equivalent to calling $(view.el).remove();
in views, $(this.el).remove(); removes event bindings and if you call render() of this view again you should call also .delegateEvents(); somewhere in your code.
I ask as I'm looking for a new JS library for a project to build the client-side interaction, and I have no idea what is different than backbone from the rest, just that a lot of folks here are interested in using it.
* With backbone's models and collections, i can organize my application structure better. It's not easy but result is a clean code.
* Backbone's Router is no-brainer.
* Syc allow me to use RESTful JSON requests. Even i'm not using it, it's good to have such an option.
* Data-binding is a plain pain. You have to write your own code but there is always a library that you can use (eg. https://github.com/derickbailey/backbone.modelbinding ).
* I can always read the source code and thanks the comments i can understand most of it. My complain about good and advanced tutorials not because of the laziness, it was because saving time.
Seriously this is better than any tutorial you can find out there.
Do you mean something more like, needs more howtos and sample apps?
'Cause backbone's got some pretty extensive documentation both in terms of the API (http://backbonejs.org/ ), the annotated source itself (http://backbonejs.org/docs/backbone.html ) as well as a big pile of references as well as tutorials here: https://github.com/documentcloud/backbone/wiki/Tutorials%2C-...
It seems like jump into coding immediately interactive tutorials are all the rage. But I have always learned more effectively by reading a high-level, conceptual/philosophical overview of how and why something works the way it does. From there it's much easier for me to work through examples. "Oh I get why this is that way". "Oh yeah that makes sense ..."
I'm left-handed so perhaps this is just a left vs. right brain discussion. Left handers are minorities but I really think its very important to understand how/why something works from a high-level.
What are your thoughts?
I like to get into the coding straight away. If what's happening is not immediately obvious to me, I'll start reading around the area I don't understand until I do understand it. Once I've tried a few set examples out, then I'll start putting my own code together. Inevitably, I'll hit a wall, and search around for an example that solves what I'm having a problem with.
And at some point, I'll start reading the high-level, conceptual/philosophical overview. And because I've now got some experience about some of the areas within the code, how everything ties together starts to make some sense.
If I had to read the high-level overview first, then I may never find the time to start coding in it!
I have read Backbone.js source code, I have tried my hand at it, I have experience with WPF/Silverlight databinding (very close to what Knockout.js does) so I got the theory fairly easily.
My blocker was more seeing it in action to put all the pieces together.
Backbone lacks good documentation. I tried to implement it but I thought it was overkill for what I was trying to do. Knockout.js feels like it is doing most of the plumbing for me.
* I of course don't mean compete in a negative way... just trying to get at the way open-source projects play off each other in creative ways.
At first sight they look the same.
Finally I understand what the whoile point of Backbone.js and client-side mvc frameworks is! Thanks!