Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm preparing a presentation for my team that lists the various technologies we could use today for our business applications.

We have been historically building HTML applications (ASP and ASP.net) for the last decade and as part of the introduction I wanted to explain why we moved from Windows applications to HTML.

Our environment is:

  • Business applications (OLTP mainly)
  • Intranet
  • Windows clients only
  • Complete control on the clients' configuration (OS version/browser version/deployment of plugins...)

The only reason I could find is that in the late 90s, deploying a windows client application could end up in a mess (many different versions deployed, dll hell...). Web servers allowed deploying the application once and have all the clients updated simultaneously. The price to pay was a big loss in user friendliness and responsiveness and complexity added to the development job.

There are alternatives today (ClickOnce, Silverlight...) but a lot of my colleagues are now totally committed to HTML and the technologies that come along (Javascript/Ajax/Jquery/Css...).

I'm totally convinced HTML is great for Internet applications. My question is: at that time (late 90s), were there other reasons to move to HTML in a Windows intranet environment than just fixing deployment issues? (because it was trendy is not a valid answer...)

Thanks in advance

share|improve this question

4 Answers 4

up vote 5 down vote accepted

I would hope that by a decade you have a litany of your own reasons. Typically an intranet site best replaces a class of application known as client/server. There are some aplications that just don't make the transition as well. The following are my own reasons for promoting an intranet over a desktop application:

  • The deployment story. DLL Hell is just the tip of the iceburg. When you have thousands of clients across multiple timezones and even national borders, coordinating a client/server release is very daunting. Updating a server cluster takes away all of those concerns.
  • Client/Server apps are much more complicated than an all server solution. You have to deal with client compatibility with mismatched versions. If you are fixing a serious bug couldn't be done to work with prior clients, you need to provide an error message the average user could understand. Data synchronization issues also become more complex, particularly when you don't have control over all the system clocks.
  • The web is more maleable, and users tend to be more open to innovative ways of interacting with a web site than they are in desktop applications. In some ways, the expectations are less rigid for a web application than for a desktop application. (user expectations still exist, mind you).
share|improve this answer
    
Thanks for your reply. In your final argument, are you thinking about such features as text copy/paste. Doesn't less rigid also mean that the user could do things he should not do? –  vc 74 Jan 18 '11 at 13:12
    
A bit more general than that. You have much more leeway over what a user would consider is a button or something to be clicked. Because of the restrictions of HTML, a user's expectations tend to match experience more often than a desktop application. –  Berin Loritsch Jan 18 '11 at 13:20

Ok, I think you're asking one thing, but want to know the answer to another. So please correct me if I'm misreading your intentions.

You're asking why HTML was chosen as the prefered development platform a decade ago, but you seem to be asking whether HTML is still a worth while platform for application delivery now.

A decade ago there was a lot of talk of everything moving to the cloud. ASP's were the hot property (That's Application Service Provider, not ActiveServer Pages) and it may be as simple as someone in your company wanting exposure to the next hot thing. Berin's answers above are good reasons too ;) Trouble is, if you don't know, you don't know, so it doesn't really matter.

If you're asking whether it is still a viable and appropriate platform, well that entirely depends on what you're attempting to deliver. If it is clearly failing somewhere in your organisation, or if you can see a need or benefit some other technology can fill, you should be able to make a technical case for it, even if you can't make a financial one.

So reasons to use something like WPF, well it gives you a really rich user experience, it makes it easy to co-opt local resources, and a WPF application will still run on a laptop while the user is on a train going through a tunnel.

Ian

share|improve this answer
    
Thanks for your answer. You're absolutely right, I wasn't clear enough on that point. The goal of my presentation is to show that today it is possible to deliver rich applications whilst still benefiting from the web applications deployment mode. BUT the question I ask here is really about why we decided to move to HTML apps in the past. –  vc 74 Jan 18 '11 at 13:34

You should remember that back in the late 90s, the Windows world was a bit fragmented. You had the DOS-based versions 95 and 98, lacking stability and security, and you had NT, having a few compatibility problems (drivers, DOS-based software that wants to own the machine etc.). The great unification, i.e. Windows XP, was yet to come.

In that situation, it wasn't unreasonable to place your bets on a technology that wouldn't break with new versions of Windows.

share|improve this answer
    
Good point. Thanks. –  vc 74 Jan 18 '11 at 13:15

Supporting the application is far easier when it is web-based:

  • It is impossible for users to still be using an old version of your software;
  • Corrupt software installs are impossible;
  • Software problems are rarely caused by operating system issues.

The first point is obviously a deployment issue. The second one could be a deployment issue (ie. broken package gets sent out). However, it could also be caused by users ("Running out of space... I know, I'll delete some files!") or the operating system ("I'll randomly change permissions on a bunch of files because I'm Windows XP, and that's just what I do").

This last example brings us onto the third point - operating system problems. They could include:

  • Permissions for parts of the application get mangled;
  • Registry gets corrupted and the app stops working;
  • User settings get deleted/corrupted and the app stops working as expected;
  • Shortcuts get deleted/moved and the user can no longer find the application;
  • Network problems. Contrast "The program loads but it won't show my data" with "I can't open the website, or even Google" from a support point of view - one is obviously a network problem, whilst the other could be anything;
  • Essential system DLLs required by the application disappear;
  • User installs Super Malware 3 Turbo which soaks up 100% of their CPU time and memory, causing your application to run slowly and crash at random.

There are dozens of things that can go wrong with Windows that can affect the performance and stability of your application. Users will typically complain about your software if it crashes all of the time, even if it's their fault for installing junk on their PCs. On the other hand, if their web browser doesn't work properly, your website is obviously not the cause of the problem.

Web software can be cheaper, too. Desktop software has more extensive hardware/software requirements: "Must have 2GB of RAM. Must run Windows 7. Must have a 2GHz CPU. Must have Whizzy Graphics Card XY." Web software has just one requirement: "Must have a web browser." (Or, if you didn't do it properly: "Must have IE6.")

Another benefit is migrating users between computers. Suppose a computer breaks and the user's settings were stored in the registry. How do you get those settings over to the new computer? Contrast that with the web experience - access the same program from any computer in the company and your settings magically reappear (they're stored in the database).

share|improve this answer
    
Thanks for your answer. I think you'll agree that points 1 and 2 are precisely deployment issues which I agree were solved at that time by moving to web technologies. What do you mean in the 3rd one? –  vc 74 Jan 18 '11 at 13:47
    
Made some edits to address these points. –  Ant Jan 18 '11 at 14:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.