IB/Gorm vs. Java GUI Builders

This post appeared briefly on osnews.com today

It's basically a "pointer piece" about an article on informit in which the author has reached an ephiphany about how much better InterfaceBuilder is that almost any java code generation GUI builder out there. From the article "It's lightyears ahead of anything we've got in the java world."

I'm really not sure why this is such a revelation to Java folks. I also do a lot of Java programming as a consultant and I've found that there is no inherent value to code generating gui builders. They are, in most circumstances, unweildy. Many of these GUI builders don't have the concept of palettes, which allow the expansion of the basic set of widgets available to the developer, which leaves the programmer using other widget sets from another jar library on his/her own when using those.

Have we made so little progress in the last decade that programmers STILL have to trudge around making GUIs by hand? This is efficient?

Intuitive vs. Counterintuitive

In the Java gui builder world the predominant paradigm when it comes to associating widgets with methods is the event/handler paradigm, even though Java has a wonderful thing called reflection, it's not used when building GUIs in any of the gui builders I can think of. InterfaceBuilder and Gorm use the target/action paradigm. The target/action paradigm, takes advantage of Objective-C's dynamic nature to allow the direct invocation of the method against the target class. This is what I think gets most Java developers tripped up when they try to use Interface Builder, since they may not be used to this way of viewing the world.