Paul Ballard made a post advocating the use of Smart Clients versus Web Applications. I don't agree with everything he is saying, but I thought it was pretty well written.
I will admit, I know next to nothing when it comes to Smart Client applications, but I think he is over-generalizing the problem. It is true you need to know several technologies in order to create web pages, but I would argue that the same problem holds true (maybe on a slightly smaller scale) for really well done Smart Client applications. Take a scenario where you don't control the database servers or access to them. Your Smart Client application cannot directly access the database server through a firewall. This means you are required to create a Service interface using some sort of Web Services. At the minimum this means you will have to know C# or VB, XSD, and WSDL. You still need to learn the Windows Forms development paradigm, which is going to be a learning curve for most of us who have been doing web development for so long. I'm not saying it is overly difficult, but it still takes some getting used to. If you are using Web Services, you still have the "using state over a stateless protocol" problem. For performance your application would probably still want to use the caching mechanisms that Paul described. Web interfaces are incredibly difficult for most developers to create. Web interfaces are difficult to build for most developers to build, I will concede that point. I have found with a really good ui/client side person AND a developer they can educate each other on the "best" way to accomplish things. I think of it as client side pair programming.
Web applications are pretty dang easy to deploy imho, but I understand that Smart Client applications are pretty easy as well. I haven't worked on very many public facing websites for most of my development career. Everything I have done seems to either be internal or a Line of Business application. In most of these cases, I get to control the browser, so I haven't felt as much pain there. It seems like the reasons Paul mentioned for performance problems with web applications would be just as pervasive, that is more of a developer discipline problem to me.
As for the ajax/remote scripting stuff, I am not a huge fan. I will leave it at that. As for the online/offline paradigm, I think it really does depend on your users and your capabilities.
In a perfect world, it would be nice to develop every application with offline capability, but realistically, do I care if I can browse the JC Penney's catalog while my internet is down? I can't buy anything while the internet is down =)
I will agree with what Paul's advice is...You should think about your customers. I am just not making the same bet Paul is.