thin client : Java Glossary


thin client
There are two main ways of writing an application, thin and thick client. In thin client there is no Java running on the client and in thick client there is, hence the terms. The following tables outlines the advantages and disadvantages of each approach.
Feature Thin Client Thick Client
Java Java runs only on the server. Java runs on client and server.
browser Required. Opera is the only browser that supports the latest Java 2 1.3. Microsoft Internet Explorer and Netscape are hopeless when it comes to Java. Optional. You can run the client portion as an Applet in the browser, or stand-alone without the browser. Getting rid of the browser gives you back RAM (Random Access Memory).
speed Slow. Everything must wait for the server to process and transmit the next screenful of information. Fast. Can instantly scroll especially if the app caches data locally. However, starting the application is slower than with thin client because you must load a copy of the JVM (Java Virtual Machine) and the application. With the server, it is already running when the end user first encounters it, so takes no startup time.
editing Edits are done in block mode. You don’t find out about your errors until you hit submit. It is up to you to find the erroneous data and correct it. Keystroke by keystroke editing possible. You find out about an error the instant you key it, or sometimes as soon as you finish keying a field. The cursor is placed on the exact source of the error.
pizazz You are limited to what you can pull off with HTML (Hypertext Markup Language) and animated gifs, or Javascript if you cheat on pure thin client. What the app does is limited only by your imagination. You have the full power of Java available. With an application instead of an Applet you have even more freedom.
hassle You must do all your coding on a server. If you don’t own a server, you will have a hard time persuading your ISP (Internet Service Provider) to let you use his, especially during the debugging phase. You have to think in terms of independent cgi transactions. Since the client does not maintain state information for you naturally, you must use cookies or other complex techniques. You don’t need Java working on the client machines. This saves a major installation hassle. You do some of your coding on the server and some on the client. This makes a natural split for a team to work on a large project. The real hassle is avoiding the bugs and deliberate booby traps Microsoft and Netscape have laid for you. If you want to do anything that requires signed Applets adds to the complication a hundredfold. You can avoid that hassle by using a standalone application instead of Applets. However, then with applications, you have the problem of distributing and installing them. In the simplest case, you don’t use a server at all and do all your work with the local Java application. In either case, you need to install and preserve from meddling a copy of the JRE (Java Runtime Environment) on each client machine.

This page is posted
on the web at:

Optional Replicator mirror
on local hard disk J:

Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.

Your face IP:[]
You are visitor number