|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
