Fog Creek Software
Discussion Board

The future of applications is HTML

What do you think about software running in a browser? In the next years, Will do I use a word processing in a browser? Could HTML be the next de fact standard to build User Interface? What about Flash?

In the pass years, I saw a lot of people migrating your software into a web-based scheme (big examples are SAP and PeopleSoft). But why?. In my opinion, you can get some advantages in the new web-based scheme and some disadvantages. The principal advantages are: no installation needed (you simple use an URL), usability, learnability (you know how to use links, what the "Back" buttons does, etc.) and others technical advantages like better scalability, fault tolerance and load balancing. On the other hand, I think that you have some disadvantages (compared to classic GUI applications) like browser incompatibility problems, heavy traffic, the interface is more static and "lags" between each pages. In classic GUI applications you can hide/show fields easily; you have less "power" with JavaScript. And what about grids? You can't scroll in Web to find a particular product.

I you could use Flash and make a web application with the same interface power that you have using Windows and the advantages of Web schema. I mean, probably I don't need links in an application. What do you think?

Nicolás Castagnet
Thursday, April 04, 2002

I think there are other ways as well to separate the GUI from the application, if you're interested in the GUI aspect of an application: Terminal Services, X-Windows, ...

Christopher Wells
Thursday, April 04, 2002

I think the web has gained particular popularity because of its ubiquity and ease.  Headaches with distribution fade away; compatibly problems become the user's obligation to fix (upgrade your browser), rather than the company's (build a service pack).  Because everything is powered by a server, code updates and service packs are a matter of pushing new files to the webserver, rather than distributing a set of fixes to all your users.

The HTML/Javascript is ubiquitous across OS platforms as well.  No more managing code lines for different platforms, or porting code to new ones.  In some ways you can think of HTML/Javascript fulfilling the crossplatform compatibility promised by Java.

But unlike Java, HTML/Javascript is an easier combo to program in.  A series of links interconnected by some scripting processes is a lot less daunting than a robust, event driven windows app. 

These are headaches that take a while to resolve.  Take into account that companies love to ship products quickly, and the web sounds like the best solution for new apps. 

Personally I don't think HTML/Javascript alone is strong enough to replace a powerful standalone app.  But by solving the issues above, the future of browser based apps is promising.  (Isn’t this the promise of .NET?  All the features of the web through ASP.NET, powered by a strong C#/VB.NET backend?)

Monsur Hossain
Thursday, April 04, 2002

Yes. .Net seems to go in this way.

Life seems to be easier to developer companies. But what about users? I am not sure if a WebForm are easier to users than WinForms. Personally, I feel more comfortable managing my mail in a windows app than in a web app. Maybe, in the future will be easier to use a web app than a windows app. But nowadays is difficult to me to think in an accountant managing the accountancy in a web app.

In Web app we have: links and "back" button. But in Win app we have more interactivity.

Nicolás Castagnet
Thursday, April 04, 2002

>The principal advantages are: no installation needed (you simple use an URL)

"No installation required" is definitely a good thing, but by itself is not a good enough reason to choose a web app over a traditional app.

>usability, learnability (you know how to use links, what the "Back" buttons does, etc.)

I disagree that there is an increase in usability and learnability just because the application is running inside a browser.  Sure you understand links and what the "Back" button does but that indicates familiarity with the browser, not with the application itself.  That's akin to saying that if someone knows how to use the Start button and how Cut/Copy/Paste then they should have no trouble using the corporate Windows accounting software to reconcile the corporate books.

>and others technical advantages like better scalability, fault tolerance and load balancing.

I also disagree with this assumption that browser apps automagically guarantee better scalability, fault tolerance, and load balancing.  Those attributes are provided by a well-designed back-end environment.  The browser is the front-end.

Thursday, April 04, 2002

Actually, browser-based apps have a much poorer scalability _by definition_ than windows apps.

In a browser-based application, the workload is distributed between the client and the server. In an ASP/PHP/JSP/etc. environment, the web server has to build the user interface over and over again for every single client request. There is an inherent bottleneck in the network and in the processing resources on the server.

But in a browser based application, _all_ of the workload is distributed to the clients. You can add an endless number of clients without decreasing performance for any of those clients. Now that's scalability!

Of course, the ideal application is one that whose deployment and maintenance is automatically managed over something like a browser, the processing happens on the client's machine in a native GUI application, and databases/files are stored on the server.

...By the way, where in the world did the idea come from that web applications can build better/more usable interfaces? That's an absurd notion. Show me how to build a WYSIWYG word processor inside of a browser window (without driving your users crazy) and I'll gladly give you a nickel.

Benji Smith
Thursday, April 04, 2002


My 3rd paragraph is actually referring to _GUI apps_ not browser apps.

What an idiot.

Benji Smith
Thursday, April 04, 2002

Many of the things that make web based applications attractive can be done with .NET quite seamlessly, even for Windows Forms applications that scale better (because they take advantage of the computational ability of the client).

I think that the pushback against web based apps will really happen in earnest once people understand how to deploy .NET apps (and, of course, once they trust .NET). The headaches incurred for web based apps (even WebForms apps) are just monumental.

Just my 2c. I could be wrong. ;)

Brad Wilson
Thursday, April 04, 2002

My company creates software that tries to run crossplatform on all sorts of systems, including browsers with Java and Flash.  Through this all, there are varying levels of independence from the server-end.  Here a little breakdown from my experience, pro and con.

- currently immature
Flash has ~95% penetration on browsers.  But writing a GUI (as I understand) is a new game.  Cute but usually nonstandard, lowering usability.  Also, for plugins other than flash (such as Java) you might want to distribute an install CD, or maybe use Java WebStart.

- dependence on internet connection sucks
Having an app that works only if you have an active connection, is viciously antisocial to users.  You'll want a version that also works standalone.  But if you do, then life will be beautiful.  Then your app will truly be pervasive.

- you'll need servers
And a net admin. 

- crashing sucks
"Don't hit the back button."  But there are ways to recover gracefully from these mistakes.

+ web apps make up for platform deficiencies
Under win32, programs generally need an installer.  On OS X, the user can download an "icon" from you, which contains the entire program from her perspective.  In reality, it is an entire directory which the user manipulates as if it were a single executable file.

+ crossplatform support is improving
New developments are happening every day.  Here is the Crossover plugin that allows IE plugins to work on Unix:
[ ]
I haven't tested it yet, but we'll see.

+ it's the wave of the future
Now that personal computers are pervasive in western countries, people want an independence from their home machine.  Also, spending a thousand dollars on something that runs an email client is becoming a bit absurd.

I would advise that one would just look coldly at these kinds of apps, and see what they need to succeed on their new platform.  Plus, keep in mind you're paying a bit of R&D, because despite Unix's old X, there are still a lot of mistakes to be made here.  Not too many O'Reilly books on making nice web interfaces.

And do research.  Curl is nice, but have you noticed the idiotic pricing scheme?  One day doing research will replace two days fixing mistakes.

Bob Winchell
Thursday, April 04, 2002

Actually, let me make that:  One day doing research will replace two /weeks/ fixing mistakes.  If you're lucky.

Bob Winchell
Thursday, April 04, 2002

The popularity of HTML/Webbased applications is due to their attractiveness to the sysadmin. The 'no installation needed' is a big carrot indeed, and the less work a sysadmin has to do on all those desktops, the better.

But from a user's point of view, the situation is not so good:

- They require an internet connection. Given the number of times I can't log on to my ISP, I don't want to be reliant on that.

- They reduce the number of applications available. How many tools do you use now that were developed as shareware by a single person, who has no hope in hell of being able to provide this tool as an Internet application?

- Where does this leave my data? Sensitive or not, I want complete control over whatever data I create, not find everything deleted because I didn't access my account in three months.

- They reduce user choice. "This application is written in ActiveX and runs only on Windows with IE".

- Many internet apps run inside a browser. For nontrivial apps, this means the UI sucks: no menu bar, for one. No windows. No palettes.
The UI also sucks because there'll be no Human Interface Guidelines to follow. Everyone will try and invent the wheel again. Welcome to the bad old days of MS-DOS!

- That internet connection is SLOW. When I create a new document in a local application, it's there in the blink of an eye. With an internet app, go wait for the page to load.
- The entire UI gets squeezed down that narrow pipe every time you do something.

- Integration between apps goes back to the Stone Age.

I used to work for a company that created a complex application for storage and manipulation of images. They had a Windows version and a Web-based version. The Web-based version was less functional, looked horrible and was bloody annoying because of the download times.

Harro de Jong
Friday, April 05, 2002

Consumers will eventually realize that web apps are less reliable than others, on average.  If the company providing the web service goes down, so does your application.

Web apps are lock-in.  The only way out is if you (the consumer) can host a server too.

Greg Neumann
Friday, April 05, 2002

Bit of a plug here, but it's on topic, so:
I think my company has a good solution to bringing the GUI features and power into a browser.

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 for the end-user.

You can have Clients in many locations sharing the same data on a back-end application.

You can have a simple or complex app. 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 since this isn't the forum for a sales pitch ... obviously I can't be objective about this :-)


Bevan McCabe
Friday, April 05, 2002

IMHO, this conversation is so late 90's.  The days of doing something a dozen different ways are over for now.  Budgets are being slashed.  People will do what they are paid to do,  tech 'religion' can take a backseat

Friday, April 05, 2002

Let me clarifiy, my point was rebutting the hype of "the future is this....the future is that..." 

The future is what you're currently working on.
Hype can take a backseat to reaility now.

Friday, April 05, 2002

The future may look more like the DHTML email client from the folks at oddpost  -  If you have been unimpressed wtih DHTML applications, check out their live demo (It's IE specific...yes all this can be done in Mozilla). 

DHTML<->SOAP<->Server(written in Python)

A true client-server application in the browser.

Dan Sickles
Friday, April 05, 2002

I'm willing to talk about "the wave of the future."  I'm not particularly concerned about money, just what people want from computers.  That is my job.

From my perspective, there is a duality.  Two contradictory desires:
1) private, stable apps that reside on machines I own
2) apps which follow me around wherever I go

These are basic desires, outside of our industry's hype.  This duality has existed for a very long time. 

Item 2) will clearly make a comeback as net speed, reliability, and pervasiveness increase.

But it should also be clear that the two can not be treated the same.  With current technology, you still can not hide the differences between the two.  Security, performance, etc all are obstacles.  But the two can work in harmony, complementing each other.  Any given application can be composed of both these components, occasionally for a greater user experience than either alone.

Bob Winchell
Friday, April 05, 2002

At the risk of a gross generalization, all things being equal:

Apps that primarily output data:  Browser good
Apps that primarily input data:  Browser bad

I have seen vertical market HTML apps that are used for high-volume data input.  It's not a pretty sight.

Long term, the dynamics of the market will provide a solution that works well in both cases.  Some would say we're already there with .NET Winforms in a URL deployment scenerio...

Bill Carlson
Friday, April 05, 2002

I'm impressed by the oddpost DHTML/SOAP site. Their email client has a very professional GUI. I am guessing, though, that their system for implementing the GUI is a home-brewed system that just _looks_ like windows but has not been modularized for repeat use.

I'm interested in a class of interface components that I can use universally to create a standard-looking application for the web. When the client downloads the application, it should all execute on the client machine unless data needs to be retrieved from the server. This request should use a socket connection (or anything faster than an HTTP request to a web server).

The Java applet described by Bevan sounds like it would fit the bill, but upon looking at the demo, it just doesn't look quite right. The interface looks vaguely like a window GUI, but it still feels wrong (in many of the ways that Java standalone apps feel wrong). I want web interfaces to look _exactly_ like windows (unless I deliberately subclass them to look different).

I've heard wonderful speculative things about .Net winForms, but I haven't seen them in action anywhere yet. Does anyone know of any websites that have good examples up?

Benji Smith
Friday, April 05, 2002

Benji, you may want to check out IBM Sash for Windows and Linux - It's a local Javascript runtime with access to the native UI.  They have a complete IDE for download. Inetesting and in the right direction. I'm watching to see where .NET Windows Forms goes.  Simple apps can be sone in JScript. Cool.

Dan Sickles
Friday, April 05, 2002

DomAPI ( ) also has an interesting set of components...

Monsur Hossain
Friday, April 05, 2002

WRT installation issues, I've baked a homemade "no installation required" routine into my corporate client/server apps.  All of my schemas have a special one-row table called Admin that contains startup initializations particular to the application, including a field called UpdateLocation which contains the UNC pathname of the NT share that serves as the application's installation directory.

After the user successfully logs into the database I use GetFileVersionInfo to compare the version number of the .EXE in the installation directory against the .EXE that is currently running.  If the version numbers differ I inform the user that a program update was detected and they will be automatically updated.  After they click OK I CreateProcess() a homegrown SETUP.EXE  from the installation directory and close the app.  The SETUP.EXE waits until the app shuts down, then deletes the old files and copies the new files, recreates the desktop and Start Menu icons, and then respawns the application leaving the user back at the splash/login screen.

This method works very well for us.  The only caveats are:

- Of course we don't/can't use InstallShield, but this isn't a problem since we're creating corporate apps for corporate desktops.  Our Setup program does everything with no user intervention required.

- Each app requires its own unique SETUP.EXE to match the application.  Actually the code in each Setup program is identical, the only difference is the array of app files defined at the top of the program so it knows what to delete and what to copy.  We discussed expanding the Admin table to include the filenames but decided it was too much work for so little benefit given that we control the entire codebase anyway.  Besides, unique Setup programs gives us extra flexibility if we ever need it.

- We use Delphi so our installations generally consists of MyApp.EXE and MyApp.HLP that can be installed via simple CopyFile routine.  We never have to update any system files or runtimes that may require a reboot.  Before we migrated our MSSQL apps to ADO we used to include the DB-LIB files NTWDBLIB.DLL and DBMSSOCN.DLL in the installation directory, but that didn't require a reboot.  Our Oracle apps assume that the OCI client is installed.

Saturday, April 06, 2002

You can create desktop UIs but still deploy them to the web with Rui:

Saturday, April 26, 2003

*  Recent Topics

*  Fog Creek Home