
Using Google Web Toolkit: A Year in the Trenches - webb
http://tech.dayzipping.com/using-gwt-to-build-a-large-web-application
======
ekidd
I've used Google Web Toolkit, and it does what it claims: It allows you to
write web apps in Java. GWT has solid abstraction layers, an optimizing
compiler, and clever support for image spriting. Using GWT is only marginally
harder than writing a desktop application in Java.

Of course, that leaves open a larger question: Do you, personally, want to
write web apps in Java? If not, then you'll find GWT to be a clever solution
to a problem that you didn't want solved.

~~~
cbo
I think GWT would be most useful to data-driven apps/services that need a web
interface. All of your heavy data mining can be done in highly optimized Java,
and then you won't need to context switch in order to implement your web
frontend. It's a win-win.

That's not to say that it can't be used in a more "social" context (Rypple
uses GWT for their app, and I have yet to see problems there), but I'd imagine
that it has greater use for data miners and enterprise applications.

------
curtis
When I was at Google I remember seeing an email on one of the lists from Steve
Yegge about GWT. Steve was talking to one of his buddies whose team was using
GWT. I don't remember the exact phrasing, but it went something like this:

stevey: I hear you guys are using GWT, how's that working out for you?

buddy: It's kind of like programming while wearing mittens.

stevey: Mittens are good, right?

buddy: Not if you're trying to type.

Make of this what you will.

------
gorilla123
I've used GWT for about a year, and I like it because I like static typing
more so than I like java the language. And yes, i've tried various dynamic
languages (ruby and javascript), and i still prefer the statically typed ones
for large projects with a large number of developers over a large time frame.
I also know that not everyone agrees with that, and if you don't, GWT may not
be the best tool for you. However, it works well for me. And if you ignore the
language debate, the toolset is very powerful.

(I also hope scala-gwt will become real-world-usable some day :) )

------
Ygor
After using GWT for a year as the basic tool for a project, I am not sure if I
would choose it again. I would, but only for a certain type of web apps.

I can't say it is bad. Actually, it has been pretty good. But, somehow when I
look at all the other development environments out there, some of them look
better. ekidd put it pretty well, actually.

The best side effect of using GWT has been a lot of business logic on the
client side.

The worst side effect of using GWT has been a lot of business logic on the
client side.

~~~
pohl
How is your choice of where to place your business logic GWT's fault? Isn't
that a choice you would have to make judiciously with any tool?

~~~
Ygor
You are correct, ofcourse. It is not the fault of the tool, but of a
developer. The tool just made it easier.

------
jcampbell1
When I visit www.dayzipping.com, I get a javascript error, and it fails to
load. The error points to some obfuscated code.

~~~
webb
Strange. What browser? Just tested in chrome, safari, and firefox and it works
fine.

~~~
jcampbell1
Chrome 9 for Mac. Standard install, not a dev build.

The error I see is: Uncaught TypeError: Cannot call method 'init' of undefined

~~~
loungin
I also see the same error. Running on 64bit Linux (Mint), happens with both FF
3.6 and Chrome 10

------
christkv
How about using node.js. Bang javascript on the server and on the client.
Personally I have high hopes for Sproutcore.

~~~
kodablah
There are some real weirdos out there (like me) who do things like this for no
reason: <https://github.com/cretz/gwt-node>

------
SupremumLimit
I used GWT for a while in 2009-2010, and didn't like it at all. I kept running
into things that weren't implemented in its subset of Java. Debugging was a
pain. Compilation was excruciatingly slow because of all the variations of the
code that always had to be compiled for different browsers (something like 40
seconds for a fairly small project) and development speed in general was slow.
Also, IIRC you could only run your project from Eclipse in some sort of an IE6
based container. All in all, it wasn't a pleasant experience at all, and I'm
not sure what the benefits are. Writing a web app in Java doesn't count as a
benefit for me, especially with so many constraints around it.

------
Tichy
GWT has to be the weirdest project ever. Imagine you were forced to work as a
LISP programmer, and out of desperation you would write a compiler that
compiles Java to LISP, so that you could continue coding in Java. It's almost
like that.

~~~
api
It would make sense if you had to write LISP to run on 30 different LISP
implementations, all of which had weird quirks that you had to memorize and
work around.

~~~
Tichy
But then you could also write one LISP that is a superset of all the LISPs?

------
karterk
I worked on a fairly large GWT based project. Once your project crosses
certain size, the entire compilation of Java to JS is royal pain and really
affects your productivity.

~~~
pohl
I've worked on several large GWT projects, and if compiling to javascript is
impacting your productivity, then your development process is not set up
right.

In particular, compilation to javascript should not be inside of your basic
edit->compile->test loop. Instead, you should be developing in DevMode
(formerly known as "HostedMode") where the code runs in a JVM. The step of
compiling to javascript should only happen once or twice as your code starts
going towards a production environment.

------
davej
I briefly tried this and pyjamas last year and I just don't see the point at
all. I guess this is aimed at the type of person who isn't experienced in
client-side web technologies (HTML/CSS/Javascript). The fact that somebody
could code a web application without much knowledge of the front-end web stack
_really_ scares me, I don't care how good the abstraction is.

------
nopal
Having to maintain static copies of every page that should be indexed seems
like a huge amount of overhead. GWT could be great for an internal app, but
until this is resolved, I couldn't see using it for a public-facing
application.

~~~
pohl
That's not a GWT issue, but an issue with architecting a web application in an
all-in-one-page AJAX style. The same would be true with any web application
written in that manner, regardless of toolkit.

~~~
nopal
Yes, and? Aren't we discussing the merits of using GWT?

~~~
pohl
That's exactly my point. Since we're discussing the merits of GWT, we should
avoid points that have nothing to do with GWT _per se_.

To put a finer point on it: GWT does not require you to structure your app
that way. If you do choose to structure your app that way, then you're making
the same tradeoff that you would make if you were to go down that same path in
any toolkit.

~~~
nopal
I don't see any point in discussing GWT by itself, without any comparison to
other development techniques, and when you compare it to traditional
approaches, the "SEO overhead" mentioned in the article is a downside.

~~~
pohl
Ok, but let's cleanly separate the concept of a tool from the concept of a
technique.

The technique here is using URL fragments for history management in AJAX
applications.

This tool (GWT) does not require that technique any more than JQuery does (or
myriad other examples), so the comparison of the tradeoffs of using/avoiding
the technique is orthogonal to the choice of tool.

~~~
nopal
That's good to know. From the article, it sounded like hashbang URLs were the
default/preferred method of handling navigation.

~~~
pohl
Yeah, I think that section of the article could be improved.

If I were facing their problem (where they had already chosen to use URL
fragments for navigation but also didn't want to miss out on crawlability) I
would use a different approach than maintaining a separate set of static
pages.

Instead of static pages, I would create a single servlet/cgi that would handle
the URLs to these pages. The content for each URL could be created on-the-fly
on the server side using some server-side browser (like HtmlUnit, Cobra or
Crowbar...) to receive the requests, translate the URL into the fragment-
format, run your actual javascript application (which is already written to
handle such fragments) and capture the resulting DOM to send back to the
actual browser that arrived via the Google search. Of course the HTML could be
persisted so that this process would only need to happen once per URL. The
benefit of doing it this way would be that when you deployed changes you could
simply invalidate the HTML cache and let your system build them again
automatically.

But it would probably be better to avoid the problem entirely by thinking
about SEO needs up front.

------
utops
Perhaps I don't understand GWT correctly, but it seems like it would be very
difficult to layout and design a web front-end from within Java code alone.

~~~
Ygor
It depends. For someone who has no experience with html/css layouts, and has
the ability to build his own design from scratch, creating the layout in code
might seem simpler. The reason: it feels similar to creating desktop app
layouts (i.e. Swing). And you don't have to worry about cross-browser stuff
(in theory).

Also, You can now use GWT Designer, an Eclipse plugin that lets you build UIs
graphically.

On the other hand, if you are a familiar with html and css layouts, this all
might seem like a big mess, and too much work to do something simple. And you
will not like the generated code (many many tables, often).

That's why they created GWT's UIBinder. You can use a html-like code to design
the UI. This is much easier than making all the panel.add(widget) stuff in
code. And it is a nice compromise, because your front-end designers will
understand it. The big downfall is that it needs to be compiled to view the
results, and believe me, this can be a cumbersome task.

I have been using it in the scenario where we get all the html and css from
the designer, along with the jquery to add some effects. It wasn't easy
porting the whole (working!) design to something usable by GWT. But, in the
end we got the GWT to generate exactly the same markup.

All in all, there's no such thing as a free lunch.

