Fog Creek Software
Discussion Board

Web applications - Are they worth it?

Hi -

It seems that at the moment, the idea of creating applications which run in the browser are a really sexy thing.  But I can't help thinking that they are really tacky.  Some colleagues of mine are currently spenting crazy amount of time attempting to emulate the UI of Windows in Internet Explorer 5.5 .  And to be honest, at first it seems really cool.  Then you look at the code, and you start boggling ...

Advantages that have been described to me are that it will:

1. Work cross-platform
2. Mean that applications don't require installation.

Well, in examination, it seems that 1. is a real joke.  What people really mean by cross-platform is Internet Explorer 5.5+ - and probably only for Apple & Windows.

2.  I can't really disagree with.  But is this such a big deal?  I have used Installshield's InstallFromTheWeb, and it seems to work - this is the nearest to the idea of no-installation for a traditional Windows application that I have seen.  And furthermore, it looks as if Microsoft's .NET platform might mean that they will be getting ActiveX Documents right, five years after the release of Internet Explorer 3 with the WinForms concept.

I will come clean here and say that I used to do ASP applications for about 2 years, and that was enough to make me skeptical for life.  In the subsequent four years I have done nothing but VB development, and I really appreciate the power that this language and environment give me.

But regardless of the technical arguments, apparently these types will sell.  What does the forum think?

Mark Bertenshaw
Chordiant Software, Inc.

Mark Alexander Bertenshaw
Wednesday, February 6, 2002

If you have a small staff, web apps are a godsend.

To me one of the greatest benefits is in testing environments.  In a company that is fast-moving, it's difficult to get features out quickly and test on 27 different machine configurations.  Browser configurations are MUCH more easily tested since it doesn't involve setting up new machines for fiddling with virtual-OS systems.

When you don't get a call at 4am saying "it says access violation in XXX.dll", then I am happy doing web development.  If I have a problem, we stage it, roll a fix to the server - done.  No deployment to 4000 workstations.  Maybe a few dozen web servers tops (and we've automated this even).

Furthermore in most modern apps, web-based access is a must anyways.  So the real question is - do you start it out as a web app, or add that module on later.  We've just chosen to stay a web app.

Wednesday, February 6, 2002

Rick -

I've got to say that the advantage I see is purely one of build - or should I say - the lack of a build.  Since everything is interpreted - it's all out there, and can be tested on all platforms immediately.

Re. Browser configurations:  What combinations do you normally do?

Also:  Are you web apps predominantly server or client based?  IMHO server is definitely the "safest" bet still, although with the disadvantage that the client experience is very batch based rather than dynamic.

Mark Alexander Bertenshaw
Wednesday, February 6, 2002

We started out writing our product as a web app, but decided that the user experience was not rich enough (ie, there were things we wanted to do in the interface that were not easy in HTML) and that the tools for developing a web app were not mature enough for us to be productive with them. This was two years ago; things may have changed. Also, our two complaints are interrelated - if you don't need to do unusual things with your UI, the current generation of tools might work well for you.

Jeff Paulsen
Wednesday, February 6, 2002

Depends on the app.  PeopleSoft dramatically changed their company for the better with a move to webify their huge suite of applications.

We have a kinda unique situation at our company (BadBlue):  it's a business-focused peer-to-peer sharing application that runs as a tiny web server.  So the UI is almost entirely web-based - but it's a true Win32 client application.  The strange thing is that you can run it on your home machine and have access to it (e.g., file sharing/searching/auto-rendering of Office docs into HTML) from your office using your browser.

p.s., info re: free preview release with Gnutella support:

Dave M
Wednesday, February 6, 2002

As with most things, the answer to the question is "it depends." If you want to build, test, and deploy an application that will be used in California, Minnesota, and New York, all within 90 days, then your web app is probably the best choice.

But there are also times when a web interface absolutely fall short, simply because interface and coding capabilities are still pretty immature. You shouldn't try to shoehorn something into the web just because everybody else is doing it. Business requirements should drive technology decisions.

p.s. It's also worth noting that you can take advantage of http for back-end data transfer, if you've just GOT to have a web-enabled app. Build some middle-tier objects that pass data back and forth between your database server and your thick client (if necessary). Then you can always build a thin web client later (also if necessary), and take advantage of the existing infrastructure.

Robert K. Brown
Wednesday, February 6, 2002

Wasn't the idea of building apps that work in the browser a real sexy thing 5 years ago?

If your app is primarily a means of letting many people push data into and out of a database, a web based app is definitely the cheapest and quickest way to get something out the door.

El Grumpo
Wednesday, February 6, 2002

Some thoughts on this issue:

Wednesday, February 6, 2002

the thing i don't get about web services...isnt' the real money in intranets for corporations???  in that case-why do people have to design around the specs of IE 5.5 & html or whatever.  just make sure the people have java or whatever installed in their browser, and you can make a better GUI. 

the one skepticism i have about web services is speed.  with cheap 1 ghz machines and 256 RAM becoming the rock-bottom-standard, ppl are used to power.  are they going to be happy with the crawling tempo that i've found doing things over the web somtimes (even on a high-speed connection-if you throw in a lot of db calls and put it in secure mode-it slows things down).

no matter how well ppl say jsp/servlets scale with say an oracle db-i still find a lot of high traffic companies where i have to log in make db calls slow enough to always have another window open so i can browse the net while the info trickles back & forth.

razib khan
Wednesday, February 6, 2002

More thoughts:

* There are no decent tools for doing DHTML development which even come up to the standards set by Visual Studio (specifically VB).  Furthermore, all the DHTML projects I have seen have had scary code.  The mentality which this interpreted code forces you into rots the brain, throwing out all your former code discipline, unless you are very, very careful.

* Is the solution for the "dirty UI code" problem the .NET solutions being touted by Microsoft.  The tools seem to be pretty good.  Webforms enforce separation of the GUI with the server.  And remember that the minimum requirements for use are no more horrendous than downloading IE 6 + the .NET framework.  Once that is installed, you can just download .NET/Win32 apps in the browser.

* What about Citrix WinFrame/Terminal Server?  To my mind, this is one of the truly great pieces of software of recent time - but so few people seem to know about it.  We use this product mainly for testing our latest builds of our app, and I am consistently amazed at how fast it is, considering that we are effectively running Win32 apps over the network.  And it is also pretty efficient - we have had 16 sessions running on a K6/266 with no apparent drop in performance.
In fact, wouldn't I be correct in saying that in the time it took for me to write a simple VB 5 app, compiled it on the application server, you would still be thinking about how to get the same effects on IE 5.5 ?

Mark Alexander Bertenshaw
Wednesday, February 6, 2002

A follow up to billm (re.

-->How frequently will the application be used?

My company is seriously going down the browser everywhere route.  And funnily enough, we _are_ writing call center apps in the browser.  *8-)

Interesting article, BTW.

Mark Alexander Bertenshaw
Chordiant Software, Inc.

Mark Alexander Bertenshaw
Wednesday, February 6, 2002

Web Apps do not = sloppy code.

They don't even encourage sloppy code.  Bad programmers have sloppy habits regardless of what language they program in.

I remember when I started programming in MFC, my document/views were complete messes of spaghetti code.

Now, my web apps are nice and separated into ASP, Business layers, data layers, and stored procs.  Smaller apps would surely find this unwieldy, but as your source code grows and your maintenance grows, there really are benefits to this arrangement.

And someone did say something right - in web apps it really is all about the database.  You better have a good DBA <g> Of course this is probably true of any app which depends on data.

Wednesday, February 6, 2002

A couple times above the assertion is made that web apps are interpreted.  This isn't necessarily the case.

For instance, WebObjects applications are compiled Java 2 code.  Sure they're still run on a virtual machine, but fast virtual machines are a solved problem and have been for quite some time.  (Since at least 1995, when Apple released PowerMacs that ran emulated 68000 code faster than the fastest 68000 processor available at the time.  And they probably weren't even the first.)

Web applications also don't always mean your application mixes together presentation, business logic, and application flow in a single layer.  WebObjects, the granddaddy of web application servers, follows an MVC design pattern and many others do as well.

Chris Hanson
Wednesday, February 6, 2002

As somebody else said, it depends on the app. Would hotmail have as many users if you had to download the application before using it?

Thursday, February 7, 2002

I think the big advantage with web apps was that it allowed people to write simple apps again.

With windows, it seemed that no app was worthwhile unless it had a big UI.

With a web application you could go back to basics, just information linked by hyperlinks.  Easy to produce and publish and easy to access.

If you write a nice basic web page like that then it is both cross platform with no installation.  This site, I reckon, is a perfect example.

The problem is that, like you say, everybody is trying to recreate windows within the browser. 

Ged Byrne
Thursday, February 7, 2002

Rick -

Just to stop the confusion here: what I am talking about here is DHTML - not server side code, which I readily agree is quite easy to layer properly (I've done enough of this not to disagree).  The GUI is necessary to provide the rich user experience that people have got used to in Windows; but this currently comes at a price.

I did not say that web apps = sloppy code, I was just saying that all the DHTML projects I have seen so far have been so.  The main problem is that there are far too many diverse technologies, and in none of the manuals I have read describing those technologies do I see any advice on how to write these cleanly. But we are getting there.  Hopefully HTC will get picked up by the W3C - I love that stuff, and it saddens me that you can only use it in IE 5.5 .

I am also not saying that you can't write good code - it just is more difficult to do so, since the developer backup just isn't there - yet.  (Incidentally, this is why I keep on banging on about .NET - it seems that MS are trying to solve this problem).

Ged -

Re. Simple apps - I totally agree.  But the problem is that sometimes you really do need the complexity.  You can go down the wizard route (like we might well do on top of our Marketing Director application), but for "expert users", they don't worry about the complexity that the power useage brings with it.

Mark Alexander Bertenshaw
Thursday, February 7, 2002

Mark -

My point exactly.  When you need that extra complexity with a rich user interface you don't want to put it inside a browser.

The biggest problem is that with DHTML it looks like you can do everything you need to do.  The functionality is almost there, but not quite.  You end up wasting good code doing things that come as standard in VB.

Then microsoft upgrade the browser, and it all stops working.

Ged Byrne
Thursday, February 7, 2002

Have any of you looked at Clarionet?  Basically, you create a Windows program and put it on a server.  You then download a generic client program.  The program runs on the server but sends screen descriptions back to the client.  Sort of like Citrix but with no runtime license issues.
Check out:


Wayne Price
Thursday, February 7, 2002

DHTML and clientside code doesn't have to suck. I promise.


The tools are finally in place to let us build truly dynamic client-side interfaces. We've got most of the plumbing in place, it's just a question of developer tools and polish at this point.

Alex Russell
Friday, February 8, 2002

Alex -

The demo at was definitely ... interesting.  But on my machine, this was really jerky.  Definitely for high-end users for the moment.

Incidentally - has anyone heard whether there are plans to have some form of JIT compilation for Javascript in browsers?  If that happened, I would for one be very happy.

Mark Alexander Bertenshaw
Friday, February 8, 2002


long-time listener (and owner of Joel's UI book), first-time poster.

One argument for web applications nobody's mentioned is that you can have Clients in many locations sharing the same data on a back-end application.
The software my company makes lets you do this.

It's a pretty slick solution to a lot of the problems which dog web applications using (D)HTML and Javascript. It's a Java applet downloaded once onto the client.
It works on any version 4 or better browser, and you get the same (very functional) UI regardless, so it is genuinely cross-platform, and there is no installation required.

You can have a simple or complex app; it's up to you. The client-side presentation is easy to build with a WYSIWYG interface which saves the interface as XML.
It integrates onto an existing application or database on the server using XML (sorry Joel!). Or you can query an SQL database or use JMS or SOAP services.

Demos at:

I'd better stop now ...
Obviously I can't be objective about this :-)


Bevan McCabe
Friday, February 8, 2002

Another long time listener, first time poster.

Web apps vs native Windows apps is the fundamental dillemna of UIs today. Some applications do not have a choice: no professional currency trader at a money center bank will tolerate an HTML user interface. That trader needs the rich interactivity of a real Windows application.

Similarly any application that is updated weekly (or more frequently) and meant for 1000s of users will not work as a native app. Think about Amazon as a native Windows application. Yeah, they would lose those 5% of users that don't use Windows, but more significantly no one wants to download DLLs that often, even with .NET.

For many applications in the middle, between the extremes of the currency trader and Amazon, either approach will work, but not equally well.

There is a new category of thing called "presentation layer description languages" that promises to solve this problem. PLDLs deliver native (like) user interfaces, but done on-the-fly like HTML. At KPMG Consulting we have been working with one called I3ML from that delivers Windows user interfaces (multiple windows, toolbars, real menubars, real tabsheets, trees, grids, right mouse clicks, etc.) but deliver these UIs via a markup language on-the-fly over HTTP. Point your web browser at the right URL and get a Windows UI.

Obligatory disclaimer: we were so impressed with I3ML that we took a small stake (about 3%) of the company.

Dave Bridgeland
Friday, February 8, 2002

An application that is updated weekly? Is it mission critical? I seriously hope that there's a good QA department - unless the customers ARE the QA department. ;-)

All that CoKinetic is doing is forcing the customer to use them as a distribution chokepoint for what are essentially native api calls. I don't see how this is superior to having some kind of framework to simply download a new ActiveX automagically when there is a new release?

Sorry, I don't need another layering model for something I already know how to program in.

ub3r g33k
Friday, February 8, 2002

This is a topic near and dear to my heart.  I am currently working on a web application product that we charge $15 a month for. 

Let me just say that we use a variety of back-end technologies, but it doesn't really matter what you use behind the local-director because the real problems are all on the client side.

We apply a great effort to make the product as rich as possible given the capabilities of the browser.

We started out thinking we'd be a great cross-platform, access anytime, anywhere product, but we ran into a huge number of problems.

First, IE on Windows (5.0, 5.5, and 6.0) shares little or nothing with IE on the Mac.  The DOMs are completely different. 

Second, at the time we started, Netscape was floundering and it was really painful even to try to get rich features to work on it.

Third, doing any sort of complicated client side JavaScript requires a really good JavaScript debugger.  For the longest time, the only one available was for IE on Windows.  Mozilla only recently added the capability to do serious JS debugging, and there is still nothing on the Mac, even with OSX.

So, we're pretty good as a cross-platform product if you consider that our platform is now IE 5.0, 5.5 and 6.0 for Windows.  BTW, IE 5.0 and 5.5/6.0 are significantly (and annoyingly) different.

So, I'd have to say that you need to be really careful about the sort of application you're designing.  If it's simple and likely to stay that way, web is a great way to go, but if it has the possibility of being pulled towards the "rich interaction" end of the spectrum, then you have to consider whether a client/server model with a downloaded native application wouldn't be less painful to develop, even for multiple platforms.

Don't get me wrong, I'm very happy with what we've accomplished, but it's pretty painful at times.  It's pretty much like working with "stone knives and bear skins".

Client JS programming is a big problem, but ASPs have even bigger issues to concern themselves with. 

Users are uncomfortable storing personal data on some server somewhere they don't control, even if they trust the company.  It's not just security and privacy, it's issues like "data hostage".  People don't want to be left high and dry when your service goes under.

ASPs need to be up all the time, like 99.999% of the time.  Users get pissed if you're down for even like 15 minutes to do an upgrade to the service.  Often, web applications depend on other internet services, like eFax or PayPal.  These can go down and impact your service.

And it might not even be you or your partners that's down.  Most users cannot distinguish between your service being down and their ISP being down, but they'll call you first.  And anyone who thinks that they can sell their service to a modem user is probably kidding themselves.  Broadband is almost a necessity for us.

Also, most ASPs actually want to charge for their service, and all these "freebie" .COMs pretty much spoiled the party.

Good luck.

Nick Brosnahan
Saturday, February 9, 2002

DHTML + sloppy code - time to debunk some myths!

But first, since I go on and you might never make it to the bottom: for some nice examples of DHTML take a look at (note this is not my site, so I'm not deserving of any praise here).

Debunking time!

This goes back to something I mentioned in a previous thread about the quality of JavaScript documentation out there - there is too much "this is how you do this" and not enough "here are the language features and here is the API".

I'm amazed seeing Java programmers fudge JavaScript given that both languages have a lot in common. Anyone who has the "Show a notification about all script errors" option in their browser checked will be aware of how many script errors there are on the web, but most of these seem to be because the programmer didn't think about what they were doing.

My experience with DHTML is based on two major projects.

In the first I built a cross-browser API loosely based on DynAPI ( that provided a Windows Explorer (file lists, menu bar, context menus, dialogs) like interface that worked for IE 4 (Windows) and Netscape 4 (Windows, Linux), supporting other browsers would only require developing a browser-specific implementation of one or two key classes which all the other classes used.

The second project provided hierarchical lists, dialogs and a couple of custom widgets (pull-down menus, scrolling panes). I came into this project after development began and there was no comparable browser abstraction mechanism as in the previous project, but since the deployment platform was IE 5+ (Windows, Mac) we could use the W3C DOM instead of vendor specific DOMs - the solution wasn't 100% happy with Netscape 6, but providing NS6/Mozilla support wouldn't have been too much of an effort.

Now, here comes the interesting part. On the second project my employer searched far and wide for someone else to join me developing on the project. They would interview one or two candidates daily and as a final part of the interview process would get me to show them some code and then I'd ask them a question to ascertain their understanding of what was going on.

Of the seven or eight people I "tested", none of them were able to answer the question I gave them correctly. I don't think I was being unreasonable with my questions (my boss who has done no JavaScript programming could answer them), it's more an issue that required knowledge isn't out there - possibly because of "scripting weenies" stereotypes: that scripting is only for trivial things like alert( "Hello World!!!!!!" );.

But given all my DHTML advocacy, I actually have quite a few reservations about using DHTML in a development project.

(1) In the second project I worked on the tree views were expected to display thousands of elements. Not surprisingly performance was poor, we improved things with a few hacks (nicely hidden from other classes), but even generating a flat HTML interface with so much content is slow - the project sponsors expected Windows performance and weren't satisfied (actually the number of elements listed would have taken sweet time if it were desktop based too).

(2) Creating custom widgets means you lose a lot of features the default OS controls provide. If you write a custom SELECT element you can forget users being able to tab to the control, use cursors to select items, etc without A LOT of work.

(3) Browser based displays are not supposed to be pixel-perfect - there are far too many potential clients that trying to achieve exact placement is a task that can never be achieved. Visual Studio.NET attempts to provide a solution for this - it will fail and will produce code that is heavier than it needs to be.

(4) The Keep It Simple Stupid approach - the most popular sites don't use DHTML, Flash, other tricks. In many cases where the developer wants to provide a DHTML interface it doesn't actually provide that much benefit to the end user.

So, it is a viable option for your web project, but keep it simple, don't overuse it and it can be a good thing.

Ok, got that? I'll never mention this again.

Books and documentation:

Walter Rumsby
Saturday, February 9, 2002

I looked at Curl a couple times; it seems like Berners-Lee's ramped-up DHTML.  Curl Corporation was built to make money on it.

But why, oh why, do these companies insist on making brain-dead business models, like charging $1/MB that users have of your application?  Curl Corp does this!

Another objectively great technology bites the bust.  When talking with people from the company, one person said that their beancounters looked at many scenarios, and decided this was the only sensible one.  Translated from dotcom-ese, it means they were under heavy pressure to find a model that resulted in a huge IPO, under the most optimisitic possible conditions.

When they die, I hope some angel buys the technology for a pittance and open-sources it.  Maybe like King Lear, they will undergo a transformation that will benefit the world.

Michael Richardson
Saturday, February 9, 2002

With sincere respect to ub3r g33k, I completely disagree.  The web is not the exclusive domain of programmers.  If it was, there'd be a total of like 13 web sites on the whole planet.  I'm pleased for ub3r g33k that he/she knows the api's well, it probably means life-time employment.  However, html changed the world because a huge load of people embraced it, not just the IT elite (read "those who can program.")

I've looked at the cokinetic stuff too and I contend that the ability to send something over the internet that looks and feels just like a client server app, but that functions just like a web page, is huge.  I especially like the fact that it's all HTTP, is just plain old XML and that you don't need their server to drive it.  That means it works will my app servers and other paraphernalia that I've been accumulating over the years. 

Also, I'm not keen to host ActiveX controls etc. from my Sun servers and I'm not in love with IIS.  Sorry but I'm not quite ready to concede the server end to MS yet.  This is not religious intolerence for MS like one sometimes sees; just that I have quite of few ctrl+alt+delete callouses still.

Something like the cokinetic stuff will be EVERYWHERE in a couple of years.  Don't doubt it.  Choke point?  HTML is the choke point.  I've spend 10s of millions of my company's dollars pushing html to do stuff that it was never intended to do.  Sure, I've added active x controls and java applets and etc, etc.  I've never enjoyed it though.  I suspect that most others don't love it either since there's still a complete dearth of ANY sophisticated web apps.  This is not because people are ignorant of the magical capabilities of these tools.  They just don't work that well (my opinion.) 

I mean, sheesh, even outlook outstrips the best web app on the planet.

Lisa McMillian
Saturday, February 9, 2002

For what is worth, I did something very close to the Cokinetic stuff in late 1999, during the internship for my thesis: an XML-RPC based protocol for reproducing interfaces remotely. We were working with Sybase's PowerBuilder on one side and Java 2 on the other side.

Nice that the idea has caught on, however. Maybe now it's the right time for such a solution.

Sebastiano Pilla
Friday, February 15, 2002

"yes, they are. No problem, you're welcome".

Monday, February 25, 2002

*  Recent Topics

*  Fog Creek Home