If you’ve ever worked in a team with UI designers, they do a lot more than just format elements on a page (via CSS). A good UI designer will create interactions (like drag-and-drop), scrolling, handle pop-ups, create windows… they are supposed to have control over the entire UI, not just how it looks. That’s why they’re called User Interface Designers, not Make the Page Pretty Guys.

With GWT you can have a team that does stuff more toward the front-end of the app, and another team that does more of the back-end business logic/database stuff, but the line is blurred as Ruju points out.

Take a look at TIBCO GI to see what true separation of front-end from backend looks like. Someone please add this type of ability to GWT! It’s such a cool way to develop AJAX except for the page/module design part. How hard can that be to improve?

Let me get this straight: Google have created a nice set of Widgets for Ajax/Javascript development and people are complaining? Whilst people may say there are already enough tools like this out there, I’ve gotta say phooey to you. The number of error prone bugy Javascript frameworks out there is high – but this looks solid, and it is still quite early in it’s development and seems to have a very active development cycle.

Raju said:
“No EJBs, no JDBC and forget about your CMS”

Umm, right. Only if you choose to use it that way. There are a number of blogs out there now which deal with issues of integrating this with existing frameworks – incorporating it inside a Struts page for example or in the larger context of a Spring application. Though it hasn’t been written to be integrated with these with good examples (and I think it’s crazy of them not to), where there is a will there is a way.

“It complicates already complex Ajax programming lot more.”

Again – qualify this statement? How does it complicate programming in Ajax? Does the idea of abstracting away from the various browser nuaces complicate things? Hell no. What about providing an intelligent way of sending objects to and from the server? I don’t know about you but I personally hate trying to make sense of XML responses myself in Javascript (kudos to DWC). Sure there are a few new ideas to learn, but once they have been learned, it helps ensure clean design – and thank god, means I don’t have to program in Javascript, though I can still debug it if necessary.

“Where can I put business logic? It cannot to translated to JavaScript. Can it?”

Business logic lives on the server – presentation logic lives on the client, though this framework would allow you to remove that restraint, good developers will be able to keep to that paradigm. Read through the docos a bit more, you’ll realise that not all classes get turned into javascript – check out:
http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.RemoteProcedureCalls.PlumbingDiagram.html

Anindita Ray

Raju said:
“No EJBs, no JDBC and forget about your CMS”

Umm, right. Only if you choose to use it that way. There are a number of blogs out there now which deal with issues of integrating this with existing frameworks – incorporating it inside a Struts page for example or in the larger context of a Spring application. Though it hasn’t been written to be integrated with these with good examples (and I think it’s crazy of them not to), where there is a will there is a way.

“It complicates already complex Ajax programming lot more.”

Again – qualify this statement? How does it complicate programming in Ajax? Does the idea of abstracting away from the various browser nuaces complicate things? Hell no. What about providing an intelligent way of sending objects to and from the server? I don’t know about you but I personally hate trying to make sense of XML responses myself in Javascript (kudos to DWC). Sure there are a few new ideas to learn, but once they have been learned, it helps ensure clean design – and thank god, means I don’t have to program in Javascript, though I can still debug it if necessary.

“Where can I put business logic? It cannot to translated to JavaScript. Can it?”

Business logic lives on the server – presentation logic lives on the client, though this framework would allow you to remove that restraint, good developers will be able to keep to that paradigm. Read through the docos a bit more, you’ll realise that not all classes get turned into javascript – check out:
http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.RemoteProcedureCalls.PlumbingDiagram.html

Google released GWT which automatically converts a Java based UI to Ajax last week. This obviates the need for the …

Do you want your business logic translated to JavaScript and exported to the Browser and executed in the browser?

It supports only parts java.lang and java.util, so you need to forget most of Java programming skills. No EJBs, no JDBC and forget about your CMS.

After all the sacrifices, do you really think, you can avoid JavaScript, think again. If you need to implement GUI Widget for a large custom DHTML component such as, Hierarchical menu of your own or Scroll for components (please see web page for an example), according to documentation on Google’s custom Widget implementation, you cannot avoid writing JavaScript code.
http://cbsdf.com/technologies/DHTML-Widgets/Widget-samples.htm

If you wish to implement a GUI Widget for a custom Ajax/DHTML component, you need intimate knowledge of the HTML elements, tags and even model. Therefore, you must have experience in both Java and JavaScript/DHTML programming.

Isn’t it the problem in the first place: to have clear separation between the Java developers (business logic) and JavaScript developers (presentation logic)?

To create an ideal solution, we need a model that let each work independently. The process must provide separation and let each individual work independently in a manner appropriate to their specific skills and consistent with their roles, in a manner that reduces the interference between them.

Web designers are great at creating great GUI components. We (java developers) must let them create great GUI Component with out any incumbarances, and once they have done that, we can create a GUI Class wrapper around it in an hour or two. This colabaration between Java and JavaScript developers must not be avoided, but can be made pleasunt by limiting to the functional requirements to just high level description of the couple of simple service the web component need to offer.

This problem is not going to go away, but will become even bigger as next generation web platforms such as SVG, XAML and MXML emerge. How do you create an Airplane to simulate near real-time air traffic in the skies?
http://cbsdf.com/technologies/GUI-Class3.htm (You need Adobe’s SVG Viewer)

These are just only few and many other obvious issues such as loosing the convince of JSP model etc.

Regards,
Raju

More info at: http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.JavaToJavaScriptCompiler.html

I’m assuming that you need your server-side logic (web services) separately from the UI.

Overall, it seems similar to haXe, but using Java as the development language rather than some new language. HaXe aims to compile to different platforms though, including DHTML/Javascript and Flash. Maybe GWT can be compiled to Flash too (like C#, see “Csswf” and other C# to SWF compilers).
http://haxe.org/intro

However, the whole layout aspect of this would make me want to tear my hair out. Didn’t they learn anything from Swing or AWT? Coding complex UI’s using East/West style layout is just plain frustrating.

If this were wrapped in JSF or there were some integration with some other existing java web framework (Struts? Tapestry? Webwork?) this would be interesting. But is anyone going to throw away their framework choices for this, when all of the major frameworks are also coming up with Ajax features? I think some of the ideas here will probably be adopted by other frameworks. The ability to debug javascript events in eclipse is pretty useful.

Where’s the business logic? It’s inside other classes, running on the server. AFAICT, when the translator sees a call outside of the packages it’s translating, it turns it into an RPC call back to your server.

Their attempt to create a Java bridge helps neither Java developers nor JavaScript developers. Where does HTML fits and how does XMLHTTP works? It complicates already complex Ajax programming lot more.

I have been working on generative programming since 1999. Based on my experience, they would wish to focus on business logic and let web designers to deal with the JavaScript.

This led me to create a simple method for collaboration. The reusable GUI Classes must provide separation and let each individual work independently in a manner appropriate to their specific role and consistent with other roles, in a manner that reduces the interference between them. Please review a simple tutorial for code generators:
http://cbsdf.com/technologies/DHTML-Widgets/Widget-samples.htm

We know how this process works, GUI Class makers (e.g. Java/Swing or Borland/Delphi) build the widgets and application developers deal with business logic.

Where can I put business logic? It cannot to translated to JavaScript. Can it?

After looking at the code, they cannot solve many fundamental problems faced by other GUI Widgets.
http://cbsdf.com/technologies/DHTML-Widgets/TECH-Status.htm

Please ask yourself tough questions, how it is going to help Java developers? I simple cannot see, how it can help Ajax?

Please debate the benefits before you decide to flame me. I know a lot about this area and about needs of Java developers.

Best Regards,
Raju

Matt: Definitely feel you on the eclipse deal.

Browser-independent toolkit.
Java into JavaScript.

The second one no doubt appeals to many, although not to me since I am perfectly comfortable writing JavaScript. On the other hand, I’d love to see Google’s take on the all-too-common browser-independent toolkit in *JavaScript*, but apparently I’m not going to!