I still find it hard to believe that so many people are saying web apps are
better than thick clients for business apps. Am I missing something? I
still have yet to see one that is as good as a thick client. Sure, I buy
into the ease of deployment/maintainability and what not (you made good
points), but given the right architecture the exact same thing can happen
with thick clients. I just can't agree with your assessment from a user
usability perspective.
With Adobe, Microsoft and Sun's latest additions to browser plugins (which
is basically like running a thick client but without the negatives) then I
could say that yes, the browser is a right answer to many things, but in
reality that isn't the browser anymore, it is a plugin to the browser that
would be the same as having to install something on the client. The secret
is to not install things that need to change a lot on the client. Just make
the code on the client the rendering engine and leave everything else on the
server.
Is there an app out there, running in the browser without things like Flash,
that somebody can show me to validate what is being said? We recently
started using SalesForce.com for our CRM. Is that an application you would
consider to have better usability than a thick client Walden? I sure
wouldn't, though I like ability to access it anywhere.
From everything I am hearing your points are all centered around the ease of
your job and NOT the best interface for the user. I am not saying you are
wrong, but you are unbalanced.
and you can attach a debugger if needed.
Can you do this outside of native iSeries languages? That is, attach to a
job running in production? I know I can debug J2EE apps when I am running
Tomcat on my desktop, but after the .war is deployed to a server is that
still a capability? I have the same question for .NET (which I am guessing
is what you were basing the statement on).
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Thursday, August 30, 2007 5:22 PM
To: Midrange Systems Technical Discussion
Subject: RE: GUI development language
While we have a personal/professional preference to ASP.Net and C#, I'm
leaving the language discussion alone for now and addressing the
browser-based vs. thick-client issue. There are very few places (_very_
few) where thick client makes sense these days -- and since you're looking
at applications that are currently on an iSeries we're not talking about any
of those cases. Games? AutoCAD? Photoshop? Sure, thick client is the only
way to go. Beyond that, it's browser all the way baby! Reasons:
1) It's the deployment model we're used to on the iSeries. There is one copy
of the code running, and it's running on the server. Want to rollout a new
version? No problem, just put it on the server and poof!
everyone has a copy.
2) Managing code on many machine is a nightmare. In thick-client land you'll
end up with either .Net or Java, and in both cases you'll have to management
the deployment of the runtime (.Net or JVM) PLUS the deployment of all the
files that make up the application. IF you think an application is just one
.EXE, go look in your MSOffice directory to see what's needed to make an
application run. There are dozens to hundreds of files needed in the typical
app.
3) You don't need to worry about conflicts. In thick-client you need to
worry about each system having something that conflicts with your
application. Maybe it's the wrong version of Office? Or perhaps you're
missing MSSTDFMT.DLL (been there), or you need SP6 of the VB runtime, but
this machine only has SP5. That's ok, we can upgrade it to SP6...
see. Simple! What? That other application you run is not compatible with
SP6, it will only run with SP5? Um... Um... VMWare anyone? (Been there too).
In browser-apps if they have a browser we're set. Browser on XP?
Ok. Vista? Ok. Unbutu Linux? Ok. Redhat Linux? Ok. Aix? Ok. OSX? Ok. ...
4) Licensing is cheaper. In any large-scale application you're going to want
to buy some 3rd party controls. Can you roll it all yourself? Sure.
But do you really want to understand the finer points of the PDF format?
OR the gotchas of multi-thread, multi-core socket programming? Probably not,
so you'll buy something along the way. In all but the smallest of companies
the single server-copy of a control is going to be cheaper than n-hundred
copies of the client version of the control.
5) It's more secure. If you have clients accessing the database then that
means that each client PC somehow has the "right" to access and change your
data. If you're using ODBC then something as simple as Excel could cause you
a headache beyond all recognition, but even with custom socket protocols
eventually your desktop has to make a data-level request to the server. On
the other hand, in web apps only the web-server has access to the database
server. Plus in browser-based land you can even firewall off the db server
from the enterprise.
6) The UI is more familiar. Like it or not, the web has imposed _some_
standards on how we craft UIs. Can we still do right mouse? Sure.
Drag/drop? Sure. But for the most part links are underlined, we click on
things to make something happen and we fill out data and submit it around
(again, familiar model). It's the same interface we all use on Amazon and
CNN. On the other hand, I've seen some enterprise thick-client apps where
you could click, right-click, Ctrl-click, alt-click, ctrl-shift-click, etc.
7) Debugging is simpler. This comes back to #1 and #2 really, but since
there is a single centralized copy of the code you know what's deployed
because you can see it, and you can attach a debugger if needed. On the
other hand, if there are 500 copies of your application on 500 machines in
20 offices then you know what _should_ be on each of those machine?
But is it? Did Sally delete a file? Did Bob restore last-months version of
the application? Was Pete on vacation w/his machine turned off when you
deployed that update last week?
8) Better usage of system resources. In thick-client you need a desktop
machine that can run the application. In browser-based you need a server
that can run the application. In thick-client you need n-hundred of those
machines, in browser-based you need one! Yes, the one server must support
all n-hundred clients, but they don't all hit enter at the same time,
really... they don't, and you know that. How? Look at the number of DSPW
jobs in WRKACTJOB. Again, we're back to #1, it's a deployment environment
we're familiar with.
9) Web browsers enforce a no data on the client rule. If I'm in a browser
environment I simply cannot store data on the client (ok, I can store a
cookie, but that doesn't count). In a thick-client world I have the ability
to store data, and since all programmers are lazy by nature (when was the
last time you wrote a subfile from scratch?) if we can store data locally
eventually we will. Even if it starts as simple settings, eventually it
grows. Then the hard drive frags and you have to explain to the CxO why the
document he's been working on for 3 weeks is simply gone! :) Also auditors
like it better; since I can't store data on the client-side, I don't need to
worry about someone losing their machine (and all the data on it.)
10) It's more accessible. To run the thick-client application I have to
have... um... the thick-client application! If I'm on the run in an airport
I'm not going to be able to install the application on a kiosk to enter an
order, or check the shipment status before that client meeting. But with a
web app... Don't like the airport? Ok, same point at home. Or in Vegas at
iSeries DevCon attending my sessions :). Or simply at a co-workers desk in
another department that doesn't use the application.
Oh... and it's simply more fun. :)
As for why C# over Java... well, that's a religious argument, and as you
said, we don't want this to "devolve into [a] is better than [b]. ;)"
-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
