In most desktop web applications I\'ve ever worked on you need a server-side web framework. The server-side web framework (Struts, Spring MVC, etc) has some kind of controller
A good question for sure and I will answer it this way. The current trend is to build a lot of interactivity into the front end. There are several reasons for this. Some do it because it's the new thing to do, others do it because they're trying to replicate the desktop experience. In the end, there is only one goal for any given web project and that is to create Best and Most Sustainable User Experience.
That being said, there would be server side technologies to avoid and that would be any of that generate the front end for you but are not using jQuery. Over 45% of all websites today use jQuery and if you select something else, you will be instantly at odds with the prevailing mobile frameworks. (GWT, IceFaces, I'm looking at you).
Probably the safest and most flexible way to go would either be using a Spring based implementation or Prime Faces. Spring Mobile is worth looking at. Prime Faces actually implements jQuery Mobile and is theme-able using Theme Roller.
In general, it really doesn't matter what backend framework (if any) that you use so long as you're pushing good markup. The browser doesn't care and the only thing that user's care about is a good experience. So, pick whatever will make your devs happy for the backend so long as it doesn't get in the way.
As for front end frameworks, yes, their popularity is increasing because they do tend to standardize some of the best practices in mobile. There are many many comparisons of jQuery Mobile vs Sencha vs jQTouch. I'll leave you to figure which is best for your project but would certainly use either jQuery Mobile or Sencha because the community of support around these is massive and you're less likely to look like the many shabby, home-grown mobile sites that tried to do it from scratch when they didn't have the experience to pull it off. It's just sad. My personal recommendation is jQuery Mobile because it's covers such a wide range of devices and (provided you stick to the standard page-by-page model) will degrade gracefully for even the crappiest of feature phones and still be functional but look amazing on smartphones.
To your question of just using a RESTful design with JavaScript loading everything and managing state. There are many that are doing that and it's certainly a snappy experience but you'll be instantly limiting who can use it to people who's mobile browsers support good JavaScript. You'll be looking at only supporting iOS, Android 2.2+, BlackBerry 6+, and Windows Phone 7+. All others will likely have significant difficulty viewing your site. Carefully consider your audience before moving to an implementation like that. If your site wont work without JavaScript and your primary clients are in the corporate world... what happens when the latest Black Hat conference exposes a weakness in the company phones and out of conservative risk mitigation (paranoia), they push a security policy to everyone's phones that disables JavaScript. This kind of thing happens all the time. So, consider your audience.
Take a look to ItsNat, ItsNat invites you to think in client JavaScript but coding in Java and executed in server generating the same JS code to the client.
The difference with GWT is, Java W3C DOM code is executed in server and JS is automatically generated, meanwhile GWT is executed in client, server data must transported to client.