The new Early Access Program (EAP) version of the forthcoming IntelliJ IDEA 6.0 provides Google Web Toolkit support. This 10-minute flash demo shows the features available in the latest build including GWT-specific intentions and quick-fixes, support of GWT native JavaScript methods, and more. JetBrains is open for suggestions and discussions. What are you waiting for from a GWT tool?

Sweet

It looks pretty cool actually.

The flash demo is pretty good at summarizing appreciated IntelliJ support, but GWT has some serious class usage limitations. So, I think 'is' still early to actually use it..

I just have to say one thing.. "Wowww".. It couldnt have come at a more appropriate time when we analysing different frameworks.. We are planning to use the GWT for one of our intranet sites... and this is really "sweet" news. Anoop

GWT has some serious class usage limitations. So, I think 'is' still early to actually use it..

Remember, GWT is just a view technology - only having a subset of Java available for the client side really isn't a big deal, since you can do whatever you want on the server side. Would you consider Velocity an immature view technology since you can't write Java code in it? Using common frameworks like Spring and Hibernate together with GWT works just fine [especially with Spring 2.0's DI support for objects created outside of the container, like GWT's RemoteServiceServlets]. I honestly don't know why GWT isn't more popular, since it insulates developers from the 'stupid' part of web development - mucking around with Javascript, CSS, HTML, etc. in an effort to make something that works correctly across browsers. Java 5 support on the client side would be nice, though, as would OSX hosted mode support :)

GWT has some serious class usage limitations. So, I think 'is' still early to actually use it..

Remember, GWT is just a view technology - only having a subset of Java available for the client side really isn't a big deal, since you can do whatever you want on the server side. Would you consider Velocity an immature view technology since you can't write Java code in it?

The better approach, with the same result, is something similar to RJS. Use the GWT API on the server-- so your widgets are actually 'rendered' on the server under the full JavaStack, basically producing the same result without all of the bulbus restrictions and extra layering. GWT then produces JavaScript back to the client for execution. Just focus on the end result and you'll find that GWT is going about it the opposite way of everyone else-- that's why it's not popular-- why would I want to program in a restricted subset when there's so many server-side component frameworks that *accomplish* the same thing?

Use the GWT API on the server-- so your widgets are actually 'rendered' on the server under the full JavaStack, basically producing the same result without all of the bulbus restrictions and extra layering. GWT then produces JavaScript back to the client for execution. Just focus on the end result and you'll find that GWT is going about it the opposite way of everyone else-- that's why it's not popular--

I may not be understanding correctly, but wouldn't doing the rendering on the server and then sending JavaScript back to the client still leave you with the same problem of having to convert Java to JavaScript? If you're writing Java code to represent things like textboxes, buttons, listeners, etc. [I mean 'regular' Java, not mixing it with JSF/JSP/whatever HTML-like templating] the server side can render whatever it wants, but at the end of the day it needs to convert its output to JavaScript/HTML.

why would I want to program in a restricted subset when there's so many server-side component frameworks that *accomplish* the same thing?

Certainly, it's better to be unrestricted than restricted, but are there any Java webapp frameworks out there that really 'feel' like Swing? Spring MVC, JSF, Struts, Stripes, WebWork, Tapestry, etc. don't - not that there's anything wrong with them, but so far I'm just finding it much simpler/quicker to write GWT code. To me, being limited to a subset of Java on the client side is an acceptable tradeoff...YMMV, of course. You mentioned RJS - meaning the new templating for Rails, correct? I'll take a look at it and see if I'm missing anything...

In most literal terms-- look at what GWT's native code blocks are producing. So take something like that, except have invoking these methods simply render the native code, send it down to the client and execute it. Take the use case of adding an item to a cart within the context of a transaction or business process. There's a lot of domain knowledge that already exists on the server and can be used, allowing simply GWT-ish helper methods to produce HTML updates and JS code for evaluation to update the UI. RJS does this over scriptaculous/prototype/etc-- such that you have 'typesafe' wrappers in Ruby that produce native JS code when evaluated. Overall, you are executing the same kind of code/process as GWT, but on the server within the full Java stack. The whole idea of components has the same effect in something like Tapestry Tacos or JSF Avatar where you do work with 'java' components on the server which mediate the JavaScript and updates for you. Here's an example from a JavaOne demo with JSF that looks similar to GWT, but is executed on the server, I agree YMMV between the different approaches :-) I look at it this way, if you have to make a request to the server (RPC w/ GWT, or Partial Request in JSF), the fact that it returns Data vs. Rendered output produces the same result to the end user. It's just a matter of where your development overhead lies.

Jacob - I understand where you're coming from now. Thanks for the clarification!

I agree with Jacob in that integration with other layers of your application isn't the strongest part of GWT. While the RPC style they force you to use to utilize the back-end keeps you focussed on the effiency - which can be a good thing - it also slows development down. Re: Swingish framework... Echo and Java2Script (SWT) come pretty close right? Or Wicket if you don't want to deal with layout managers (my reason not to use Echo in the past) but instead use HTML directly, but without the need of writing javascript for Ajax.

I hope they will support osx soon too

Intellij works fine on OS X. Just running it on 10.4. Also runs nicely on Linux. Afterall it is java hence you would expect it too. Eike

yeah, i am also running it all the time on osx but the gwt support doesnt work there chris

Cool. How about Eclipse?

Cool. How about Eclipse?

Google provided Eclipse integration themselves, although only in the form of a generator for Eclipse project directories and a .launch file for use in debugging. I wouldn't be surprised if they are working on a proper plugin to provide deeper integration for the next version, though.

There is an Eclipse Plugin for GWT called Googlipse. The project is hosted in sourceforge- http://sourceforge.net/projects/googlipse

Nice Demo.. Keep it coming. Good to see IDEA making the right moves and supporting frameworks with potential. Thanks.