Oh, fuck yes:http://documentcloud.github.com/backbone/

Example app:http://documentcloud.github.com/backbone/examples/todos/index.html

Annotated source for example:http://documentcloud.github.com/backbone/docs/todos.html

The way we're doing webapps is about to REALLY change. Ajax and web2 were just a transitional period to a real connected desktop experience through the browser. This stuff with an SPI hooked into a long polling/web socket/XMPP connection is where it's at.

Incidentally, I'm considering writing a Rails/MongoMapper plugin to automatically generate client side Backbone.js models. That would be sextown.

Originally posted by: Stinky This stuff with an SPI hooked into a long polling/web socket/XMPP connection is where it's at.

I know, right? I was saying this exact same thing at lunch the other day.

No I wasn't. I have no idea what any of it means.

weeps

SPI is just jargon for Single Page Interface like Indaba Music or Facebook has where you only reload the content, not the shell when you navigate pages.

Long polling/Websockets are both strategies for maintaining long connections to a server, XMPP is the protocol that Google and Facebook use for their chat services, but it can be used to send push updates to clients over HTTP. Combine all those and you get cool, tricksy stuff like live updating page elements based on server state.

Imagine that you had an app where you saw a list of contacts that are online, say that one of them comes online while you are looking at the page—you would instantly see it (without the overhead of constantly polling) because the Javascript model would receive a push notification. The whole thing would be represented by a Backbone Model on the page. Hotness.

Neat.

The page-based model of UI is long overdue for an extended death.

won't someone think of the Back button?!?!?!

Thanks for asking the Q Baron... I was wondering what he was on about too and it does indeed sound pretty sessy.

Actually that's the thing about a well done SPI, the back button works fine, and you can deep link easily

Both Facebook and Indaba check the hash to see what page you're on and load the content based on that. Actually, if you're using Chrome which has the History API you'll notice that the hash-bang (#!) in the URL is gone because they are using Javascript to manipulate the browser history without ever taking you off the page. Clever dicks.

I think this may be just what I have been looking for. As you can probably tell from my recent questions in front end I haven't been happy with the way javascript projects are currently structured. I've always felt like I'm missing a piece, I think this could be it.

Originally posted by: Stinky Incidentally, I'm considering writing a Rails/MongoMapper plugin to automatically generate client side Backbone.js models. That would be sextown.

That would be awesome. I've been playing around with mongodb lately and it seems super nice. I love being able to handle my data structures in code and not having the database dictate that so much. It's really pretty refreshing.

On a side note, why the preference for MongoMapper over Mongoid? I haven't settled on one yet so I'm curious.

The only reason I went with MongoMapper was that I ran into a bug in Mongoid back in January and decided to switch because MM didn't have the bug and because MM at the time seemed to have a more active community. That was a mistake, mainly because MongoMapper's documentation is atrocious. However, now I have an entire app on top of it so I'm stuck. Frankly, I'd recommend Mongoid.

MongoDB is fantastic. I can't speak of it highly enough, it just fits with OO development in a way that RDBMS's just don't.

Interesting, after a bit of experimentation with this I think that Backbone is great if you're writing the majority of the application in Javascript, if you are using JS based Haml (or Mustache, or whatever) templates and if your server is giving you JSON and all of the view logic is already in JS.

However, I don't like that. I like having views defined as html fragments using HAML and ruby. I see client side scripting as glue for interactions, not for mimicking the application logic I've already written on the back end which is what Backbone feels like to me.

So, I though I like the idea and the conventions I don't think that JS should have model style objects. They are better thought of as proxies to server side resources. That Proxy is probably linked up to several view-states, and it's also likely bound to one or more forms. That tells me that I can probably use declarative data- attributes in HTML to define my Proxy objects and reduce duplication.

View layers get a data-proxy-url, forms already have a URL that defines the resource endpoint as well as input names that define attributes. I can then put the validation logic either in data- attributes or in the JS.

Anyway, I think it's very easy to accidentally overthink things.

Where is Backbone a good choice? I reckon where the actual application is in Javascript. So, say, a chat app or an interactive canvas based drawing tool. Any number of situations where it makes sense to have model objects that aren't just proxies to a URL defined resource.

I'm rethinking my original stance on Backbone. I officially think it's the best way to handle representing server data on the client. My experience using it with Node.js as well as bringing it onboard with some Hey Foxy development changed my mind.

I was wondering if your opinion had changed after your post about the facebook app. I guess I'll have to give it a try.