Backbone: Dealing with stateful applications (part 1) | Hacker News Reader

Backbone: Dealing with stateful applications (part 1)

pau.calepin.co

110 pointsmasylum20 comments

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.

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!

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.

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!

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

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

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

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.

[1] https://github.com/sstephenson/stitch

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

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

The Todos example is handy, but not every app is a todos app, and there's plenty of Backbone functionality that is not exercised in this simple app.

And when there isn't an existing example of what I'm trying to do close at hand, I find the Backbone docs to be quite good.

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.

I also have a couple sample apps up on github that I used to learn backbone if you'd like to see some more examples: https://github.com/jwarzech/inspire_board https://github.com/jwarzech/realtime_hn

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 is in the top 5 list of why I dig Backbone. The code is concise, clear, and eminently readable.

Here's a complete app built on Backbone.js: http://weblog.bocoup.com/startup-data-trends/

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.

I'm a big fan of Derick Bailey's stuff.

He has a framework on top of Backbone called Marionette that is well documented and makes handling large apps much easier: https://github.com/derickbailey/backbone.marionette

He then builds an email client app with it: https://github.com/derickbailey/bbclonemail

And has a ton of great articles on backbone: http://lostechies.com/derickbailey/category/backbone/

Definitely worth following his work.

I think it's because of its in-house past.

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.

Interesting.

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.

Reply on news.ycombinator.com