However (and this is another conversation altogether), I don't think that you really want to structure your client-side application around faux-routes. Maintaining browser history with "hashchange" is important, but hardly the central aspect of a JS app. Usually you want to reserve history changes for special states that deserve to be bookmarked, not for every single action performed.
For the record, this is the little module that we use to record and listen for "hashchange" events:
Can you please expand on this? I don't get it: do you think something like newtwitter is badly designed because it uses faux-routes? If you don't have faux-routes then how can you easily insert links which will "go to page X" ?
Not at all -- hash-based URLs for Ajax applications are critical. They're just not something that you want to structure your entire application around, and Sammy is a framework that uses faux-URLs as the central abstraction.
All I'm saying is that you don't need to ape the server-side paradigm (one URL, one page) quite so closely. Use a module that gives you URL setting and tracking with "onhashchange", by all means, but you don't have to shoehorn your application into it.
However (and this is another conversation altogether), I don't think that you really want to structure your client-side application around faux-routes. Maintaining browser history with "hashchange" is important, but hardly the central aspect of a JS app. Usually you want to reserve history changes for special states that deserve to be bookmarked, not for every single action performed.
For the record, this is the little module that we use to record and listen for "hashchange" events:
http://gist.github.com/624773