Subscribe to The Way I See It
6 Comments
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
). 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 FavoriteThis should get you well on your way to developing more manageable and efficient GUIs throughout your Java programming career. Cheers!
Categories: Java GUI
Share This Entry:
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
Luckless
31 July 2010 - 08:10 PM
I appreciate that, especially since this is my first one! Good rules to follow on your end as well
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.
Luckless
08 August 2010 - 01:25 PM
Thanks for the comment. I'll be happy to answer your questions.
Question #1: As far as benchmarks, I have none. Code in Java for a while and it simply becomes apparent how jumbled and unorganized GUI Builder code is. For a complex GUI system, good luck finding anybody who will want to modify that behemoth. It's not so much that it runs much slower, but the amount of lines necessary is tremendous and the small problem that it is unreadable by humans.
Question#2: It's no cake walk to update any program, but if you code everything by hand, you should have no problem modifying something deep within the recesses of your program. Good luck editing what you need in a Generated GUI. Example:
I am in a development group dealing with robots and grids (for some senior's project). The genius senior designing the GUI used Netbeans to design the 2000 line GUI. Well, he had 3 behaviors loaded into a JComboBox when he designed it, no problem. But once 4 more behaviors were designed, he couldn't add them to the list because he couldn't figure out how to add them to the JComboBox until the last week of the semester. Netbeans had scattered it ALL through the GUI class. Wouldn't had been a problem if he had designed it by hand (a few tabs, JTextAreas, JButtons, a JComboBox, and a grid).
Question #3: maybe for those languages it is acceptable, I don't know. But in Java, nobody bothers with GUI Builders. For now, the GUI builders are sucky. Also, you don't gain any understanding of how it all works, which can lead to problems when things don't go according to plan. You end up robbing yourself of helpful information and experience
Question #1: As far as benchmarks, I have none. Code in Java for a while and it simply becomes apparent how jumbled and unorganized GUI Builder code is. For a complex GUI system, good luck finding anybody who will want to modify that behemoth. It's not so much that it runs much slower, but the amount of lines necessary is tremendous and the small problem that it is unreadable by humans.
Question#2: It's no cake walk to update any program, but if you code everything by hand, you should have no problem modifying something deep within the recesses of your program. Good luck editing what you need in a Generated GUI. Example:
I am in a development group dealing with robots and grids (for some senior's project). The genius senior designing the GUI used Netbeans to design the 2000 line GUI. Well, he had 3 behaviors loaded into a JComboBox when he designed it, no problem. But once 4 more behaviors were designed, he couldn't add them to the list because he couldn't figure out how to add them to the JComboBox until the last week of the semester. Netbeans had scattered it ALL through the GUI class. Wouldn't had been a problem if he had designed it by hand (a few tabs, JTextAreas, JButtons, a JComboBox, and a grid).
Question #3: maybe for those languages it is acceptable, I don't know. But in Java, nobody bothers with GUI Builders. For now, the GUI builders are sucky. Also, you don't gain any understanding of how it all works, which can lead to problems when things don't go according to plan. You end up robbing yourself of helpful information and experience
Page 1 of 1
Trackbacks for this entry [ Trackback URL ]
← February 2019 →
| 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 |
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)
| 