GWT vs WebCream(AjaxSwing)

[zb]

I would like to know are there any major differences between GWT and
WebCream? Obviously, it is easier to use WebCream if you have been
already developed Swing app. But if you are starting from begining...

[Peter Blazejewicz]

hi,
I know only from recent readings:
- AjaxSwing is not open-sourced (or there is specific case when it is
open-source) commercial tool
- AjaxSwing is Server side only (like ITMill toolkit) while GWT is
sold to client side technology with very large possibilites with
language-neutral server side technologies
- AjaxSwing is modelled (well, that's is porting library I guess)
after Swing, with GWT we are free. I've built my own components
without extending toolkit UI at all,
- AjaxSwing has "Swing" marks on it (I don't know how to explain that
better), with GWT I can write device (or browser/runtime) specific
widgets with specific interface usability and design (thik about
iPhone and let me know if AjaxSwing can write customized iPhone-ized
applications for "made for iPhone" mark),

And: there is a community there, there is countless number of GWT 3rd
party libraries (variety of licenses and purposes),

regards,
Peter

[koollx]

Here are some of the major differences

- GWT statically compiles Java into JavaScript, so entire client code
runs in the browser. AjaxSwing runs Java code on the server. Running
as JavaScript in the browser provides faster response time to the
client, but places various restrictions on what Java features you can
use

- GWT has it's own limited set of components/widgets. AjaxSwing
supports standard Swing components that are much richer then GWT

- GWT based UI has full access to browser API because it runs in the
browser, but is limited to server-side frameworks that can be used
with it effectively. AjaxSwing based UI has no access to browser API
in Java (it can be done using JavaScript) but has full access to any
Java frameworks running on the server

- GWT is relatively young and is not quite ready for large
applications (doesn't support Java 5 yet, doesn't have dynamic linking
at runtime for modular applications, doesn't allow for reflection,
doesn't have built-in UI themes etc.). AjaxSwing and Swing are mature
products that have been around for a long time

- GWT is easy to pick up but it requires learning and understanding of
Java and JavaScript. AjaxSwing doesn't require any learning beyond the
knowledge of Java and Swing.

- GWT will scale better because more logic is run on the client.
AjaxSwing doesn't scale as well because it runs logic and rendering on
the server.

In the end it probably boils down to what kind of application you are
building. If you need to run a lot of logic in the browser and your
application is not too big, GWT is probably a better choice. If you
already know Swing and want to get started faster, AjaxSwing is
probably a better choice.

[NN]

excellent post

[Tim T]

ajaxswing looks like crap...

[koollx]

A few more comments.

GWT's Java application can only be run in hosted mode, and in
production the app always runs as compiled JavaScript.

AjaxSwing works with Swing applications, so they can still be run as
thick Java clients or launched from the web with WebStart. And
obviously, if you already have a Swing application then you can
leverage all of the code.

As far as extending GWT/AjaxSwing with custom components, I would say
that both are equally easy or hard, depending what you call easy/hard.
In GWT it's relatively easy to create custom components with
composition, but you are not going to get very far. To create
something truly powerful you'll have to resort to writing low level
DOM manipulation methods or just offload it to "native" JavaScript
methods. Same with AjaxSwing - you can extend Swing components and
combine them into new ones, but if you want to step outside that
simple realm you'll end up writing a custom renderer that would most
likely use a lot of JavaScript.

This is not completely relevant to this comparison but we ran into
some issues that prevented us from using GWT (we fell in love with GWT
and were super-excited about using it). These issues were:

- Not being able to build a library module that is reused by different
application subsystems. Surely you can create modules in Java but when
GWT compiles the app it seems to be throwing all Java code into the
same JavaScript source file. As your application code base grows, so
does the size of that single .js file. This means long initial time
regardless of the percentage of the functionality used by the user.
This is not scalable approach - am I missing something here or is it
really the case?

- Not being able to dynamically link with modules. Similar to the item
above - we have a product that we want the customers to be able to
built upon. We want to define a Java interface for a "custom
component" and have clients implement it and register their component
with our product. Since GWT compiles everything into one module before
deployment, it doesn't seem to be possible to add anything to that
module later. So the only way to integrate with GWT-compiled app is
through JavaScript, and that get very ugly very quickly. Again, did we
miss something or is this really the case?

- Http Session access. We had a real hard time passing initialization
parameters to GWT module. It gets started in a vacuum and the only
clean way to get startup parameters is by making an Ajax call to the
server. A similar problem is that there's no clean integration with
HTTP session, so if the user hits Refresh in the browser the entire
state of GWT application is lost.

These seem to be quite obvious things that most applications would
need. These issues are non-issues with a server-side framework like
AjaxSwing or JSF, but they don't seem to be addressed out of the box
by GWT. I was wondering if other people ran into these issues and how
did they solve them?

[zb]

Thanks koollx and Peter Blazejewicz for very good answers.

Regards,
zb.