If you have been involved in a new software development project during the last five years - and if you read this article, chances are you have - then you have probably been faced with the question "Web application or Windows® UI?" And in the vast majority of cases, the answer to this question was probably "Web application." For modern, enterprise-wide systems there were simply many reasons and issues that made it hard to implement the desired feature set in a conventional Windows application and deploy it in a reasonable manner. At this point, the advantages and disadvantages of each application type are well understood, and decisions are easy to make. Or are they?
You can sum up the most striking feature of browser-based Web applications in a single word: Reach! You can build a single application and deploy it to a server, and voila, you have an application that everyone with access to the Internet can reach. This spans organizations, countries, and continents, and even the larger gaps such as operating systems.
If you want to break things down to a more granular level, you'll discover a number of detailed features that make browser-based applications such a great choice. Single server (farm) deployment is a great way to deploy an application to a large number of people because you really don't have to "deploy" to those people at all. Instead, people "pull" the application's interface down on their browsers. You don't really deploy or install the application on the client machines. Naturally, this provides a great upgrade path since only the server needs to be updated. The standardization of the browser-world is a blessing, and you can often compensate for the remaining differences by technologies such as ASP.NET. Certainly some HTML-based applications are more sophisticated than others, but by and large, users have fairly up-to-date browsers that allow for sophisticated functionality.
Browser-based applications also provide some interface features that can trump Windows applications (in certain areas). This may sound wrong at first, but consider flow-layout (document content that flows flexibly top to bottom) or the navigability of HTML applications (the Back-button is one of the greatest usability features that has become popular in the relatively recent past). The declarative (rather than programmatic) way of defining interfaces also has great advantages. Developers can easily define a label with a few bolded characters using HTML tags. Achieving the same programmatically (by setting properties, for instance) is a lot harder. Try to imagine the theoretical syntax this would require to see what I mean. Declarative programming also makes the on-the-fly generation of user interfaces very simple. Creating a survey-application with flexible questions in HTML is a snap compared to achieving the same in a traditional Windows application.
All That Glitters Is Not Gold
So the world is great and every application should run in a browser, shouldn't it? That was often the assumption, but this answer is not necessarily always right. Browser-based applications have several problems. Simply put, the browser is not good at anything that requires either a lot of control or functionality that HTML does not support by default. Windows applications allow a developer control at a very granular level (by creating or using custom controls for instance), but this is very hard to achieve in HTML, especially in a browser-and-operating-system-independent fashion. This problem area not only includes display issues, but it also spans navigation and application flow. An application that allows forward and back navigation is easy to create in HTML, but what if you want to disable the Back button in a Web application? Or suppose you want to create an application that features pop-up windows similar to Outlook, Excel, or many database applications?
In Web-based applications, control problems occur when a developer tries to create more than a simple standard interface. An application that has to access specialty hardware is a big problem. Try accessing a serial port with a control on an HTML page! It's even hard to access a folder on the local drive. Heck, even printing from a Web-based application with any accuracy is a difficult feat, and when it comes to truly sophisticated printing such as the MICR-line on checks (the encoded line at the bottom), even workaround technologies such as PDF often can't get the job done.
Oh, and how about that pesky issue of connectedness? Even though the major ISPs don't want to admit it, the world is not yet truly connected. You can browse to Amazon.com when you want to buy something from many locations, but this still is not possible when I am on an airplane where I have lots of time at my disposal (though this too is coming). While this is an annoyance for e-commerce sites, this limitation becomes more severe if you are a business man who wants to review customer details before going into an important meeting and you cannot connect to the Internet. If you are a maintenance person on your way to visit a customer but forgot to print out the address ahead of time, you might be in serious trouble because there is no Internet access from your car. And I have not yet mentioned truly mission critical apps!
Some applications simply cannot run in a browser. Can you imagine running AutoCAD® in a browser? How about Microsoft® Word? Do you think these are extreme examples? I beg to differ! Consider that the vast majority of database applications have some sort of note-taking capability (as one example). For instance, order entry screens may require description fields that allow users to enter additional information. Most description fields do not allow formatting in any significant way, but how much longer will that be true? How many mass text entry examples can you name that did not ultimately transfer to a more flexible approach? Consider e-mail for instance. Not very long ago, e-mail did not support formatting. Yet today, that is not the case anymore. And I see a similar transformation with all sorts of text entry, so a browser-based word processing scenario is not that far-fetched. Why wouldn't I want to paste an image into a description field? Or add a hyperlink? Or perhaps simply add a line in red or in larger type? But in HTML applications, there is no good way to edit this data, and there is no good way to modify HTML's capabilities to provide this functionality. The only solution is to borrow from fat-client technologies such as hosted ActiveX® controls, but ? bang ? there go two of the greatest advantages of browser-based applications: browser and OS independence, and deployment ease. In fact, ActiveX controls introduce DLL Hell, a deployment nightmare bigger than almost all other deployment issues. Java® applets might be a solution but with the virtual machine mess, they have all but disappeared (and as it seems for a good reason, but I will leave that for the reader to decide).
Smart Clients Close the Gap
Let's put aside the conventional wisdom for a moment and re-examine Thick Clients with an open mind. Windows Forms applications have been around for a long time (they aren't that different from DOS UIs from a paradigm point of view). However, WinForms applications have evolved. They have steadily made the programming model better, and as a result, they are now very competitive in many areas that drove us to Web applications several years ago.
One of the top arguments against Thick Clients is the deployment issue. "I have over 1000 workstations I have to update and that is not manageable with anything but a browser-based app" is an argument I hear regularly. However, with modern WinForms applications, this argument is no longer true! Windows apps can now also be loaded from the server simply by browsing to them. .NET 1.x supports this functionality with a few lines of code (loading assemblies from URLs is natively supported by .NET). .NET 2.0 will make this simpler with a feature called "Click Once Deployment." Using this technology, developers can deploy WinForms applications to Web servers and users can simply browse to them. The system then installs the application locally in a fashion that is at least as secure as the typical browser-based application. The system is also smart in terms of "trickling" the application to the client. This is an area that browsers handle very well: Even though an application may be huge on the server side, the user only receives the part of the UI that is needed for the current action. WinForms applications can mimic this by retrieving only needed components. You could argue that WinForms apps still need to download more data to launch, and that is certainly true, although after your users have hit a few pages on a site and they've had to go through multiple "micro downloads" of the HTML UI, the WinForms app probably has an advantage because previously downloaded components do not need to be re-downloaded. I also see this mainly as a bandwidth issue, and even though companies are not adding bandwidth nearly as fast as they need to, more and more bandwidth is becoming available. This will favor auto-deployed WinForms applications.
Microsoft's Click Once technology also handles deployment of updated versions very well. As you deploy new software versions on the server, the client will download and install the new version in the background, completely transparent to the user (and with a good amount of control by the developer). You've no doubt already heard of similar technology today through BITS (Background Intelligent Transfer Service), which is the auto-update mechanism that Microsoft Windows uses. In fact, developers can use BITS for their own purposes.
Windows "Longhorn" will make another huge step toward Smart Client deployment. XAML, the spiritual successor to WinForms (and Windows applications in general), offers rich-client features in Longhorn applications. However, there is nothing inherent in XAML that says an application needs to be installed locally. As the developer you can choose to have your clients load XAML apps piece-by-piece just like HTML applications. In fact, the same application that can be executed over the Internet can be installed locally.
One of the remaining problems with Smart Client applications is that they require a local runtime. A WinForms application is only going to run on a Windows computer that has the .NET Framework installed. Similarly, a XAML application is only going to run on computers that have XAML components installed (either Windows Longhorn, or a Windows XP PC with the required components). On the other hand, the .NET Framework now runs on most Windows machines, so that is not a big deployment hurdle for many business applications. If this concerns you, consider that browser-based applications also have the "runtime" problem. After all, Web browsers are only runtimes for HTML apps.
Smart Clients also close the gap in terms of UI flexibility. The only real UI advantage browser-apps have is the "flow layout" approach to HTML (and in the majority of cases, WinForms UIs are more powerful than flow layout). So far, Windows applications have used a "grid layout" approach (where all controls are positioned at certain X and Y coordinates and have a certain height and width). But is there anything inherent in WinForms applications that forces grid layout? Not at all! XAML and Avalon (the UI engine in Windows Longhorn) will fix this by allowing developers to choose between the two layout models. Better yet, developers will be able to freely mix grid layout and flow layout much more easily than can currently be done in HTML!
What about declarative programming? HTML can do it, but so can XAML (as well as third-party products available for WinForms 1.x). XAML will trump HTML by allowing the developer the choice between declarative syntax (using an XML dialect) and programmatic syntax that is more similar to the current WinForms approach. Once again, the best of both worlds!
I don't want to forget to mention the most obvious of advantage for Web browsers: connectivity. Browsers run over the Internet, allowing people around the globe to access applications. But connectivity is not exclusively tied to the Web browser. Modern technologies such as Web services and Service Oriented Architecture allow Windows applications to behave and work in much the same way as Web browsers do (with the added benefit of offline capabilities).
Ongoing Invention
One really nice feature about Smart Client development that excites me is that Microsoft is bringing true ongoing innovation in client technologies. Tablet PCs and ink functionality are a perfect example. Wouldn't it be great if you could add inking to Web browsers without adding Smart Client technologies such as ActiveX? Well you cannot. The W3C has frozen the HTML standard so don't expect significant improvements. This very deliberate move prevented many potential problems of having to deal not just with browsers that speak different dialects, but also with browsers that have drastically different capabilities. Putting an end to HTML innovation also prevented a scenario where almost everything one wanted to do was only supported by a very small percentage of all browsers. This was a potentially huge problem and a fix was needed. As important as it was to fix this issue, browser-based application UI improvements are now at a dead end. The only innovation revolving around HTML applications happens on the server and revolves around making it easier to write the same HTML.
Smart Client technology is different! Innovation is everywhere. I think we are on the verge of another big step in UI technologies. Longhorn's Avalon interfaces will make current Windows UIs look outdated. These new interfaces bring new ways of interaction that will allow anything from 3D UIs to pen-and-ink input. Handheld devices (Smart Client UIs of course are not limited by certain hardware or operating systems) are available in more variations ranging from the conventional Pocket PCs and phones to the more exotic devices like programmable watches. All of these devices are going new ways including the UI, while HTML remains static. How much longer can HTML compete and how good an investment are you making today if you put all your eggs into the HTML basket?
On a recent episode of the .NET Rocks! Internet Talk Show (www.Franklins.net/DotNetRocks), Billy Hollis talks about the medical field. Medical record management is a very interesting area for software developers with a lot of development right now (in fact, we at EPS Custom Software ? CoDe Magazine's owner - are also involved in this industry). Large players in this arena have made a huge investment over the last few years to move their products to Web applications. They are now ready to start deploying these applications but the market has moved on. Tablet PCs are very important in this particular industry and are beginning to see significant adoption. But how well are Tablet features (ink support) going to work in Web applications? Web apps can support ink input controls (through ActiveX), but this functionality requires additional deployment and quite frankly does not come close to working as well as in Windows applications. With that and other issues, more and more of the applications that have been recently developed in this field will have to provide Smart Client features that aren't easily supported by Web applications. Will the investment those large players made into HTML-based applications pay off? Let's just say I have not bought any of their stock...
More Productive Users
Web applications are also less productive than their WinForms counterparts. You may not think that it's a big deal to sit through entering an order on Amazon.com, but that UI is not a heavy data-entry application. If you have to use an application eight hours a day, five days a week, and your job is data entry (such as entering financial information), would you rather use a Web application or a Windows app? A simple comparison: Would you rather use Microsoft Outlook or Outlook Web Access? Perhaps it is a matter of opinion, but no-one at EPS/CoDe chooses to use Outlook Web Access over Outlook, even though we give everyone the choice. And no one on our staff does a lot of data entry!
Data entry applications have two main problems: the number of controls available and flow between data entry fields. The controls issue is big since you're stuck with the limited set of controls supported by .NET. Good data entry applications use a lot of textboxes, but if the user needs to format the input, things get considerably trickier. Also, many controls that are quite fundamental in Windows applications, such as combo boxes that allow for drop-down data selection yet also support simple text entry, simply do not exist for Web applications. Developers have to compensate for limited data entry features, which generally involves round trips to the server. Control shortcomings, server round trips (and the associated latency) and similar issues all add a tiny (or sometimes "not so tiny") overhead here and there that in sum is a considerable productivity drain (and added bandwidth will not reduce the latency problem).
The flow between data entry fields is no less of an issue. Back in the days of DOS and mainframe applications, the flow between entry fields was probably at its best. Users could perform data entry tasks without even looking at the screen. In Windows, data entry is not quite as productive because there are many more controls the cursor might jump to. Often, Windows applications force people to use the mouse to navigate around and between data entry screens. Over time we've managed to address many issues, but I still think that the data entry flow was better in DOS apps. Web applications push this problem to the extreme! Navigating HTML-based input forms without a mouse can often be next to impossible. To often the cursor jumps to elements such as hyperlinks or images. Most Web applications also do not support hotkeys and similar concepts. And how frustrating is it to click the "Submit" button only to see some error message and the user is forced to navigate back to the data entry form that the server has reset to blank?
The Real Cost of Deployment
It amazes me when companies use deployment cost as the number one reason to use Web applications. Consider this example: Let's say you have an application that you need to deploy to 1000 workstations. Perhaps it takes you 15 minutes to install a WinForms version of the same application on each workstation. Someone will have to invest 250 hours (less than two man-months) to deploy the application (assuming you aren't using any deployment technology, which would be dumb, but bear with me...). In the course of bug fixes and updates you may of course have to deploy multiple versions of the application throughout a year, so let's say you deploy five times to each user. That would be less than 10 man-months. Now let's say that those 1000 users suffer a 5% productivity decrease because the app is a Web application and not a WinForms application. That means that the equivalent of 50 users' time was wasted (because they are less productive). So you compare 50 man-years of additional expenses for a 10 man-month deployment benefit and try to convince me that the Web application is a better solution. If you use an advanced deployment technology like BITS or Click Once, you would have reduced the deployment overhead to much less, quite possibly limiting the overhead to only during the very first install, if at all! Even if you add staff to deploy the application, that is much more expensive than data entry staff (and how hard is it to deploy an app?), the calculation does not favor Web apps.
Of course, it also depends a bit on whose payroll the required staff is on. If the person(s) needed for deployment are on your staff, but the people using the app are on the client's payroll, then you might be tempted to save yourself the deployment time (I will ignore the issue of business ethics for the moment). On the other hand, if you can offer your client the opportunity to reduce their staff by 50 people, you may be able to charge quite handsomely for a "deployment service."
More Productive Developers
Productivity doesn't just concern the users. You must consider developer productivity! ASP.NET is a great product and it has made Web developers significantly more productive (and ASP.NET 2.0 will drastically increase productivity again). But even so, I would argue that it takes longer to build a data-based Web application than the equivalent Windows application. Take the combo box issue for instance: If you need a combo box on your Web form you will have to create an advanced control yourself. The control will have to be a combination of multiple controls. You probably have to add a secondary window that lists the available options. You will have to jump through considerable hoops to make things look like a combo box. And, and, and... And while you can do all of this, it is hard to get it done quicker than the time it takes to perform a drag-and-drop operation in the WinForms designer.
Another example: I recently had to build an application that supported drag-and-drop functionality and also allowed lasso selection of some on-screen items (a list of images). While this was quite trivial to do in Windows, can you imagine trying to create the same functionality in HTML? It can be done but it is considerably harder. A 30-minute task turns into several days of work.
Also consider the talent it takes to create that combo box in HTML vs. dragging and dropping the default combo box into a WinForms form. Consider the difference in skill between implementing drag-and-drop features and lasso-selection in Windows vs. the browser. Even if a developer can do these tasks in the same amount of time, the developer who can perform that task is likely to be significantly more expensive. How many lasso-selection features does it take before a 10 man-month deployment benefit is used up? Based on our own statistics at EPS, implementing browser-based applications is anywhere between 30% and 80% more expensive than the same features in Windows apps. (Disclaimer: This is anecdotal information and a research firm would have to take a much larger sampling of the market to get an accurate picture.) Furthermore, the chances of finding and hiring such capable professionals are much slimmer, making it tough to scale production. Not to mention being competitive with the prices charged by off-shore companies.
The Future of Browser Applications
So does that mean browser applications are on the way out?
No, I don't think so. Browser-based applications fulfill a very specific need. I like to call this need "public applications" or "occasionally used applications." A public application is used by an unknown public user. Many e-commerce apps fall under this category. Amazon.com creates their application (site) and waits for people to browse to it. There is no good way for the Amazon.com staff to deploy the app to their customers other than letting customers go to the Amazon.com site. Customers also want to start using the site immediately, and when they leave, they want no trace of the app on their system. Similarly, whenever I use my bill-paying application, I simply want to browse to a Web site and approve payments. I do not want to install software for this task, and I want to be able to do this from any computer I can get to.
A very specific target audience uses "occasionally used applications" and those applications don't get used very often. Suppose that you deploy a mission-critical application to a company and employees use it around the clock, but managers only want to peek at stats once a month. In that case, the managers ("occasional users") may prefer a Web interface they can browse to no matter where they are at and what computer they are on. In fact, the usage profile of occasional users are practically identical with public users, expect that you likely know who they are.
In either case, browser-based applications are a good choice, and they will remain a good choice in the foreseeable future. I simply can not see Amazon.com switch over to a WinForms client as their main way of conducting e-commerce (although Amazon.com has publicly demonstrated a XAML prototype as their storefront). So if your main skills include ASP.NET and HTML, don't worry! Your skills will be in demand for a long time to come.
However, ASP.NET should not be the automatic answer to the question of development strategy. Two or three years ago, there was no question that modern applications should be Web based and run in a browser. Today, applications still need to be Web based, but that does not necessarily mean HTML anymore. Web services and other technologies migrate almost all advantages of Web browser applications over to WinForms applications. Smart organizations will consider these new scenarios paired with the traditional advantages of Windows UIs before making the call.
