Re: What do I use?

On 4/13/07, Walden H. Leverich <WaldenL@xxxxxxxxxxxxxxx> wrote:

>To the original poster, go ahead and use Visual Age for RPG.

Ok, yes, to get back to the OP's question. I'm in the opposite camp.
Unless you're building an app that needs to work disconnected from your
servers (user @ 30,000 ft.) or building something like Word,
World-of-Warcraft, iTunes, or Photoshop DON'T BUILD THICK CLIENT!

Non-browser-based apps are a return to the nightmare that was
client-server. No matter how "standard" the deployment environment is
you'll spend lots of time figuring out why the app behaves differently
on different machines. At a minimum there are 5 versions of W2K (no SP
-> SP4) 3 of XP (no SP -> SP2), Pre W2K if you want to support it, and
now what 6 versions of Vista? Add into that (if you care) how many
versions of Office? At least 4, O2K, OXP, O2K3, O2K7. Testing and
deployment is a bear.

Is that true with .NET or Java apps? Are there any technical reasons
to not have the current runtime installed on the PC running your
application? I have not used it yet, but one ClickOnce deployment
sounds great. The user has a supercomputer on their desk. Treating
it as an end node is an insult!

here is MSFT article that makes the case for desktop apps and explains
how ClickOnce works:
http://msdn2.microsoft.com/en-us/library/ms953320.aspx

from the article:

On the other hand, as much as I love the Web, it's hard to say that
the user experience on the Web is stellar. When compared with Windows
applications, the Web has several disadvantages:

Its user interface is quite poor. Things that we take for granted in a
Windows application, such as drag and drop and right-clicking the
mouse, are very hard or even impossible to do in a Web application.

Even when we do manage to do rich interface tricks, it usually
requires an insane amount of client script, a kind of code that is
particularly hard to write and debug.

A Web application uses a lot of server resources, bandwidth, and user
patience because most things have to be done at the server with a
round trip and some waiting involved.

Printing is limited to "print screen technology," with little control
over things like page breaks due to different fonts, margins, and
paper size.
Some of the problems above can be mitigated through the use of
plug-ins or ActiveX controls, but those in turn tend to have the same
deployment problems that the old non-Web applications used to have.

------------------------

-Steve