I assume you're referring to the deployment/management issues;
Nope, I am talking about building your application so you DON'T have very
much, if anything, to do with deployment issues. You install this thick
client once and only update it as much as you would update your browser
version. I am talking about creating a desktop thick client that really
only knows how to render form definitions, retain state, and communicate
with the server. EVERYTHING to do with database access, business logic,
process flow, etc is done on the server. This is really quite similar to
what the browser is doing, except it can be done in a thick client
environment using thick client controls. I should have been more detailed
in my OP.
Sorry, didn't mean to. Short answer: Yes, I've used several applications
that deliver better business value then their thick-client cousins would
have.
If you have the time could you detail what they are (technologies used,
purpose of application, etc), if they are public, etc? I am really trying
to either expose a well written browser app that gives thick clients a run
for their money, or expose your original comment as an overstatement of
confidence in browser applications.
<Walden>
Longer answer... the question isn't valid. You pose a question that assumes
you will deliver a "well written" browser app and a "well written' thick
client app. OK, given the choice between them, as a user I'll take the thick
client app. However, there are two problems with the question, first it
assumes you'll be given the time/resources to build and maintain a
thick-client to the same level as a web app, and second you ignore the
back-end management of thick clients.
</Walden>
I think we have the same understanding that in the end, from a users
perspective, a thick client is most always going to be better. I am not
arguing your point of thick client implementations being messy. I think
that is a product of short sightedness on Microsoft's part - they are still
trying to get enterprise minded concerning infrastructure. Right now they
get most of their business because of look and feel for both users and
developers - doesn't bode well though for the enterprise infrastructure as a
whole because I still don't believe that Microsoft is a good long term
investment compared to what IBM has offered to date with server side (no I
am not going to argue that IBM has sucked it up big time with their lack of
GUI, that is exactly what Microsoft has used for their in-road).
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Friday, August 31, 2007 8:50 AM
To: Midrange Systems Technical Discussion
Subject: RE: GUI development language
Have you honestly ever explored this space?
I assume you're referring to the deployment/management issues; yes, I have
explored the space. Am I an expert? Absolutely not. I'll admit, there are
some very good ways to do this, with ActiveDirectory/SMS and InstallShield's
update service probably being two of the biggies.
However, most people don't have a good deployment of AD at all, let alone
one that will support SMS. Installshield's update service is promising too,
but you've got to build the right packages in your build step (I've got
several .ise files on my pc now) and it's not trivial in a large app. Plus,
what if someone doesn't have the current version? Can they connect to the
DB? What if the old version didn't know about a new required element, will
it die gracefully? Bottom line is, all these problems are (somewhat)
solvable, yes, but why bother when the browser interface doesn't require you
to solve them. Spend those resources on solving the business problems.
Does it take a different mindset to program more generically with a
framework mindset?, you bet, but it is easier than you think.
Not sure where you're going here. What kind of framework?
You danced around the base of my question. Have you ever used a well
written browser app, private or public, that was better than a well
written
thick client app?
Sorry, didn't mean to. Short answer: Yes, I've used several applications
that deliver better business value then their thick-client cousins would
have. Longer answer... the question isn't valid. You pose a question that
assumes you will deliver a "well written" browser app and a "well written'
thick client app. OK, given the choice between them, as a user I'll take the
thick client app. However, there are two problems with the question, first
it assumes you'll be given the time/resources to build and maintain a
thick-client to the same level as a web app, and second you ignore the
back-end management of thick clients.
-Walden
--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
--
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
