tags:

views:

107

answers:

5

I recently added GWT to our project to implement an Ajax feature of our web app. The other devs are complaining about the extra time GWT compile adds to the build and are asking why I didn't use JSON and jQuery instead. What should I tell them?

+1  A: 

What was the reason you used GWT instead of JSON/jQuery?

I would ask the same question since for what you need, GWT may not be legitimately needed.

Milan Ramaiya
Using it for a shopping cart with item configuration and repricing in the cart.
DataSurfer
+1  A: 

In my experience, I totally understand the complaints you are getting. GWT is a wonderful technology, and it has many benefits. It also has downsides and one of them is long compile time. The GWT compiler does lots of static code analysis and it's not something that has an order-of-magnitude solution.

As a developer, the most frustrating thing in the world is long development-deploy-test cycles. I know how your developers feel.

You need to make an architectural decision if the technological benefits of GWT are worth it. If they are, your developers will need to get used to the technology, and there are many solutions which can make the development much easier.

Yuval A
A: 

If there was a good reason for using GWT instead of pure javascript, you should tell them this reason (skills, debugging for a very hard to implement problem, you didn't want to deal with browser compatibility, etc). If there is no good reason, maybe they're right to be upset.

I use GWT myself and I know about this compile time :-)

If you used GWT for an easy-to-implement-in-javascript widget or something like that, maybe you should have consider using javascript instead.

Thomas
Using it for a shopping cart with item configuration and repricing in the cart.
DataSurfer
+2  A: 

Try to make the build smarter, if it isn't already: The GWT (client) part should only be re-compiled, when the client source changes. I assume, it's mostly you who changes that source, so the other developers won't experience the pain.

Caveat: This doesn't work of course, if your client source shares code with the existing project (I assume, it's a Java project on the server side?). But maybe you should avoid shared code in your case: Even though that's violating the DRY (Don't Repeat Yourself) principle, realize that you'd violate it anyway, if you didn't use GWT.

However, if you do reuse code from the server project, then you have a good argument, why you used GWT.

Chris Lercher
Yes Java Spring Hibernate backend with domain objects and DTOs. DTOs are being used for all service calls from flex, jsp, and now GWT.
DataSurfer
@DataSurfer: In that case, the GWT client side code needs to be rebuilt, whenever the DTOs change. That can be an advantage: Your GWT code will fail to compile, and you'll repair it immediately, while JavaScript code would continue to "work", but probably break at a later point (usually in production ;-)
Chris Lercher
Ah yes. I realize your point now. Type safety. I think type safety will be the most convincing argument in GWTs defense here. Thanks.
DataSurfer
Also, if the other developers use a specific browser, you can restrict compilation to that browser (here firefox, safari and chrome): <define-property name="user.agent" values="gecko,safari">
Arthur Kalmenson
+2  A: 

If developers have to compile the whole GWT stuff (all the permutations) in order to develop application it is real pain. Starting from GWT 2 you can configure the webapp project to be run in "development mode". It can be started directly from eclipse (Google plugin) thanks to built in jetty container. In such scenario only requested resources are compiled, and the process is incremental. I find this very convenient - GWT compilation overhead in our seam+richfaces+GWT application is very small during development cycle.

When it comes to application builds there are several options which can speed up GWT compilation. Here is checklist:

  • disable soyc reports
  • enable draftCompile flag which skips some optimization
  • by adjusting localWorkers flag you can speed things a bit when building on multi-core CPU
  • compile limited set of permutation: e.g. only for browsers used during development and only for one language

Release builds of the webapp should have draftCompile disabled though. Also all the laguage variants should be enabled. Maven profiles are very useful for parametrization of builds.

morisil