Skip to main content

Thin vs. thick clients - What's the future?

5 replies [Last post]
Joined: 2003-10-23

I hope this isn't too off topic, but I'm currently implementing a web-based application that I am *sure* is going to make me rich (heh). What I am wondering/concerned about is what is the best (or most appropriate) client?

I can see a desktop client being much richer, but a browser-based client being easier to deploy. I guess the root of the issue is where are application interfaces going? Browser-based thin-clients or thicker desktop clients which take advantage of web services (etc)?

Any direction would be appreciated.


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-08-12

This is how I see it.

If the users of your client application is going to use it often (the app), then a "real" GUI is needed since the constant reloading of web-based solutions will be very irritating in the long run.

If they will just access the app a few times a day to check something (like you visit a web page for news) then a webb-app is ok and efficient.

I'm very much into making Ultra User Friendly applications since they reduce what's really expensive; User Training. So I'm a bit biased towards a real GUI.

And I *love* swing. I have since I tamed it ;-)


Joined: 2003-06-10

I think there will always be a market for desktop-gui applications. Mostly in the line-of-busines user area. People who today are using VB, Powerbuilder and Delphi Apps for doing data entry, reporting and complex workflow really can't do with the browser-based way of doing things. This is where Java GUIs really fit in.

The second most appealing area is in standalone commercial desktop applications.

I think the web is returning to what it started at, which is shareware. Anything complex or interesting is moving towards flash, and I think people are realizing that web-based intranet applications are not all they are cracked up to be.

But, it makes sense to use J2EE and EJBs to hedge your bets. Worse comes to worse, you can port your app to the other client platform without too much worry about changing your business logic/implementation framework.

Joined: 2006-02-17

Why do you say browser based clients are easier to deploy? Webstart does a fairly good job in deploying applications. So I guess that is not really an issue..

Furthermore, creating a **good** browser-based client that works on IE, Konqueror, Netscape, etc is a hell of a job and after trying too many times, you'd probably just give up after a while....

Creating UI's in swing is not an easy task if you use an editor like VI. But there are a number of tools out there which can help you creating a decent swing based ui. I prefer to use uic. But that may be because I am one of the writers ;)

Joined: 2003-10-23

I guess I was saying they are easier to deploy because one only needs a browser to interact with the application. The main issues with this are: 1) cross browser compatibility (as you mentioned), 2) UI capabilities (much less than with Swing, etc).

I've just started looking at XUL and JDNC as possiblities for creating the UI/client. I was also planning to use Webstart for the deployment, but I was concerned that the requirements might be too much for the average joe (admittedly, those concerns are probably due to my ignorance). Are there many applications that make use of Webstart, or would I be "ahead of the curve" (which I don't mind at all)?

Back to my original question tho, is a "better" UI worth the (slightly) additional user requirements and are web-based applications moving in this direction (as was stated in Amy Fowler's JDNC paper)?


Joined: 2003-08-07

The future is in the rich client which provides both desktop-like interactivity and zero-client deployment. Soon Javasoft hopes to have Swing installed as part of every desktop computer. Until then, you can use compatible rich clients like the Asperon AppProjector. See