Guest Opinion

The Smart Client's Revenge

Clients might insist on a Web interface, but a smart client's benefits can often outweigh those of an ASP.NET-based app.

I love the Internet and the ability to reach millions of people, regardless of the browser and the operating system they use. I have created my own share of Active Server Pages and then ASP.NET applications, and I find them both fascinating and challenging.

Notwithstanding the hype about and the benefits of the ASP paradigm, I never really bought the idea that Web programming can replace more traditional Win32 business applications. Everywhere I turn, I see customers who decide that their application must run in the browser "because it's cool, trendy, and/or fashionable." But is this an informed decision?

Web-based business applications do present several compelling benefits, including multiplatform compatibility (they work on any operating system); simpler security (it's more difficult for them to harm the system); and ease of deployment.

But let's look at these advantages more closely. True, you can make your Web application work with any browser running on any operating system, but only if you avoid using advanced ASP.NET features such as smart navigation, DHTML support, and absolute positioning. Even if you stick to HTML 3.0, you should test your app against several versions of the two or three most popular browsers, with and without JavaScript and cookie support. It's no surprise that when you factor in all these requirements, most ASP.NET solutions are designed only for intranets and extranets, and only for Internet Explorer. Goodbye multiplatform compatibility, at least for serious business apps.

Security has its own issues. With all the browser vulnerabilities reports, security alerts, and cross-site scripting attacks, Web security looks more like a myth and less like reality. A Web application is as potentially capable of harming the end user's system as a standard Win32 application, especially if you rely on ActiveX controls and components for nontrivial tasks.

At the end of the day, the only serious and undisputable advantage of Web applications is ease of deployment. Users don't need to install anything to run your software, assuming they're lucky enough to have already installed one of the browsers you decided to support.

.NET smart clients (Windows Forms over HTTP) represent a great alternative—and often a better alternative—if you're building an intranet/extranet application that requires Windows on the client and can be deployed easily. Smart clients require the .NET runtime on the client, which users can get in Windows XP SP1 or can download from Microsoft's site. Like ASP.NET apps, smart clients support automatic updates: The next time the user runs the application, its executable downloads transparently to the client machine.

Smart clients can also be much safer and more trustworthy than Web apps. Code Access Security (CAS) is more granular than Internet Explorer security, so end users can grant smart clients only the permissions they strictly need and refuse all others.

Smart clients have many benefits that Web apps won't have in the foreseeable future. You can develop them faster, debug them more easily, and use them to provide a richer user experience with less effort. Ask an ASP.NET programmer what it takes to implement basic features such as quality printing, drag and drop, and bullet-proof modal windows. Perceived speed is also faster with smart clients because they require no postbacks and less data travels along the wire (once you download the executable).

I'm also glad to see how Microsoft has improved smart clients with the introduction of the ClickOnce technology. The big news is that .NET 2.0 smart clients can work offline, so users won't strictly depend on Internet connectivity until they need to download or upload data to the server. Also, ClickOnce supports multiple versions of the same application, which ASP.NET doesn't—at least in any easy-to-implement way.

It's highly unfortunate that the excitement about the great features of ASP.NET has obfuscated the virtues of smart clients, to the point that many .NET developers aren't even aware that the smart client option exists. Yes, ASP.NET is the only reasonable choice when developing a Web site. But the next time your customers ask for an intranet-based application, do them (and yourself) a favor: Give smart clients a chance.

About the Author

Francesco Balena has authored several programming books, including Programming Microsoft Visual Basic .NET Version 2003 [Microsoft Press]. He speaks regularly at VSLive! and other conferences, founded the .Net2TheMax family of sites, and is the principal of Code Architects Srl, an Italian software company that offers training and programming tools for .NET developers. Reach him at [email protected].

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube