HTML-based Web development has dominated application development for the last six years or so and there are no signs of that changing.

However, things are changing as the .NET initiative takes hold. Although Microsoft has put a lot of effort into its Web-based interfaces, which include the powerful new ASP.NET Web Forms framework, I am guessing that there will actually be a push back to desktop-driven, forms-based applications once .NET takes hold.

Things are changing. Browser-based HTML applications aren't the only way to take advantage of the Web and distributed architecture anymore.

What? I must be kidding, right? I don't think so. Let's start by looking at some of the issues facing HTML development as an application front end.

What's Wrong with HTML as a Front End?

Although Visual Studio .NET makes it somewhat easier to build HTML-based Web applications, it is still far from simple. There are too many limitations in HTML's markup definition and no matter how fancy the wrapping is around the basic controls, HTML still produces an inferior interface to those found in desktop applications.

Lack of Visual Tools

The release of Visual Studio .NET also has not made great inroads into HTML design itself with its visual editor, which is not exactly a milestone above the one found in Visual Interdev. Yes, CSS/DHTML-based positional interfaces are easier to work with visually, and some major ‘issues’ have been fixed.

But, for standard, page-flow-based HTML (read table-based layouts), the VS .NET designer leaves a lot to be desired when compared to full visual tools like MacroMedia's Dreamweaver or even Microsoft's own FrontPage.

On the other hand, the HTML editor in VS .NET has seen many very welcome improvements, which pays tribute to the fact that most developers still use code editors rather than visual designers to build HTML by hand. While it's not difficult to manually write HTML, it's very tedious and time consuming. For most Web applications, HTML creation takes more time and resources than writing the application logic.

Web forms can help with some of the tedium. While the Web controls generate a great deal of your HTML, you are still faced with the task of getting those controls onto the HTML page and positioned correctly, which puts us back at the original point of the lackluster visual support for layout. The point here is that for broad market HTML applications, it continues to be a lot of work to create workable HTML interfaces.

Limited HTML Form Interface

On a broader level, there's the issue of HTML as a form interface for serious applications. I had an interesting experience a few days ago when I got a call from a telemarketing company that wanted to know how the local cable company was doing. Slow that I was that day (never accept a call from anybody calling you Mr. Strahl after 7:00 p.m.), I accepted the ‘invitation’ and was treated to a long-winded survey that went on for almost 20 minutes.

The person on the phone kept fumbling and complaining about moving the mouse around her application, with fields not flowing properly from one control to the next in their new system. When I asked more questions, I found out that the application is an Extranet application running in a browser. This application enables telemarketers to work from home while storing survey data in a centralized location for immediate availability and rating. It sounds like a good idea, but apparently the execution was bad (either that or there was a severe case of operator error).

While this is a specific instance, I've seen this in many business locations where companies have gone overboard slapping an HTML interface onto everything that needs to be centralized. This is especially true for complex applications that require lots of data entry, which is notoriously the worst feature in HTML - the lack of complete control over data entry controls. Take things like the simple concept of a Treeview control, drag and drop or even multi-column list boxes, and you can get a good idea just how limited HTML really is.

I've built a number of applications in the past that have both a Web and a distributed model desktop interface. If it comes down to a choice of which is easier to use on a day-to-day basis, the desktop versions usually win hands-down for usability and for the sheer speed at which they can accomplish the same tasks.

ASP.NET is specifically geared towards developing rich, form-based applications (using HTML) while attempting to mimic desktop interfaces. ASP.NET achieves its mimicry using ‘simulations’ of rich interface controls. Most of these simulations are clumsy and slow - they also end up sending a lot of HTML around unnecessarily, which wastes network bandwidth. ASP.NET accomplishes much of its form-based metaphor through a state saving mechanism that pushes most of the UI changes through standard form variables, which can greatly affect the size of the data traveling over the wire.

I'm not talking about online shopping carts or a simple query application that display a few numbers from a database. In these applications, the overhead is probably minimal. I'm referring to applications that corporations run on a daily basis for data entry and management of their data. There's been a big push to get many of these types of applications running over Intranet or Extranet connections because of the universal accessibility of these applications from any network connection. I've seen a number of these applications fail, mainly because of HTML user interface issues - users simply didn't want to put up with a huge step down and managers didn't realize the extra effort it would take to build a highly usable interface using HTML.

Alternative Content

Remember that there's more to applications than text! There's the often overlooked issue of alternative technologies that are used today to handle content that a browser can't deal with directly. Have you ever tried printing from a Web application? There's no native way to get controlled printing out of a Web page. Printing HTML from a browser is hardly a solution for anything but a single page.

To use serious printing of any sort, you can resort to generating a PDF document and sending that down from a Web server. But, that is also problematic, since there are so many problems with the PDF viewers in Internet Explorer from dynamic content.

There are a slew of Java applets out there (although there's much less hype about that these days) running applications that can't be easily written using even advanced DHTML code, because of performance or lack of access to the necessary services. Java applets and Macromedia's Flash technology are the rule in this area. Microsoft was never able to make a dent in this arena with either Internet Explorer's DHTML implementation or the browser-based ActiveX platform (ActiveX controls and Active Documents). The former has been limited by the browser's dependency on Internet Explorer; the latter is simply too scary due to the security implications of the control having full access to the underlying OS.

However, there is demand for these types of services that need to run on the client machine for performance reasons. Script often can't touch this, specifically for rich applications that provide network IO and XML services that client side code requires in order to be functional. If you look at the various online gaming interfaces available, you can get a good example of applications that actually require this kind of functionality to provide fancy graphic interfaces and network access to communicate quickly with the server. Interestingly, you'll find that most don't use Microsoft technologies because the tools to build them are missing or not supported by Microsoft. However, this may change with .NET.

Distributed Architecture Gives New Options

I don't think any software developer will argue with the point that HTML or browser interfaces, in general, are very limited. Unfortunately, corporate managers often can't see the distinction between a desktop application and one running in the browser, except that a browser-based application can be accessed over the Internet.

One of the big reasons the push to HTML occurred originally was the fact that HTML applications were distributed?many clients could access content simultaneously over easily accessed connections and immediately available data. Well, things have changed a bit since those early days. Today we have the ability to access content without requiring an HTML interface. With the distributed architecture, we can now build Web Services or even plain XML-based content for consumption by any type of application over the Web. With the right tools, integration of this type of functionality on the client is very straightforward and doesn't require much code.

This also means we're no longer tied to a complete application running on a Web Server, but can have a server on the Web acting as a data service to provide information for consumption by a wide variety of different clients, including other Web Sites, desktop applications and hand held PDAs. We can have the user interface (UI) and some basic validation business logic running on the client to provide the user with instant feedback without going back to the server each time to check a business rule that requires some data.

With the distributed architecture of XML and/or Web Services, HTML interfaces are becoming much less important, as you can now build applications that access their data via the Web without an HTML front end to do it. You can have a rich UI customized to the needs of the end user. Existing applications can integrate Web functionality now without requiring a full re-write. This is especially important for many vertical applications that have an established market. In many cases, there's no need to throw away an existing interface implementation just because the need arises to share data from a centralized location.

With a Web Service interface, you can now access data over the Web and bring it down into the client-side application relatively painlessly for easy manipulation. Even if you don't buy into the Web Services hype, retrieval of any kind of Web content, whether it's binary data or XML, is easy to accomplish from a desktop application.

The extensive hype of the .NET release has helped to increase the awareness of distributed computing in the developer community. While there is still a lack of publicly available, useful Web Services, they will show their true potential on the internal side of things, such as data services for in-house or vertical applications with private non-published interfaces used only by internal developers.

To take advantage of distributed application development, rich client applications have a variety of ways to spread out and retrieve data. Here are a just a few common scenarios:

Pulling data updates from a server: Many applications require frequent updates of critical data, which can be pulled over the Web as needed. This is especially useful for vertical applications that run standalone except for occasional data updates. Developers can handle version updates in the same manner.

Running with remote data: It's easy to build a Web Service that acts as a data server to provide a client application with all the data it needs locally. This involves treating the Web Service as a data source and requires an always-on Internet connection.

Running with offline data: Another scenario is to pull data down from time to time and run the application offline. .NET DataSets are one technology that makes this type of operation very easy by providing a local data engine that can easily synchronize with the full data backend, using a Web Service for communication. In this scenario, an Internet connection is required only on demand when posting and retrieving updates.

The downside of non-HTML applications is that there are installation requirements on the client, which have been a problem in the past. However, .NET may also change this aspect of deployment considerably.

Windows Forms: The Most Understated .NET Feature?

The .NET Framework hype has focused mainly on its Web and Web Service features, but the framework also includes a complete GUI object model for building rich client desktop interfaces. The new set of classes exposes the Windows� GUI in a rich and consistent model that provides the power of C++ programming with the ease of development of 4G languages like Visual FoxPro and Visual Basic.

The .NET Framework also exposes a very large chunk of the underlying operating system with a largely platform-independent class framework. While this type of Windows application may not serve all types of applications (primarily shrink-wrapped, big-name-vendor commercial applications) it certainly addresses corporate and small business development and vertical market needs.

Windows Forms do not provide a revolutionary new concept?the features combine some of the best features of various GUI development environments, including Visual Basic, Visual FoxPro and Delphi/C++ Builder. However, what's different is that the environment is language independent (at least for .NET languages), consistent, and runs on a unified runtime that is installed and controlled by the operating system. As we move forward, .NET runtimes will be available on all Windows platforms.

Rich Framework keeps code size down

This has several implications. First off, form-based applications generate modules that are relatively small, because they include just the application code and no system components.

Because the .NET Framework is so rich and accessible from within applications, the amount of custom code will also be comparatively small (no more linking in of all sorts of different libraries to get basic features), which will result in smaller distributions that can be easily downloaded from the Web. The framework exposed by the .NET runtime provides so much functionality that formerly required third-party tools are no longer needed, reducing the size and number of files installed.

Easy Installation

Installation also is getting much easier with .NET's XCOPY installation paradigm, which refers to registration-free installs. The Registry is no longer required to specify locations for application components and the associated DLL hell that goes with it. This greatly simplifies installation and, in most cases, means simply copying files and creating a shortcut. The result is that an application will not affect system configuration in any way other than the disk space used, and uninstalling will be as simple as removing the files or directory tree.

You can also easily install an application with a small footprint from the Web with no installation hassles. .NET includes hooks to directly invoke Windows Forms-based applications from the browser (IE 6.0 only), which makes it possible to mix Web and GUI content very closely. This mechanism is still somewhat rough, but you can bet that we will hear more about it.

Security

A big issue with running ‘external’ applications is security. .NET intrinsically supports security settings in executable files and modules so that applications don't rely on taking over the operating system and invading the user's machine and privacy. This has been the biggest obstacle for Microsoft in the past with its binary interfaces being ‘native’ code that can wreak all sorts of damage on a user's system.

Now it's possible to lock out functionality or unlock certain features via security policies assigned to specific providers of software. This means you can block access for certain software while giving others full access to the system. There is a big tradeoff here?it's now potentially difficult to configure applications to use features they might need (like file access), and there are no tools yet available to provide this type of security setting as part of the installation process. Security configuration and the entire security model are not for the faint of heart.

However, for the purpose of distributed applications that communicate with a single Web Server via Web Services (or other Internet protocol) to retrieve data into a rich client GUI application utilizing all the bells and whistles, this type of functionality is available even in the most limited security model. I predict that much of the focus of ‘distributed’ development is likely to head in this direction.

Where Are We?

All of this functionality I have mentioned points to addressing the limitations of the HTML model by providing the same interoperability model with a much richer user experience. The .NET desktop and Web Services model has addressed many of the issues that have driven people to use HTML-based applications.

If you are a vendor selling packaged software and are worried about the Web's impact, you have the tools in .NET to integrate the Web into those applications easily without a complete redesign to HTML interfaces. In addition, even if you are a vendor playing around with the Application Service Provider (ASP) model, it applies to rich distributed applications just the same in using Web content from your Web service as with an HTML-based interface.

Is all of this going to be the end of HTML? Not a chance. There are still a lot of applications that require the full, broad-reach access that HTML provides, such as store fronts and most public Web sites that must run on every conceivable platform and browser. These types of applications will continue to do well with HTML, primarily because they are not heavy on data entry.

Many corporate applications, however, have different requirements; and we're moving towards more complex applications that must utilize Internet technology. HTML is not the way to move forward?either from a UI perspective or from a developer perspective?as complex HTML-based user interfaces tend to be much more time-consuming to build than equivalent GUI interfaces.

The promise of .NET for the desktop is very strong. Microsoft surely has a stake in keeping the Windows brand in strong use, and pushing the desktop forms engine can only help that cause. I think it's a good match for developers and end users alike, and we'll see much more of this as the .NET Framework becomes more ubiquitous on end-user computers. We're not quite there yet because it will take some time to get .NET ingrained in the Windows desktop, but you can bet that it's coming.

For comments on this topic, you can post a message at:

http://www.westwind.com/wwthreads/default.asp?forum=Code+Magazine.