Picture a kid riding a bicycle on the highway in first gear... He has to make it 40 miles and he's traveling at about 5 miles an hour. 8 hours to get to the destination--Totally inefficient, right? Why not just shift into a higher gear so you can travel at 18 miles an hour, reaching your destination in a little more than two hours?
Over the past few weeks, the Java forum has been assaulted with a multitude of Netbeans-generated GUI (note the corresponding red text
). I'm here to explain why you should avoid it at all cost (actually, there isn't any cost
) Just avoid it.
Reason #1: It's not efficient...at all
The Netbeans does the best that it can to create a GUI to your liking with it's drag-and-drop approach, but it takes 3X the amount of code to accomplish this feat. 3X the code is usually accompanied by 3X the inefficiency. For a programmer (at least for me), It's kind of like a punch below the belt when you realize you could have made your program 3X more efficient if you would have taken a different approach. This is something that no programmer likes to hear (and definitely shouldn't tolerate).
Reason #2: It's a MONSTER to maintain
Going off of Reason #1, since there is 3X the code, there is 4X the unnecessary clutter. Not only that, but the way in which Netbeans organizes the code, it is impossible for a mere mortal to comprehend what is going on. For those of you who have posted erroneous code, this isn't good news for you. The more experienced coders won't even bother sifting through the jungle of disaster to find the errors you are experiencing, simply it's because it is a BEAST to understand and keep organized in your thoughts. It's not that GUI Builders are reserved solely for the genius's use, but that it is unwise to use such a product in the first place. There is absolutely no rhythm to the code that Netbeans produces.
Reason #3: It's downright lazy
No offense to those of you who use it because you were never told otherwise--I'm telling you now. It's a fact that GUI Builders encourage lazy coding habits. It seems very simple on the surface of things--drag the different components into place AND... presto, a working application( if only it were so simple). But you are left with the problems described in Reason #1 and #2. It's better of to study the GUI classes and components then piece together an efficient, manageable version of your program in which you understand every single detail contained within it. This is the pinnacle attribute of a good programmer. Not only will you understand your own code, but if you have small problems, other experienced coders will understand how your program should work at a brief glance. To get you started on your way, take a look at these tutorials:
A Brief Introduction Into The Recently Outdated AWT GUI Components
Beginning In Swing, Java's Updated GUI Package (Somewhat Exhaustive)
Personal Favorite
This should get you well on your way to developing more manageable and efficient GUIs throughout your Java programming career. Cheers!
Over the past few weeks, the Java forum has been assaulted with a multitude of Netbeans-generated GUI (note the corresponding red text


Reason #1: It's not efficient...at all
The Netbeans does the best that it can to create a GUI to your liking with it's drag-and-drop approach, but it takes 3X the amount of code to accomplish this feat. 3X the code is usually accompanied by 3X the inefficiency. For a programmer (at least for me), It's kind of like a punch below the belt when you realize you could have made your program 3X more efficient if you would have taken a different approach. This is something that no programmer likes to hear (and definitely shouldn't tolerate).
Reason #2: It's a MONSTER to maintain
Going off of Reason #1, since there is 3X the code, there is 4X the unnecessary clutter. Not only that, but the way in which Netbeans organizes the code, it is impossible for a mere mortal to comprehend what is going on. For those of you who have posted erroneous code, this isn't good news for you. The more experienced coders won't even bother sifting through the jungle of disaster to find the errors you are experiencing, simply it's because it is a BEAST to understand and keep organized in your thoughts. It's not that GUI Builders are reserved solely for the genius's use, but that it is unwise to use such a product in the first place. There is absolutely no rhythm to the code that Netbeans produces.
Reason #3: It's downright lazy
No offense to those of you who use it because you were never told otherwise--I'm telling you now. It's a fact that GUI Builders encourage lazy coding habits. It seems very simple on the surface of things--drag the different components into place AND... presto, a working application( if only it were so simple). But you are left with the problems described in Reason #1 and #2. It's better of to study the GUI classes and components then piece together an efficient, manageable version of your program in which you understand every single detail contained within it. This is the pinnacle attribute of a good programmer. Not only will you understand your own code, but if you have small problems, other experienced coders will understand how your program should work at a brief glance. To get you started on your way, take a look at these tutorials:
A Brief Introduction Into The Recently Outdated AWT GUI Components
Beginning In Swing, Java's Updated GUI Package (Somewhat Exhaustive)

This should get you well on your way to developing more manageable and efficient GUIs throughout your Java programming career. Cheers!

6 Comments On This Entry
Page 1 of 1

pbl
31 July 2010 - 07:39 PM
In any computer application there is a rule to respect. Keep as separated as possible these 3 elements:
- the user interface (Can be a GUI)
- the business rules (Code based on user input and data)
- the data (can be flat file, arrays, SQL database)
If you move your application from flat files to SQL Database, should shouldn't have to modify the user interface part. If you pass from console application to GUI application then you shouldn't have to midify the data part.
Using a GUI generator defeats this rule because you end up so tight to the GUI (that you can hardly modify) that you will end up patching it and patching it over to insert business rules and data access into it.
Very good blog Luckless
- the user interface (Can be a GUI)
- the business rules (Code based on user input and data)
- the data (can be flat file, arrays, SQL database)
If you move your application from flat files to SQL Database, should shouldn't have to modify the user interface part. If you pass from console application to GUI application then you shouldn't have to midify the data part.
Using a GUI generator defeats this rule because you end up so tight to the GUI (that you can hardly modify) that you will end up patching it and patching it over to insert business rules and data access into it.
Very good blog Luckless

Sergio Tapia
04 August 2010 - 06:04 PM
Granted I'm new to Java but I'd like you to answer some questions. 
I'd like to see some benchmarks that this is actually the case. Is this true? Does a program built with drag+drop GUI run slower than one you crafted by hand?
No arguments here. If HTML has this exact same problem, why should programming languages be any different.
Meh. I guess it comes down to personal preference and how robust the GUI builder is made. In C#/Windows Forms you'd be VERY hard pressed to find someone who manually tinkers with the Designer.cs file that has all the GUI declared.

Quote
Reason #1: It's not efficient...at all
...3X the code is usually accompanied by 3X the inefficiency...
...3X the code is usually accompanied by 3X the inefficiency...
I'd like to see some benchmarks that this is actually the case. Is this true? Does a program built with drag+drop GUI run slower than one you crafted by hand?
Quote
Reason #2: It's a MONSTER to maintain
No arguments here. If HTML has this exact same problem, why should programming languages be any different.
Quote
Reason #3: It's downright lazy.
Meh. I guess it comes down to personal preference and how robust the GUI builder is made. In C#/Windows Forms you'd be VERY hard pressed to find someone who manually tinkers with the Designer.cs file that has all the GUI declared.
Page 1 of 1
Trackbacks for this entry [ Trackback URL ]
← January 2021 →
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
My Blog Links
Recent Entries
Recent Comments
Search My Blog
0 user(s) viewing
0 Guests
0 member(s)
0 anonymous member(s)
0 member(s)
0 anonymous member(s)