views:

449

answers:

6

I'm a Java developer. To be honest, I'm a little intimidated about writing lots of javascript, so the idea of writing a web app completely in Java with GWT appeals to me!

I'm planning a new web app and one of my considerations is that I want it to run well on mobile browsers (for android and iphone). I've also used a few GWT apps that still feel a little sluggish...not quite as responsive.

If you've used GWT, can you give your thoughts about A) how efficient is the client-side code as compared to hand-coded html+jquery. And B) are there any server-side efficiency considerations that you would consider when using GWT, in particular with Google appengine.

In particular the stacks I'm debating using are appengine + slim3 + jquery ... OR appengine + GWT + objectify.

A: 

The problem with GWT is that it makes it very difficult to include any Javascript that's not already been ported to GWT. GWT and EXT-GWT give you a lot tools and widgets, but if you need to use anything that's not already part of GWT, you'll have difficulties, especially in debugging.

In my opinion, Javascript isn't nearly as hard to write as it used to be. Firebug, especially, makes debugging Javascript very nice.

quanticle
Actually the statement that interacting with JavaScript is difficult is not true - GWT offers JSNI (JavaScript Native interface) allowing you to write Java methods with JS and calling Java methods from JS.
Nico Adams
+2  A: 

I have used it, but I can't say I recommend doing it unless you're really afraid of learning some JavaScript, you'll most likely have to anyways to debug your application or when the provided features just don't cut it. IMO jQuery or some other JavaScript toolkit is the way to go.

Niklas
Why would you have to learn JavaScript to debug a GWT application or "when the provided features just don't cut it?" You can debug a GWT app in a Java runtime - that's one of the big selling points. What sort of features have you needed that required you to use JavaScript?
Isaac Truett
+11  A: 

If you are experienced with Java, I'd definitely go with GWT - Java is a object oriented language, which allows writing "clean", easy to maintain, testable code (try unit testing JS code :/). Thanks to the awesome GWT Compiler, the resulting JS code is in most cases faster and more optimized than handwritten JS code (unused code is removed, code is inlined, many static invocations for maximum performance - not the kind of JS code you'd write by hand, but it's the fastest). I'd recommend watching the Measure in Milliseconds: Performance Tips for Google Web Toolkit presentation from last year's Google IO. There you'll see how fast is the JS code that GWT produces (note that the GWT Compiler is constantly improving, so it should produce even smaller and faster code now). You might also be interested in other prestentations from Google IO 2009 and Google IO 2010.

I'd stay clear of projects like Ext GWT/GXT - while they offer all sorts of widgets, they are also very sluggish - it's better to roll out your own widgets, optimized for your specific needs.

And I don't agree with quanticle - JavaScript Native Interface (JSNI) makes it as easy as possible to integrate JavaScript code with Java code (think JNI for "vanilla" Java).

Igor Klimer
+1 I had ported a somewhat large project from GWT to JavaScript, because I didn't want to rewrite non-trivial widgets such as color pickers myself, and the ones available for GWT at that time were out of date. However, in retrospect, I wish I had used JSNI to just integrate with existing JavaScript options which would have worked out much better. The argument that JavaScript can do without static type checking is I believe overrated, especially as projects get larger.
Anurag
A: 

I'm very familiar with JS+HTML+CSS, and except some basic JSP, I know nothing about JAVA. For me using GWT would bring 2 pains, learning JAVA and losing the touch with the real stuff.

I worked few years in SAP projects, and they have something called "Web Dynpro" that took a similar approach. HTML and JS are hidden in a JAVA stack that generates everything for you.

In the end you build very standardized screens, with a "relatively" limited freedom. Big corporations like them as it gives them a certainty over the uniformity of the screens. They are all ugly but they look the same and you can switch from one developer to the other very easily.

But if you are more on the 2.0 creative side, you quickly end up frustrated of the possibilities the framework offers you to build new ideas.

IMO if you are in big projects, big teams and know well JAVA: GWT (+ App Engine)

If you are a creative person and/or in startup mode: Javascript+HTML+CSS

Mic
The question wasn't what's best: GWT or pure HTML+JS for every man (that sort of questions get closed in a matter of minutes on SO - thankfully), but for a programmer with experience in Java. And I'm sorry, but your "creative" argument doesn't really stick - that's like saying that C++ is not creative while the assembly language is, because you saw all that cool scene demos that give you so much "freedom". In most cases the programmer is the limit, not the language/framework. And TBH, I'm relieved that GWT let's me focus on programming, so I don't have to remember all those JS browser quirks.
Igor Klimer
+4  A: 

An answer to A):

If you look at Google it's only ever travelled in one direction; browser applications. The question Google have is how to make browser based applications as usable as desktop applications, and the answer is 'make them faster'.

Google are investing a lot of time and money in new and faster browsers, operating systems, and internet protocols. These will all help them reach their goal, but their key advancements will be made in how they make Javascript run as quickly as Java (or at least very close).

As Google use GWT for a number of their key products, and given with each release the compiler produces faster and more efficient Javascript, the answer should be fairly obvious. If you want a faster site/application in the future you're better off letting GWT create the Javascript you desire.

An answer to B):

One of the most frustrating parts of GWT at the moment (which may well be resolved in the future) is you have to make a decision whether to code for AppEngine or not for AppEngine. You could theoretically code for both, but this would be time consuming and more painful to test. This issue is down to the lack of current support for MySQL (et al) on AppEngine, and lack of an external availability of Big Table* outside of AppEngine.

Saying that, if you don't use AppEngine you're not really developing anything you wouldn't have to develop if you didn't do it in GWT.

I hope that's useful. If not I hope it's useful for someone :o)

*If anyone knows otherwise please let me know.

specialtrevor
A: 

This fairly new video provides the answer to part "B" of your question. There are no optimizations for the google app engine. However, the google app engine does provide performance optimization for apps wether they use GWT or not.

It comes at a cost however. Which is that JPA object CANNOT have a direct pointer to any other JPA object. They must store the foreign key in Java as a long, or string and then manage the relationship in code rather than let the JPA provider handle it.

HDave