I tried Backbone and am now looking at Angular... but part of me is starting to think "is this such a good idea?". All the authentication stuff, and validation, and so on has to be done server side anyway, and perhaps replicated in the JS framework. Also, keeping models in sync looks like it might be easy to screw up.
The paradox is that the more dynamic and "app-like" you want your site to feel, the more javascript you need, and eventually you need a better way to organize it than the jQuery spaghetti code you typically end up with, which inevitably leads you to a javascript framework like Backbone or Angular. It's not necessarily a good idea or a bad idea, it's just a problem that needs to be solved.
It is also, by the way, the same problem native app developers have to solve when they create an app that relies on a web server for its data. They must make sure their models are in sync and that authentication and validation happens on the client or is at least represented consistently.
If it still doesn't feel right to have a thick javascript application on the client, though, you might want to do a little research into how 37 Signals wrote Basecamp two. They did it without relying on a thick javascript client framework and instead pass up all the JS/HTML necessary on each request and use HTML5 pushstates to keep the app dynamic and snappy.
As a related note, I highly, highly recommend Angular.js. Aside from all the awesome two-way bindings stuff (which you get with a lot of other frameworks), the big selling point for me was the fact that dependency injection is baked in at every level and the emphasis on writing testable code that doesn't rely on DOM manipulation.
I suggest you try it out, I think your lines of code will greatly decrease. The biggest reason I prefer to program in Angular over Backbone is that I simply don't have to write rendering logic code because of data-binding. There's no "render" function, no jQuery DOM manipulation for common tasks, because all rendering behavior is declared in the HTML. Unless you're doing something non-trivial, in which case you should write a custom directive. (For those unfamiliar with Angular, a directive is a declaration of a new HTML tag or attribute with custom behavior which can be reused throughout your app)
I've got to admit that I've never worked on a substantial Backbone app, but many of the issues I see people having with Backbone (regarding rendering item and list views, programmatically binding events, etc..) are simply non-existent in Angular.
We investigated using Backbone vs. Angular for a project and went with Angular and could not be happier. It's not just the two-way data binding, which you can get with frameworks like Knockout.js and Ember.js; it's the dependency injection and testability of the code. Never before have we had this good of test coverage in a pure javascript app, and most of it is unit tests which is very impressive considering how concerned javascript usually is with manipulating the DOM.
You don't necessarily have to replicate validation on the client side. You have just have server form responses / validation errors come through AJAX responses and display them client side.
Client side stuffs like validation,etc ... are here only to enhance user experience , you dont want a user to wait til the page reload just to know the password he entered should be at least 6 characters long. Same thing for auth , permissions to access resources are set server-side, and dealt on the client with HTTP response codes. So there is nothing to keep in sync,The server is still free to forbid any resource access, or invalidate granted access.
Sorry, I didn't mean to imply that the auth stuff needed to be kept in sync, I meant models. People are used to pushing a button and getting a GO / NO GO response of some kind, whereas it seems that with some of these frameworks, people could edit something and have that not show up, if something went wonky in the middle: it's saved "locally", but the ajax request hasn't been completed yet.
