Both DWR and GWT are pretty wide-ranging and their only common denominator is the Ajax part...
Can you elaborate on what you want to achieve in the first place? It's like if you asked "Should I take the plane or the helicopter?" And then we find out that you're just willing to go to school, which is 5 minutes from home... [ August 27, 2007: Message edited by: Valentin Crettaz ]
My Linked In
posted 12 years ago
Thanks for the response Valentin,
What I am trying to achieve is a building a java web application on tomcat with a bunch of neat Ajax features. Nothing extremely advanced, I guess comparable to the complexity of an online hotel booking system.
The application will consist of a database, hibernate, java classes, and JSPs.
I am usually not very fond of that kind of complete solutions, I find that often the simplification of development limits you too much on what you can do. (JSF is one of those complete frameworks that I dont like, I prefer Struts)
I also got the idea that GWT forces a certain project structure on you, which would be kind of annoying. Am I wrong?
But hey, if GWT is the exception where they actually managed to provide a simplified development method (pure java GUI programming) for webapps without restraining your possibilites I'd be happy to go with it.
posted 12 years ago
Well, if noone has experience with both DWR and GWT, maybe someone can talk a bit about their experience with either of the frameworks? Likes and dislikes and whatnot.
I think I'm finally starting to 'get it' with regard to GWT ....
seb wrote ...
"I am usually not very fond of that kind of complete solutions, I find that often the simplification of development limits you too much on what you can do. (JSF is one of those complete frameworks that I dont like, I prefer Struts)"
I too much prefer struts and was thinking that GWT was just a code generator designed to let Java devs avoid learning JS, HTML and CSS. I think something much more strategic is a play here and may be a huge factor in your decision about how to proceed with your app.
Ajax seems to be the present and the future for web apps (maybe all apps?). Though I like JS quite a bit it aint enterprise grade. Prototypal inheritance in JS doesnt provide the classical inheritance (should I say class based?) and scoping (private, protected, package) you get in Java.
Can you image a JS app with 200,000 lines of code? With GWT you can build your app the way want or need to and let the GWTs JS compiler do the compile time type checking and performance tuning (which should improve as GWT matures) for you.
If your building enterprise apps, you should avail yourself of enterprise language features. IMHO.
For what it's worth, what bothers me most with GWT are the following issues.
1. It is very difficult to have a graphical designer working on the team. The problem here is that GWT generates everything (HTML, CSS, JS) for you and the only place where you have a hand on is setting a CSS class name for a given GWT component. You don't get to tweak the HTML, CSS or JS, even though you can bring your own CSS and JS files into the GWT mix. On one project we started last year, we had to turn down GWT for this very reason. We had a graphical designer and an HTML integrator (who is not a Java developer!) on the team and we could not think of a consistent and productive way to work with them using GWT. Designing new graphical components that are not in the base library will require efforts on the part of your Java developers . And, well... Java developers are not the best persons to do this kind of things (Fact: 90% of Java developers, myself included, suck a graphical design!). Usually, a graphical designer does that and an HTML integrator transforms the Photoshop sketches into HTML/CSS/JS. With GWT, you can send the HTML integrator guy at home and ask a Java developer to do it in its place... or teach the HTML integrator guy to develop in Java...
2. You have to decide in advance what gets generated. That is, GWT will generate a huge amount of files depending on your needs. For each browser and each language to support, there is going to be a copy of the website. For instance, if you have to support IE6, IE7, FF, Opera, Safari and Konqueror in English, French, German and Chinese, you're going to have 24 web sites generated for you. Then all the magic happens when the user connects to your site. GWT detects the user agent and the language and serves the correct files to the user. This has the advantage of having a ~100% compatible website for every user, but adds some runtime and compile-time overhead.
3. Everyone looking at the source will know that your website has been generated by GWT (a META tag says which Java class is backing up the page being viewed). Looking at it from a security perspective, I personally can't stand the fact that users know what kind of technology is used behind my application. The more they know, the easier they will find out what kind of security issues your website is vulnerable to.
Thus, my personal opinion on GWT is that it is fine to use it if: - you don't have to care too much about global UI constraints and pixel-precise look&feel accuracy - you don't have too many browsers and languages to support - security is not of primary concern to you [ September 23, 2007: Message edited by: Valentin Crettaz ]
My Linked In
Evil is afoot. But this tiny ad is just an ad:
Devious Experiments for a Truly Passive Greenhouse!