Fog Creek Software
Discussion Board

www/Why did client-side apps lose steam?


After looking at the differents solutions for server-side scripting, I'm taking a look at ActiveX (and possibly VBScript) to rewrite dedicated VB applications. This looks like a nice solution, but I only found _one_ book at a big computer bookstore today. Even in the Java section, it was hard finding any material about developing Java applets.

So... apart from the security and platform issues (but then, Windows and IE make up sthing like 90% of users)... why did the industry drop the client-side solution in favor of server-side stuff like J2EE and .Net?

Thx for your feedback

Frederic Faure
Tuesday, August 26, 2003

From having wrestled with development/maintenance of a rather feature-rich Java applet for the last couple of years, I think I can say with confidence that it is for good reason.  The problem with writing Java applets is you pretty much have to support the MSFT JVM, which has not been updated since 1997, with the exception of a few bug fixes.  This is java version 1.1.8 or so, so you can't use Swing.  Presently, of course, MSFT doesn't distribute their JVM anymore, so your problems are solved, right?  Oh, except that now you have to download sun's JRE, which is approx. 7 MB in size. 
Really, IMHO, if you want a rich client app, you just don't want to run in the browser.

Tuesday, August 26, 2003

Simplicity and band width. 

Given a global application, it is simplier to distribute to a server than to 1000 desktops.  Then add bandwidth.  Kali in South Africa does not need to download a 12 meg application over a 14k/s modem from the USA, after each application change.

There are a host of other reasons, most however have to do with simplicity (controlling distirbution, security, etc.)

Tuesday, August 26, 2003

Java is pretty widely used, actually. ActiveX less so: it's pretty much limited to intranets these days, where you can allow the known internal servers access. As an Internet technology the security issues of ActiveX are pretty much insurmountable.

Peter da Silva
Tuesday, August 26, 2003

If you look at a full-fledged java application, and a purely server-side solution, a java applet gives you the worst of both worlds.  Beyond little demos in your home page, I think you'll find that you're better off with a different solution.

Tuesday, August 26, 2003

Macromedia doesn't think so. Have you checked out what they are doing with their Flash client?

Tuesday, August 26, 2003

also, i've recently discovered that writing winforms apps in .NET is a lot easier than writing web apps in J2EE.

Tuesday, August 26, 2003

Even though ActiveX-enabled IE is so widely deployed, it isn't 100% so is not good for general purpose web-based apps. Java applets in the browser are just plain bad. With DHTML/DOM/JavaScript fairly standaradized across browsers, I see richer browser-based interfaces developing along those lines.

Tuesday, August 26, 2003

>> i've recently discovered that writing winforms apps in .NET is a lot easier than writing web apps in J2EE <<

Writing winforms apps in .NET is a lot easier than writing web apps in .NET.  Having a rich, stateful client library makes programming a GUI much easier than faking it with a server side solution.  WinForms apps delivered over the web are going to start gaining market share: easier to write and use, but with the easy maintenance of a web app.

Ted Graham
Tuesday, August 26, 2003

"... why did the industry drop the client-side solution in favor of server-side stuff like J2EE and .Net?"

The original client-server architecture kept user interface and much of the business logic in the client application and only the data separate in the (database) server. This meant that changes to business logic required a new application to be distributed, which is difficult enough over a LAN and horrendous over the Internet.

By separating business logic in a separate service and simplifying the user interface into something that could be displayed in a web browser there is nothing that needs to be widely distributed. Changes can be deployed much more readily and maintenance/ support is easier as you can be sure of which version a user is running.

The only real problem is that HTML based UIs are cannot be very rich, and anything more complex - whether downloaded as a Java applet or otherwise - consumes bandwidth that may not be available.

David Roper
Tuesday, August 26, 2003

I was justing remoting a XWindow app yesterday, and it yet again became apparent why browser based software makes sense in a lot of cases.  Something as simple as dropping down a menu takes forever because the logic to draw the menu is on another computer.  The web has naturally evolved into a 3 tier architecture, which is simpler to maintain than many fat client products...

christopher baus
Tuesday, August 26, 2003

In addition to the distribution problems that have been mentioned you also had firewall issues,  and version problems between different apps.

Also the client server apps did not provide a good separation between the user interface and the business rules. They were not good at three tier apps.

When the web got popular companies wanted to develop for the web, the client server tools did not do web development, so new tools were adapted and these could do the web work and the client server work.  The new work was web based and client server was left behind.

Finally, client server apps never addressed the large batch jobs that were written in Cobol. You would not run the General Motors payroll app as a client server app. Java can handle this as it can run on large servers as well do web work.

Wednesday, August 27, 2003

The main reason browser front-ended server apps got any foothold was non-maintenance focused applcation developers. It was perfectly possible to develop auto-updating client side apps before .Net and JWS, but it required a little more effort.
Of course there where also some realy trivial clients that did not benefit much from having a rich runtime, and those could be easily handeled by some HTML frontend.
I believe the next step foreward from the current "smart client" systems will come from the verifyable execution environments (think Palladium and whatever the competition will be called). These will be the first distributed systems where the server can trust the integrity of the client code, and thus offload more work to it.

Just me (Sir to you)
Wednesday, August 27, 2003

Ted Graham:

Although stateful programming is wonderful and all that, I have to say there are plenty of opportunities to move stuff to the server side. At my office we ran into numerous situations where you can't always move everything to the client side due to the uncertaintly and nonuniformness of the client desktop. It's gotten to the point where I started to understand from personal experience why the most attractive sales pitch of Java was "Write Once Run Anywhere"... (well.. what's not so attractive is how Java (almost) delivers on it)

Li-fan Chen
Wednesday, August 27, 2003

I'm suprised no one has mentioned this yet:

The start-up time of the JVM is awful, even on the fastest browsers.

Who wants to have the world come to a stop when you browse to a site with applets? Users hate it.

If you want/need a rich client, use Flash.

Joe Grossberg
Wednesday, August 27, 2003

As somebody who has made the mistake of trying to develop apps as ActiveX controls, I can tell you that it's a collosal mistake. Reliably updating clients is a real pain.

Distributed clients written in C++ or Delphi might work well, but the poor soul on a dialup connection does need to be considered for updates. Data exchange via SOAP would work well though.

Clay Dowling
Wednesday, August 27, 2003

Could you expand on the issues you saw?

Thx everyone BTW :-)

Frederic Faure
Wednesday, August 27, 2003

richer functionality isn't necessarily a bigger download that HTML. The tree widget in Mozilla is leaner and meaner than the DHTML solution.  The problem is the runtime download. The download is just xul.

Flash has the advantage in runtime installs. But their direction is clear. Rich client apps need to get out of the browser.

fool for python
Wednesday, August 27, 2003

I can't imagine what anyone writing ActiveX controls for internet apps is thinking. You have most of the inconvenience of plugins, plus you have to convince your potential users to upgrade to a recent Internet Explorer (assuming IE isn't banned at their site: it was at ours until we were Borged).

Flash, Java, or Javascript, if plain HTML doesn't cut it... and think long and hard before doing anything beyond plain HTML because there's still resistence even to Javascript in some areas.

It's a pity Sun abandoned NeWS -- imagine Display Postscript with GUI objects running entirely in the client (the display server) as Postscript applets. Now imagine that running on Apple's Quartz or other printer-quality display technology.

Peter da Silva
Wednesday, August 27, 2003

*  Recent Topics

*  Fog Creek Home