RE: GUI development language

From: albartell

Which begs the question: if speed is really the issue, why aren't you

pushing 5250 applications?

I think we both know that 5250 has become unacceptable because of it's
non-GUI-ness so I will assume you don't want more of a response on this
front. I am looking for the next best alternative to 5250.

Okay, but again I don't like to say one technology is superior over another,
because the real answer is "it depends on the situation".

I am trying as best I can to stay on user interface (user experience) and
NOT deployment. I am not ignorant to the fact that deployment and other
messes do play into the mix, but I am just debating user experience (or at
least trying to keep it to just that).

Is a thick client more feature-rich than a browser? Yes, we all know that.
But taken out of context, the question is moot. From a miles-per-gallon
standpoint, the best car is... a bicycle.

Not in the least - I have very-much-so lived through JSF's sucky-ness. I
developed, from scratch, and maintain an application where the entire UI
is
in JSF (about 120 dynamic pages at last count). Well, most of it is,
except
where JSF sucked it up and I had to retro fit back to JSP to make things
work. There are things I love about JSF (ease of tying button clicks to
methods) and things I hate about it (anytime you deviate from what the
spec
authors or spec implementers thought would be "the right way" you can get
yourself into many wasted hours of trying to "work around" the framework).

This is frameworks in a nutshell, and one of the reasons I tell people that
using a framework that you don't understand at the lowest level is fraught
with peril. I'm having some discussions right now with the IBM folks about
their JSF extensions and it's quite annoying.

You are correct. I have never deployed a multi-OS desktop application, or
rather, I haven't pointedly tried to test for desktops outside of Windows.
That is why I put the disclaimer in there that I thought it wouldn't be
easy, just that the number of variables would potentially be less (i.e.
developing for 3 OSes vs. developing for 3 browsers on 3 OSes which would
give you 9 things to thoroughly test).

I still don't agree with this. Sure, you may have to test nine times, but
typically that doesn't involve changing a line of code. Whereas writing the
code for three different operating system effectively triples your work.

If the need/money was there I would do 10 operating systems (just like
anyone here would do 3 browsers per OS). The fact is that I would
probably code for 2, maybe 3.

You HAVE to code for a minimum of Windows, Linux and OS/X. Then there are
the vagaries of each version of Windows, such as XP vs. Vista. Then you
have to choose the appropriate Linux distros; there are at least three major
versions.

And that's ignoring handhelds and cell phones and Unix variants including
AIX and on and on...

Our definitions of hack vary then. You needed to do that because the
environment (browser) forced it on you, otherwise you would have just
started the application in a chromeless browser vs. having to create it as
a child window.

Sorry, you lost me here. I click on a link, another window pops up with my
application running inside of it. Not sure why this is a hack.

You can implement type ahead with Ajax.

Example? I haven't seen this anywhere yet. What I have seen in the
community is they consider "type ahead" to be Google's Suggest features.

The reason you can't do type-ahead in a browser is that there is no way to
capture keystrokes during page refreshes. With Ajax you don't leave the
page so you should theoretically be able to capture keystrokes during an
asynchronous Ajax refresh and then insert them into the next page. It
wouldn't be simple, but it should be doable.

I think we are starting to reason away good things and settling for less.
Maybe less is becoming acceptable? Maybe once the fun looks of web pages
wear off we will realize that we need more than cool things to keep our
business efficient? Web pages have done such a great job of looking
pretty
and surprising us with their "new" functionality that I think we are using
that as a crutch to settle for less.

I think all you have to do to convince me (or anyone) is to provide a
situation where a rich client will make a user demonstrably more productive,
then show us the cost of writing that rich client code.

You seem to be trying to sell the idea that "rich client is better" and I
keep trying to tell you that no IT decisions are made in a vacuum, they have
to be made in the context of the whole business. Maybe it's just me, but I
have found that whenever technology is chosen for technology's sake, just
because it is "better", then you almost always end up with a solution
looking for a problem.

Joe