Design:

The Java User Interface Browser works very similar to the HTML-Browser you are currently using.
Server-Side Presentation logic (running on a J2EE server) sends down a description how the User Interface should be rendered and which actions should be triggered on events.
JUIBrowser does not use a text-based protocol like XML, but instead the server-side API is the way developers talk to the client-side "renderer", very much like Java developers talk through the Swing-API with Swing.
The client-server protocol itself is highly optimized and compressed.

For every registered interaction the user does, the server is notified sending down a "changelog" and the client alters its UI according to the "changelog".

JUIBrowser uses the "half object" pattern where each Object on the server has its conterpart on the client:


Size:
JUIBrowser has been optimized to be as small as possible, the framework itself is processed with proguard which yields to really impressive results.

Default client:  35kb
With encryption:   45kB
With GroupLayout: 80kb

Of course JUIBrowser's size will grow a bit over time, however the framework can be considered feature-complete.
The small size is archieved using several clever tricks:

1.) For the most common cases we don't even need a client-side half-object, therefor functionality can be added without bloating the client in any way. This is the case for most Swing-Objects.
If you need complex functionality (e.g. real-time input visualization) you can simply add your client-side classes to classpath without recompilation or any class-register operations.

2.) Theres only a single class implementing all AWT/Swing Listener interfaces which redirect events to the server.
Of course you can add your own client-side classes but in the case the only thing you would like to archive is to receive swing-events simply use this class. Using only a single class we are able to save a lot small classes in favour of one large, good compressable one.

3.) JUIBrowser also keeps the server-state in sync with the client state using these listeners. However their listener-registration isn't sent down every time a widget is created - its hardweird inside JUIBrowser to save bandwith.


Which advantages does JUIBrowser has compared to:

AJAX:
JUIBrowser uses technology that has been designed for creating interfaces.
What AJAX does is basically creating complex user interfaces using a scriptable Text-Viewer, its like using MS-Word+VBA for creating fully fledged applications. It works to some degree but is a lot for work and the archievable results can't be compared to what could have been done with the right technology.

ULC:
Well, JUIBrowser is from its design quite similar to ULC. However its free software (GPL) and is even free for commercial use. JUIBrowser is no ULC clone, I've never written programs using ULC nor did I have a look at their APIs.

WebStart/Applets:
Webstart client-server application have the disadvantage that they have their presenation logic running on the client.
This has several disadvantages like:

- Size scales with functionality. Applications which grow in functionality will also grow in size which has to be downloaded. Applications written with JUIBrowser always have the same size (size of the client-runtime).
- Additional effort is needed to keep state in sync. It takes some time to make sure that the state of the presentation-logic on the client and the data-logic on the server match.