* You usually want to avoid having multiple client-side models for a single database row. Keeping your client-side schema close to your database avoids mapping headaches later.
* When navigating around, be sure to cancel outstanding ajax requests if the user clicks on another link before the response arrives.
* You often aren't modeling the complete server-side state in the browser, so look for opportunities to simplify by glossing over data that only concerns the backend.
This looks like just what I need. I am trying to use Backbone for the first time after eyeing it for a long while, and I'm completely lost as to best practices when it comes to loading and rendering things, either from the router or from a view, and also when it comes to dealing with collections that are part of a model.
One thing I'd like to see covered in discussing stateful web applications is handling concurrent use and modification of data of data by multiple users or even multiple devices/tabs from the same user. Moving state to the client can result in inconsistencies across clients as each one makes changes.
Locking data to prevent this is a usability problem. Pushing changes to the each client is a partial solution, but then you're faced with the users watching the data change in front of them, without any action on their part. This is especially a problem in complex applications with multistep workflows.
Perhaps it is outside the scope of this series, since this appears to be focused on the technical aspects of using Backbone rather than application design. But a discussion of patterns that overcome these problems would be very useful.
I think that discussion would be interesting as well.
I can almost see some sort of DAG-type (like git) versioning possibly working; or maybe where the only changes that are saved to the store are properties that only one client modified.
That's an interesting idea for certain types of applications.
It seems as though you would need to specify what groups of attributes need to be modified atomically. Say you have a user model, for example; an address comprised of multiple fields should probably be modified as a unit, but the address and email could be modified simultaneously. This might correspond to how you would logically divide your models anyway. Merges could then be allowed as long as these units are intact.
Doing this while maintaining usability seems like a tremendous challenge, however, and I'd love to hear ideas for doing this in a way that's painless for the user, especially when there are dependencies between models.
In a nutshell, it takes everything under app/templates and compiles it from Rails (so it has access to I18n and ruby) and serves jades, which we later compile and minify.
Trimmer serves the Template and I18n objects, as you can see on this compiled file:
I like that your solution actually packs it together with the rest of the code, avoiding one extra request for templates. Maybe we'll add that to our system too.
This might not be possible for you, but we're running under nodejs and using stitch[1]. It compiles the templates to javascript functions, and we bundle them with all the rest of the javascript as one big file. Simple distribution and awesome performance.
What I do is Makefile compiling templates to separate js files for development and for production I combine them using the module system which makes sense - in different projects I had stitch, ender.js and AMD (require.js & seajs).
When starting out with backbone.js I also had a difficult time just using the documentation. Backbone is kind of the opposite of other popular MVC frameworks in that its un-opinionated, it doesn't enforce any strict organization which gives more flexibility but also makes it more difficult to learn.
What worked the best (however not optimal) for me was to combine the techniques used in the PeepCode(https://peepcode.com/products/backbone-js) screencasts and Thoughbot's book (https://workshops.thoughtbot.com/backbone-js-on-rails). Once you start getting in the groove of things the documentation is actually really good for quick look ups and you'll start to see that the framework is actually surprisingly tiny.
My advice: take backbone's code and read it a couple times as you'd read a science book. Get to understand every function and how it ties into the rest of the framework.
Most writers read a lot more than they write. Programmers could learn from that.
This article is not meant to be a Backbone introduction. I was just exposing some solutions for some problems that we had on building big Backbone apps. The best way to learn Backbone IMO is to start hacking something easy while reading the source.
Backbone expects you to have your architecture already in mind, and your use case to be more or less similar to DocumentCloud's. Then it will really shine.
The problem is that docs don't really define the whole picture. So you need to figure out stuff yourself, and may unexpectedly find yourself ‘fighting the framework’.
I personally think this is a problem. Backbone really should be re-positioned and turned into a full-blown client-side framework, with more control flow inversion; so that a developer would be able to just create ‘a Backbone project’, customize a few things and be ready to roll.
I'd tend to think that it's because Backbone is agnostic about your backend, and agnostic about your UI. That tends to leave a lot of the big pieces up to you...
That said, I like your premise. If you have more concrete thoughts about what "re-positioned and turned into a full-blown client-side framework, with more control flow inversion' ... would mean in practice, please open a ticket and describe your ideas for discussion.
* You usually want to avoid having multiple client-side models for a single database row. Keeping your client-side schema close to your database avoids mapping headaches later.
* When navigating around, be sure to cancel outstanding ajax requests if the user clicks on another link before the response arrives.
* Lazy-loading of associated models is handy, described further here:http://backbonejs.org/#FAQ-nested
... and a few more tips:
* You don't need to use an event when a simple callback will do.
* In terms of JS apps, Tim Toady is your friend: http://backbonejs.org/#FAQ-tim-toady
* You often aren't modeling the complete server-side state in the browser, so look for opportunities to simplify by glossing over data that only concerns the backend.