Java, GUI builder or hand coding?

Question

My company software has a lot of forms, till now we wrote the code by hand (MVC way).

We are considering to start using GUI builder.

There are few problems with using a Builder.

1. Parts of the code are not readable.
2. Parts of the code are not editable.
3. It will be harder to edit the code later.
4. We will have to continue using the builder in the future, even if we want to replace builder or write by hand, and no one can assure that the tool will be available and supported in the future.

I want to learn from others experience:

• Do you recommend using tool or should we continue write code by hand?
• Which builder is better?
• How does he deal with the problems? (Is there any other problems?)

Answer 1

For just a few forms I recommend using a Builder. It will get the done way faster. However, if you have a lot of forms that you need to maintain for some time, I recommend against a builder. For this case the time you spend in reading the code and maintenance is much larger than the initial design time. So, while the builder saves you some time at the initial phase, it makes code reading and maintenance more difficult. More over, it makes code re-use, even in the form of copy and paste from one form to another, more difficult.

I don't know if you are referring to web or desktop applications, but in general I haven't found a Java Gui builder that produces elegant output. Netbeans Swing generated code for example is a mess. Perhaps, if a nice builder were available I would change my mind. I had no problem using Visual Studio's form designer - it produces nice code that you can read and understand.

For desktop applications have a look at MiGLayout. It's a layout manager, not a builder, for Swing and SWT that will make your life easier.

Answer 2

By using a good builder the development will be a lot faster.

The anxiety you have of not being able to modify the code may be due to you have a lot of logic in the view where it does not belong. Actually this change may help you to move logic from the view which is good precisely for the ability to change the visual elements with out breaking the code.

As per the "unreadable" you should consider use a better GUI generator. I've heard only positive things about NetBeans, and I have used IntelliJ GUI builder whose code is pretty clean.

On both the source code is readable and editable, but only for minor tweaks. For major ones, well use the GUI builder.

I think for a small number of forms, there is no problem in proceeding by hand, but since you have "many of them" as you just said, using this tools will be most beneficial.

Answer 3

This is my experience:

I never liked the code the GUI builder generated. At least, it's not like in the VB world that everyone (well, almost) will use the same IDE for building apps. In Java, people use several IDEs, and some use VIM and Notepad too. And all IDEs don't generate the same kind of code. And another problem is, they don't usually understand the code generated by other IDEs. So to answer your 1st question, I don't recommend.

Your next question: Which builder is better? The last time I used, Netbeans was better than most of them I tried.

If you must use a GUI builder because you need to develop applications faster, then make sure all of your team members are using the same builder. It's better to get their opinion on this, otherwise their eyes are gonna get hurt by the IDE generated source code.

Let us know your decision!

Answer 4

I would stay away from gui builders. In my experience(matisse) you end up spending just as much time writing gui's with the builder by hand, if not more. Due to trying to read the generated code, and clean it up, when making changes. Also if you write the gui's by hand you will have to understand the code in order to write the gui, and this will help overtime to become more proficient, and you will get faster at writing gui's, and you will be faster and hand writing them. Over time you can also develop a component library for gui functionality you find yourself writing multiple times. I would stay away from builders. A good developer will beat an average developer with a builder any time.

Answer 5

I have been using Netbeans' Java Swing GUI Builder (Matisse) for all of my projects for the last 3 1/2 years. I've read so many people's complaints about GUI Builders and the most seasoned programmers chide everyone who even hints at using one, but here's my experience:

1. The un-editable code is never necessary to edit. Really, the GUI Builder provides a skeleton for your GUI. You drag, drop, resize, and constrain your components using the editor, but the content of the table, the list for the combo box, etc., all need to be handled on the backend. The GUI builder allows you to focus on that while it takes care of making things look pretty and stay in place.
2. WYSIWYG is always more productive. Word Processors are the testimony to this. People will tell you: "you don't edit GUI code that much so if it saves you time, it's not that much time." But this statement is extremely relative. When you work in a software environment with a process model that necessitates constant updates due to business model changes, this statement is false. Also, you spend the majority of your time on the content of your English essay, do you not? So this argument would say that WYSIWYG Word processors don't save you that much time, and such a statement would fall on deaf ears because no one would want to hand-code their essay's look-and-feel.
3. There's nothing a GUI Builder cannot do that handwritten code can, whereas I've spent hours trying to solve small challenges with handwritten GUI code that took me 1 minute in a GUI builder.

Netbeans' GUI builder, in particular, has gotten so much better over the years that a lot of the flak it has received (akin to a lot of the flak Java has received) has been really nullified. It's a great program and it's a great way to build feature-rich, beautiful interfaces in a time-effective way. I highly recommend a good GUI Builder, especially Netbeans'.

There, I said it.

No, I don't work for them.

Answer 6

If you have not too complex forms to build, then you could take a look at DesignGridLayout, it is Swing LayoutManager with a fluent API that makes it very easy to write code for your form and easy to read this code (and maintain, I mean modify if needed) and visualize the form through the code.

With DesignGridLayout, one row of components in your form is one line of code. No XML, full compile-time safety. No hard-coded spacing values, alignment... DesignGridLayout handles it all for you.

Short learning curve and as quick to layout a form as a GUI designer!

From the time I have discovered it about 2 years ago, I have used it exclusively (I always have been allergic to GUI designers because of the terrible generated code). That was the reason why I took over the project 8 months ago, because I wanted to give it full potential.

Answer 7

We do it by hand, but with a library helping us with the layout (JGoodies Forms) and so on. Further we use a set of predefined components we plug into our UI (Jide). Works out well for us.

Answer 8

I've used many GUI designers over the years (for different languages): Delphi, Visual Studio, JBuilder, Netbeans.

The quality of code they produce and the volume is important. Delphi was fantastic, it produced small amounts of code relative to the form size and the code was easily understandable and the two-way tools allowed you to change generated code with confidence. This was helped by a simply understood GUI library. VS produces reams of code and you do get scared to change it.

Java is partly let down by the language, no delegates or closures and so event based code can quickly become a sprawl.

I would knock up simple stuff with Netbeans Matisse and - once confident - hand code them. The complex stuff is worth planning out and hand coding so that you get your model defined well.

It helps if you build a library of your own GUI components that you can re-use. This is relevant to all languages with GUI libs.

Answer 9

For systems with a lot of simple forms, I've tended to go the XML route -

• define XML files for the information and any work flow for each form
• create XSLT to generate Java/XHTML/whatever code to run the forms on desktop PC/mobile/web
• also create XSLT to generate source code data objects etc.

You can use XForms and implementations thereof, but usually I've been working in places where buying in solutions takes longer than building your own simple XSLT. It generally takes a week to get everything up and running if there aren't too many specialised widgets in the forms. If you make your own code generators, you have full control. If you find you want to switch all your forms from scrolling up/down to be presented in columns, then there is just one place you have to change, rather than changing each form's implementation. (though you could make a framework to abstract form information from presentation in Java, it's not well suited to such declarative programming)

Answer 10

I personally am a fan of separating the GUI layout from the code (otherwise you end up with the problems you just mentioned). It also seems to be the trend: Microsoft has their XAML, you keep hearing about different view engines for MVC, etc.

Why not go with XML-based GUI design? You could try out something like JFormDesigner which can handle both XML and code-generated layouts.

Answer 11

I've been doing both recently - I'm using Netbeans, and was initially frustrated by the lack of control of generated code. I then discovered that you can add custom code from the GUI builder, which overcame most of the issues. However, I became more frustrated by the layout manager in NetBeans, and found this was hurting my productivity more than anything. I've switched to using MiGLayout and doing most of the coding by hand now. Having said that, NetBeans overall is pretty good, and perhaps I should have spent more time learning the GroupLayout.

If you are doing team development, make sure you are all using the same tool if relying on a GUI builder.

Answer 12

I would say only use a GUI builder if you understand enough of what you are attempting to do that you could do it yourself.

Answer 13

If your forms are simple and not dynamic then a GUI builder is perfect. The more complex the form the less benefits you will get from using GUI builder.

The company I work for does just that. Simpler apps are developed with the GUI builder and more complex apps are done by hand. Once there are enough hours trying to work around the GUI builder's limitations it is usually abandoned. Also each GUI builder is not created equally so it will take some evaluating on your part to determine under which situations a GUI builder is appropriate. (The NetBeans GUI Builder is pretty good.)

Personally I like to use GUI builders to come up with the overall layout of and app/form and play with the different layouts but then I convert that to more readable code and do the rest by hand.

Answer 14

Whether you are building GUI forms using a GUI editor or not, I would highly recommend you develop a set of standard 'bean' panels that you can place on your forms.

We have about 100 of these beans that we've used in over 600 forms. Below is a picture showing one of these beans:

This panel consists of a standard Label, a mandatory indicator (red asterisk), an editor field (a combo-box in this case) and a display-only field (the grey box). In this case, the combo-box and display-only fields are mutually exclusive - only one is visible at a time, depending on which mode the form/field is in.

These beans contain our standard (framework) functionality, which includes standard look-and-feel colours, fonts, etc. If we want to change the way all occurrences of these fields work, or what they look like, we change it in one class and it changes on all forms that include it.

Now, how do we build our forms? Well, we do all our forms in the NetBeans Matisse GUI builder. We are very happy with it. While you cannot edit the code that it generates, I have never had any instances where that has stopped me from doing something in the GUI. The beans I mentioned above can be easily added to the Palette, so adding them to forms is a drag-n-drop.

There are certain techniques, tho, which make things easier, in my opinion. We use BoxLayout (in page-axis) on most of our forms, and combined with our standard bean panels, building a form can literally take just minutes to do (the graphical side, at least). Also, FlowLayout is useful if you have multiple controls on the same 'line' on the form (e.g. multiple checkboxes).

And it's easy too, which means that we can get some of the (non-programmer) business analysts building the forms before a programmer adds the code 'under the hood'.

Answer 15

I started off as VB programmer and then move on to C#. I would say Netbean GUI builder is still far off Microsoft especially with the layout manager in the form. It get really flustrated when you tried to move buttons and label to be aligned to what you want and those you doesnt want to move icon started moving all around the place.

The auto-generated code also cant be edited in the source which made it even more non-user friendly

Answer 16

I've used Netbeans in the past to build GUI code and used Eclipse to write the program logic. Just include the GUI code as a separate LINKED source folder.