Does it make sense to use Google Web Toolkit (GWT) as a full-blown Java web framework?

Question

I am interested in the possibility that GWT could serve as the basis for my entire presentation layer.

I would be interested to know if anyone has tried this successfully - or unsuccessfully - and could persuade or unpersuade me from attempting this.

Answer 1

GWT is relatively new. The compiling process tends to get kinda slow as your code base grows. When we worked with it we found many problems with the layout and rendering of more sophisticated widgets, and the emulator acted totally different from real servers. Also, we had trouble with i18n for right-to-left languages...

All in all, GWT has (the usual?) problems of young technologies. However, it does make certain things really easy, like Ajaxifying as you named it.

Answer 2

I worked with GWT about a year ago. At the time it seemed like a great idea, with a number of caveats:

• I had "gotcha" problems with some parts of the API, that were probably related to the fact that you're coding as if you're in java when in fact you're actually writing for a separately compiled environment that acts like java, so you make some incorrect assumptions (in this case, passing nested values to the front end). I think there was another was rewriting my ant scripts to use a 32-bit jvm for the gwt compile.
• I spent a bit of time trying to tweak the appearence - we never deployed a finished project so I'm not sure how much work this would've taken to get to a professional level, but it seemed (logically) like it'd be comparable to tweaking a swing interface. maybe a bit more unwieldy, visually, than html.
• Because the ajax is so hidden from you in the final product, I had some concerns about what I might do if the performance was poor.

That being said,it definitely seems worth playing with, and my experiences were a long, long time ago in internet years, especially given that it's probably much more mature now. It's also worth pointing out that it's a very different (and refreshing) way of developing GUI code from most MVC frameworks, and worth a look if for no other reason than that.

My feeling is that if you're building a high-load professional site with very demanding graphical requirements GWT is probably not a good choice, otherwise ok.

Answer 3

We have done this for a very large project, and as long as you know it's limitations, strengths and weaknesses it works great. Funnily enough presentation was the least of our hassles, as we just skinned it just like you would any other HTML page, using CSS. The project went live, and ran flawlessly so I have no complaints.

The pitfalls I found with it you can find here:

http://stackoverflow.com/questions/99866/biggest-gwt-pitfalls/99977#99977

Answer 4

You mentioned that GWT would handle the presentational layer. Would you be doing the business layer in Java too? If that's the case, I'd like to point you towards IT Mill Toolkit, that does exactly this: It's a toolkit that uses GWT to render its GUI components, allowing you to do your applications entirely in Java. I think the term it's trying to coin is "server driven RIA".

I come from a PHP background, but instantly came to like the toolkit. But it's probably better that I won't say anything more and let you do your own decisions.

Disclamer: I do work at IT Mill, although that's irrelevant to my opinions.

Answer 5

some good info on about that on this raible video: http://raibledesigns.com/rd/entry/my_drunk_on_software_interview

Answer 6

We have developed a large HR Portal application with the whole presentation layer done in GWT. The backend is Spring. It all works very well and the UI has been very well received by users. Very importantly it is easy for us to add new functionality and maintain the application. I think it would be much harder to do something comparable and maintainable using Javascript libraries.

You do need some sort of client side framework or you will end up writing one (as we did!): Our app is built on GWT Portlets (free and open source).

We use HTML fragments for skinning the app for different deployments and the layout of each "page" is stored in an XML file.