No Rob, Dumb Terminals are a Dumb Idea

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”.

  • Number of technologies used.  It’s not enough to know VB or C#.  To create an even remotely useful web page you have to know HTML (tags and DOM), CSS, Javascript, and at least one programming language.  Put ASP.NET WebForms architecture on that and you add the concept of server controls, postbacks, and XML.  Now throw in multimedia or applets (Java or ActiveX) and it gets significantly worse.  Heck, I still haven’t figured out Flash and thousands of sites use that. 
  • 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 Links Lynx, 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:
    1. 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. 
    2. 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.

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.


 

11 Comments

  • Well, as much as I respect your opinions otherwise, the section on



    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.



    is just WRONG WRONG WRONG. As a corporate IT developer, supporting about 1000 field personnel with notebooks, I can tell you that since we switched from a windows form-based application to a web app, our distribution troubles have gone to ZERO. Whenever we'd have to update our application, we would have to make sure that each and every user got a new copy of our application. Mind you, I'm not talking about windows DLLs or custom controls or anything, I'm talking about changes to the application driven by the customers. With our asp.net-based solution, we deploy our changes once to the web server, and we're done. No more having to make sure that each user has gone thru the download-and-update process to make sure they have the latest version of our app code.



    The other points you make are good, but on this one, you really missed the mark. I do NOT miss having to ask our users, "what version do you see when the program starts up?"...

  • Yes, users at times may prefer winforms (for applications that require richer behaviors), and yes, scalable web applications are harder to build... but web applications ARE easier to deploy.



    1. Far greater range of ready devices

    The fact is that browsers are far more ubiquitous than even Windows much less .NET, and most of them have standardized to some form that it isn't too difficult to build cross browser apps.



    Consider any version of Windows (from v3.1 all the way up), Macintosh, Linux, various Unixes can run a decent web browser, and you've got a deployment platform of practically every _internet connected_ device out there.



    2. Zero installation of applications

    No need to worry about things like hard drive space available, or where to install the applications.. No need to worry about user permissions. Really, nothing to download, nothing to install.



    I visit dozens of sites a week--each a web app on its own. I love the fact that nothing installs on my PC when I do.



    For that matter, when a user should no longer have access or no longer needs the application.. zero uninstallation process.



    3. URLs make "integration" easier

    The fact is, it is real easy for a site like CitySearch.com to have URLs that can open up Mapquest.com because it will work. The folks at citysearch don't have to worry about whether mapquest uses a "compatible" smart client technology. Same goes for evite.com, amazon.com, ups.com, etc...



    There are many reasons for smart clients, but I would venture to say many others for web apps. Yes, think about your users, but I suspect the appeal of web apps is clearly because it doesn't have startup/installation costs, nor does it leave artifacts on your PC.







  • To quote Bill Clinton, "I feel your pain". But this problem can also be solved by Click-once web deployment. Now that's a relatively new technology so I understand that we have some healing to do from prior client installation hell, but let's not hinder forward progress because of last year's stubbed toe.

  • I've done both web apps and the human DNA mapping, and the DNA thing is easier.

  • Actually, "dumb" is not "dumb", "thin" or anything: "dumb" means that "I have not to install anything smart", but the smart things are already there ready to be used. E.g. I doubt IE or Mozilla may be called "dumb".



    Such dumb terminals are a great idea as far as a) one can rely on the network, b) the required client infrastructure is powerful enough, and c) it is available without needing of any additional installation



    a) is near a reality. b) is not true, but is evolving fast - what we need is a truly powerful platform; like Java applets were to be but weren't. And c) is not true because b) is not yet available, but when it is, the problem will be more competition among rival options (e.g. .Net / Java).



    I do not think AJAX is a good platform because I do not think JS is, but I hope there will eventually be a ubiquitous, powerful, robust and reliable platform.

  • I have never, never, never seen the sense in Citrix server setups for business use. Similar dumb terminal concepts (like Sun's) are even more hopeless. But their value in curing the deployment and configuration blues (and the elimination of malware) is undisputable. The bean counters will also vote for this if you shine a bright light in their eyes so they can't see the numbers properly.



    Now the small conceptual leap across the chasm to browsers also hurts my brain. A browser is a smart client app with wonderfully responsive local processing, scripting language, graphics, and extensibility. And it is remarkably useful for running most business back office and front office applications at minimal standardization cost. Better yet, new features and bug fixes can be deployed in Web apps at lightning speed, with simplified testing compared to unitary smart client apps.



    But it is amazing how many people (regular people) want to use all those keys on the keyboard. Their word processor and spreadsheet use the Enter key, why not that Web app? Where are the shortcuts? Their Tablet does cool things with a pen! They like the reponsive control and cool interactive graphics of the client app.



    So if you don't mind really standardizing the desktops and laptops of the business (and many businesses have been doing this for decades), the really cool stuff will be client this year and smart client next year. When they figure out how to include smart phones and PDAs in the mix, same thing.



    As I recall, Microsoft wants us to develop smart client apps that integrate into Outlook. Hmmm....

  • Are you serious? Web application development is much easier than WinForms. Counting the number of technologies involved is no reliable measure. Are you seriously advocating WinForms development because it excuses you from learning HTML? Declarative frameworks like ASP.NET hide most of the complexity of HTML (let's not forget it's only markup). Besides, if you need an advanced web page, find one on the Internet and copy its HTML!



    "What web based application fans might not understand is that this same argument [ubiquitous browser] is also why .NET based Smart Clients are a good idea."



    No. Not at all. I'd say it supports the converse.



    "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."



    So the easiest model is you're-on-your-own? No framework, no abstractions, no infrastructure to support common tasks. Servlets (or CGI for that matter) are the simplest model. But certainly not the easiest for development.



    Is this post a joke? Or am I way off?

  • It's not a joke. You are way off! :-)

  • While I hear your agreement for richer apps, the truth of the matter is that the larger to organisation, the more likely it is that your users will not have a workstation good enough to even support .NET - may not matter where you work, so it's a moot point.



    Add to that tight IS policies around restricting access to servers, single sign-ons and the like, and web applications offer by far the path of least resistance.



    As far as servlets for complex development... that's a bit like saying that programming was easier with punch cards.



    Take a look at a Java framework called Wicket. Straight HTML, and Java on the back end - it's VB for web apps. AJAX can be used, but the idea is that it's transparent as it's provided by the framework, all you deal with are server-side event handlers.



    I'm not saying that web development is easier than smart client, most of the time it's a pain is the neck, but the technology has a lot going for it and is moving ahead rapidly. Unless you have an application that specifically demands ultra-responsiveness (which most do not), web apps are going to be the easier sell.

  • Please repost this article five years later, when ALL computers are smart client enabled (not only Windows, please).

  • "...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 statement is like "your mouse stops functioning and you can't point and click. What can you accomplish? You can still use keyboard shortcuts...". In fact, both are critical failures and should be addresses immediatelly. Visual Studio development, if you are not working on your own, depends on a networked source control server. A CRM application alternative to salesforce.com can be used offline for a short period of time, until you hit the point where you need to collaborate with others. You can write that article offline but you will have to send it to the editor, maybe deadline is the failure day.



    Network connectivity is equally essential part of the business today. It's unacceptable to loose it, and I can't even print without it :)

Comments have been disabled for this content.