considerations for choosing a web application approach?

Question

I am a long time Java web applications developer, and in my experience there are 2 major approaches for building web applications.

The first approach, is to use technologies which go back and forth from the client to server like Struts, SpringMVC, JSF and so on.

The second is to use technologies which run mostly on the client like Flex, Swing (web start), JavaFX and so on.

I know these two approaches are going to stay here for a long time, and I know each has it's advantages and disadvantages.

I would really like to know when do you prefer to use each of them? What should I consider when choosing the one over the other?

Say whatever comes to your mind in terms of Security, application type, Stateless/Statefull, DB calls, or anything else.

It would be interesting to see what are the different aspects.

Answer 1

My advice would be to avoid plugins in all cases. Don't use the java, flash or silverlight plugins for web apps. You're setting yourself up for a world of hurt down the road. If you want to build a rich client, use something that generates javascript. If you like Java, use GWT. If Java is not your cup of tea, look at the javascript toolkits, like ExtJS, Dojo, Sproutcore.

The way I see the trade-offs:

Thin client (regular HTML):

• Upside: easier adapted to a variety of browsers and devices
• Upside: Better for low-bandwidth devices
• Downside: less richness in UI controls
• Downside: roundtrip times will kill "flow". If users are expected to work for long durations in your app, this approach won't work well.

Rich client (GWT or JS toolkit):

• Upside: server-side can implement just a clean API
• Upside: UI design is easier to implement, richer
• Upside: you can plan your design around slow roundtrip times (with "offline" being an extreme case of slow roundtrip times)
• Downside: need a separate front-end for mobile devices and low-powered browsers
• Downside: low bandwidth will make loading so slow users just walk away

For my apps, I fall squarely into the rich client camp. But then I don't make apps for the "public" internet.

Answer 2

Basically the distinction is between that of 'thin' and 'fat' clients.

Some pros and cons of both

Fat Client

• Opportunity to push more processing logic to client, alleviating server resources. This can also lead to a better user experience as the GUI can execute update tasks concurrently.
• Easier for client to run off-line
• Can be easier to implement richer more complex GUI functionality
• BUT can be harder to re-use logic across different client types (e.g. desktop & mobile)
• BUT can be harder to code up, requires more specialist skills than generic client/server web devlopment, and sometimes means more of the application logic is coded into the client, resulting in fewer separation of concerns.
• BUT often proprietary (e.g. flex)
• BUT can be harder to expose data to web crawlers

Thin Client

• Can hand off GUI development to a separate specialist team to code, while business logic is coded on server side by another specialist team (although of course, this does very much depend on the type of app in question, and where the logic sits)
• Coding skills more readily available (for both client and server)
• Promotes re-use of business logic on server side across different gui types or APIs
• Data can readily be exposed to web crawlers
• BUT guis can be less interactive often at expense of user experience
• BUT generally can not run off line

The advent of more powerful browsers like Chrome is blurring the boundary between the two though.

Generally speaking I would assume that the default would always be a thin html client based solution, with business logic on the server, unless requirements dictated otherwise (such as advanced multimedia or processing needs or specific UI look and feel design choices like animations)