The company I'm currently working for hosts a web application. The application uses various bits of downloadable componentry to perform fie upload and extremely trivial image manipulation that run on the client side.
Why use web applications over fat applications? The obvious reasons:
Ease of deployment - Web applications don't require deployment of client software to end-users.
Cross platform - Since the application environment is a web browser, and web browsers conform to certain standards, creating a cross-platform web application is easier than creating a cross-platform fat application.
Instant distribution of application updates. Since the software is all centrally contained on a controlled web farm, upgrading the application or applying simple patches is much easier than requiring thousands of clients to update their software.
The problem is, NONE of these are true statements once you start dealing with downloadable components with .Net:
Ease of Deployment: We pay a support person full time to diagnose issues with spyware, adware, malware, and even anti-spyware, anti-malware, and anti-virus software blocking the installation of our components. Why? Because downloadable componentry is such a great vector for infecting computers, and the people who write such applications are very protective of their turf. So once you get a piece of nasty code installed, the first thing it does is secure your system against other invaders. Or from our legitimate, signed code. Anti-spyware software does exactly the same thing, as part and parcel of securing your computer it prevents our components from downloading. We have no ease of deployment. Every deployment is a risky venture. "Oh, but we have a tightly controlled corporate environment where we strictly control what software everyone installs on their computers!" Fine. Install a fat app then. You are gaining nothing by writing a web application, if you have that level of sophistication, you can easily distribute fat applications to your clients, you can do it in a more controlled manner than having them visit an intranet web site, and you can update more precisely.
Cross Platform: So you write a .Net client-side component and expect it to be cross platform. Heh. Very funny. Once you start writing in .Net you lose any pretense of cross platform capability. "Oh, but all my clients are running Windows anyway". Fine. Write a fat app then. Writing things to run inside Internet Explorer is just holding you back, you gain nothing from artifically limiting your architecture to Internet Explorer.
Instant distribution of updates. Our component uses .Net 1.1. If you download .Net 2.0 and access our site, it will crash your browser. So, no, you don't get any updates, and not only that but if you use another vendor's software that requires .Net 2.0, we have to provide you with a "special" patch. Not only are .Net 1.1 and .Net 2.0 not compatible with each other, they seem in our case at least to be actively hostile towards one another, to the point of crashing Internet Explorer. Yes there are workarounds. Unfortunately, our .Net componentry is so sophisticated we have a long development and testing cycle to prevent QA problems form effecting our customers, so we can't update it either.
Using the web server to pass data back and forth, so you need to have a web application? Use SOAP. Transfer data over port 80 to a web service running on your server. Heck use RPC over well defined ports. THAT'S WHAT IT'S THERE FOR. SOAP is a crutch to get out of doing paperwork to get real RPC working through a firewall, and a dangerous crutch to boot, it simultaneously obfuscates your messages so your intrusion detection software can't properly monitor what's going on AND it eats a huge amount of bandwidth.
My favorite part of this was the discussion I had with one of our developers. It boiled down to this: the bane of a web application programmer's existance is the BACK button.
Look. If your application can't deal with a back button, then it shouldn't be in a web browser. Period. Fix your application, don't tell your support staff to tell your users to not use the back button. It's like telling someone not to use the backspace key on their keyboard, and almost as effective.
So why do developers and desginers focus so much energy and effort towards writing web applications instead of fat applications?
Web applications are the new hotness. Fat applications are old and busted. In other words, resume buffage and increased chance of people with the word "Chief" in their title buying into your product and authorizing your budget. So compromise your architecture and the usability and maintainabiltiy of your software in order to get buy-in from the chain of stooges.
Overcoming corporate inertia. In order to drop a new application onto your company's PC's, you have to go through rigorous testing of functionality and interoperability. You can probably circumvent a lot of that by using a web architecture instead, where you can download components onto computers and be guaranteed they won't crash any other fat applications. Unfortunately, you still have all of the version incompatibility problems of a fat application environment, so you're really just cheating to get around the barriers put into place by people trying to provide a supportable environment.
Overcoming Corporate Inertia, Part 2: Using anything besides port 80 traffic on the public Internet would require getting your firewall rules adjusted, while using SOAP gets around that process. Of course, using SOAP also bypasses a lot of the intrusion detection capabilities of your firewall, so you're essentially circumventing the people trying to keep your network safe.
Looks like the main reason developers are biased towards web applications is because corporate IT bureaucracies are broken.
So can anyone explain what I'm missing here? Why does .Net componentry suck so bad, and why do people still use it instead of .Net fat applications, or just plain old fat applications in general?
How do we fix it?
Quit using your wrench as a hammer. Web applications have a lot of advantages, specifically ease of distribution, update, and cross-platform capabilities. If your architecture requires you to use techniques that abrogate those advantages, then don't use a web application. If you require .Net client-side componentry, you are no longer cross-platform. If you have a very stable and capable application deployment mechanism, you don't need easy deployment, you already have it. If you have a long, involved QA process for making server-side changes that turtles along at the speed of smell, then making the application easy to update frequently is a waste of effort.
Legacy Comments
|
Stephen Moore
2006-06-13 |
re: The Paradox of Web Application Development
I would agree with you that if your website is using downloadable .net components, there isn't much difference than having a .net fat app. And .Net makes fat apps a lot easier to deploy than pre-.Net. Just put everything on a network share, and use a loader app that people run that points to the actual .exe so you can deploy a new version while people are still running the old one.
However, I think that the majority of web apps are fine as web apps, and don't require downloadable components. If your web app doesn't require downloadable components, then a web app is a lot simpler to manage. There are so many different variations on individual boxes (in our corporate environment, we often have to think about how to handle terminal server clients specifically) that a web app is just simpler.
It seems awful weird to me that you're having problems running .Net 1.1 and .Net 2.0 apps side-by-side. We have both apps running side-by-side in the same environment and they work fine. Could you elaborate a little more on that point? |
|
jarilo
2006-06-14 |
re: The Paradox of Web Application Development
There is something about BACK button...Do people have BACK button in their old, fat, desktop application? Is there such functionality? Or do that oldies have bookmark functionality (another 'problem' with ajax application)? Backspace and BACK button is not the same. You don't have additional navigation in that fat desktop application which is independent from core application...
|
|
Napoleon9th
2006-08-18 |
re: BACK vs Backspace
The lack of the back button in old apps is similar to the impossibility to erase written text on a typewriter... |