Also: FatClient, ThickClient, RichClient. (FatClient & ThickClient may be considered pejorative by some: RichClient is more positive) A term whose meaning has become muddied over time, a FatClient system may be one where * most of the processing happens on the client (desktop) side as opposed to centralized server(s), or * there are programs to be deployed to the client for the system to function (e.g. a VB client that simply sends request to the server would be considered a FatClient solution, as opposed to a browser-based solution where the target system is assumed to have InternetExplorer installed already) By both definitions we have grey areas: Does using JavaScript make a fat client? Using lots of JavaScript? (Perhaps we could assess how much TuringComplete content has to go to the client per different application). Suppose we rely on a plug-in that the browser may not currently have loaded up. Does it count as a program that needs to be deployed on the client system? ''Plug-ins that can automatically install on the client system is the grey area. Other than that, the usual distinction between fat/thin is whether you need to install a client or not (with the assumption that the client already has a browser), so a heavy JavaScript app is considered "thin". The browser assumption is natural since the term ThinClient comes from the marketing of web-based applications.'' The alleged advantage to fat clients is less load on the server and faster response to user input. Alleged downsides include more desktop "babysitting" to keep the client software up-to-date and configured properly, and more SecurityManagement concerns because the business rules are on the client instead of on the server hidden behind protocols. ---- AJAX, in my view, enables FatClient web applications. Is a desktop application that relies on one or more servers no longer a "desktop application" because of said reliance? Here's my list of things that differentiate FatClient: * User interactions handled locally. * Asynchronous (background) server communication. * Server interaction at the command, rather than gesture, level. * Local (client-based) processing. * Local (client-based) object/variable scope. * Local (client-based) session management (though I'm less sure of this) -- TomStambaugh ''And therefore RichInternetApplications are FatClients?''