Successful GUI Building... Today
I'm not surprised to find negative sentiments towards GUI builders of the kind recently voiced by the HackNot blog (and linked by John Reynolds). For a long time, I avoided GUI building in Java, finding it a terribly unpleasant exercise.
Over the past year, I've experienced a very pleasant change in attitude, and whereas last year I would have voiced ambivilance about using GUI tools, today I think you'd be crazy to avoid them.
In my experience, the number one reason why GUI builders hold appeal is that they often lead to an order of magnitude improvement in productivity over handcoding, especially amongst average-level Swing developers. I consider myself above average, and I see improvements in productivity around 2x-10x (perhaps higher) in my own work. I challenge anyone who refutes this to a code off; just check the No Fluff Just Stuff schedule to see when I'm going to be in your area -- or let's do it at JavaOne 2006.
Why such a radical increase? Frankly, I think its fairly obvious, but since HackNot's piece didn't acknowledge it as a factor, just consider that the domain of GUI design is, err, visual, and doing design by writing code either means you've got to get to the point where you can reliably visualize what your layout manager does in your head (emphasis on reliably, folks), or you wind up compiling and executing over and over again doing minor/major tweaking until you finally get it right. That cycle alone seems to indicate how a visual tool can speed the process up. Consider also that Karsten Lentzsch, the Swing community's resident visual expert, recommends that hand-coders layout the GUI on paper before attempting to code it. Again, not hard to see how using the visual tool can lead to a significant productivity improvement by allowing you to skip that step.
By the way, I need to mention that I'm not talking about using a GUI builder to do absolute positioning -- I'm talking about doing layout management with the GUI builder.
I think the negativity voiced by HackNot and others about GUI builders isn't a rejection of the productivity increase of the GUI layout -- I think its too obvious and powerful to refute. I think its really a response to the current way that the tools integrate with Java code. (Though again, anyone who thinks modern tools don't intergate well with layout managers needs to look again.)
The key to success with GUI builders is to eschew code generation. That's a really bad idea for a lot of reasons. The model I've come to favor is using GUI builders to generate a binary representation of the GUI that you load at run-time.
For example, I use a tool to build a GUI panel, save it to a file named "MyForm", and then at run-time I do something like this:
RuntimeForm myForm = loadRuntimeForm("MyForm");
JPanel container = myForm.getContainerPanel();
Using this approach, I don't have to worry about how the GUI builder generates code, how it names variables, etc. Its then easy for me to attach behaviors to this GUI:
JButton myButton = (JButton) myForm.getComponent("myButton");
The key here is that you name the button "myButton" in your GUI tool (e.g., using the Swing "name" property). This approach also makes reusing common GUI elements easy. If I am working on design and notice that there's some common recurring pattern that can actually yield an ROI if I reuse it I save the reusable component off to a panel and combine it at run-time, in a fashion such as this:
RuntimeForm myForm = loadRuntimeForm("MyForm");
RuntimeForm subpanel = loadRuntimeForm("SomePanel");
JPanel somePanelParent = (JPanel) myForm.getComponent("somePanelParent");
Of course, this process can be made much easier by adding some conventions / helper methods to your framework, but that's another story. (By the way, "
RuntimeForm" is an abstraction layer that lets you use any GUI builder at any time, or XUL tools for that manner -- they all generate the same product at run-time: a Swing component hierarchy.)
HackNot mentions having to layout components differently depending on locale as an argument against GUI builders. This requirement can be pretty easily generalized into a Swing widget, or it can be realized as code that manipulates your loaded panel, whatever your pleasure. This seems a pretty weak case against GUI builders to me.
So to summarize, using modern GUI builders and the right techniques, you aren't stuck with absolute positioning, you can reuse GUI patterns easily, you get separation of concerns for free, you can do i18n easily (every decent GUI builder supports this, but that doesn't matter -- you can do it at run-time without tool support), and you get a huge increase in productivity.
Before I wrap up -- which GUI builder do I use? There are a number of high-quality GUI builders on the market today. My favorite such tool is JFormDesigner, created by one-man-show Karl Tauber; its killer feature is tight integration with JGoodies FormLayout. Of course, when Matisse is ready, it is looking like it will be the one to beat.
Stop worrying and learn to love GUI builders. Their time has come -- but just say "no" to code generation.