[gaslightchris]

The important difference I see in the approach used by backbone is it gets us away from having the server be in control of navigation and UI events. After the initial page load, I'm exchanging simple data as json with the server. It wasn't HTTP I was arguing with, it is having a server side framework managing the UI navigation.

The best way I've heard coffeescript described is as a better syntax for javascript. Though at first this may not seem like a big deal, in my experience it's been a huge deal in the effect it has on how I approach client side code. Now that I can write code I really love on the client, it's greatly lowered the barrier for me to do so.

[abrenzel]

I just see this as an incremental development, rather than a revolutionary one. As I mentioned above, the server is still very involved with UI events and navigation. If the user causes a UI event that saves data to the server, even if there is client-side validation it will often be the server that responds with an error and forces the page to do something with that. The nice thing is that we now get to encapsulate the server's influence on the application into definable actions, rather than by a single request. That's a rather good thing for us developers, but it is still well within the bounds of the traditional HTTP model.

As for Coffeescript, anything that tames some of the nasty bits of Javascript is fine by me. I don't dispute Coffeescript's usefulness. My point was just that Coffeescript is like syntactic sugar for Javascript, not a paradigm shift in client side coding.