We put our GWT-based job site (http://www.careercommons.com
production on Monday. This is a summary of my experience coding the
whole thing in GWT. Not sure how useful this is for other people, but
here it goes:
1. It has about 900 classes, including all the interface classes, data
transfer classes, etc. Not a big system for a team, but not a small
system for two people.
2. We have about 17 GWT modules, as one module would take too long to
load for this kind of application, in our opinion. It takes about 18
minutes to compile on my Windows machine, and 1 minute longer on my
newer and much faster Linux machine, which baffles me no ends. Why is
JDK faster on Windows? I am curious about the speed of compiling GWT
on a Solaris machine now.
3. It took six months to code. It was mostly done by me, with a friend
helping here and there. And it was my decision to use GWT. And I can
honestly say that without GWT, it would have taken a lot longer than 6
months, and the result would be much worse.
4. We use OpenOffice as the backend to generate Microsoft Word and PDF
documents. So, we have to create ODT documents on the fly. We have to
convert some data from HTML entered by the user into the RichTextArea
widget. The HTML to ODT capability is quite limited right now, but
will be improved as time goes on.
5. We use Tomcat 6.0.16 on the server side. As a production system, it
has its problems. But after using Tomcat for the last 8 years, we sort
of know what to expect and what to avoid.
6. We use postgres 8.3.3. as the database. In our pre-production
period, we were patching the database from deployment to deployment to
figure out the character of the system (every system reacts
differently in production, and we wanted to learn that character
before putting the system in production), and PLPerl is really good in
handling data migration on the fly. Underpowered (try passing arrays
in as parameters), that is for sure, but easy to handle.
Now, these are lessons learnt by me coding this application. They
might not apply to your situations. And they are really common sense.
If you don't agree with them, I am all ears.
1. Can't reuse data transfer classes. Initially, we had general
purpose data transfer classes between the database and the browser.
Then we found out that we are transferring way too much information,
and data security was getting scary. So, mid-way, we decided to have
data-transfer classes that are tailored for particular remote methods.
Both approaches have their disadvantages, of course, but I am happier
now as I don't have to worry as much about data being leaked to the
2. (Non-GWT) JPA is godsend in 90% of what we need to do with a
database. For the other 10%, it is a drag. We use Hibernate first and
then OpenJPA, the performance for some operations is still not good
enough for me. JPA is doing too much sometimes (fetching stuff not
needed), and too little in other times (not fetching stuff that is
needed almost right away). But no system can read the programmer's
mind, so I am extremely grateful to be able to use JPA for the 90%,
and I have no problem coding by hand the other 10%. The only thing is
that refactoring is made harder by JPA, as the queries are in
It would be nice to have a tool that allows programmers to code in
Java for the queries, to make refactoring of the entity classes
easier. But then that will need a GWT-like compiler to make it
possible to write queries in Java, so that people can develop and
debug in the Java mode, and then compiled into JDBC or JPA queries
strings for a "production-mode". Sounds like an interesting project to
3. GWT 1.5 is easier to handle than GWT1.4. The system was in GWT1.4,
and I moved it to GWT1.5 to anticipate the next version of GWT. But we
could not stay with 1.4, as the generics and annotations are simply
too valuable for refactoring. The lesson learnt is that even though we
don't create our own generics, just as a compilation checking tool and
its ability to facilitate refactoring for GWT, it is worth it.
4. Test the browsers. Don't assume everything will work in the same
way. We did have to avoid some browser problems, like one time we were
causing Opera to crash consistently over some HTML produced by MS
Word. That is not a GWT issue, of course, it is an Opera issue (it
should not crash when fed with that HTML), and our issue (we should
not feed Opera HTML that it is going to choke on). And the other time,
when we crashed IE with the PushButton widget; this is a GWT issue, as
it should not crash IE, and it is IE's issue, as it should not crash,
period. But compared to what we would have to handle hand-coding
The other thing is, if you have a lot of information to display, the
browsers don't display them in the same way. For instance, Firefox
would display information when it comes, IE would display only after
all the information has arrived, etc. So, a progress widget is easy to
code for Firefox, but much tougher for IE.
We are not usability experts, and we are not graphic designers either.
wanted to build a system that is clean, and made the editing
operations in-place, so that the user's attention does not have to
switch to a new page, and then back, whenever they want to do
something. Instead, they will look at the same widgets when
information is displayed, and when they want to change the information
being displayed. I think we accomplished that.
For the site, we aimed to make the UI as clutter-free as possible, and
make the different operations available as cleanly as possible. I
think we succeeded in those two goals as well. But see for yourself,
as the site is free for everyone. Obviously, we have just started, and
we have not started to talk to companies and recruiters yet, so there
are no job postings right now. But you can enter information, and see
how the information is displayed, edited, etc.
If you did try the site, please let us know what you think of it. We
value your suggestions, criticisms, and comments very much.
Obviously, whether the site is going to be successful really does not
depend on what toolkit we used to code it.