views:

112

answers:

3

For a typical business application, should the focus be on client processing via AJAX i.e. pull the data from the server and process it on the client or would you suggest a more classic ASP.Net approach with the server being responsible for handling most of the UI events? I find it hard to come up with a good 'default architecture' from which to start. Maybe someone has an open source example application which they could recommend.

+1  A: 

It depends greatly on the application and user. In the general case, however, you'll always scale better and the user will have a better experience if as much of the processing as possible happens on the client.

Further, with Google Gears and other such frameworks it's possible to separate the client from the network and still have use of the application. If all the UI is on the server it's much harder to roll out a roaming solution.

Adam Davis
+1  A: 

It really depends on the application and the situation, but just keep in mind that every hit to the server is costly, both in adding load (perhaps minimally), but also in terms of UI responsiveness. I am of the mind that doing things in JavaScript when possible is a good idea, if it can make your UI feel snappier.

Of course, it all depends on what you are trying to do, and whether it matters if the UI is snappy (an internal web app probably doesn't NEED extra development to make the UI more attractive and quicker/easier to use, whereas something that is used by the general public by a mass audience probably needs to be as polished and tuned as possible).

Mike Stone
A: 

Do you need to trust the data? If so, be aware that it's trivial to tamper with client-processed data in nasty and malicious ways. If that's the case, you'll want to process info on the server.

Also, be aware that it can be a lot harder to code javascript apps so they are stable, reliable, and bug free. Can you lock down your users so they only use one particular browser?

Tim Howland