I was reading Paul Graham's book "Hackers & Painters" yesterday and found that a good portion of the book talked about designing web-based apps. Like many, I thought this was a good idea. However, in the past year or so, major doubts have entered into my mind; part of this is that my current employer makes extensive use of them. That's where I'm seeing the downside more than anywhere else. Though, the greatest likelihood is that my very classical libertarian belief system bristles at the idea of losing any form of control over my own content.
So, I suppose the question is, are web-based applications a good idea?
Web Based Applications - Good or Bad Idea?
May 16, 2005 - 1:25pm
#1
Web Based Applications - Good or Bad Idea?
In my mind, a web-based app that uses LOCAL storage wouldn't be wholly horrible, but it's like leasing a car. You get to drive it as long as you hold the lease, but then you gotta take it back. So you've spend how much for the dang thing, and in the end you don't own it? It's a great model for software companies, but a bad model for consumers. Webapps require connectivity, so if your network is down then nobody can get work done.
I'll relate a story I heard about Sprint and the early days of VoIP. KC is the WHQ of Sprint, and they have alot of offices and servers around in many buildings in the city. In the server room of one building somebody was doing a checkup or maintenence of a system, and noticed that the one next to it was unlabelled and had many lines going off through the room. They notified management that it seems the techs might have installed their own box in the server room, what to do? Management told them to shut it off and they'd deal with it. So, the machine was hard powered off. No trouble, so it seemed. Then it was discovered that the phone in the server room didn't work. Went to the outer office, that phone was dead, etc. They had advertently shutoff the brand new VoIP server and cut off much of the buildings phone system, including managements, so no one could call to say they were haveing phone problems. Cell phones worked, but without a working line coming in to the building, they were useless. They had to find a technician to come get the box back up and restore the phones. If I remember the ending right, they ended up putting a note on the door that said to call a tech to do anything to a machine, even if management says not to. The techs know what is going on, management just signs the purchase orders.
Moral of the story: Don't leap at a new technology, and then shoot yourself in the foot because you didn't think of the simplest error of implementing it, having it turn off.
I write web based applications in PHP. Most of them use MySQL or Oracle behind the scenes to store the data.
If you own the server it's running on, and the server is on the site of where the application will be run, then there's quite a few good reasons to go web based. Our intranet's helpdesk system is all web-based. Any tech, instructor, or lab aide can hop on any computer on campus and pull up the help desk tickets.
Applefritter is a web-based application: a discussion forum and a content management system.
My personal website, www.focushacks.com is just a database browser, and also a makeshift content management system.
Of course, there are things that a web-based interface isn't good for. Although javascript and activeX make it possible, you probably wouldn't want to make a word processor that's web based. Things that need to interact with hardware, for instance, a time clock or barcode scanner on a serial port, are also examples of things that wouldn't be easy to do over the web.
What kind of project are you working on?
Thick clients rule!!!
Mainframes are the only way to go. There is nothing better than running
Terminal emulation software (Celview) on your Mac and connecting to your local friendly mainframe and pounding away at some good old fashioned COBOL.
To heck with all of this cleient server mess and those d@mned guys on the other side of the floor talking about Java this and web portal that. It is bad enough that XML is so pervasive through OS X (at least that makes sense).
I am sorry, I just wanted to put in a good word for the old days.
Thanks for the input, guys...
I'm not working on any project per se... I write (plus a few other things... not terribly 2d). It's just that as I read what Graham had to say, I could see the beauty in the concept, but at the same time, it just doesn't set that well with me.
My day job, such as it is, is at a ompany that collects bad checks. I'm the troubleshooting wonk; my job is to keep the customers happy when they don't receive the information in a timely manner. One of our primary web-based apps allows us to fax their data via the web. Problem is, the whole application looks as though it was a sophomore's software project; the interface is not very well thought out, there's a screen refresh everytime you change a parameter, and too often it is just slow (30 minutes to complete a simple task? Really...). If we had a client side application (which we should for this), it would speed things up wonderfully. We don't... it isn't.
I also don't like the idea that if you buy the software that you don't have steady access to it if the network is acting flakey. Nope, don't like it, don't like it one bit. For me, as an end user, that just doesn't fly.
There are a great many web-based apps, and the number will continue to grow, no doubt. I just find it ironic that, in the end, Ken Olson, formerly of DEC, may have the last laugh. He said that he saw no reason for the average person to own a computer. At this rate, that may ultimately be the case; we won't own computers, just thin clients.
Actually it sounds like it would be just fine for a web app, it was just coded poorly, i.e. javascript to refresh every time you change something. Client/Server apps are just as prone to network availability issues as web based apps. Unless you wanted a fax/modem in every PC that this program was running on, client/server is the way to go. Whether the client is a GUI written in C that uses ODBC to talk to the database, or the client is a web browser accessing a web app, it's the way to go. The interface could probably be spruced up a bit.
Actually, many companies find web based time clocks like ours
(at www.spectrum-research.com/V2/web_based_time_clock_software.asp )
superior, because time and attendance information is centralized. Many of these companies have the need for multiple time clocks, perhaps at different locations. Their administrators want to access
data from their own office.
Biometric input devices can still be attached to the time clock computers via USB or other types of connections.
From a management perspective, web based applications have allowed us to provide a better product and better service. New features, updates and fixes can be applied from one location. We can go through the server logs, find and fix errors, even when our clients
haven't reported a problem. Finally, we can make sure that data is
backed up, when a standalone system at a customer site might not get
backed up.
I see the lack of security in improperly written web apps as the biggest drawback to web applications. We ended up writing a code generator that we use to write 85-90% of our web application code. The code generator adds all of the client and server side data validation and anti-hack code, thus making that code more secure.
It has also reduced the bug rates in generated code to almost
nothing.
Actually, many companies find web based time clocks like ours
(at www.spectrum-research.com/V2/web_based_time_clock_software.asp )
superior, because time and attendance information is centralized. Many of these companies have the need for multiple time clocks, perhaps at different locations. Their administrators want to access
data from their own office.
Biometric input devices can still be attached to the time clock computers via USB or other types of connections.
From a management perspective, web based applications have allowed us to provide a better product and better service. New features, updates and fixes can be applied from one location. We can go through the server logs, find and fix errors, even when our clients haven't reported a problem. Finally, we can make sure that data is backed up, when a standalone system at a customer site might not get backed up.
I see the lack of security in improperly written web apps as the biggest drawback to web applications. We ended up writing a code generator that we use to write 85-90% of our web application code. The code generator adds all of the client and server side data validation and anti-hack code, thus making that code more secure. It has also reduced the bug rates in generated code to almost nothing.
The whole web application thing is getting rather tiring for me. I am going back to doing all development on and for the Apple II.