There is no single answer to your question. It's a continuously evolving environmental balance of capability, capacity, and need. More importantly, the line constantly changes, and good application architects keep tabs on where that line sits.

Remember the first efforts at using applets to provide desktop-like functionality in Windows applications? I worked at Lotus at the time, and I really tried to use Components (remember them?). They were difficult to use, unstable, and ultimately unsuccessful. Presently, we're seeing some of the latest attempts with Zoho and GoogleDocs, and while these web applications have considerably improved in feature, form, and functionality, they still come nowhere close to full-fledged desktop applications. Footnote display...nope. Integrated multi-page layout...nope. To take it one step further, I have yet to see any web application come close to mastering full CAD/CAM, with interactive finite element analysis. Word processing is one thing; highly complex, graphically intensive CAD is another.

Yet the dividing line is not always so simple to see. I recently worked with a Fortune 100 company that created a web-based configuration system. Using the web environment they purchased, it required nearly 30 seconds per user selection. It lacked a dynamic graphic interface, and it consumed megs/user to run. (And the platform is from one of the biggest DB vendors out there.) Centrally managed rules, consistent dataset...that's what the business thought initially was important. But when European users would abandon the system after 2pm, because US East Coast users would saturate the system, that suggests something just not designed right. (The system, BTW, was deployed on robust hardware, but frankly, nothing would have been robust enough.) Counter that with a desktop-based application, using a rules-engine, with a rich graphic user interface, and response times in less than 1-2 seconds...obviously, sometimes, you have to focus on what really meets the users' requirements not the marketing spooge or "design by magazine" approach that many CIOs follow.

Today, Web 2.0 tools and designs have shifted the expectations of Web-based applications. A good application architect considers the user's expectations, the performance requirements, the communication and real-time connectivity, the usability, and the computational intensity of the business goals. Only by balancing all of these constraints and requirements against the company's goals, the costs, and the deliverables can productive systems be created. Yesterday, the solution may have been desktop applications, tomorrow, perhaps a web application. Good architects know both environments.

This guy not only piles it high, he makes it talk. The judge should prejudicially dismiss the suit and have him pay all attorney fees. He's suffered no damage--at least yet, Blair notes--but more importantly, his damage will be minimized during replacement (hey, not the best scheme, but he does not loose the value of the phone).