GWT pros and cons

[pady...@gmail.com]

I have been told to put together a pros/cons list for GWT for my
company for future direction purposes. I am decvently familiar with
GWT but am not sure abt show stopper bugs/issues. Here is the list I
have put together and if people can add more to it, it will be much
appreciated.


Pros
---------

1. One language to work with ( Java ). In an usual Web app or AJAX
app, one has to know to code in HTML/DHTML, Javascript, JSP/ASP, JSTL
etc. With GWT it is all Java.
2. Tooling: Integration with Eclipse and IntelliJ. One can develop a
GWT app like developing any other java app.
3. Debugging: Like any other java app, ide debugging into both client
and server side code. No need for separate tools for different
browsers ( IE vs Firefox )
4. Deal only with POJOs - no JSON/XML/DOM stuff. Can leverage typical
OO design patterns.
5. No code reengineering done at run time. All java code is compiled
to Javascript.
6. Support for many AJAX widgets
7. No browser specific code. GWT generates it.
8. Java 1.4 compliant on client side and no restrictions on server
side.
9. Code size and execution speed is much lesser ( > 100% gains )
compared to typical javascript coding.
10. Time to deliver is much faster and fixing issues are much faster
than typical jsp/javascript apps.
11. Unit testing: One can write client and server side JUnit tests
like any other java app.


Cons
----------

1. Just because one can write in java doesn't mean all java api's are
supported. This is not a restriction of java - rather it is of
javascript. Since GWT compiles the java code into javascript, only
features that are supported in javascript can be implemented on the
client side code in gwt.
2. Some syntax quirks around passing complex java objects between
client and server. Like Collections have to defined in the javadoc as
an annotation.
3. Concept of modules can be confusing.
4. Jumping between secure to unsecure modes can be quirky - ie have to
move between web apps because of app context.
5. Since generated code is javascript/html, one needs knowledge of css/
html for setting styles to the rendered page elements - can be set in
separate css file or can be set directly on the Element.
6. Exceptions and Serializable issue has to be done with a workaround.



Thx

-- pady

[pady...@gmail.com]

I noticed a nice discussion related to the same topic...


http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/a4b65b2239005dbc/f5b976645a0b5380?lnk=gst&q=gwt+pros+and+cons#f5b976645a0b5380


Thx

-- pady

[walden]

I have not found a single showstopper with GWT. I think the Cons on
your list are mostly non-issues that can be lumped into the general
category of "learning curve", which every technology has. CSS is a
Pro, by the way.

Walden

On Mar 4, 8:30 am, "padysr...@gmail.com" <padysr...@gmail.com> wrote:
> I noticed a nice discussion related to the same topic...
>

> http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...
>
> Thx
>
> -- pady

[NN]

Cons:
1. Multiple modules separation is not straight forward i.e. per module
js files is not generated with concise JS & HTML files. I had some
problem with that and workaround is not great.

2. If you want page type navigation i.e. PHP or JSP type per page
application then you have to found your own way to do it.

3. Hibernate and Spring with GWT-RPC kinda do yourself but GWT has
nothing to do with server side. (Flex has server side service which
cost you but they have it and works well with flex)

4. If you write big fat one module application then download time is
higher (JS/HTML combo size goes up). In this case per page module load
or one module loads and use by multiple HTML or JSP or PHP pages which
makes life easy. In short you download only module per user request.
If user don't go to certain area of website why to download that
source code.

5. You are at mercy of third party libraries for (DataGrid and
Charting or Drap and Drop) advance or large data set operation.

6. No clear separation between application developer and designer i.e.
person who will design look and feel needs to know little bit about
GWT CSS or Java style look and feel. We can use any typical designer
who provide HTML/CSS and integrate that in JSP or PHP. But GWT makes
life harder in that case.

I can write more but don't like to bash or cry because of certain
things don't work easily but that's the case with every technology.

[Francis Amanfo]

Another con:

Wierd and non-conventional project structure and no standard or trivial way to set up a GWT Maven or Ant build project. Packaging and deploying to an external webserver could also be a pain.

Francis

--
Beware of bugs in the above code;
I have only proved it correct, not tried it.
                                   -Donald Knuth

[Jason Essington]

I've gotta agree with walden, no real show stopper issues with GWT,
there are however some caveats to be aware of.

1) SEO - pure GWT pages cannot be indexed by web spiders.
2) GWT is ultimately javascript/DOM manipulation on the client, and
thus will not work in environments where javascript is forbidden or
disabled.
3) Fringe browsers that don't use the rendering / javascript engines
of IE, FF, Safari, or Opera will not necessarily work well, if at all

I'm sure that there are others. But those are some things you should
be aware of when planning your overall architecture.

Remember, GWT is only one part of an over all web application.

-jason

[Leon]

I would add one more con for big apps:
GWT Compiler is very slow comparing to standard java compiler.
Prepare to wait about 10 minutes just to compile the large GWT
application on common windows desktop computer.
During development good module separation approach can save you from
such problem to some extent.
But anyway you will have to perform integration between multiple GWT
modules in some point.

-- leo

[Dan]

On Mar 5, 8:29 am, Leon <leon...@gmail.com> wrote:
> I would add one more con for big apps:
> GWT Compiler is very slow comparing to standard java compiler.
> Prepare to wait about 10 minutes just to compile the large GWT
> application on common windows desktop computer.

Really? how would you define big? I have quite a substantial GWT app
and a full ant build to a war file including all java and gwt
compiling takes less than a minute on my not so new windows laptop.

Dan

[PiotrN]

On Mar 4, 8:49 pm, Jason Essington <jason.essing...@gmail.com> wrote:

> 1) SEO - pure GWT pages cannot be indexed by web spiders.

For many purposes, this is the real show stopper.
You can however move around the problem by including he content to
html
and then manipulate it with GWT.
This however complicates things greatly.

[David Easley]

The accessibility story isn't great. Uses table-based layout in
situations where, nowadays, one might expect CSS positioning to be
used instead.

If anyone has any experience of a non-trivial GWT app being used with
a screen-reader, I'd love to hear how it went.

David

[George Georgovassilis]

Dan, then you obviously have worked only on small applications. A
reasonable app (500+ classes/interfaces on the client, 30+ for RPC)
will take much more than a minute. This makes development on layouting
for a browser different than the hosted mode browser very tedious
since you wait two or more minutes just to try out a twist in your
html. Yet I am confident that as GWT matures the compiler will become
faster too.

[Jason Essington]

Actually this just demonstrates that you shouldn't place all of your
faith in one technology ...

GWT + CMS (of your choosing) is really a good solution to having a
nice dynamic site and allowing SEO

Enjoy your alphabet soup :-)

-jason

[Jason Essington]

Actually I believe that the default Table based layout of GWT was a
conscious decision on the part of the GWT team.

Fancy CSS layouts are not something simple for the entry level
developer to wrap their head around, whereas tables just work.

However, for anyone who is well versed in such layouts, it is not
difficult to recreate them in GWT.

Now, do screen readers even process DOM manipulated content?

That may be another place where GWT + CMS would be a better fit.

-jason

[Dan]

On Mar 5, 1:35 pm, George Georgovassilis <g.georgovassi...@gmail.com>
wrote:

> Dan, then you obviously have worked only on small applications. A
> reasonable app (500+ classes/interfaces on the client, 30+ for RPC)
> will take much more than a minute. This makes development on layouting
> for a browser different than the hosted mode browser very tedious
> since you wait two or more minutes just to try out a twist in your
> html. Yet I am confident that as GWT matures the compiler will become
> faster too.

Yeah ours is something in the region of 100 classes client with only 2
doing RPC.

[Leon]

By 'big' I mean at least several hundreds of client classes which
needs to be compiled by GWT Compiler.
In our application we currently have around 1500 client classes and I
think in several months there will be 2000+. So slowness of GWT
compiler becomes a very major issue in this case.

Leon

[Axel Kittenberger]

The big pro why I use GWT.

You code in a strong typed language. That is type oriented, and the
compiler will complain about a lot of standard errors you just *will*
do, even before you have to test the application and encounter the
specific code line.

Like for example a function taking 3 parameters, but you accidently
called it with 2 or 4. In GWT the java compiler will halt, and tell
you to fix the problem. In javascript nothing will ever complain,
infact the 4th paramter is just ignored... and you can debug days to
find the issue that took 3 minutes on GWT to find.

Thats why IMHO there are hardly large javascript applications (except
google-docs :-), because after a given size of the project, the week
nature of JS language makes it just unmaintainable.

The biggest con I encountered by other people indirectly saying...
They just don't like java. If there would be a "ruby-webtoolkit", they
would be won for this technology also, but emotions are emotions :-)

[Andre Freller]

Pros:

Fast, reliable and robust application.
No javascript nightmare.
No client side installations. Your users just access your page and are ready to go.
Open source.
Free.
Intl. support.
CSS based layout.
Able to use native JS when needed.
Able to interact, throw JS, with JAVA and Flash.
Did i mention no javascript nightmare?
No browser nightmare!

Regards,
Freller

[arthu...@gmail.com]

I have to agree with Jason here, you can't put all your eggs in the
GWT basket. I personally wouldn't use GWT for mainly content sites
with very little dynamic features, rather, I think GWT is perfect for
_web applications_ that wouldn't be indexed anyways.

[TheB...@gmail.com]

GWT is extremely helpful for coding dynamic applications. At first I
was coding an dynamtic application using php and javascript while was
working well until they keep requesting changes after changes. The
dynamtic code became extremely complex and messy but with GWT it is
easy to rewrite parts of the code. Even though gwt takes longer to do
a simple site but when a site is very dynamtic and complex. gwt saves
a lot of headaches.

[Matt]

I guess you haven't heard of the gwt-maven plugin?

http://code.google.com/p/gwt-maven/

On Mar 4, 6:17 pm, "Francis Amanfo" <fama...@gmail.com> wrote:
> Another con:
>
> Wierd and non-conventional project structure and no standard or trivial way
> to set up a GWT Maven or Ant build project. Packaging and deploying to an
> external webserver could also be a pain.
>
> Francis
>

> On Tue, Mar 4, 2008 at 2:25 PM, padysr...@gmail.com <padysr...@gmail.com>

[Peter Blazejewicz]

hi Leon,
I think you need good evangelist,
google docs as we know are not written as monollithic block of html/
ajax mix and there are more reasons for that then simply long
authoring time (or compile time as with java) of hypothetical single/
monolithic "google docs" single browser page release,

regards,
Peter

[Sumit Chandel]

Hi Francis,

Could you elaborate a little more on these points? We realize that GWT does have a particular project structure that may not be completely intuitive at first glance, but GWT is a particular kind of technology.

If there is any confusion about the project structure that makes setting up a GWT application tricky for new developers aside from the initial learning curve, let us know. I believe that the GWT project structure isn't so bad once newcomers get more familiar with it, but it's quite possible that a lack of proper documentation about the project structure could hinder the learning process.

We are already working on greatly improving documentation along with the 1.5 final release, and we'd be happy to get some early input to make sure we haven't missed any key information to ease the learning process.

About setting up a project for easy Maven or Ant building, I'm probably missing some details on what makes integration with these builders particularly difficult. From my perspective, integrating GWT project build and deployment in Ant is nothing more than a matter of creating a build target for the GWT compiler to compile the project and moving the files to the directory from which you expect to serve your GWT application files. GWT-RPC or other server-side application components could probably be handled in independent build targets.

Is there anything more than this that I'm missing that could make Ant building trickier? We've recently introduced a new Linker subsystem in GWT 1.5 that might be able to provide something to make integration easier depending on the issues involved in making build integration easier.

Linker subsystem:
http://code.google.com/p/google-web-toolkit/wiki/LinkerDesign

Cheers,
-Sumit Chandel

--
Join us at Google's biggest developer event of the year
May 28-29, San Francisco
http://code.google.com/events/io

[Peter Blazejewicz]

hi,

On Mar 5, 1:09 am, NN <neh...@gmail.com> wrote:
> 3. Hibernate and Spring with GWT-RPC kinda do yourself but GWT has
> nothing to do with server side. (Flex has server side service which

> cost you but they have it and works works well with flex)

I know (being using) Flex from v.1.0 (which was not free and not
available for regular developers) and it always supported the same
thing as GWT: plain old pojo like based RPC and DTO/VO objects (the
first ever book on Flex ria by guys from IterationTwo was full of
things that sounds like every day routine for people knowing GWT RPC).
The only difference is protocol: Flex was (is) using binary amf1/amf3
protocol while GWT RPC uses plain ajax rpc (gzipped to save
bandwidth),
From developer point there is no difference and you can use the same
code for both, am I correct with that?

regards,
Peter

[Isaac Truett]

Sumit,

I don't think there's anything inherently difficult about building GWT
applications with Ant; but that's coming from a background of
extensive Ant and Java experience. What I have observed with some
developers is that they have trouble making the leap from following
the Getting Started guide to picking things apart to see how they
work. If all you've done is run the .cmd or .sh scripts created by
applicationCreator/projectCreator to compile and start hosted mode,
then you might not be comfortable enough, or even know where to start,
to write an Ant target.

As far as improvements, more documentation is almost always a good
thing (and a pain to write, for most developers). Some people might
find a pre-written <gwtc> Ant task easier than writing a <java> call
to GWTCompiler. I was about to suggest having projectCreator produce
an Ant build file, and then I looked and found that it already has an
option to do so! Maybe that needs to be advertised more to get people
to use it? Would there be any interest in giving the projectCreator's
Ant build file a face-lift for GWT 1.5 (or beyond)? I would be happy
to lend my time to write it.

- Isaac

[Peter Blazejewicz]

Hi,
I second Isaac post,

>I don't think there's anything inherently difficult about building GWT
> applications with Ant; but that's coming from a background of
> extensive Ant and Java experience.

Take me as example: I hate Ant (I even hate maven worst and never used
it), maybe i'm seasonal developer but I always been using tools for
compilation,
See: it took some time to convice GWTD team to add "compile" target to
GWT Designer (so I don't have write Ant now):
http://www.instantiations.com/forum/viewtopic.php?f=11&t=1821
now having written compile/run targets as part of IDE I can play with
things,
regards,
Peter

On Apr 9, 11:16 pm, "Isaac Truett" <itru...@gmail.com> wrote:
> Sumit,
>
> I don't think there's anything inherently difficult about building GWT
> applications with Ant; but that's coming from a background of
> extensive Ant and Java experience. What I have observed with some
> developers is that they have trouble making the leap from following
> the Getting Started guide to picking things apart to see how they
> work. If all you've done is run the .cmd or .sh scripts created by
> applicationCreator/projectCreator to compile and start hosted mode,
> then you might not be comfortable enough, or even know where to start,
> to write an Ant target.
>
> As far as improvements, more documentation is almost always a good
> thing (and a pain to write, for most developers). Some people might
> find a pre-written <gwtc> Ant task easier than writing a <java> call
> to GWTCompiler. I was about to suggest having projectCreator produce
> an Ant build file, and then I looked and found that it already has an
> option to do so! Maybe that needs to be advertised more to get people
> to use it? Would there be any interest in giving the projectCreator's
> Ant build file a face-lift for GWT 1.5 (or beyond)? I would be happy
> to lend my time to write it.
>
> - Isaac
>

> >  On Tue, Mar 4, 2008 at 6:17 PM, Francis Amanfo <fama...@gmail.com> wrote:
> > > Another con:
>
> > > Wierd and non-conventional project structure and no standard or trivial
> > way to set up a GWT Maven or Ant build project. Packaging and deploying to
> > an external webserver could also be a pain.
>
> > > Francis
>

> > > On Tue, Mar 4, 2008 at 2:25 PM, padysr...@gmail.com <padysr...@gmail.com>

[Sumit Chandel]

Hey Isaac,

As far as improvements, more documentation is almost always a good
thing (and a pain to write, for most developers). Some people might
find a pre-written <gwtc> Ant task easier than writing a <java> call
to GWTCompiler. I was about to suggest having projectCreator produce
an Ant build file, and then I looked and found that it already has an
option to do so! Maybe that needs to be advertised more to get people
to use it?

That's right, there is an option to have the projectCreator produce an Ant build file! I had actually forgotten about this as well ;-) We have a new batch of documentation coming out with 1.5. I'll have to check it out and see how visible and clearly explained the bit about using projectCreator to create an Ant build file is and whether we need to add any improvements there.
 

Would there be any interest in giving the projectCreator's
Ant build file a face-lift for GWT 1.5 (or beyond)? I would be happy
to lend my time to write it.

It sounds like this thread is ripe for graduation to GWT-C.I don't think the GWT team currently has any plans to make changes to projectCreator for 1.5 (not sure about after that), but it would be a good idea to bring it up on GWT-C to see if there is any community interest in potentially improving the projectCreator script. Feel free to post up and list out some of the things we might want to change in a potential face lift and let's see where it goes.

There's another recent thread on these forums on the same topic. I'll point those posters to the GWT-C thread to get there input.

Related thread:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/fa24533fdbd89c2/86b404264445eebf?lnk=gst&q=ant+task+for#86b404264445eebf

Cheers,
-Sumit Chandel