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
midrange.com
