× 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.



I hope we agree that fat clients are only really viable for a rather small
niche.

Good descriptions and based on how you presented them I am the camp of "rich
client" being better than browser. I can see where fat clients would be a
mess of messes. Thanks for clarifying where I could not :-)

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.

I think that is the problem - picking a standard. If you control both the
server side and the client side (i.e. build your own "rich client") then you
can completely hide the implementation (e.g. XUL if you choose, or
proprietary). Look at the vast amount of success 5250 had because IBM wrote
the rules. Look at how much trouble they are having now because they aren't
writing the rules but instead trying to "play with everyone else". I don't
want this paragraph to read "Aaron is against standards" because that is not
what I am saying at all. Instead I am saying that the community is trying
to utilize technologies (i.e. HTML/CSS/Javascript) for a front end that
weren't intentioned to replace more solid counter parts.

Aaron Bartell
http://mowyourlawn.com

-----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


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.