Server-side architecture for mobile web applications

Question

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 for processing requests and then a templating engine (Velocity, JSP, etc) for generating dynamic content.

Now I am starting to work on mobile web applications and all the discussions I see revolve around selecting a UI framework (jQuery Mobile, jQTouch, Sencha Touch, etc) but I don't see any discussion of what is happening on the server-side to actually process HTTP requests or to generate the HTML, CSS, and JavaScript.

Does this mean that most mobile web applications do not use a server-side web framework... meaning the server serves static content, the majority of the interactive behavior is coded in JavaScript, and the only server-side code is REST services that the JavaScript client loads?

If I wanted to use a server-side web framework would that be a bad idea? What problems would I face? Does anyone have a recommendation on web framework that would be a productive platform and not "get in the way" of mobile UI frameworks like jQuery mobile?

NOTE: The developers I work with mostly come from enterprise Java backgrounds, however, I wouldn't limit it to only Java-based web framoworks. There are other frameworks out there that have roots in Java that could be considered (Grails, Lift, etc).

Answer 1

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.