[abrenzel]

Some things from this article just don't make sense to me.

Like, why is AJAX/client-side MVC pointed out as something that overcomes the HTTP request/response cycle? No, it doesn't. It just means you don't have to refresh the entire screen every time a request is made. Whether the server now sends back "a wad of HTML/javascript" or some JSON to be parsed by the Javascript MVC framework du jour, nothing you are doing is transcending the HTTP protocol either way. AJAX changed the way users interact with web applications, but it did not change anything really fundamental about their architecture.

Second, Coffeescript does not liberate you from Javascript. It IS Javascript. It makes it easier to control some of Javascript's difficult areas, like the meaning of "this" as execution context changes as one example, but it doesn't suddenly give you license to write browser code the way you would write Python or C++.

In any case, let's not confuse convenience with paradigm shifting.

[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.

[Joeri]

No, I think it is in fact a Big Deal (tm). The old model was about involving the server in the behavior of the page. The new model is about turning the web into a classic client-server architecture, replacing the desktop executable with a javascript client.

The way I write web apps these days is to have static javascript code, that contacts a web service to fetch its settings, and to load the data to be edited. Then it performs all editing client-side, without contacting the server. When it's done, a single save() method call to the server persists the data. That the communication occurs across HTTP is almost irrelevant.

That's eerily familiar to the desktop apps I've implemented. In a sense, it's a paradigm shift back to the way stuff used to be built, except there is no dll hell, because the client always has the latest version of your "executable".

[abrenzel]

Well yes, now you can perform more manipulation of the page without needing a roundtrip to the server, but saving the state of the application still involves one, unless you are the type of radical early adopter who is going to try to do it all with HTML5 local storage.

The relative balance of the work may have changed, but I don't see it as a revolution except in terms of user experience, where AJAX has definitely drastically changed the way users perceive a web page.

Otherwise, the development model of HTTP - the server sends me something, I send a reply, and it sends me back something else - is still alive and well. That's to be expected, since browsers were built with HTTP in mind and the supporting technologies, Javascript included, all must live within that box. The server is still intimately involved with the behavior of the page, but its involvement is encapsulated into individual actions rather than an entire page load (i.e. the server returning an error can be responded to in the context of the HTML form that caused it, rather than with a page redirect or some such). Again, I don't deny that's a helpful thing.