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



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?

Fair question back to me.

1) Speed. When I am working in web 2.0 browser apps they are still slower
than their thick/rich counterparts. I am working on some doing some tests
of my own to see how much speed I can crank out of a simple browser app.
Here is one of my attempts: http://red.rpg-xml.com/rxs_ajax.html

2) Right clicking. Can you do it in the browser? Yes. Have I seen it
implemented well? Rarely. Usually it is sluggish.

3) Drag'n'drop. Can it be done? For *some* things. Can I drag and drop
onto my desktop? No (ignorance might play here as I haven't been able to
drag a file). Can I drag something from the desktop into a browser app
without a rich client plugin? I could wrap this into a general limitation
of access to desktop "services".

4) Modal dialogs. I have seen it done in some conceptual Javascript samples
using Tapestry add-ons (Apache project), but never in a "real"/"production"
environment.

5) Back button in browser. I have heard of people having solutions to this,
but with the solutions I use (i.e. JSF) this absolutely sucks because nearly
everything is a POST with JSF. Is EGL using JSF under the covers I am
guessing?

6) Writing to lowest common denominator for browser wars - there are still
things that I can only run in IE, for example , Sharepoint and Outlook Web
Access are considerable stripped down when I use them in FF. Probably by
design, but others have followed suit and it takes extra effort to plan for
the top few browsers.

7) Can't completely control tabbing. I don't want to tab through the
browser address bar and then like.

Those are what I could come up with. A lot of them are situations where the
browser *can* emulate some things, but just can't do them as well.

BTW, here's another cool website I found where they are doing some pretty
cool things in the browser (but still less than the desktop).
http://www.youos.com/html/index.html?mode=demo, and www.goowy.com

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:42 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: GUI development language

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


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

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.