From: Shannon ODonnell
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.
If there were a standard rich client platform (like, say, the Rich Client
Platform from Eclipse <grin>), then I'd have to start making decisions based
on architecture.
1. Is the bandwidth equivalent for the same function? A lot would depend on
the actual syntax of the communication, which in turn will depend on the
tool used to create the page. Take a look at a generated JSF page; it's
quite verbose as opposed to pure HTML.
2. Speaking of tooling, is there a powerful WYSIWYG designer that can allow
me to easily generate pages that I can then attach to the business logic of
my choice on the back end? This is where EGL shines, by the way. Not even
JSPs have a good interface to RPG, but EGL pages allow direct calls to RPG
code using data structures. Very powerful stuff.
3. Debugging. Is there a powerful end-to-end debugging tool? Is it easy to
prototype the UI (as you can with HTML) and then test it by itself in order
to isolate UI issues from business logic issues?
If the performance of the UI in those areas is roughly equivalent, then you
finally get to take a look at the productivity of the user. That's where it
gets a lot more subjective. Aaron has been asking how a browser application
is better than a thick client. I guess I'd turn the question around: can
you name specific classes of user interactions that are made better by a
thick client? The only reason I ask is that these days much of what you can
do in a thick client can be emulated with JavaScript. Some of it is not a
good emulation, granted, but what are the definitive features of thick
client that make it more productive than thin?
Joe
midrange.com
