× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Joe, all...

If thick (fat) client software distribution and updates was as easy to
control and perform as browser-based applications, would fat clients then be
the better all around solution? Or would web-based applications still be
best?

I would think the former rather than the latter, but I have an open mind
about it and would be happy to be convinced otherwise.


Shannon O'Donnell



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Monday, September 03, 2007 3:19 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: GUI development language

From: albartell

I feel like there is a sector of people here that carry two things around
in
their pockets - left pocket=water bottle, right pocket=browser Kool-Aid;
and
whenever you need a lift you quickly mix the two and announce to the world
that HTML/CSS/Javascript are better than what one could develop in a thick
client?

Whoa, Aaron, calm down. While there may be a few people who over-emphasize
the browser, there are also people in this list who over-emphasize every
technology, whether it's SQL or Java or PHP or CGI or JSP or even RPG. For
whatever reasons, we have lost the concept of the best tool for the job, and
that's sad.

That being said, there are a number of powerful arguments against thick
client. But before we go there, let's quickly identify a couple of terms.
Thick client is sort of a generic term meaning "not a browser" and it can
cause some confusion; I like to use the terms "fat client" vs. "rich client"
to identify the amount of business logic on the thick client. Fat clients
include some business logic: rules that change in response to changing
business requirements. Rich clients, on the other hand, are really just
powerful graphics renderers: uber-browsers, if you will, with some sort of
TCP/IP communications to a host.

I hope we agree that fat clients are only really viable for a rather small
niche. The biggest reason is distribution: it's almost impossible to keep
fat clients in sync even in a highly controlled corporate IT environment,
much less in a distributed (and possibly non-authenticated) Internet-enabled
architecture. If there is ANY business logic on the client, then changes to
the business require pushing those changes to the client and that's awfully
difficult when your client is on a WAN, much less coming in from a dial-up
connection.

Now, the other side of the coin is some sort of rich client technology,
where the information that is pushed to the client is little more than a
sort of enhanced HTML: sort of a "GUI markup language" (and IIRC, Mozilla's
XUL is exactly that). In that case, updating the business logic is
centralized since it runs on the server, and only the UI instructions are
sent to the user. The problem to date with that is the lack of standards.
What browsers have over rich clients today is that HTML is the standard.
There are no others. And until we reach some level of standardization on a
rich client language, the best you can do is sort of pick something and hope
it doesn't go out of style.

Ask the Struts folks about backing the wrong horse.

Unfortunately, rich client is still at the VHS/Betamax stage, and until
there's a clear standard, it's pretty hard to bet your business, especially
when a browser interface will get you anywhere from 70 to 90 percent of what
you need (depending on your application, and while I made those percentages
up off the top of my head, they seem about right).

Joe



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.