Applets require an Java-enabled browser to execute properly and usually have restrictions due to the nature of downloading code from an untrusted source.
Applications on the other hand can execute by themselves without any need for a browser or appletviewer and do not have such restrictions such as: not being able to write to files on the client. This is allowed because they aren't being downloaded and executed simultaneously. However the user must have the a Java VM(Virtual Machine) on their system(currently) to execute your application, the compiled bytecodes to be exact, and your application can not be 'embedded' into a HTML page like an applet can.
Applets have the following execution path:
The applet itself is a Panel(Container) and has access to most of the AWT. But applets generally are graphical, thus they're not good replacements for CGIs. And unlike CGIs which run on the server's side, applets run on the client's machine(thus alleviating server-overload). Also CGIs can be written in any language and be accessible to all WWW Browsers(even Lynx). Where as applets are restricted to graphical browsers and generally require a high-bandwidth connection with lots of memory on the client's side. i.e More than 8 megs RAM, 486 or greater(386 dies a horrible death) and a 28.8k > connection.
Applets in this case use Java and the AWT as a weak-multimedia scripting language, rather than as a general purpose one, such as C.
A Sample Applet: Boss Dartboard(from Dilbert)
If you had sound, he'd being screaming. Here is the source
Note: One major restriction an applet has is: It can only communicate back to the host where it originated from.
Note: args differs from C/C++ to retain portability. i.e args is not the first string on the command prompt
Applications can be either text/character or GUI-based, thus Java can be used for CGI scripts as well as developing WWW Browsers(i.e HotJava). But character-based applications are not as straightforward as they would be under C or Perl, due to the nature of portability(and abstraction from the OS) in Java.
There is no restriction in making Java platform-specific with the use of native methods. You don't even need to use the AWT to create GUI applications in the platform of your choice. As long as there is a way to link native libraries(i.e DLLs) to Java, you can create applications as you would in C++.
Template AWT Application
Some example application code from CValcarc and explanations in comments also.
Q: Why use Java and the AWT? Why not use X?
A: The AWT(and Java) is portable. But so are tcl/tk, right? And how about Python? What about Smalltalk, Eiffel, C++, etc? To put it simply: Those languages and GUI libraries for them are far from simple nor portable. And languages like tcl are far too slow to be pratical. C++ too complicated and low-level for anybody but professionals. In short, every tool and language has its own use. Java accels in true portability and simplicity. Featurewise Java matches(or beats depending whom you talk to) C++, Eiffel, Smalltalk and Objective-C. And the AWT, although young has enough functionality for small applications. It still lacks many features to make it usuable in developing mainstream applications
Q: Which is better applets or applications?
A: Depends :-) I prefer applications, since applets have yet to "strike a chord" with me. But due to the youth of the AWT and the fact the lack availability of good tools(see Digital Focus for a list of tools) and some basic functionality such as printing classes, I must attempt both. For another it shouldn't be a difficult question. Do you want your "application" to run within a browser or outside of one?
Q: What is missing in the AWT?
A: Quite a bit if compared to wonderfully designed(simple and elegant) GUI libraries such as the VCL(Visual Component Library) of Delphi. The current AWT is still fairly low-level, not X calls, nor WinXX API, but lower than your average application framework. It currently does not separate interface from implementation very well, nor is there a resource format, nor true device independancy, nor printing capbility, nor a uniform help system, nor good inter-application communications protocols, etc.
But it does have threading and networking which is lagging is 99% of languages and GUI libraries.
Q: Who supports Java and the AWT?
A: Sun is the original developer of the language. Netscape adopted it back in May/95. Borland, Metrowerks, Macromind, Oracle, IBM, SGI, Symantec, Natural Intelligence, etc. have recently announced support for it. With support of Borland, who may or may not add "extensions"(IMHO good for the AWT), Java will take off like C++ did back 5 or so years ago. We need tools like Delphi to speed up development. Writing and re-wrting code for event handlers is more pain than necessary. Programs should generate all monotonous code for us and leave us with real programming. See AppletGen for a applet generator and check out Symantec's Espresso.
Q: The future of Java and the AWT?