I also have to say, "Duh." <grin>
Of all people I wouldn't have expected you to consider something "good
enough" :-) I would take that more like "the customer isn't complaining so
neither am I". Or "...they are used to slow web applications; why can't
mine be too?"
What is the issue? There is no "back button" in a thick client
application, so it seems to me the only problem is disabling it. I do that
in PSC/400 quite effectively.
Re-POST's. It more might be the framework/technology I am using (i.e. JSF)
than anything. There was a good podcast by somebody well respected titled
"JSF, the 7 layer burrito". This was one of the issues they brought up.
I think a lot of what we would both agree on is that the browser can
implement MANY *cool* features that we haven't seen much before, but they
are still second place to a well designed "rich client".
But instead you're going to write a fat client and have to worry about the
OS wars!
Writing for the OS has potentially less work involved than writing for x
times the number of browsers on each OS. I am not saying developing a Java
"smart client" for 4 or 5 OSes would be easy, I am simply saying that the
environments to write for are less in number vs. having to retest your web
app with each browser on each OS. I still remember my first RPG CGI app
about seven years ago. It worked fine with IE on Windows and did work fine
with IE on the Mac.
Piece of cake with a chromeless browser.
<cough> Hack. :-) I had a PHP app that did this. Most annoying app I ever
wrote because it always had two browser windows open. It was a customer
mandate. Two years later they paid me to take it out because they thought
it was too annoying also :-)
Another one I forgot in my initial post:
7) Type ahead. I am not even a fast order entry type person, but when I
know an app well I REALLY enjoy the benefit of type ahead. Inherently that
means the app is going slower than me, so yes there are many a
thick/fat/rich client apps that still aren't as fast as I like - but I don't
have type ahead capabilities in a browser (potential ignorance again - but I
am guessing I am right).
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 6:26 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: GUI development language
From: albartell
1) Speed. When I am working in web 2.0 browser apps they are still
slower than their thick/rich counterparts.
And both are slower than 5250. Realistically, a well-designed web
application is "fast enough". This is a very subjective issue, and one I
don't want to spend a lot of time on. I submit that local UIs that don't
have to go to the host are faster.
I also have to say, "Duh." <grin>
2) Right clicking. Can you do it in the browser? Yes. Have I seen it
implemented well? Rarely. Usually it is sluggish.
We use it all the time. We use right-click to prompt (that is, we map it to
the F4 key). Works like a charm.
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".
This is absolutely the nut, and I'm kicking myself for having forgotten it.
Half of that is security: you really don't want a served application to be
able to access your local disk. But for those applications that need
desktop integration, thick client applications win hands down.
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.
Again, this is something we've done quite a bit.
5) Back button in browser.
What is the issue? There is no "back button" in a thick client application,
so it seems to me the only problem is disabling it. I do that in PSC/400
quite effectively.
Is EGL using JSF under the covers I am guessing?
Yes.
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.
But instead you're going to write a fat client and have to worry about the
OS wars! Remember, since there is no standard rich client platform, you
have to write your own, and if you have to write your own, then you have to
now support Windows (all flavors), Linux (at least GTK and Motif), a whole
slew of *nixes, and of course OS/X.
7) Can't completely control tabbing. I don't want to tab through the
browser address bar and then like.
Piece of cake with a chromeless browser.
So, of your seven issues, I think 2, 4, 5 and 7 are more of a matter of
education on your part, and 6 is actually a point in favor of browsers, in
my opinion. Point one is pretty subjective (is the browser "too slow" or
just "a little slower"?). Point three is really the big kicker and in fact
when I give seminars on web architectures, I always bring that issue up: if
you need to integrate with the desktop, thick client is best. And if you
need to integrate with Windows applications, IE is best. So if that issue
is really the highest priority, you probably have to give up on Firefox :).
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.
midrange.com
