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.
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:
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.
On Mar 4, 5:25 am, "padysr...@gmail.com" <padysr...@gmail.com> wrote:
> 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.
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> wrote:
> 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
-- Beware of bugs in the above code; I have only proved it correct, not tried it. -Donald Knuth
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.
> 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...
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
On Mar 4, 9:49 pm, Jason Essington <jason.essing...@gmail.com> wrote:
> 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
> On Mar 4, 2008, at 12:28 PM, walden wrote:
> > 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...
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.
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.
> 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.
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.
On Mar 5, 10:53 am, Dan <daniel.vaug...@gmail.com> wrote:
> 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.
> 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.
> 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
> On Mar 4, 1:25 pm, "padysr...@gmail.com" <padysr...@gmail.com> wrote: >> 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.
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.
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
On Mar 5, 11:53 am, Dan <daniel.vaug...@gmail.com> wrote:
> 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.
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 :-)
On Mar 6, 8:32 am, Leon <leon...@gmail.com> wrote:
> 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
> On Mar 5, 11:53 am, Dan <daniel.vaug...@gmail.com> wrote:
> > 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.
*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
On Tue, Mar 4, 2008 at 8:25 AM, padysr...@gmail.com <padysr...@gmail.com> wrote:
> 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.
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.
On Mar 5, 7:32 am, PiotrN <piotr.nast...@gmail.com> wrote:
> 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.
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.
> 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>
> wrote:
> > 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
> --
> Beware of bugs in the above code;
> I have only proved it correct, not tried it.
> -Donald Knuth
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
On Mar 6, 9:32 am, Leon <leon...@gmail.com> wrote:
> 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
> On Mar 5, 11:53 am, Dan <daniel.vaug...@gmail.com> wrote:
> > 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.
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.
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> > wrote:
> > 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
> -- > Beware of bugs in the above code; > I have only proved it correct, not tried it. > -Donald Knuth
> 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?
> 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.
> On Mar 4, 5:25 am, "padysr...@gmail.com" <padysr...@gmail.com> wrote:
> > 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.
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.
On Wed, Apr 9, 2008 at 4:00 PM, Sumit Chandel <sumitchan...@google.com> wrote: > 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.
> 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> > wrote:
> > > 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
> > -- > > Beware of bugs in the above code; > > I have only proved it correct, not tried it. > > -Donald Knuth
>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:
> 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 Wed, Apr 9, 2008 at 4:00 PM, Sumit Chandel <sumitchan...@google.com> wrote:
> > 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.
> > 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>
> > wrote:
> > > > 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
> > > --
> > > Beware of bugs in the above code;
> > > I have only proved it correct, not tried it.
> > > -Donald Knuth
> > --
> > Join us at Google's biggest developer event of the year
> > May 28-29, San Francisco
> >http://code.google.com/events/io
