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
- It could read or write the values of <form> fields
- 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.
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.