It's definitely possible to do all of the front-end in Javascript on the client's browser (unless you have to support JS-less or very old browser), reducing the server's role to that of offering a REST-ish interface for the client's AJAX calls (as well of course as serving static files of various sort;).
This approach is known as thin-server architecture and jQuery (just as much as, say, Dojo or Closure) is suitable for implementing the client-side part of it. If you can restrict yourself to advanced browsers with HTML5 goodies, you can do even more client-side, further lightening the load on your server and enhancing scalability (how much you can demand of the browser varies widely with your app, of course -- if it targets iPhone, Android or other advanced mobile phones specifically, or if it's an enterprise-internal web app where the users can be made to use Chrome or Safari, say, you can be far more demanding than if you want millions of random users out on the open web;-).
For the server-side part I'd suggest an ultralight microframework on top of Werkzeug and WSGI, such as Flask or (if the server uses App Engine) tipfy (there are others, esp. for GAE -- see here for a list).
I would not place on the client-side anything that needs "security", though - since all of your Javascript code, jQuery or not, can be examined and hacked easily, anything you want to be "safe" should live server-side.