Thick and Rich Like Snickers Cake
  Posted November 24, 2003    PermaLink    Comments (0)  

It appears that I've been getting some drubbing over what I call thick and thin. One coward who wouldn't leave a real name in the comments section stated that

Are you implying the Swing == thick ?????
This is completely false.A Swing client could be thick or thin.

One of the things I learned in school is to make statements that don't contradict themselves, like calling something completely false and then immediatly stating that part of the time it is true. This is predicate logic, typically covered in the sophomore year of most CS departments, which the responder must have been too drunk to remember. Mr. "Look at me I'm Anonymous!" should have just said that my choice of words was imprecise in his opinion.

Neil kindly pointed out that Sun has been using the term "Rich Client". I always thought that term was a reaction to the (formerly) negative connotation of a thick client, when they were client/server applications (such as your typical PowerBuilder app). Perceiving it to be marketing fluff I had quickly expunged this term from my vocabulary. But the lines and definitions between thick and thin are getting very blurred and stuff like WebStart is even obliterating some of those lines.

But sometimes things can be too rich. If you ever cook a Snickers Cake be sure to use semi-sweet chocolate chips instead of milk chocolate chips. That was a little too rich and thick.

Thick Client : Thin Client :: Red Pill : Blue Pill ?
  Posted November 21, 2003    PermaLink    Comments (3)  

Now that the Web has finally invaded just about every corner of life and the magic of "thin client" has been applied to every conceivable application we can finally as ourselves the question "is this the right thing to do" rather than "can we" or "how do we." the answer to the second is "yes" and with some Googling the answer to the third is within easy grasp. But these two beg the first question, of "should we." At my company we started out our first pass on the GUI as a pure think client DHTML nirvana. At the time the think client kool-aid was quite strong and everybody bought into the vision of it. We didn't have any real serious discussions on any non-html solutions. We have since started going down the swing path for various reasons. It wasn't a bad thing we started out thin, because if we started out thick we would have certainly have been asked the question about why we don't just do it in HTML. Now people can see the difference and for waht is wanted it is a real value.

But thick isn't always the answer. Sometimes thin is the way it should be done. But when and which? Here is a bullet list based on some of my experiences, dating all the way back to when NetDynamics was sold by a company called Spider Technologies.

  • Scale - This is actually two questions, with different answers for each extreme based on the way you ask it.
    • Number of Users - How many users are going to be using this application? If it is large (hundreds to thousands per instillation) then a thin client avoids messy install issues. If it is small then either way.
    • Amount of Data - How much data is the user expected to handle. It's not about how much water is coming through the hose but how big the nozzle is. To much data coming through a thin client is like a fire hose. But on a thick client it can look like a meandering river. Lots of data at once means go thick
  • Interactivity - Is the interface meant to be highly interactive? We're not talking just mouse overs and hovers. Resizable and removable column headers have a hight cost associated with then in a thin client. Similarly a frequent need to update data on the server can place a heavy load on the server application if done poorly, even if done smartly. A thick client can more easily update a small piece of data without dragging back across the wire a large amount of strictly visual effects, such as adding a new node to your typical tree control.
  • Rich UI Controls - How much control do you need over the UI controls? Editable ComboBoxes/SelectBoxes are one example that are all but impossible to do well in HTML. A rich table control with sortable columns that can be dynamically resized and have columns removed showing thousands to possibly millions of rows can be done with HTML through various HTML and serving tricks, but the tend to work better when thick. Some controls can be emulated "good enough" in HTML with scripting, such as calendar selects and formatted fields, so that may work for thin. But plain old goofy controls will requires some meat on them bones.
  • Frequency of User Use - How often is the typical user going to use it? If it's once a month they won't endure a 10 minute install, like your typical online banking app. But if it is continually used they may want a client image, like an Instant Messenger client. Some frequently used apps can be done well with a thin client, but that's because the UI is simple

Thin clients are good, but I think they are being over-done. When I hear of people writing a UI that 10 people at each large client will be using all day with rich table controls and massive amounts of data pushed through it being written as a DHTML web app it makes me want to take the blinders off and introduce them to old friends like Applets and new friends like WebStart. After all, thick is the big trend.

NetBeans Feels the Refactoring Heat
  Posted November 20, 2003    PermaLink    Comments (0)  

In addition to starting up an interim release 3.6 that NetBeans initially didn't consider doing they have also recently proposed major changes to the 4.0 plan. Originally a re-worked Projects system was to be the centerpiece of the 4.0 release, but that has for the most part been scrapped. The big reasons pusing this? It was consuming too much resources that they felt should go to requested features such as code folding and (no suprise) refactoring. Some projects stuff will come in but most of the projects bugs will be closed as WONTFIX.

A real IDE arms race is heating up now that it seems that NetBeans realized that this is a battle that is winnable and worth fighting. But honestly I don't see there being only one true IDE for java like Visual Studio is for Windows development. Combine this news with the recent additon of a Visual GUI Editor to Eclipse means that Netbeans 4.0 and Eclipse 3.0 should have very solid parity with no clear advantage to either. Things will get very interesting if the common IDE plugins JSR gets supported by both as well.

Python one-ups Java in Consumer Land
  Posted November 19, 2003    PermaLink    Comments (0)  

So I spent most of the afternoon setting up and transferring data for my new HP computer (a250n for those who care). Boy you wouldn't believe the junk that comes pre-installed with a consumer model. But when I was uninstalling the junk that had unistallers I was astonished to see that one of the items that came pre-installed was Python 2.2.1 and the win32 extendsions. But Java wasn't. Python, yes Python was on my consumer PC. I don't know why, I can't find any *.py* files.

So Java, with sun behind it has to play second fiddle to Pyton being the pre-installed suprise. Who'de of thunk?

IBM Move Fills in Eclipse Hole
  Posted November 18, 2003    PermaLink    Comments (1)  

Almost year ago I posted a review and comparison of NetBeans and Eclipse. The ultimate end for me was to stick with NetBeans because it had a visual gui designer and Eclipse didn't (an essentail job function of mine). Well, that looks to be changing. IBM will start it off by donating its Visual Editor from the WebSphere Studio line to the Eclipse project for JFC/Swing editing, and other companies will be extending it to support SWT. This perhaps may explain why SWT Designer sold itself to Instantiations earlier this week.

This basically leaves refactoring as the bigest distinguishing feature of Eclipse, and Code Folding for Netbeans once 3.6 ships.