Fog Creek Software
Discussion Board

The Rich Client Strikes Back

Java Web Start & .NET Auto Deploys may indeed replace HTML as the UI.

Thursday, January 29, 2004

`There is a movement afoot in the world of enterprise applications toward "rich clients," reversing the past few years' trend that abandoned client/server in favor of Web-based interfaces'

I'd love to see their proof on this... my own observation has been the exact opposite, and that the pace to replace thick-clients with thin-client web apps has _accelerated_ (and has been extremely successful).

Of course I suppose it depends upon the definition of thick-versus-thin : Some "thin" client apps make use of SVG, Flash, and other very complex web technologies that give powerful graphics and interactivity, but are cross platform and easily deployed.

Thursday, January 29, 2004

I could sure use a rich client right now.

Impoverished Programmer
Thursday, January 29, 2004

What the world needs is a good just-in-time/web-deployable rich client, which gives the best of both worlds: ease of deployment and good usability.

Thursday, January 29, 2004

Which is what you get with .NET.

Brad Wilson (
Thursday, January 29, 2004

...and with Java -- JavaWebStart has been doing this for a while now.

Chris Winters
Thursday, January 29, 2004

Yea, web apps are easier to deploy and maintain so the IT department likes them; but IMHO they're usually feature starved, put one side by side with a rich client and the browser based app stinks. And there isn't a "latency issue" with web apps, they're slow.

Been There
Thursday, January 29, 2004

My experience over the past year is that there's only one person that wants web apps any more - the CIO. Developers don't like web apps because
a) clients want rich functionality and it's up to us to provide it, no matter what the platform
b) state management sucks

Users don't like web apps because
a) They're web apps

But in several cases I've seen a CIO hold firm against pushing from *both* sides for a Win32 app.


Thursday, January 29, 2004

I should have added "cross-platform" to my statement.  That rules out .NET, at least until Mono is reliable on other platforms.

Being "good" as a client rules out Java, because unless you are among the 1% who know the inside tricks required to write a responsive and good-looking Swing app, Java sucks on the client.

Thursday, January 29, 2004

One of the nice abilities of web apps is for corporations to "stitch" them together just by making a page of links into a kind of intranet, so the users only have learn how to visit a single web page to get their work done.

Users also like the ability to just hit the back button in a web app., gives them the feeling of control over the application.

Matthew Lock
Thursday, January 29, 2004

I can see that it is easier to create "rich" WinForms apps, but I reckon you can still do a pretty good job using DHTML/CSS/JavaScript/ASP.NET.

Just take a look at the web-based version of Outlook that ships with Exchange for an example of what can be done.

I'm in the middle of a big web-application project and while it does have some downsides, the fact that it can be deployed across the client's entire workforce and then made available to their trading partners and customers, with almost no effort makes it worthwhile.

Steve Jones (UK)
Friday, January 30, 2004

Steve Jones (UK),

.NET Auto Deploys allows you to do the same with a Win Forms .exe and Java Web Start is similar in J2EE.

You just copy your .exe and .dlls to a web server and the client hits the .exe on the web server I.E. "" - this can be an internet shortcut.

The app downloads automatically to a local cache as needed (Dlls only as needed).

If a new version was released on the web server, the next request coming in from the client knows automatically to pull down the latest version.

Simple deployment just like a Web App - but no browser, real state & real functionality....

Friday, January 30, 2004

> And there isn't a "latency issue" with web apps, they're slow.

They'll never be as fast as thick clients, but they can be fast enough, which is what matters. And yeah, I've seen plenty of slow ones, but I've also seen some great click-the-button-and-bam-there's-the-next-screen ones too.

I have to wonder how much "Rich Client Strikes Back" is wishful thinking and predicting the thing in order to create it.

Friday, January 30, 2004

"I could sure use a rich client right now"


Friday, January 30, 2004

----"Just take a look at the web-based version of Outlook that ships with Exchange for an example of what can be done."-----

I'm using it at the moment, as I'm on holiday. IfI had to do my normal work with it it would take three times as long, before we count the slowness of the dial up connection.

Stephen Jones
Saturday, January 31, 2004

How do you determine if your web apps are slow & how do you improve their performance? Are their industry standard ways about addressing sluggish web apps?

Derek Weller
Tuesday, February 10, 2004

Well, I'd like to see some good smart-client apps out there.  Too many customers want "windows-app-like" look and feel and responsiveness in an IE6 web application.  Then it takes loads of DHTML/JS & Server Side code (C#) to make it happen.  And in the's still too slow, even if it looks really nice.

There are just too many applications that require REAL speed - even 1-2 second round trips in the browser are too slow.

A smart client (rich-client) .NET application that runs locally on a PC with online/offline smartness, communicating with a suite of Web Services is ideal.  If the NET is down - then it works offline until it can reconnect again.

I think the "Strikes Back" is right on target.  It started in the 4th quarter of 2003.  By this time next year - the shift away from web based applications will be on.  Web Services will be supplying 100% more server side interactions to support an increasing flood of Smart-Clients.

(maybe just wishful thinking...)

Friday, March 5, 2004

*  Recent Topics

*  Fog Creek Home