Application Development in the Internet Age

---

Robert Hess
Developer Relations Group
Microsoft Corporation

September 21, 1998

The following article, which was originally published in the Site Builder Magazine (now known as MSDN Online Voices) "More or Hess" column, continues a series in which MSDN Online columnist-at-large Robert Hess investigates application development in the Internet Age. Next month, Robert will delve deeper into the strategies of developing Web-based applications.

The Web and, more specifically, Web pages were originally structured to provide easy access, display, and navigation of documents on the Internet. Even this simple model was a very ambitious endeavor. I won't bore any of you with the details of what reading documents was like before the Web, but suffice it to say that all usefully shareable information was stored as plain-vanilla text files (with hard carriage returns at about column 78), and going to a secondary document that was referenced in the first meant manually locating the file on some other system and downloading it.

The combination of a document viewer that would format a file based on a simple structure language and the ability to create "clickable links" to other documents that would automatically load them up was nothing short of a windfall to the Internet community. The Internet was all about sharing information with little (if any) dependencies on operating system or platform.

So what has changed? Why are people beginning to focus on Web sites as applications?

The answer is pretty simple: "Because they can."

Traditional application developers may feel that an application needs to be something that is written in a cryptic programming language, run through a compiler, linked with additional "library" code, and then installed by users onto their machines. Oh yeah, and once a year or so the users need to check back with the developer to see if there is an update available to fix the problem they reported when they first installed the application. Applications should also be something that only "programmers" can develop.

The Web is quickly pointing out that this is no longer the case. As the Web grows up, it is becoming possible to apply Web-based technologies to solutions that would otherwise have been written in C, Visual Basic®, or some other application-development language.

There are two issues regarding this emergence of Web technologies that I'd like to address in this column: Why is so much focus being turned toward Web-based applications, and how far can this go?

Why Web Apps?

Let's return to the why. Many people think the answer is easy: "Platform independence." A wide variety of Web pages can be viewed on virtually any operating system. Heck, I even understand that there are Web browsers available for my old Apple IIgs, which I haven't fired up for almost 10 years now.

However, I don't think this is the answer. Today, Windows-based systems account for the vast majority of user systems. While platform independence may be a useful feature, I think in this situation it is probably as important as being able to find leaded fuel at a gas station.

What is probably more important is the ease of deployment.

Users don't have to install Web sites onto their systems. They simply browse to them, look at the information, provide whatever feedback is needed -- and when they are done, move on. The only impact on their systems is that their "temporary Internet caches" will hold a few files for them until they are cleaned out. It's true that plug-ins or ActiveX® controls add some additional files to the underlying system, but as advanced features such as Dynamic HTML are added to the browser, the need for those extra components is decreasing quickly.

I can't count the number of times that one service group or another here at work developed some form of custom application, and, in order for me to fill out a form, I had to install a bunch of stuff on my system before I could run the application. If this were the only time I needed to fill out this form, I would then attempt to remove the application and all of its associated files. If I did happen to use the application at some point in the future, I would often get a response back from the group that they had a new application in place, and that I needed to install it instead. (But I'm sure I'm the only person out there who has had this experience.)

Today, these same groups are deploying their services via Web pages, which makes the same solutions far easier to install, makes a much softer footprint on my system, and allows better control of just-in-time updates.

But this type of application isn't limited to departmental applications; similar benefits are easily applicable to a wide range of solutions. I can drop my film off at a photo processor, and then pick up the "digital" images from a Web site. I can update my stock portfolio and instantly calculate values based on the current market prices. I can invoke language translators for when I receive e-mail from foreign countries. I can print out maps and driving directions from my house to anywhere in the U.S. Even word processors, spreadsheets, databases, and other traditional "personal productivity" applications are being made available as Web sites.

Web-based solutions provide a mechanism for deploying applications that install swiftly and easily, run well without crashing, and usually uninstall themselves automatically without leaving any debris on the user's machine. Sounds like a perfect model for software deployment. So it is no wonder that people are taking a very hard look at the benefits they can gain by utilizing Web technologies in their application strategy.

Going the Distance

But how far can this go? How "advanced" an application can be developed with Web-based technologies?

First, it is important to understand that the term "Web-based technologies" is a slight misnomer. We can easily talk about Web browsers, and people have a pretty good idea of all of the various components: document rendering, network communication, scripting technology, Java, ActiveX, cached storage.... Take a look at any one of these pieces individually. Each one of them was available outside of the "browser." Even Java and ActiveX technologies were essentially fully formed, and were simply adapted to be leveraged by browsers. So Web browsers are opportunists. They are gathering together a range of diverse technologies and capabilities, and are providing an arena in which they can all come together.

As most of you have probably seen, when you try deploying application solutions in the form of a Web site, you soon run into a few brick walls. The most impenetrable is the fact that the client system is essentially hands-off. Not only are you not allowed direct access to the storage media of the client system, you also aren't allowed access to very much in the way of information about the system on which your application will run. Directly because of the ease with which Web applications can be silently transferred to the user's system, there is a very high concern regarding security and privacy.

This means that many Web applications need to be specifically designed to operate within the confines of a secured Web interface. They need to put more and more of the functionality onto the servers. They need to require less access to the user's system, and they sometimes need to use tricky mechanisms for providing persistence of information from one session to another. They also need to be prepared to operate within the functional capabilities of a large number of different Web browsers.

However, just because an application utilizes Web-based technology doesn't mean that it is a Web site, nor that it is deployed via the internet. It doesn't even mean that users have to have an Internet account or a modem/network connection on their computers. And it doesn't necessarily mean that the application needs to be at the whim of whatever browser the user might have installed.

If you happen to have Microsoft Money 98 installed, then you've already experienced a new class of application -- one that is leveraging Web-based technologies, but is also a stand-alone application with little resemblance to a Web site. I've pointed this out to a number of people who use Money 98, and it is amazing how many aren't aware that a lot of the content they see within Money 98 is based on Dynamic HTML. I think this illustrates quite well how the difference between a traditional Windows application and an application that utilizes Web-based technologies can get fairly fuzzy.

So applications that leverage Web-based technologies can virtually run the gamut of functionality, from a simple Web page to a full-fledged application environment. Even applications that don't utilize Web-based technologies can expose their functionality in such a way that they can be utilized by applications that are designed around Web based technologies.

The Hard Part

All this leaves you, the solution provider, working to properly understand the right strategy to take with your design development. Each of the possible directions you can take provide both benefits and limitations. It is your own strengths and abilities, as well as the needs and expectations of your users, that will play a critical role in determining how to provide your services to others.

If your experience and background is with Web sites, then the best approach is probably to evolve that model forward as you increase the functionality of your solution. Add some dynamic content to your pages. Leverage new technologies of the browsers. Or if you are an traditional application developer, think about how you might expose your functionality as components that Web pages and Web-based applications can utilize both on the client and on the server. Look at the extended capabilities of Dynamic HTML and see how XML might be appropriate vehicles for exchanging your data and information with other applications.

Web technologies, as well as traditional application technologies, can share a lot between themselves. Look for the sweet spot. Find where your solutions can gain the greatest functionality from the operating system and the services it provides. This is the direction that application development is going.