A discussion of when to use a web application or smart client.
This document is work in progress.
For concision I will represent some very common terms with acronyms. Smart client(s) as SC, smart client functionality as SCF, web application(s) as WA, web application client functionality as WACF, client functionality (i.e. SCF or WACF) as CF, server/service functionality as SF, runtime environment(s) as RE, client runtime environment(s) as CRE, service/server runtime environment(s) as SRE, client host(s) as CH and service/server host(s) as SH.
Any system may be partitioned with varying degrees of difficulty to have a combination of SC and WA approaches. However, there should be a good reason to partition, because it increases overall complexity and development costs. A good reason is: distinct user communities or roles would benefit from using different approaches.
The correct approach can be determined by the relative importance applied to each of the factors discussed in the following sections. I have arranged the factors in decreasing order of significance for the typical project, in which I assume the most important constraints are the must-have-features delivered while minimising development and maintenance costs. The order then depends upon the balance of development and maintenance costs against how much impact a factor would have on the choice of WA or SC if it effects must-have-features. Remember that each factor should be considered in terms of each distinct user community and role.
This prioritisation scheme leads me to conclude that for the majority of projects the pivotal choice for WA or SC is the question about the nature of the target user community highlighted in the CF deployment factor. If the answer to that is not clearly WA then probably the correct approach is SC.
SCF is deployed to CH while WACF is deployed to SH. Clearly there is potential for SCF deployment to be more effort and more complex than WACF deployment, although there are tools to help. Large user communities and/or turnover complicates SCF deployment, especially where the user is unable or unwilling to install functionality themselves. The extreme example is the open internet based user community, where the client base is unconstrained, rapidly changing and clients want the minimum of effort to use services they only require once. The nearer to this extreme we get the more attractive WACF deployment and hence a WA approach is.
The balance of functionality execution load can be more easily shifted from SH to CH with SCF relative to WACF. A distribution biased toward CH has several advantages:
When managing programmer resources it is more cost effective to minimise the number of languages and RE used. Unfortunately this militates against WA, because WACF languages are impossible or difficult to use for SF forcing multiple languages and RE.
There is a wide choice of language and RE for the SC and SF, although more recent RE such as JRE and CLR have better equipped libraries for network communication. WACF is usually written in JavaScript/JScript because the RE is implemented in many browsers, although there are implementation differences which cause compatibility issues. Otherwise language and RE choice should be based on cost, which typically is determined by availability of skills.
For two reasons it is easier to produce or increase CF sophistication in SCF than WACF. Firstly, a number of useful features that are commonplace in SC, such as DB access, require post-back in WA, which only has negative traits. Secondly, because increased sophistication requires more functionality, downloaded WACF is at a functionality initialisation disadvantage.
The functionality initialisation performance of WACF is worse than SCF and that differential becomes more significant to the user the more frequently they use the CF. The differential increases with the amount of CF because more WACF has to be downloaded, increasing the initial delay and network load. Increased network load exacerbates the download delay, although there are caching strategies that go some way to mitigate this. In addition WACF may have to be translated before execution although it is more usually interpreted. Ultimately this performance differential resolves in higher hardware and/or energy costs.
There are a range of CRE and compatibility can significantly complicate programming where RE version sensitivity of the CF is important. This is a problem for both WA and SC but there are more common WA CRE and more versions of them than SC CRE, sometimes with subtle variations in their implementation that make WA CRE compatibility issues more problematic.
Systems don’t usually have exclusive use of networks and networks have finite capacities. WA need greater network bandwidth than SC because of their CF deployment scheme. This not only negatively impacts themselves but also other systems using the network.
Theoretically the performance of WACF is the same as SCF. However, it is generally worse because WACF tends to use interpreted languages rather than pre-translated languages as in SCF. This differential becomes more significant to the user the more frequently they use the CF. The performance differential increases with the amount of functionality. Ultimately this performance differential resolves in higher hardware and/or energy costs.
When different users require different versions of functionality, WA simplify the problem by making versions available with different URLs. Forcing a new version on all users is also trivial, by simply changing the necessary URL targets. SCF version control suffers the same disadvantages as in CF deployment.
CH usually have resources that are external to the CF and CRE that can be utilised more easily by SC. For example: printing, local host search, email client, word processor, media player. Most WACF can also access external resources, but where it is possible it us usually more difficult and diminishes any sandbox feature.
A pure sandbox RE separates host from executing functionality but that is a double edged sword. It insulates the host from the adverse effects of rogue or faulty functionality, but it prevents access to external resources. In practice no pure sandbox RE are in widespread use, because there are always mechanisms to access external resources. The actual difference is in the balance of permission. With SC the CRE assumption is complete access permission, where in WA the CRE assumption is no access permission. So in the end the practical result is that if external resources are used it is more difficult to do so from a WA but that the host is better protected from faulty functionality.
Rendering a UI is done by the CF invoking functionality in the RE. In the WACF that is the browser. In the SCF that is the OS or CLR or JRE. In many cases they ultimately defer to OS GUI calls but each RE adds its own flavour to the UI. This may result in performance and style differences.
Gary E Byatt