How I Came To Write One Of The World’s First Rich Web Applications

And The Lessons I Learned Along The Way

I wrote my first Rich Web Application way back in 1998, seven years before the introduction of AJAX. Running on Microsoft Internet Explorer 4 (IE4), which was released only a couple of months before, this app could even work offline. The application was deployed to hundreds of customers, including a large installation at HP. But by 2001 the bubble had burst, I had moved on, and the software quietly died. It then took me almost an entire decade to get back to professional web development. This is the story of how I wrote one of the world’s first Rich Web Applications, and the lessons I learned along the way.

In The Beginning

This startup — BackWeb — developed technologies for transmitting content super efficiently over the wire for the then nascent, and bandwidth-poor, consumer Internet. The initial implementation of these technologies was for pushing advertisements to consumers’ computers, ostensibly as a means for subsidizing free Internet connections. But by 97' a company called PointCast made a big splash, and BackWeb pivoted into the newly hot Push Technology market. Even though we utilized some web technologies, such as HTTP, our product was very much client/server, with users having to install a native client in order to receive the pushed content.

Only a single year later, PointCast imploded, taking the whole consumer Push market with it, and at BackWeb we were scrambling to find a new direction. Fortunately for us, we were well funded, and were able to pivot again, this time to the enterprise market. Our first post-consumer offering was a Marketing Encyclopedia, basically an application with an online interface to a collection of documents that a salesperson might want to help a customer make a purchase decision. Our unique twist was that in addition to the online interface, we pushed select documents onto the salesperson’s computer so that she could access them while offline. (Back in 98' people were often offline.) The online part was implemented as a standard multi-page Web app. I was the architect for the offline part, and started looking for a good solution for the UI.

I set myself a goal that the offline UI should look and work the same as the online UI, so that ideally the end-user couldn’t tell them apart. In order to achieve this, I decided to ditch our existing native interface, and display the local, offline content using HTML, inside the browser, just like the online content. I wasn’t aware of anybody else doing such a thing, but the idea was very appealing to me, and I was able to successfully pitch it to Management. Obviously we were taking a risk, but thought the risk was worth the reward of a successful, innovative product. Moreover, it felt like the right course to take. My initial approach was to implement a local web-server to provide the local content. But it quickly became apparent that running a web-server with ASP functionality on top of Windows 95 was going to be very problematic, so I began researching alternatives.

The DHTML Revolution

  1. It could read or write the values of <form> fields
  2. It could write strings directly to the document stream using document.write. While this method did provide complete client-side control over the document content, you were forced to rewrite everything from scratch each time (kind of like React, but much, much slower ;-). This is because after the document is loaded, document.write has the nasty side-effect of clearing out its entire content before writing to it. And while I did see some nice tricks implemented using frames, it was very painful.

With DHTML, JavaScript had total control over the document content using a cool, new API called “the DOM”. It could insert new elements, remove elements, modify attributes, etc. Basically, what Web developers take for granted today. (And BTW, if you’re wondering whatever happened to DHTML, it simply got a new/old name: HTML.)

When I learned about DHTML and the DOM, and that IE4 provided an API that enabled native plugins (ActiveX components) to interact directly with them, and with browser scripts, I knew I had a solution. I transformed the BackWeb fat client into a headless plugin, and used the API to push the local content into the browser. The UI was implemented as a Single Page Application (SPA), although the term didn’t exist at the time. I was very happy with the results, and so was Management — nobody had such a solution at the time, and it provided us with a distinct edge. Customers liked it, and so did partners. The gamble had paid off.

The Nitty Gritty

The second dilemma was whether to use JavaScript or VBScript as the scripting language. Back at that time, Microsoft was heavily promoting VB and its siblings, and IE4 supported both scripting languages equally. VBScript also had the advantage of being the programming language we used in the web-server for the online mode, with ASP. In addition, this was before try…catch was introduced into JavaScript, so handling errors was very problematic for it, whereas VBScript had its wacky but workable on error mechanism. Nonetheless I chose to go with JavaScript, because I greatly preferred both its syntax and semantics. The business justification was that we hoped to add support for Netscape when it finally implemented DHTML, and even though it never did, this also proved to be a correct decision as in-browser VBScript began to wane, and JavaScript took off.

Even though the product was very successful, we did run into several snags. First and foremost, IE4 wasn’t really designed to be an application platform. It suffered from numerous problems such as memory leaks, and general stability issues. For example, as I mentioned at the beginning, HP purchased the product, but didn’t use it for marketing and sales collateral. Instead they used it as a library of technical product documentation for their field engineers. Thing is, HP had thousands of products, with several documents for each product. As a result, instead of displaying a few hundred documents, as originally designed, the product had to contend with several thousand or more. Displaying a list of so many documents would cause the client to slow down significantly, and even crash the browser. This forced us to switch from a single, long list to a paged display. But thanks to the inherent flexibility of the DOM and JavaScript, as well as the application design, we were able to implement this change quickly.


I’m a Performance Specialist at My job is to make 80 million websites hosted on the Wix platform load and execute faster. Opinions are my own

I’m a Performance Specialist at My job is to make 80 million websites hosted on the Wix platform load and execute faster. Opinions are my own