views:

1564

answers:

9

I am a long time Java web developer and as most web developers I have used quite a lot of JavaScript. Even though I don't hate JavaScript as many other Java developers, I am still aware of its faults.

GWT is a way to write javascript using java. Since I know both languages for a long time I am pretty skeptical about this claim. I mean, I having a hard time believing that you can really create full Java dynamic web applications with a rich GUI using just GWT. That is why I am asking here if anyone had the chance to work with GWT on a large scale project. If so, I would really like to hear what they think of it.

+2  A: 

I've looked at it briefly for an older application at one of my jobs, and I must admit that it was very impressive. All the code was written in Java, and the javascript was built beautifully.

It had AJAX, dynamic pages, the works. There are plugins for it as well, such as the Ext GWT framework.

It's definitely worth looking into and trying out, but you may find that the development cycle doesn't "feel" right, so you might opt to use regular JavaScript.

Mike Trpcic
good point about the dev environment "feel." GWT is definitely only for those that enjoy/tolerate the constraints of a language like Java.
Steve Reed
+4  A: 

As with any tool, it needs to be used properly. One can wield a hammer skillfully and build something nice, or just wave it around at stuff and do more harm than good.

Google Wave, I think, has become the prototype of "what's possible" with GWT.

It's still rather hard to find good GWT design patterns because the technology is too new, so that can harm efforts to develop a very rich, large-scale web app in GWT. Before beginning such a project, I would recommend looking at examples of the model-view-presenter (MVP) pattern and be sure to use it, or something like it, as a foundation for the control flow of your web app. One nice thing about GWT, and writing your code in Java, is that the high degree of abstraction and decoupling necessary for a clean MVP implementation is pretty easy (thanks to the compiler).

Steve Reed
+28  A: 

I've written fairly large sized app in GWT, and i have to say that i'm even more impressed by GWT than i was when the project started. My general 'feel' of the platform is that things are really well thought out, and they don't do things unless they can do it well, and can do it well on all browsers (IE users are still your users!)

Now, keep in mind that what GWT really excels at is the creation of large, highly dynamic single-page style webapps. If your goal is to enhance an otherwise static page with some javascript effects, than GWT is massive overkill (gquery may change this, but i don't have experience with gquery)

Some features I enjoy include:

  • The ability to share code between the server side and the client side. (if your server side is written in java, of course). I didn't expect to use this a lot of this at first, but in practice, it can really save a lot of code duplication. However, i find that in general, this only works with code that has been written with GWT in mind - using code that was not written with GWT in mind often doesn't work well. This is because GWT only has a subset of the classes in the JDK, and in javascript, you have to care about performance a lot more than you do on the server side.
  • It aims to achieve the fastest javascript, faster than you would ever write by hand (because if you did write it by hand, the code would be unmaintainable). The unfortunate reality is that the browsers that a lot of people use have incredibly slow javascript engines, so the performance of your javascript code matters a lot. Gwt's compiler is a real optimizing compiler - it will inline methods, intern all your strings. devirtualize your method calls when possible, etc. Because you are compiling for each browser and locale, the compiler can also inline browser-specific and locale-specific code. This Google I/O presentation has some benchmarks a few slides in.
  • It will also automatically sprite your images together to minimize the number of http requests needed, again improving the speed of your site. GWT 2.0 will allow you to combine together arbitrary files.
  • most of the files created by gwt have a strong hash as their filename, which lets you set the files to be cached forever, but not worry about people having old versions if the file changes
  • The code splitting in GWT 2.0 is very impressive and would be very difficult to do by hand. As the size of your application grows, dealing with the size of your javascript matters more and more, and you need to be able to split it into chunks
  • You are coding in a statically typed language. I know some people prefer dynamic typing, but i like to compare this debate to the emacs vs vi debate - there are a lot of smart people on both camps, and arguing on the internet isn't going to change anyone's preference
  • You get to use a lot of the great tools that exist in the java ecosystem, which are generally a lot more mature than the equivilant javascript tools. - junit, java IDEs, java debuggers, refactoring, etc.
Chi
Oh, and i guess the biggest downsides is: - compile time - hosted mode is great, but you can't currently use it for the system non-default browser - GWT 2.0 and out of process hosted mode should fix this though. - The java language can be verbose at times, although that is far from a showstopper. (gwt for scala would be awfully nice :) )
Chi
+5  A: 

If you have familiarity with both JavaScript and Java, you really are perfectly suited to get the most out of GWT. What many people do not realize is that GWT is pretty well layered and that you can really decide which of those levels you want to work at.

For instance, I sometimes write directly against the DOM library for projects. Thats a lot like writing JavaScript code except you're able to use an IDE properly and get the power of a compiler. From the compiler I get static type checking, lots of good compiler optimizations, and (actually my favorite for maintaining code) debug mode assertions. Nobody ever really makes much of the ability to do assertions, but it's so nice to be able to compile a debug mode that does expensive checks to tease out bugs and then turn off the debug mode and have the code just evaporate. (Not just the assert statements go away, but all the code reachable from the asserts also gets compiled out).

Other times, I write code against GWT's UI library. That code looks a bit like swing or SWT code so it is most comfortable to pure java developers. Working at this level, you don't have to worry as much about the DOM and it is usually possible to construct an application without writing any JavaScript. You do occasionally run into a bug where something doesn't work consistently on a particular browser. The GWT folks consider those bugs.

You can kind of pick what level of abstraction you want to work at. There are tradeoffs at each level, but GWT should support them.

Also, full disclosure: I'm the dude in the video that Chi linked above, so you might say I'm pretty attached to GWT.

Kelly Norton
+3  A: 

I have created two quite substantial GWT applications in my three years at Google. It delivers what it promises - my apps were far more interactive and far more ajax-y than my knowledge of Javascript and my Javascript tooling would have let me produce using other tools.

I also found the apps more interactive and more fun than the purely server-side alternatives I had used before moving to it.

It is not free of warts, but it is a very productive environment to do the kinds of apps I do.

And do watch Kelly's presentation. It, and some of the others from I/O, give a really clear idea of what GWT can do. You will pretty quickly get a good idea of whether it is the right tool for the task you are envisioning.

Scott Ellsworth
+1  A: 

I have been developing a green field application on GWT for a year and it has been surprisingly pleasant. The subset of Java used in GWT causes some headaches but nothing major after all. I didn't have too much JavaScript knowledge when I joined the project but I think that was not a problem.

The common GWT related problems I have encountered had usually something to do with Ext GWT/GXT framework or FCKEditor integration.

Petteri Hietavirta
+1  A: 

Simply GWT rocks google is making "google wave" fully on GWT.

iftee
+4  A: 

I think GWT does what it says on the tin...

Top 5 Reasons for choosing GWT:

  1. Tapestry can be overly complicated and the learning curve is pretty steep for new developers who are starting out \ joining the team. Esp. on larger projects.

  2. I found that I could develop "richer" applications using GWT seeing that my strength is Java not Javascript. In order for me to implement similar functionality using Tapestry I would have to hand write Javascript which would later become a maintenance nightmare.

  3. Browser compatibility, I would spend large amounts of time trying to get my hand written Javascirpt to work on all the different browsers (like I said Javascript is not my strength :-) The GWT Compiler hides me from this which results in me spending more time writing features.

  4. Back button blues, GWT's History listener is handles the browsers back button in comparison to Tapestry.

  5. GWT has a smaller footprint because only the data is being sent across the wire apposed to refreshing the entire page.

The list goes on but all in all, I am very happy to have made the change and have not looked back since.

Jon Lai Lam
+1  A: 

I didn't know much Javascript when I tried to create my website. In fact, that is why I had been putting off creating the website.

So for me, GWT made a huge difference as it enabled me to create a dynamic, cross-browser website that I definitely would not have been able to create without putting in significant effort into learning Javascript.

Asif Sheikh