j2s-development] gwt groups post

[Ash W. <as...@gw...>]

Josson Smith wrote:
> By the way, if you have any ideas or thoughts about Java2Script,
> Java2Script team will appreciate for your discussion on its development
> mail-list.

thx for the invitation. ill cross post so both lists can take their dig
at me <g>. the purpose of this post is to present some random thoughts
that i have had.

josson,

thanks again for your contribution to the thread. i appreciate your
openness about the j2s classloader issues & ideas, and also your
interest in understanding the motivations of the gwt compiler.

i find myself routinely getting svn updates of your commits and
monitoring your progress. there is something that is very right about
your approach, that for me keeps gwt in check.

first, let me state where i think your project is positioned (pls
correct me where im wrong). i believe j2s is positioned b/n xml11 and
gwt. my rationale is:
* xml11 is server heavy and renders any awt based application to a
browser by sending delta DOM changes over the wire in a similar fashion
to ZK as one of its two approaches. there is work in progress to
support both swing and swt. the point being is that if you had existing
desktop java software that needed to be accessible via a browser, then
this may well become the most effective solution when xml11 maturity
improves.
* gwt is almost completely client based, has created a new ui widget
API that is coupled to the DOM, and does not attempt to leverage
existing java gui APIs

now lets discuss ui. note, whilst im not a huge fan of the gwt widget
API, there are the following things that i do like:
* it is very light weight
* it uses the clever gwt browser module strategy approach for
addressing browser independence
* it aims to be simple

to be honest, im not a big fan of swing or swt either. however, having
said that, what i do like about j2s is that:
1. java developers can leverage a matured, well understood, and
documented gui api
2. all widgets work out of the box (ie. no css files to hack)
3. it leverages an existing tools market built around swt

however, let us consider how important these points are to a community
like gwt. im sure the community will correct me where i am wrong.

> 1. java developers can leverage a well understood and documented gui api

sure there are many old swing/swt hacks that are in this community, but
to my surprise there are many non java folks. most of these guys would
probably look at swing/swt code and proclaim: "what the ...".
furthermore, there is a large advocacy for a middle ground between
social based web apps and traditional desktop style application in a
browser. perhaps this is where the openlazlo folks are headed. claude
has spoken at lengths on this subject (consider searching his posts) on
this group. therefore, should this motivation have a high priority as
we both originally anticipated?

> 2. all widgets work out of the box (ie. no css files to hack)

imho this is one of the most undervalued benefits of j2s. ive also
experienced this with zk and openlazlo - things just work without
configuration or deep knowledge. not only do u provide a near complete
swt widget impl., but it actually renders as expected. being part of
the client/server generation and developing apps in win3.1, win95, etc.
it became evident what tooling was required to attract the masses. i
think gwt (or gwt tool community) has a long road ahead and relies too
heavily on css/graphic expertise for the masses to arrive any time
soon.

> 3. it leverages an existing tools market built around swt

here again is another instance of the "minimise duplication, maximise
leverage" prinicple. however, having enough weight behind gwt, there
are 2 tools at present to support gui building for gwt. i use
instantiations' windowsbuilder pro::gwt-designer edition which is
slowly doing to gwt, what it did for swing/swt. therefore again, should
is this motivation have a high priority as we both originally
antipicated.

finally, lets discuss some of the pain points experienced by some
members of the gwt community.
1. developing applications with modules that can be dynamically linked
and shared accross multiple modules/projects
2. the limited jre causes engineers to duplicate code from existing oss
java projects when required
3. there is no support for reflection. gwt does support a powerful
compile-time concept called defered binding. admittedly, most things
can be pushed to either defered binding or the server side, but very
occasionally you do discover the need for reflection

---

i have never looked at j2s and gwt as competitors, rather ive always
looked to complement gwt with j2s and attempt to address some the paint
points above. i have often thought wouldn't it be cool if:
* j2s could achieve a static (way ahead of time) compile like gcj and
render an entire appl as a single html/js like gwt, and/or offer a
partitioned html/js with shared objects (designers can choose with
compiler switches)
* j2s could let me statically link my library with apache commons lang
(etc.) and render a js that i could call from gwt. hence, whenever gwt
could not do the heavy lifting, i could turn to j2s.
* all of j2s's swt widgets could be synthesized into gwt, but leverage
the low level DOM and Event abstractions rather than gwt ui widget api.
this time focus on a more common listener interface, build drag'n'drop
into the base and also consider component serialization and convenient
component to component assignment

---

in your blog u felt that this thread became x v's y. im sorry u felt
like that. as indicated above, i and im sure many others here are
uninterested in competition, but better solution.

im convinced that there is a market for your work. what and how this
community can leverage it within the context of gwt depends on the
roadmap of gwt.

best wishes
ash
http://www.gworks.com.au