Absolutely ! I have created thick client applications as a student and was a whole lot more satisfied than today when I am a professional doing XMLHttpService and thinking so hard to refresh nothing but webpages. And guess what - business says "its no rocket science" !!!.

Actually, there are several good approaches to Java client ubiquity including Java Web Start et al. These days, getting the necessary "run time" on the client required to run Java applications is no more difficult than installing a Flash player or other browser plug in. But Java, player plug-ins and frameworks are just different instances of managed code approaches. As Peter Coffee recently opined in E-Week, managed code approaches seem to be the future in terms of taming the otherwise wild environment differences that have plagued browser based clients from the introduction of the second browser candidate forward.

The problem with fat client Java is client ubiquity. AJAX has ubiquity. But if you want ubiquity and the power of a real fat client, check out Flex. There's a free Alpha download based on Eclipse at: http://labs.adobe.com

-James

Right ON!

What is even more amazing to me is that sober developers would even think of:

"...and if, for example, they need to repopulate a part of the screen by executing some DB query when a user types a character in a text field....."

Such dynamic updating is often touted by proponents of AJAX but never does anyone consider the server load/overhead of making a query back to the serverside DB for every keystroke event on the client. Talk about bringing the network/server to its knees! Of course the Java app would do the same thing if implemented the same way. But the "fat" client programmer is more likely to make a single query with subsequent local refinement rather than refining on the server side. The Javascript programmer in a browser environment probably won't for a number of reasons.

Aside from all that, it is very amusing indeed for those of us that date back "pre-web" (3270 screens anyone? VT100?) to watch folks that have never known any other terminal user interface than the browser get all excited about being able to do what was standard fare long ago. Your anlogy is so apt! We've been living with the limitations of the browser (another "goat" instance) for so long that when the least thing comes along to aleviate that (AJAX) folks start foaming at the mouth. HTTP itself is another "goat" instance. Look at the number of kludgey things we have to do just to maintain state. Don't get me wrong. It is ideally suited for the purpose T.B. Lee envisioned. We've just pushed it way beyond anything he ever imagined at the outset.

Personally, I'm very excited about products like Netbeans 5.0 which finally deliver a VB-like development experience (in terms of layout ease) and which can easily consume web services via WSDL (it generates all of the Java client code for you.) Writing those services is trivial using Coldfusion components (Java and Apache Axis under the covers) and if you want the freebie version check out BlueDragon by NewAtlanta. Netbeans doing Java "fat" clients coupled with Apache and BlueDragon on Linux with a Postgres or other DB back end and you have a totally low cost and very robust solution.

I've been to one of the russian parties you mention at a restaurant in Brooklyn. And yes, it is really something to experience. But we never mention the cost. It was expensive, which is why you do it once.

That is what our industry has done with browser-based web applications, especially for enterprise development. Why exactly would we build enterprise apps the same way we build consumer-oriented apps? If we were designing an enterprise development/deployment technology would we design the web as it is today (complete with browser fragmentation)? I would hope not!!

But I would tweek your original solution description a bit. I would use web service requests using JAX-RPC instead of RMI. On the one hand perhaps you are right that running an app server isn't needed for your gas station, I would counter that running AXIS on Tomcat is probably going to be not much more hassle than configuring your RMI server and the firewall. And that is where your business' technical requirements will likely grow, so XML and web services do provide value.

I agree on all your other points and would add that the next trend beyond AJAX might be to actually build RCPs (rich client programs) which perhaps embed browsers in them for the web content they need. The ultimate portal framework might actually spread itself across both the browser and server.

I have to disagree with Sean, at least partially. I've seen at least as many PC's with Javascript disabled as I've seen without Java. As far as Costa Gino's comments are concerned, there are some valid points there, if we were going back in time 20 years. Are there no web services? No http/s tunneling? Are we missing javax.net.ssl?

after five shots of vodka I always go to the same conclusion... only a triple espresso shot will bring me back to reality... and coming back to your story I will list some of the reality's issues:
i) your runtime architecture is two-tiers, client server story... and that is it... out of how you deploy it... it runs as two-tier.

ii) a special port into the firewall has to open
today enterprises have firewalls that open and close:
a) Will you open db port right there ???
b) Will you open RMI port ???
With (b) the worse part is that there are ... ports (many)

iii) security/encryption... while SSL is just there
you have to deal with encrypting ora-net or rmi... it is not impossible ... but is not just there

iv) security reloaded
thru web/html you expose pages you see and now... if you expose your binary service to internet (*.*.*.*) how can you make sure someone is not "enjoying" the methods that were not meant to do so.
(unless you saw it with fron-end rmi-actions and back-end rmi ??? hope you didn't go that far)

v) design --
you encourage developers to "power" client-side validations... what is wrong with that... the wrong things will appear as number (iv).

The whole thing will not be really enough for pure internet apps... for intranet yes ... but for intranet you don't really need jnpl and web server ...and xml... you can drop your classes (even jvm) to a network drive... you know that.

And last but not least:
If java fat client is so good ... the next step is to pop up unix/legacy terminals thru a web browser... and then that will be the solution... black/green screens will be "web" ready hmmmm !!!
Is this what you are looking for ?

Guys, I appreciate your feedback, but please get down to Earth. We are not solving global warming problem here. We are automating a small business, namely my gas station. I do not need to worry about clients with unknown version of JVMs. I know exactly what is installed on my 3-4 client computers.

Sean is talking about thousands of clients... Yes, the chances are that I'll become a CIO of Mobile one day. But even then, I'd better know (and control) what OS and JVMs are installed in MY COMPANY's client's machines.

Stop thinking Google or Amazon. Get real :)

But its not quite as simple as HTML/AJAX vs. distributed Java fat-client applications. Yes, it is now possible to reduce the cost of ownership of Java client applications through automatic updates. But this gets more complicated when there are a suite of related applications that need to be updated as a group.

But the real problem is that distributed client/server programs have to be designed differently than traditional fat-client applications. Distribution has to be factored into how the user interacts with the program, when fields are refreshed, what data is cached in the client and when, how tolerant the application is to stale data, etc. AJAX makes you think about these things because you can't build an application without it. Java can do it too, but you have to deal with the distribution patterns yourself.

In the real world where you have thousands of clients with all sorts of different setups on their PCs, the browser is the common element you can depend on. Some PCs may have java, some may not; some have the wrong version, and it's not like java is all that portable between versions. No, AJAX avoids the issues of java and plugins, providing a solution you can deliver to the most people.

You know, we are supposed to be able to manipulate the DOM from an applet just like you can from Javascript, its been there in one form or another since JDK 1.3. I say supposed to be because I haven't been able to get it to work right, and the documentation, as usual is lacking. So maybe we all need to start moving some votes on the Java bug tracker?

I'm releaved to see there are people that have the guts to see through the frail hype of AJAX.
In many rich web clients JWS will be the best choice. The richer the client the better.
If you are doing a client for an intra net then there really should be no question about it (there are of course special cases and exceptions, as always...).

The problem with your thought is Microsoft.

As long as most users are using MS Windows, which often hasn't Web start or a recent java version installed, it is easier for users to use a web application.

Installation of web start might even require administrator privileges which the user probably doesn't have.

Though it may have been written with a hangover, this is one of the most clear-headed articles I've read in quite a while. I would just add that in the mid-90's Delphi additionally brought custom visual components and visual form inheritance to rich client development.

Yesterday, we celebrated the birthday of my employee Alex in a fancy Russian restaurant. If you haven't tried it, go there - once. The party started late, and I've never seen such a variety of food on the table at the same time (they call this setup 'bratskaya mogila,' which means 'mass grave'). After five shots of straight vodka, we enjoyed a Broadway-type show, and then more drinks and food. Anyway, this morning the last thing I wanted to do was drive to my gas station.