You don't need to pull a whole page down to get new data and you can do the form validation on the client side although you need to redo the validation on the server side anyway to make sure the client JS hasn't been tampered with.
You don't need to pull a whole page down to get new data and you can do the form validation on the client side although you need to redo the validation on the server side anyway to make sure the client JS hasn't been tampered with.
It's true that it doesn't give you any magical power that you didn't have before and you can do everything it can do with vanilla javascript or any of the other frameworks. However that's a bit like saying you don't see the point of rails because you can just use vanilla PHP for everything.
The simplest way to use AJAX with a server-side MVC is by fetching blocks of pre-rendered HTML. This is commonly known as AHAH. It's dead-simple to do, powerful and trivial to use via progressive enhancement. That is what you should treat as the server-side alternative to client-side MVC.
Instead of writing your own code to handle AJAX on top of jQuery, you write code that handles the real logic and let the framework handle the DOM manipulation. In that way, it's easier to test, easier to debug, easier to provide superior experiences.
Right now, writing AJAX in the browser is equivalent of the JSPs of yesteryear. Remember all that horrific logic that used to creep into your JSPs? That's what jQuery looks like, and this new crop of frameworks is getting us to JSTL or facelets at the minimum.
Which is non-semantic, so it cannot be progressively enhanced, does not benefit from browser updates and is pretty much not crawlable by anyone except Google.