If you were previously looking at integrating Backbone.js with Sammy, jQuery-BBQ, or another hashchange-based library, there's no longer any need. Instead:

    var Workspace = Backbone.Controller.extend({

      routes:{
        "search/:query/p:page": "search",
        "folder/:name":         "openFolder",
      },

      search: function(query, page) {
        ...
      },

      openFolder: function(name) {
        ...
      }

    });

Which will properly route URLs like "example.com/#search/lemons/p7"

Does the critic that you made to Sammy applies to Backbone? :)

Link: http://news.ycombinator.com/item?id=1788631

I presume you're referring to this: http://news.ycombinator.com/item?id=1882476

Pieces of the critique definitely apply to this release: I'm still of the opinion that routing is a relatively small portion of a client-side app. And you'll probably wind up with 10x more Views, Models, and Collections than you do Controllers.

The big difference between this approach and Sammy's is that here Controllers are just a library you can use -- with Sammy you structure your whole app around inappropriate faux-server-side-URLs-with-HTTP-methods. (Also, this works in Internet Explorer.) In the end, enough people requested we add routing to Backbone that it made sense to plug it in, one more battery included.

is there any way to change the url from "/#" to "/#!" so that it can be crawlable by google bot?

At the moment, you can do it by including "!" at the start of your routes. Perhaps it should be a configurable option...

We talked about it a bit, and the consensus was that "/#!/" URLs were a temporary hack that is obsolete now that "pushState" and "replaceState" are part of HTML5 -- you can now mint real URLs that are crawled by Google and are accessible from single-page apps as well.

Added link to the comment about Sammy. Basicly it said you shouldn't organize the whole app around faux-routes.

Didn't understand the downvotes.

Just a nit: is that "search/:query/:page"?

You could do either, but in this case, I'm going for URLs like:

    example.com/#search/washington+news/p10

... to make it a bit more obvious that the number at the end is a page number. This is actually a real-world example -- it's the same route that DocumentCloud uses to run searches in the workspace.

I don't think so, "example.com/#search/lemons/p7" would route to search("lemons", "7").

Actually, why use colons instead of URI templates?

http://tools.ietf.org/html/draft-gregorio-uritemplate-04

Hey, that's a great idea. I've been following the progress of that draft a good bit, and we're already using URI-templates as part of the DocumentCloud API...

    "image":"http://s3.dcloud.org/docs/101/pages/inauguration{page}-{size}.gif"

I'd be a bit concerned if we used them in Backbone, that we wouldn't be following the spec by parsing all variants of the expansions -- but on balance, it's probably a great thing to do.

Cool. We use a URL patterns variant in Midgard MVC, so that should make Backbone integration easier :-)

http://github.com/bergie/midgardmvc_core

I am refactoring my application to use Backbone.js right now and just wanted to thank Jeremy for this great piece of code (as well as underscore.js). There is still some friction in certain places, but overall the experience has been great and my app has been seriously despaghettized.

So, thanks!

I refactored my app using Backbone.js, and it really hits the sweetspot in terms of being lightweight and flexible. I really like how view objects, collections and models abstractions are so simple, yet fit so well together (change:attribute events etc...) Until now I also used jaskenas HashHistory snippet for routing...

I'm already using Backbone in production. It has been a huge boon, not only in time saved but in forcing me to design things well.

I'm not sure I like the way this is going.

A large part of jQuery's appeal is its modularity. The address-plugin already exists and seems to do the job very well.

In that spirit I'd prefer to see backbone stay as modular as possible, too, and have it integrate with existing, mature solutions, rather than grow its own knockou^Wknockoffs.

Modularity is great, but you don't need to worry about the way this is going. The entirety of Backbone.js is still fewer lines of code than just the jQuery Address plugin. ;)

Now that there is a bit more client-side-only code, in the next release, we'll probably split the source into individual components, so that you can just load Models and Collections on the server-side.

Yes, I didn't mean to dismiss backbone as a whole by any means. It's in fact on my "try asap" list (still undecided whether backbone or knockout is the way to go).

With modularity I don't strictly mean LOC. Rather I think that most of these lines in the address plugin are probably in there for a good reason. Thus if backbone ships its own solution to the problem, but that solution covers only part of what I need, then I'd have to integrate both - and perhaps deal with conflicts. That would be undesirable.

On the other hand I recognize that introducing dependencies to specific other plugins is also undesirable. I'm a bit torn about which is the lesser evil here.

If the solution only covers part of what you need, then that is indeed a problem that should be fixed ... by covering all of what you need.

On the other hand, I'll leave it up to your judgement whether the lines in the address plugin are necessary. You can compare implementations here:

https://github.com/asual/jquery-address/blob/master/src/jque...

http://documentcloud.github.com/backbone/docs/backbone.html#...

If 90% of Backbone apps end up using Controllers, it's better to include a concise implementation than a heavy dependency, I think.

Is there a mobile widget library for backbone.js?

No, there isn't. A big part of the idea of Backbone is to provide some support for large web apps without dictating anything about your HTML or CSS for you -- there are already a large number of frameworks that give you widgets, and I'd suggest looking at one of those.

Why not plug in jquery mobile or some other mobile framework?

Because jqmobile doesn't provide an mvc like framework.

There should not really be a problem with using Backbone.js and jQuery Mobile together.

Sounds strange to me. How does jQueryMobile pages relate to Backbone.js views? Do you have an example?