Guest Opinion

Good Riddance to Browser-Based Apps

Smart clients will replace browser-based applications because they offer both a better user experience and a way to write more secure applications.

• By Billy Hollis
• 07/01/2005

You'd have to be deaf not to hear the drumbeat for smart clients in recent months, especially if you're a Microsoft developer.

Microsoft has had an epiphany—not only are smart clients good for users, but they're good for Microsoft as well, which owns the desktop. Smart clients were the subject of several tracks at recent VSLive! conferences and other developer-related conferences. No doubt they will be emphasized at Microsoft Tech•Ed and other Microsoft-related developer events throughout the rest of the year.

The knee-jerk reaction of some developers who hear this buzz building is to dismiss it out of hand as marketecture or simply the latest fad that will be passé by the time anything real comes out of it. I understand that reaction; it's smart to be skeptical of grandiose claims. We've all seen the cases in which Microsoft announced a new product direction with great fanfare, only to change course quietly a few months later.

But smart clients are the real deal. I've been building smart-client applications since the advent of .NET, and demand for them is building exponentially. Like a lot of new terms that come into vogue, smart clients mean different things to many of the people who use them. For the sake of simplicity, let's use Microsoft's definition: Smart clients are easily deployed and managed client applications that provide an adaptive, responsive, and rich interactive experience by leveraging local resources and intelligently connecting to distributed data sources.

Why smart clients? Decision makers are starting to realize that the browser sucks as an application platform. Smart clients offer a significantly better user experience than a browser-based app. This saves money through higher productivity and lower training, on top of increasing user satisfaction. Plus, a properly written smart client is more secure than a traditional Web client, on both the server and the client. On the server, a Web client is subject to a variety of hacks that a Web service is not. The smart client can check for many different kinds of conditions before giving a user access to information, from fingerprint scanners to pen signatures on a Tablet PC. As a developer, you can encrypt the data for transport in many different ways. This means that the server, which holds the most important data, has a much smaller surface area for attack when talking to a smart client.

On a traditional client, browser-hosted data is vulnerable the moment you look at it because of browser caching. Plus, the data can be cut and pasted to anything on the local machine. There are some browser hacks that attempt to mitigate these problems, but all of them have holes big enough to drive a tank through.

With a smart client, you can set up an app so it never caches the data locally. You can even prevent its data from being transferred to another app through the clipboard.

That said, developers must be educated on how to create a proper architecture before they can write secure smart clients. Poorly done smart client implementations leave open many potential holes to exploit. Of course, this is no different from browser clients that are the source of mountains of spyware today.

Smart clients will succeed because users want them. Users want slick software that figures out how to help them do what they want. Users don't want software that lets them enter data for 15 minutes, only to throw up a "server busy" message and throw that data away.

It might be Windows Forms, it might be something else. But something is going to displace the browser because we've taken HTML as far as it can go. I can see next-generation browsers supporting a new protocol that lets you write smarter clients that take advantage of local resources. It's true that any technology that uses local resources will introduce security issues to consider; however, users are going to demand the use of local resources because the "mainframe writ large" model of HMTL-based browsers was always a kludge. It was never destined to be the dominant technology for user interfaces because it does the job so poorly. Smart clients offer a way out of this kludge, and users will demand we exercise this option.