This comes at the perfect time. I have just started a project where I am using Backbone for the first time and I have found the documentation to be lacking at best.
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've used Backbone for a handful of projects already and went through exactly what you're describing. As a result, all my projects look different, structure-wise.
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.
You may want to look at EmberJS[1] if you want a more opinionated framework for single-page apps. It's still in development and I'm not sure if all of the components are production-ready but I've also heard (??) you can use it alongside Backbone.js
I would be surprised and confused to see how one would use Ember alongside Backbone. Both Ember and Backbone have separate notions of how models should be handled as well as having separate routing systems.
I'm not entirely clear what you'd be mixing and matching.
I have been following Ember since it was still SproutCore 2 and I am looking forward to try it out on a hobby project. Looks like they took the good parts of other frameworks as inspiration and left the bad parts of SproutCore behind, but a little too cutting edge to use in a project with real deadlines for now :P
https://github.com/codebrew/backbone-rails will generate backbone scaffolding and includes JS that binds your rails model set/get to html element change events so you can go from 0 to functional and see how Backbone could work. Try a new Rails project with a basic model and generate the Backbone scaffolds for great examples to mimic in your app.
Yes, I saw this, and I like how there is an opinion from the Rails community on how to structure Backbone code, but shouldn't the opinion be apparent on Backbone's website? My current Backbone is not backed by a Rails app (it is an existing backend in Perl), so I should not need to create a dummy Rails project to learn Backbone.
* 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.
There are a lot of not-so-great blog posts and tutorials out there for Backbone, so I'm not entirely surprised to hear that you found them "useless".
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:
I've always thought a bit more explanation up-front about the philosophy, the way high level components/concepts interact, and the use cases would really help with backbone. The API is decently documented, but the context is not so well documented, and sometimes that is more important than the functions themselves (I can read code, but I don't want puzzle out which things that are technically allowed are bad/good practice within the lib's architecture).
edit/note: its been about 6-8 months since I was looking at backbone hard, so this may have improved.
I've enjoyed reading the Backbone docs and found them useful reference. Actually, I quite enjoy reading all of your project docs, @jashkenas!
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.
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.
No problem, you asked for specific examples, and I figured since I'm writing my first large production backbone.js code I should chime in on my experiences.
Thanks for all the great work! I use and love BB, CS and _ everyday.
I think part of the problem is also that Backbone made some backwards incompatible changes as the framework developed. I found that a lot of the backbone tutorials were out of date - the &Yet blog had a bunch of good tutorials but were quickly out of date, and the posts were never revisited.
* Majority of the tutorials on the net are just useless. One can't uunderstand how the backbone internals works. We need more advanced tutorials than "Hello World with Backbone" and "Introduction to Backbone"
* Some important gotchas with backbone isn't documented ( or somehow i missed ), one example :
from document :
...
remove view.remove()
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.
Just curious - if the documentation and tutorials were so lacking, what made you choose Backbone in the first place?
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.
* 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.
The code base for Backbone is small and hugely documented. Take 1 hour, read the code, feel good, learn techniques, let it sink in for a while and use it.
Seriously this is better than any tutorial you can find out there.
I hope you are monitoring your post asymeric because I would honestly appreciate an answer to a question I have:
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.
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.
Some words of caution: it seems like not all the information in this guide is equally recent. For example, it references Controller.saveLocation(), which has been replaced by route.navigate() etc.
This looks more like a quick start condensed guide for someone who has already has a good understanding of JS. The official documentation is more extensive and will take an hour or two to read.
[quote]In this mini-book, I'll be covering a complete run-down of Backbone.js; including models, views, collections and routers. I'll also be taking you through advanced topics like modular development with Backbone.js and AMD (with RequireJS), how to solve the routing problems with Backbone and jQuery Mobile, tips about scaffolding tools that can save time setting up your initial application and more.[/quote]
Excellent, really looking forward to hear how you deal with loading of backbone.js modules and how you organize your code. Would be interesting to know if you precompile your modules..
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.