My friend and colleague Rob Howard recently posed the question on his blog, “Are Smart Clients a Dumb Idea?” In his post he recanted his earlier statements regarding the adoption of smart clients and now is convinced that web based applications written with the magic of AJAX are indeed the future. In this post, I hope to bring him, and the rest of the AJAX Hip-Mo-Tized world back to some semblance of reality.
Let’s start by dispelling a few myths about web based development.
1. Web applications are easier to develop
Easier than what exactly? Faster than light space travel? Mapping human DNA? Or perhaps just figuring out why people watch Reality TV? It might be easier than these but it’s certainly not easier than Windows Forms based development. Here are a few bullet points of where web development, even in ASP.NET falls far short of “easy”.
- Most applications don’t work in a strictly request-response paradigm. ASP.NET goes to huge lengths to overcome the basic obstacle of web development which is that it is a request and response based communication. We’ve added ViewState, SessionState, Application Caching, SqlDependency, Output Caching, and lots of other things all because centralized server based processing doesn’t hold state between requests. To create a robust, enterprise scale application a developer has to take on the burden of wiring together all of these various services just to be able to recognize that the user has already logged into the application. Now I will grant you that ASP.NET does a fine job of making it easier, but easier doesn’t mean easy.
- Web based interfaces are incredibly difficult to build accurately. Any developer who has written a widely deployed web based application has gotten that call from a user saying that some piece of the web page isn’t showing up or isn’t showing up in the correct way. Even on the same browser and version (more on that later) dozens of settings from screen resolution to font sizes can change the way an interface looks between users. This leaves the developer with either having to test the interface on as many browsers as their PC will hold or simply aim for the middle and hope for the best.
To summarize, consider this. If Windows Forms development was so hard, why did the ASP.NET team go to such huge lengths to make Web Forms work in EXACTLY the same way? The easiest web development architecture I ever saw was Java Servlets. You get a Request Object in and you spit out a Response. What happens in between is entirely up to you.
2. Web applications are easier to deploy
This myth is based on the concept that it’s easier to deploy an application to a server or web farm than to 1000 desktops. But that concept is another IT slight of hand that has people looking the other way while the same deployment issues that exist with local installations get solved through different means. Specifically here are some examples of the issues involved with web based deployments.
- Without the browser on those 1000 desktops, your web application is useless. Why then does it seem like no big deal to deploy a web browser? Simple, for the most part it’s already there. Windows (the ubiquitous desktop platform) includes Internet Explorer of some version or another. So many companies can leverage that browser and concentrate on the apps, or so they think.
What web based application fans might not understand is that this same argument is also why .NET based Smart Clients are a good idea. It wasn’t too long ago (and yet not long enough in my mind) that you couldn’t predict which of the various browsers your clients, even corporate desktop clients, would be using. Netscape ruled the world and IE was coming up quick, but there were others. I can still recall having to make sure that our applications worked with
LinksLynx, a text only based browser (Man, I’m old!). But since Microsoft started pushing out IE with every version of Windows this has become much less of a problem. The same thing will happen as the .NET Framework is included with every new version of Windows and on Windows Update. And here’s another thing that many people haven’t considered. Other companies, I won’t mention any specific names but one of them has the initials HP, distribute the .NET Framework on their new PCs because the custom software they use to annoy you with advertising is written in it. Windows Media Center, which is growing more popular every day, requires the .NET Framework. With more than 120,000,000 installations, it’s unlikely that you really need to worry too much about the fact that a Smart Client application requires the .NET Framework be installed. So relax, it will be there when you need it and if not, it’s a pretty simple install.
- Browser incompatibility. I’m not just talking about the differences between Internet Explorer and FireFox, which is a big enough problem. I’m talking about the differences between IE 5.5 and IE 6.0 or even IE 6.0 with HotFix A versus IE 6.0 with HotFix B to say nothing of Windows XP SP1 versus XP SP2. These can be hugely time consuming to track down and fix and require you to get deeply acquainted with the innerworkings of your client PCs. This is not easier deployment, you simply have shifted the issue from one of application deployment to that of browser deployment.
- Production servers are usually all or nothing deployments. Many organizations prefer to release their software in a controlled manner through one or more pilot releases. Pilot releases with a web based application can be extremely difficult. You have to either give the users a new URL, thereby breaking any saved links they might have, or you have to play DNS/Routing games on your network. Then, when the application is ready for widespread distribution, the pilot group has to change their URL again or more network settings have to be changed.
- Development is rarely done on production servers. Most ASP.NET developers create their applications, from web interface to database, on their local machine. Then they go through whatever deployment and testing process they go through and the application ends up on the production server, where it promptly stops functioning. This can be for a number of reasons such as:
- Incorrect Server Configuration
Between IIS and web.config there are dozens of ways to misconfigure an application. A seemingly simple change like forgetting to bump the max System.Net connections or using different MachineKeys in a web farm can cause a web based app to crash that worked fine in development.
- Performance was not adequately tested
Too many web applications are developed only to have to undergo massive overhaul when put under production loads. During development it is difficult for a developer to simulate how an application will react to things like 90% of the users signing into the application within the first half hour, or users leaving their browser windows open when they go to lunch only to find out that their session has timed out when they come back.
- Incorrect Server Configuration
3. Web Applications Cost Less
This is another one of those statements that doesn’t require any actual numbers to back them up. It, like the earlier myth, is based on the concept that one big-time server is cheaper than 1000 desktops. This argument would make sense if the desktops weren’t already out there in corporate America, waiting to be used. But they are. Most of the desktops being used by your average business worker get less exercise than I do (which is damn little exercise, but I’m planning to change that). And yet, companies continue to buy new quad CPU servers with SANs and clustering for every new web application they deploy while relegating the desktops to dumb terminals that know how to run Outlook and IE.
Getting back to Rob’s comments let’s look at a few other of the things he says while under the influence of AJAX.
“The only offline application I care about is email and that problem has already been solved in Outlook.”
Okay Rob, so consider this. You are in your offices at Telligent working away and you lose network connectivity. Not just Internet, but the internal network too. What can you accomplish? You can still continue to develop CommunityServer, your award winning ASP.NET based CMS. You can still write articles for MSDN or even TheServerSide.NET (Please, Please!!!) While a nuisance it won’t slow you down all that much. Now consider a branch loan officer. He’s got a line of people waiting to complete applications for new loans and is thinking about the boat he’ll buy with the commissions when he loses network connectivity. Unfortunately his company decided to go for the “ease of development and deployment” myths and created a loan application system that is web based. He can kiss that boat goodbye to say nothing of the customers.
We computer nerds are not good examples to use when thinking of the “online/offline” question. Most of what we do is offline. I’m even writing this rather lengthy blog post offline in Word. If I lose network connectivity I can save it and post it tomorrow. But it’s companies that are building applications that rely on the browser and network connectivity that will suffer if their decision makers don’t understand the importance of being able to continue working while offline.
“Watching someone like my wife use a computer makes me realize that she, as a pretty typical user, does about 95% of her computer usage through the browser”
Why is that? It’s not because the browser is the better solution it’s because the technology to allow Amazon to create an interactive catalog that you can browse while offline hasn’t existed long enough for them to see how useful it would be. Imagine if JC Penney decided to create an application that would let you scan in a picture of yourself and then shop for clothes by superimposing the image of the clothes onto the picture of you? That would be a very cool application (Hey Chris Anderson, if you ‘re reading this how about a nice XAML demo of this?).
“and then read about some of the new "web enabled" offerings coming out of Microsoft like live.com”
See my earlier post and you’ll notice that Microsoft’s Live services are more about smart clients than browser based applications. Web 2.0 (a name so cute it makes me want to hurl, but they’d just name it Dinner 2.0) isn’t about a resurgence of websites that almost mimic functionality of Windows 3.1. It’s about the services that can be offered over the Internet and delivered through a number of means, with smart clients being (IMO) the best possible platform.
“Why should you care about writing smart clients. You probably shouldn't. If you can write it as web application do it.”
The reasons listed above are why we as computer geeks care about browser based applications versus smart clients. But the real reason that organizations should care about smart clients is for their users. Users want and deserve the best applications that we can give them. Applications built on technology from 10 years ago (even if it does have a snazzy new name) won’t keep them fooled forever.
So for any of you readers out there who may be wondering how to decide which type of application to write, here’s my advice. Think about your user and Do What Works Best For Them. I’m betting it will be a smart client application.