Announcing GWT 2.0 Milestone 1 | Hacker News Reader

Announcing GWT 2.0 Milestone 1

groups.google.com

35 pointssilkodyssey32 comments

Is anybody here using gwt? Is it really easier to use than any of the other widely used javascript libraries? The whole java to javascript translator/compiler sounds overly complex to me. Is there some other benefit to using it aside from ease of use? Is it more likely to generate code that is cross browser compatible than one of the other solutions?

I think I remember reading somewhere that the Google Wave team gave up on supporting ie6 so this suggests that GWT doesn't eliminate all cross browser issues.

I don't use it though. I have looked at it and I don't see the point of compiling java to javascript. I like the output it produces but I don't like the workflow. I am not fond of java's verbosity and I would have preferred an approach similar to the one taken by YUI in implementing rich widgets in javascript.

So far I have not encountered browser compatibility issues with GWT. Please do understand that GWT handles the JS part, someone still have to handle the CSS part.

Someone has to handle DOM part too. If you are writing your own widget wrapper (if you are subclassing UIObject or Widget, and I imagine that the Wave team is doing this), you will also have to handle cross-browser compatibility.

The cross-browser promise of GWT will only get you something that runs in ie6. It might never give you something that performs well.

No layer of abstraction will ever cover up the fact that you have the world's worst garbage collection algorithm coupled with the world's slowest javascript runtime. At best, it can only make the semantics of your code the same across the various browsers.

It's the difference between getting an obese person to walk 26 miles when what you want is for them to run a marathon.

Also, at its core GWT is just the compiler, and you can (if you desire) choose to ignore the cross-browser abstractions and work at a lower level if you want the best possible performance. For example, a mobile safari app written in GWT (one that needs to fit inside a very small browser cache) might avoid using GWT Widgets to keep the resulting javascript as small as possible. It could be that the Wave developers took that route.

We've used gwt extensively and eagerly await 2.0.

GWT is basically built for building webapps like gmail. If you are building a website then I wouldn't bother with it personally, I find jquery much easier in that sense. It's really built for highly interactive, gmail/google docs/wave like applications which are a single page with dynamic content.

Take a look at the following project, which is a nice example of what gwt can do outside of google health, wave etc: http://code.google.com/p/gwt-cal/

There are huge benefits with 2.0 over other libraries for building these types of applications:

http://www.infoq.com/news/2009/10/gwt-2-m1

http://fredsa.allen-sauer.com/2009/09/gwt-for-enterprise-dev...

In terms of cross browser, we have only ever had a single issue which was a drag and drop, google map like component. Workarounds were not that hard.

Oh, and styling your interface is very easy if you use firebug well. We have a 37-signals-esque single page interface which is pretty slick.

Just to be clear, Gmail was _not_ written with GWT.

Though it probably would be if the project were started today.

does new v3 beta maps use gwt?

I don't believe so, though the web implementation of Latitude (http://maps.google.com/maps/m?mode=latitude) for iPhone and Palm Pre does.

It's worth noting, though, that Google's implementation of Wave is written in GWT. Since GMail predates the invention of GWT, it's likely that it would be a GWT application if started today.

Many things would be different if Gmail were started today -- not all of them good :)

Yes, I use it a lot. It is perfectly possible to make close-to-native web frontends in GWT.

There are very many other benefits which depend entirely on how you work as a coder

GWT suits if you work with Java, code in Eclipse, build with ant, use servlets and web development is just the GUI aspect to you.

There are some very sophisticated widget sets like GXT which are written in GWT and compile small to a single JS file :: http://www.extjs.com/products/gxt/

Word of advise: stay away as much as possible from GXT unless if you're working on an internal enterprise app that requires no modification in the UI. At my office, we've been trying super hard to remove all GXT widgets...

I have done a lot of modification to my GXT widgets :: with a comparable amount of pain I've had with normal widget sets like Swing and SWT

There is definitely room for improvement with GXT. Event handling sucks (different handlers for different widget types WTF!!), and maybe your usecase exposes some pathologies I've been immune from. YMMV, but thanks for the tip hello_moto!

We make TeamPostgreSQL with GWT (teampostgresql.com).

GWT is very different from Javascript libraries. Our entire code base has not a single line of Javascript in it, it is all Java classes. I can't imagine what a nightmare organising and refactoring all this code would be in regular Javascript (though to be fair I have never tried, so there may be good solutions for this).

The Java -> Javascript thing does sound messy, but amazingly it actually works.

* About cross browser compatibility: As for the script executing right, it is just not something we have to worry about, GWT does it all (it makes different script targetetd to each supported browser). Appearance sometimes needs tweaking to look right on all platforms though.

I went to your website and saw the screenshots... man... they look awesome!

From the screenshots it looks like a large (in good sense) app. Do you have problem with load times? How do you handle them? I'm working on the GWT app and it seems it gets a bit slower to load (not surprisingly) as it gets bigger. I'm getting worried that at some time in the future it might affect users on slow connections.

GWT 2.0 should solve most of your problems I suppose.

There are 2 things that can make a large app slow: 1) Load time 2) Rendering time

For load time all you can do is to maximize the use of ClientBundle and GWT.runAsync()

For rendering time, don't create panels willy-nilly, use tag-first approach if possible or use low level dom operation (DOM.createDiv, DOM.createSpan) if your widget isn't overly complex.

Make sure your listeners don't leak... other than that... nothing much I guess.

While I agree that the code-splitting in GWT 2.0 might help you, you may also want to see where the slowness in loading is really coming from.

For example, is it really the size of the app that makes it slow to load, or is part of the problem that you're not using lazy-initialization judiciously? If all of the possible widgets are eagerly created, that could make it appear to be loading slowly.

Another possibility is the number of HTTP round-trips that have to be made. Do you have a lot of images? If so, are you using the ImageBundle facility? (It's awesome: the compiler automatically makes a CSS sprite image and generates the code to slice the images out automatically.) If not, you should.

Another possibility is whether you are using any 3rd-party GWT widget toolkits. Some of them are wrappers for other, more traditional javascript libraries, and those will really bloat the amount of code the browser needs to download! Stick to a widget kit that is actually written in java, or create your own custom widgets as needed.

Another possibility is that I once accidentally left my compiler configured to emit verbose javascript. Make sure you're emitting tight, obfuscated javascript.

Finally, make sure that the HTTP daemon that serves the files are configured to gzip the javascript for those browsers that are capable.

The application does take a while to load, but the bottleneck seems to be browser javascript performance, and mostly in Internet Explorer. In fact that might well be the biggest issue we have with GWT, and we have to resort to a few tricks to make the application perform acceptably in IE when trees and dropdown boxes get large enough.

I believe that as long as you show the user that something is happening, preferably by showing them how long they have to be patient, there is not much to worry about. Unless we are talking about ridiculous download times. Of course, what is ridiculous depends on the perceived value of your offering: people don't mind waiting 45 seconds for some flash movie, so obviously it's not a complete showstopper.

Regardless of your opinion of Java as a language, there are some significant advantages to having a real compiler that targets JS...per the 10000-foot GWT intro:

"[it] performs comprehensive static analysis and optimizations across your entire GWT codebase, often producing JavaScript that loads and executes faster than equivalent handwritten JavaScript. For example, the GWT compiler safely eliminates dead code -- aggressively pruning unused classes, methods, fields, and even method parameters -- to ensure that your compiled script is the smallest it can possibly be. Another example: the GWT compiler selectively inlines methods, eliminating the performance overhead of method calls."

The compiler produces tight and gzip/eternal-cache-friendly JS. For supported browser type and supported locale in your application, the compiler will generate a permutation specific to that combination and automatically serve that up, e.g. Chinese Webkit users will be served Webkit-optimized code and only the Chinese localizations instead of getting code that contains IE6 hacks and English localizations.

There are lots of other benefits - for example, GWT 2.0 will include code splitting, which will allow you to fetch code when you need it instead of a huge monolithic upfront download of your entire application.

There are drawbacks to GWT, but going back to "regular" web programming feels like dropping into assembler after you've become acclimated to coding in a high-level language.

We use GWT; it works very nicely. I think it is nice that the hole application (client and server) can be written in Java.

Absolutely, I've used it on a couple of large projects. I would say that trying to distill its appeal down to the phrase "ease of use" probably loses too much nuance. The best aspect of it comes as a project matures, and especially as it changes hands from one developer to another. Having a statically-typed source language allows you to bravely refactor, especially with the help of an IDE, knowing that the compiler will catch potential breakage long before runtime.

While we're on the subject of GWT, I want to plug the best one hour presentation that you'll ever find on the subject of software architecture best practices in a large GWT project:

http://code.google.com/events/io/sessions/GoogleWebToolkitBe...

I have watched this no less than 16 times, and keep pulling out bits of wisdom with each viewing.

GWT is wonderful. If you've come from a world of swing programming (like me), it's very easy to build great, responsive GUIs.

I'm really excited about GWT 2.0. The new out-of-process development mode will let me debug in any browser, using both the eclipse debugger and firebug at the same time. Furthermore, the hosted mode browser on Linux was Mozilla 1.7, which didn't support some things like SSL or Canvas. Now I plan on using canvas a lot more.

I'm not sure how this changes the incubator project. I imagine they will bring in many of the incubator classes into the main branch.

I'm going to have to play around with the declarative stuff. Not too sure how useful that will be.

Maybe it's just my dynamic language bias, but isn't GWT about 100X more complex than using something like Cappuccino with Atlas to build a desktop-like app?

And won't it look 100X uglier in GWT unless you are a CSS zen master?

Just watching that GWT "best practices" video made my head spin with all the many layers and buzzwordy concepts one has to master just to make a simple GUI.

Or perhaps it's just that I hate the staticness and verbosity of Java...

I thought I would reply just in case you were referring to the video that I linked to. If so, that is most certainly not a beginner's tutorial on the basics that one would need just to make a simple GUI!

Rather, it's the other end of the spectrum: an example of how the toolkit allows a large team to bring serious, large scale software engineering practices to bear on something ambitious and complex.

One of the great things about GWT is that it offers something to that entire spectrum.

Pardon my ignorance, but what kind of infrastructure do you need for running GWT? It pretty much means running your own (dedicated) servers, right? (For example, I understand that Google's App Engine does not yet support it!)

Actually, Google's AppEngine is nicely integrated with GWT. Check out the Google Eclipse Plugin (http://code.google.com/eclipse/) -- even if you're not using eclipse, this will give you a good idea.

It's also worth pointing out that a compiled GWT application can be deployed entirely statically. The Java RPC system does require a servlet container, but there are lots of other ways of talking to servers (JSON[P], XHR, etc).

SproutCore is also gearing up for 1.0 release soon. Some really good choices nowdays for javascript based windowing apps.

Reply on news.ycombinator.com