Fog Creek Software
Discussion Board

When are web-based apps not recommended?

I'm going to have to make a decision to rewrite VB-based apps for payrolls, accounting etc. that my dad currently sells. Considering that we have to send updates regularly to customers who are still often not connected to the Net (thanks to the ProComm BBS by the way...), and are far from being computer-savy... I'm thinking hard about whether to rewrite those as web applications.

If some of you went through the same thing, ie. rewrite dedicated business apps into web apps, what did you discover? Would you recommend it, or are the hassles of writing web apps not worth the effort?

If the projects were successful, which tools would you recommend? Plain languages like Perl or PHP, or full-fledged toolboxes like Zope, .Net, J2EE, etc.?

Thx much for any infos

Frederic Faure
Monday, December 2, 2002

i think it really depends on the kind of software you're making. complex interfaces with many input validations is a pain in the ### imho.

I always had the feeling that i couldn't rely on javascript and the browser gives a user to much possibilities to screw up a system. add to this the fact that server-side-scripting combined with html and possibly javascript messes up your code bigtime.

i know many successfull projects have been build in this way, but it really depends on the kind of project you're working on.

one of the main pro' is offcourse the ease of deployment.

just my 2 cents

Monday, December 2, 2002

Is the data that these applications use on some remote system?

If not then I wouldn't use web services to move that data around not use a web application as the UI.  As its accounting data its likely not remote, or rather I'd be dubious about remote accounting data being handled that way.

If your apps aren't broken, don't fix them with this year's glue.

On the other hand if customers are asking for secondary data, the results of queries for reports, statistics, input into other management systems and so on, then yes, provide a web service for the data.

But not a data entry application.

People using accounting systems around the world bemoan the lack of a stable keyboard entry user interface that allows them to enter large volumes of data in repetitive processes.

Bring back the green screen.

I need my tablets now nurse, please don't do, I'll be good...

Simon Lucy
Monday, December 2, 2002

Don't write them as web apps unless they stand to benefit from the advantages of being a web app, and those advantages outweigh the disadvantages of being a web app.

Advantages of web app:
1. Portability - the user's operating system doesn't matter, as long as they have a web browser (and as long as the programmers don't use Internet Explorer-specific tags or JavaScript in their HTML!)

2. Deployment - When you change the app you don't have to change anything on the users' machines.

3.  Remote access -  makes it simpler for users to run the app remotely, such as when they work from home.

1. Less interactive and responsive  -  there are fewer ways in which you can dynamically manipulate the widgets and data in response to a user's choices, as compared to a local GUI app.  In many cases you'll have to reload the whole page to get the desired effect, instead of being able to immediately refresh the data and/or individual widgets on the screen.  There are many things for which a connection with the server is required in order to update the screen (e.g. the user wants to sort by a different column) which would have been done without another call to the server in a local GUI app.  This tends to make web apps poor for  massive data entry.

2. Usually harder to build and maintain  -  you'll have to deal with session state management, the evil "back" button, and many other aspects that you wouldn't have to think about with a local GUI app.  You'll also have to do some policing to ensure the developers don't use IE- or Netscape-specific tags or JavaScript. 

3.  Restricted choice of user interface widgets - you are restricted to using the limited set of widgets that are available in standard browsers.

T. Norman
Monday, December 2, 2002

Adding to the very complete answers above..

If the apps circle around large amounts of input, dont bother. Webapps work well for output-centric applications, (which ofcourse is where webapps began).

You might want to consider using flash though. Its a relativily easy way of putting a GUI together and it would allow you to store stuff locally (for multipage forms etc).

Eric DeBois
Monday, December 2, 2002

You are also forgetting that all and any of your windows applications can be web enabled with a few mouse clicks?

So, if ONLY web access is the goal, then you can deploy any windows application to web with a few mouse clicks. (you just use windows terminal server).

Will the cost of deployment to web pay for the cost of development? This whole thing is all about turning code into dollars.

I have often posted the following article on mine on this board. It does explain the difference between web enabled products, and .net.

I mean, why bother writing  for the web, when current technology from MS enables you to web enable any software you have now without re-writing one line code ?

Anyway..check out my thoughts on this at:

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Monday, December 2, 2002

Nice articles Albert!

Prakash S
Monday, December 2, 2002


You might want to check Paul Graham's articles.

Here are some of those.

hope this helps.

Prakash S
Monday, December 2, 2002

Frederic,  Why are you rewriting these existing apps? Please post your cost/benefit analysis.

Monday, December 2, 2002

Most apps are better off as web apps, IMO. Practically all ERP-type apps (payroll, customer managements, etc.) can be done effectively with web technologies. Don't use Flash, of course.

Monday, December 2, 2002

I'm in the process of re-writing some of our VB Apps as Activex Controls to be embedded into web pages.  Personally, I think this will give us the best of both worlds because I can build the GUI in VB (which is great), and deployment of Activex controls is simple.

These pages won't work on anything but Windows, but for our clients this doesn't matter.  I'm just getting sick of not being able to do what I want to because scripting can't handle it, plus I like a nice looking UI which is easily done with commercial activex controls.

This is not to say that ALL of our apps will be re-written, only some of the "vertical market" plugins that are deployed to a lot of machines at client sites.

Wayne Bloss
Monday, December 2, 2002

For something like accounting programs where there's a lot of data entry involved, a rich and responsive user interface is absolutely necessary.  Current browser technologies currently do not offer this ability. 

Also, it seems you think creating a web-based app would be better since it would make it easier to deploy changes and updates, since everything is centralized.  However, how often do you think you would actually be doing updates?  Two or three times a year at most for an accounting program I would think.  If so, you can just let clients know via e-mail, phone, or whatever and have them download the updated version.  It shouldn't be that painful for them since they wouldn't have to download the new version that often.

However, with new technologies such as .NET, the tendency is now to move to richer UIs which are still easily updatable via the web.  .NET offers something similar to Java applets where the code downloaded runs within a sandbox.  The good thing about the .NET "applet" version over Java's version is the better user-interface offering.

See for an example.

Tuesday, December 3, 2002

"just use windows terminal server"

JC Albert! Do you have shares in Microsoft or something?!

Tuesday, December 3, 2002

Remember security.... Web apps with data on your server introduces a whole lot of risks and liabilities.

When it is sensetive accounting data, things can get really messy really quickly.

Just my paranoid $0,02 worth. :)

Tuesday, December 3, 2002

Thx everyone for your valuable input :-) To sum things up:

- If your application changes a lot and you need to lower the cost of deploying new versions, there are three possibilities: client-server (where most of the logic is located on a server process running on a central host), thin client (Citrix, MS TS, etc.), and web applications

- The web interface is fine for outputing infos, but pretty poor at inputing; if your application requires fast and rich input (accounting, etc.), forget about using a web browser as the client interface. You might want to take a look at Flash to see if that solves the problem. MS' .Net (ASP.Net, really) technology makes it easier to develop web-based apps, but we're still limited to the browser's capabilities

- Writing web applications requires quite some experience to write clean and easy-to-maintain code due to its mix of presentation and logic; Don't underestimate the time and work required before you can build applications similar to fat clients; Sophisticated apps often require mixing different technologies & tools (eg. server-side scripting, client-side scripting, ActiveX, etc.). Take a look at the demo at for an amazing web-based interface

- Advantages of web app : Portability, Deployment, Remote access. Disadvantages : Less interactive and responsive, Usually harder to build and maintain, Restricted choice of user interface widgets

- Think about whether your application needs to interact with other apps, in which case fat-clients are more relevant

As food for thought, if someone knows of a good site/book on developing client-server apps, I'm interested.


Frederic Faure
Tuesday, December 3, 2002

If your application changes a lot and you need to lower the cost of deploying new versions, you might also want to consider auto updating rich clients. I find they often give you the best of both worlds.

This article discusses .NET, but the same functionality can be (and has been)  implemented on most platforms with a bit of care and work.

Just me (Sir to you)
Tuesday, December 3, 2002

Thx. Indeed, I'm beginning to think the best solution would be to move toward client-server with auto-update for the few times the client would need to be updated once the fast-moving parts are moved to a server.

Thx much for the link on using WinForms with .Net :-)

Frederic Faure
Tuesday, December 3, 2002

For auto-updating rich client application for the "other framework" (ie: J2EE .vs. .NET), you have the java web start which take care of it with just some XML description file.

Robert Chevallier
Saturday, December 7, 2002

*  Recent Topics

*  Fog Creek Home