RE: GUI development language

From: albartell

I also have to say, "Duh." <grin>

Of all people I wouldn't have expected you to consider something "good
enough" :-)

Hmm. Then you haven't been reading what I write. What I say is "it's a
business decision" and in a business decision, if it's good enough for the
user, it's good enough. Which begs the question: if speed is really the
issue, why aren't you pushing 5250 applications? There's hardly a person on
this list who wouldn't agree that 5250 is the fastest interface out there.

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

No, I would take it as "How much more productive is the user with a browser
vs. a thick client." And "How much longer does it take to make a thick
client, and how much more does it cost to support it?" Balancing those
questions is what an IT manager does. Architects and academics think up
cool ways to do things; managers figure out how to pay for them.

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.

Far be it from to suggest that you might be displaying a little bit of a
tendency to repeat other people's complaints without really understanding
the underlying issues, Aaron, but it seems to me that you might be
displaying a little bit of a tendency to repeat other people's complaints
without really understanding the underlying issues. :)

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

I almost never see a situation where one technology is inherently "second"
to another. I think that's a classic trap technologists fall into; they
become enamored with some technology and then insist it's better than
anything out there. Each technological decision is a business decision: how
much does it cost, and much does the company profit by this choice. And
once those are answered, then you can afford the luxury of worrying about
strategic direction and platform independence and technological elegance.

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.

This is hogwash and poppycock, Aaron. The differences in graphic APIs far
outweigh the differences in browsers. By orders of magnitude. What's the
analog of an HWnd in GTK? How do you write to a printer in Windows?

I'm guessing here, but I don't think you've ever tried to deploy a
multi-platform thick client application. Remember, even if you go the route
of a renderer (e.g. a rich client), the renderer itself is a full-blown
thick client, subject to all the vagaries of thick client distribution).
It's hard enough to deploy a single-platform thick client. Good luck
deploying it across 10 operating systems.

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

It's not a hack. It's an easily implemented feature. The biggest problem
is going from an normal browser session to a chromeless one, because the
system thinks it's a popup. But if you're going to write your own thick
client, it's almost inconsequential to write your own chromeless browser.

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

You can implement type ahead with Ajax.

But for those applications that absolutely require type ahead, I again
assume you're planning to use a 5250 interface, because that is by far the
fastest interface available.

Joe