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.
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.
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.
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.
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:
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.
some good info on about that on this raible video: http://raibledesigns.com/rd/entry/my_drunk_on_software_interview
GWT in it's self is a UI enhancement library, not a framework. If you use it with Google App Engine you then have a basic framework. (That is a different story, and while I looked at it, I decided not to include that into our architecture).
It is a great library, we have done some spectacular things with it. As it is a library however, it is only as good as your architecture allows it to be.
As far as ANT goes no problems with a 64 bit compiler.
<java failonerror="true" fork="true" classname="com.google.gwt.dev.Compiler" dir="${dir.GWTCompile}"> <-- dir.GWTCompile is the directory containing GWT --> <classpath> classpath </classpath> <jvmarg value="-${gwt.maxMem}"/> <arg value="@{gwt.baseModule}" /> <arg value="DEBUG" /> <arg value="-strict" /> </java>
As far as the generated code, it is all there in your war if you want to look through it. (It is also open source, so you can look at it there.)
What GWT does during the compile process: It creates several copies of JS libraries for different browser sets (One reason it can take minutes to compile), you can add/remove these as needed. This reduces the JS package that needs to be downloaded and increases the speed as it does not have to have those nasty if (EI) this else if (FF) that. However when your doing local debug (at least in eclipse) you don't have to wait, allowing to leave that for the build server (or when you need to manually build and deploy (neanderthals)).
The downside of GWT. As it is a javascript client side (almost purely), you cannot utilize it for things that do not support it, or support one of the versions. So for things like iPads and iPhones you can run into some issues if you don't use additional libraries designed to bridge those gaps (like mgwt).
来源：https://stackoverflow.com/questions/744515/does-it-make-sense-to-use-google-web-toolkit-gwt-as-a-full-blown-java-web-fram