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