Fog Creek Software
Discussion Board

When to design Web-based Applications?

When can one design a thin client application? i.e. what should be the guiding light?

CityDesk is a pc based product - most new applications are browser based.

What are the boundaries beyond which designing a browser based application is not practical?

This has puzzled me for some months - my supervisor would like us to build a new customer service application for our sales personel.

We are at the moment specing the product - our inclination is to go with a PC based product. But then there will be hassles with keeping the clients updates.

Data is stored in our central server that the sales team can access remotely.

Sari Loumanien
Friday, August 1, 2003

"most new applications are browser based."

Really? I'd like to see some statistics for this. If you include most of the 'look at these photos of my cats' webpages, you might be right.

Friday, August 1, 2003

Most new applications are browser based:

We are currently installing SAP's ERP - it is completely browser based.

The reporting tool from Cognos is also browser based.

These are heavy-duty applications - not simple internet interactions.

Also our financial management system was upgraded two years ago to browser based application.

Sari Loumanien
Friday, August 1, 2003

I think whether or not to do a project web-based depends on a few things:

* where are the users who will access it?
  - spread out over huge area/cities/etc -> web based
  - small office 3-5 people, can do it local.  (this points to support)

* what kind of control do you have over their computers (you have much more control over what browsers they use than the computers)
- web pages can work in a more "standard" environment usually.

* where is the data?
- does each user have a copy, or is it in a central database?

* how often will they use it?
- web based apps still have a small amount of latency which is very irritating.  If they'll be using it 24 hours a day heavily, then might want to go fully on the client.

Andrew Hurst
Friday, August 1, 2003

Ah, and related to "where is the data", will they need to access it offline?

Andrew Hurst
Friday, August 1, 2003

At work, we're speccing out the next generation of our home-grown ERP, and we're very seriously considering a browser based thin-client, with a Java based applications layer and the current RDBMS (MS SQL Server) at the back.  Here's the points in favor of a thin client:

1. Most of what everyone does with the system is data-entry/data-retrieval/reports.  A rich interface isn't necessary; JSPs with Javascript providing things like input masks is more than sufficient.  For the occasionally needed rich interface, we've got Java/SWT or VB.

2. As you pointed out, updating is centralized.  Our current system (that I inherited) is Access/Excel based fat clients going directly to the RDBMS, which scales horribly, and has a ridiculous update scheme, namely that the Access/Excel app is copied from the server to the local hard drive and opened from there, every time it's opened.  If someone maps a shortcut directly to the server instead of to the launcher program, it locks the file, preventing everyone else from opening it.  It's just... awful, and any change to the system involves searching through stored procedures and multiple apps to find all the relevant code.

3. Easy to develop the front end, with no expensive development tools to purchase.  A limited client means its harder for the developers to get in trouble; with web-based frontends, a lot of it can be abstracted into templates, includes, and whatnot, meaning centralization of components.

4. For those who need richer reporting, Excel generating components are already in use and available for our architecture at reasonable costs (i.e., ~$3,000 for an enterprise licence).  Licencing is simplified, too, when you're purchasing for a server or two, rather than for every client.

5. Easy to include low overhead paperwork in the whole system.  One of the reasons we don't go paperless now with quite a few processes is that it's viewed as too much of a headache to transition to an already clunky fat client system.  It's a low priority job that we never get around too.

Points against:  No big ones that I can think of.  If we choose a richer interface, it will be for greater advantages in that direction, not because I can spot any killer objections to thin client.

Justin Johnson
Friday, August 1, 2003

The browser is just the interface to the application. Throw in VB components and you have a powerful combination for creating business applications that are *easier* to distribute and maintain.

It reminds me of how many programmers turn up their noses at MS-Access. But it makes a very powerful front-end to SQL Server. MS-Access is just an IDE; it just happens to also come with the JET engine. But you don't have to use JET.

And you don't have to use VBScript with web applications either.

Bill K Ramsey
Friday, August 1, 2003

MS Access is great front end to SQL Server--considered by itself, as a standalone app.  Forms builder, easy integration with VB, report builder, all in all a nice little package.

It's in the aggregate that it's an unmaintainable monster.  The temptation to fatten the client is too great, and you end up with what we have: 200 different fat clients that are logically related, and no good way to search and replace through all of them, among other things.

Justin Johnson
Friday, August 1, 2003

Justin hits it right on.  Centralized servers with thin clients are the easiest to maintain.

Friday, August 1, 2003

"The browser is just the interface to the application. Throw in VB components and you have a powerful combination for creating business applications that are *easier* to distribute and maintain."

I'm a little skeptical about combining web apps with ActiveX controls.  To me, it seems like one of the main reasons for going the browser route is the complete freedom from having to have the client pc's configured a certain way. 

When you require all clients to have certain controls installed so they can run in the browser, you throw that advantage away.  And if you're going to do that, then you might as well build a real Win32/WinForms thin client that's just a download away but has the richness of interface you can't get with a browser-based app.  Considering that your clients are going to have to download the controls and you're going to have to maintain the correct versions of those, the ease of distribution and maintenance of an ActiveX control-based browser app isn't necessarily any better than that of a Win32 client.

I realize it's not quite as cut-and-dried as that.  But if you find yourself designing a browser-based app around ActiveX controls, at the very least I think you should give some thought to whether it might be a better idea to use Win32 or WinForms thin clients.

Herbert Sitz
Saturday, August 2, 2003

Although it requires the 20 megabyte download, I would strongly encourage you to check out "streamed" href-exes as implemented by the .NET Framework. What a wonder! Great security model, seamless updates, easy remoting, etc. It's been a dream to work with, as the whole web design thing, which was interesting at first, has gotten a little old.

Saturday, August 2, 2003

A little advice, from someone who has been down most of the roads mentioned here.

Using ActiveX controls in your web pages is aluring, just like the siren's song. You'll find out about the siren's teeth when you need to update that control. It is very hard to get all of your clients updated, and they'll probably spend some downtime while the update process is going on.

If you need the rich client, go for a nice clean .exe program that is 100% free of ActiveX controls. This is again because ActiveX controls are hard to update consistently. You'll still need a mechanism for keeping the .exe updated, but it will be easier than ActiveX. I've had the best luck with Delphi/C++ Builder for rapid application development without ActiveX.

Entirely browser-based applications are pretty nice to maintain. Your interface isn't as flashy, but it can get the job done nicely. Updating is a breeze, because you only have to update your servers and everyone gets it, instantly.

You might be able to get the best of both world by combining a thick client with web services. Even if you don't want to use Microsoft's tools, packages like gsoap make web services available to most compilers. I haven't been down this road yet, but it appears to hold some promise.

Clay Dowling
Saturday, August 2, 2003


>> We are at the moment specing the product - our inclination is to go with a PC based product. But then there will be hassles with keeping the clients updates. <<

If you're able to use .NET technology to build your product, you can have the best of both worlds. .NET allows you to download a rich client assembly from a remote server over HTTP using a web browser. Any updates to the assembly on the central server can be automatically downloaded and installed to each client.



Mark Pearce
Saturday, August 2, 2003

I find it hard to discuss technologies without the framework of a specific application, in other words, the question can't even be answered.  You first need to understand your requirements and functionality, only then you should pick the technology.

And relevant requirements are:stand-alone vs. connected, GUI complexity (i.e. drag'n'drop not possible with vanilla HTML), response time, security, and much more.

I've seen many project go beserk where the technology was picked first ("must use XML"... "must use Oracle", etc.).

Michael Jastram
Saturday, August 2, 2003

When there are, or might eventually be, remote users the application should be web-based.

The Real PC
Saturday, August 2, 2003

Real PC -- That misses the main issue of the thread: is a browser-based interface better if it depends on ActiveX controls that have be installed and maintained?

Do you mean to say that an app should be entirely browser-based (i.e., browser w/o ActiveX controls) if there may be remote users?

The main issue in this thread seems to be now regarding whether there are benefits to a browser-based app with ActiveX controls over using Win32 or WinForms clients.  The ActiveX controls erase most of the benefits of browser-based apps, in which case Win32 or WinForms clients can be just as easy to deploy but provide a better user interface.  Even if we're talking about a situation with remote users.

For what it's worth, I can imagine lots of cases where a 2 or 3MB thin client app that's easily downloadable and upgradeable (single .exe) would be preferable to a purely browser-based app, even when users are accessing remotely.  If they've got broadband the thin client .exe download or upgrade takes what, 20 or 30 seconds?

Herbert Sitz
Saturday, August 2, 2003

Once you say "ActiveX is okay", why not design the entire application to reside inside a single ActiveX control? Then you get client-side code without a heavy-weight install.

Personally, I believe that HREF-served .NET EXEs are a great option if you have control over the environment (i.e., you can dictate the installation of the .NET Framework).

Brad Wilson (
Sunday, August 3, 2003

Although it's fairly simple to implement something similar yourself if you're not using .NET (some game companies do it for example).

And the horse you rode in on
Monday, August 4, 2003


If you are considering using Java for your application you could have a look at Java Web Start. You can launch applications from your browser. The client gets installed on your desktop. Updates are automatic. You can also launch your applications from the desktop without the browser.

Ranjit Nair
Monday, August 4, 2003

"But then there will be hassles with keeping the clients updates."

If you can assume the clients will be on the network (which they would have to be anyway if you are considering thin-client), there should be no problems keeping the clients up-to-date. As other have mentioned, .NET is extremely capable in this respect, but also Java and classic applications have no problems updating (automatically or on demand) themselves if you plan for it.

Just me (Sir to you)
Monday, August 4, 2003

*  Recent Topics

*  Fog Creek Home