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