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

My professional software career started in earnest way back in 94' (I had worked part-time during my college days, and even taught BASIC programming during high-school, but was hardly payed for either.) My first real software job was developing games for the Windows platform, which I did for two years. It was fun while it lasted, but by 96' I was back in the job market. Fortunately for me the Dot-com Bubble was just starting to inflate, and I quickly landed a good position at a hot new startup as employee #9.

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

On October 97' Microsoft released a new version of their browser: IE4. These days we tend to put down IE, but back then it was revolutionary. In a bid to take the lead from Netscape, Microsoft rewrote their browser from scratch, and introduced the world to the concept of Dynamic HTML (DHTML). Up to that point JavaScript running in the browser could access and modify the browser document content in very limited ways:

  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

I had two main dilemmas while working on this project: the first was whether to implement the entire logic inside the ActiveX component using C++, and have it interact directly with the DOM elements, or to push the data into script, and use scripting to implement the UI and business logic. I chose the later, as I thought it would make the implementation more flexible. This turned out to be a very fortuitous decision, as we later integrated this product with several CRM packages, and the script-based approach made it possible to perform these integration projects without having to modify the ActiveX at all. As a result, integration was simpler and faster, greatly contributing to the success of the product.

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.

Conclusion

The success of this and others products, enabled BackWeb to go public in 99’, and by 2000 we had an amazing valuation of over $2B! When the Dot-com Bubble burst the stock did plummet, but by the end of 2001 I was out of the company anyway. My next job pulled me back to client/server development using C++, Java and C#. However, my experience made it clear to me that the Web and JavaScript are an extremely powerful combination, and one that I greatly enjoy using. This led me to work on various JavaScript side-projects, but it wasn’t until 2010 that JavaScript and the Web became the focus of my day-job again, and continue to be to this day.