

Backbone: Dealing with stateful applications (part 1) - masylum
http://pau.calepin.co/backbone-dealing-with-stateful-applications-part-1.html

======
jashkenas
Some of the highlights from the post:

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

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

Here's hoping the next post comes soon!

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

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

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

------
michokest
One of the biggest challenges we found with big Backbone apps is serving
templates. Looking forward to hearing how you serve assets from the backend!

~~~
jashkenas
For the record, the approach that we use to serve templates (along with CSS,
and JavaScript), is available here:

<http://documentcloud.github.com/jammit/>

Just the templating bit: <http://documentcloud.github.com/jammit/#jst>

... which allows us to include all of our templates in our JavaScript asset
packages by listing them like this:

[https://github.com/documentcloud/documentcloud/blob/master/c...](https://github.com/documentcloud/documentcloud/blob/master/config/assets.yml#L20-22)

... which then means that they'll be served as part of the final, minified,
compressed "core" asset package here:

<http://www.documentcloud.org/assets/core.js> (bottom of the file)

Or, as a standalone asset here:

<http://www.documentcloud.org/assets/core.jst>

~~~
michokest
I was commenting hoping to get others to explain their templating system,
honored to see your reply :)

This is what we use: <https://github.com/teambox/trimmer>

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:

[https://d238xsvyykqg39.cloudfront.net/assets/trimmer-
en-58fc...](https://d238xsvyykqg39.cloudfront.net/assets/trimmer-
en-58fced1047f854838c20e20d4d639677.js)

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.

------
rorrr
Every time I start reading Backbone documentation, my head hurts. This article
is even worse.

What they need is a _simple_ , to the point, complete examples of apps.
There's one that I found that makes some sense to me:

<http://documentcloud.github.com/backbone/docs/todos.html>

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

~~~
joelhooks
This is in the top 5 list of why I dig Backbone. The code is concise, clear,
and eminently readable.

