I've been thinking a little more about Chris' presentation and the whole "smart client" thing in general. It's definitely very cool from a purely technical perspective, and the possibilities if you're already using a WinForms application are pretty exciting.
You've now got a Windows application with the same deployment model as a web application and sandboxing with partially trusted code for free. Chris also demonstrated lazy loading portions of the application using remoting and/or reflection, which is very, very cool (but, of course, is already an inherent feature of a web application).
That being said, the standard case for using so called "smart clients" is that you now have many of the motivations for moving to a web application in the first place - most notably, of course, being deployment - and at the same time you can deliver a richer user interface easier.
As I've started to play with each, though, I noticed that there are still compelling reasons to use one or the other, depending on the application and other considerations.
In my mind, some of the advantages that web application has over a WinForms application include:
-
Resizing and scaling. HTML provides much better native support for resizing and handling layouts that scale at a particular percentage. In HTML, I simply use the % on the width for a table, and the browser handles the formatting. In WinForms, you have to write custom resizing logic to do this.
-
Session state. Session state, ironically, is easier to use (from the developer's perspective at least). Granted there is a lot more plumbing required for maintaining sessions over the stateless HTTP, but from the development perspective you have this global Session hash where you can save your state. When dealing with WinForms, there is no central store for this information across forms. Sure, it's simple enough to roll your own, but the point is you have to roll your own.
To take this a step further, when using State Server or SQL Server to maintain session information, you have a truly persistent session. The client browser can crash or one of the web servers can go down and you don't lose conversational state. With WinForms, if your application crashes, you theoretically lose everything (unless, of course, you again roll your own solution for making this information more persistent using IsolatedStorage, etc).
-
Policy. Policy deployment can be an issue in the enterprise. There is no built-in, automated way of distributing policy files to individual machines, at least that I'm aware of. This may not be a big issue as policy is unlikely to change very often, but it can still be a sticking point. Another approach might be to write a custom ConfigurationSectionHandler to help
-
Platform reach. As Chris already mentioned in his presentation, you confine yourself to client machines that are running Windows with the .NET Framework installed (at least at this point in time). This typically doesn't matter a whole lot in the controlled intranet environment where smart clients have their most value, but there may be scenarios where this is problematic.
Then again, there are advantages that WinForms has as well.
-
Certain rich controls. Anyone who has tried to write a DHTML version of the toolbar menu knows full well that these things can definitely get messy in client-side JScript. It might be different if ASP.NET provided a nice control for this, but at any rate, using the built-in WinForms control is infinitely easier than building your own. It gets especially tricky when you have to deal with "windowed" controls - that is, SELECT, IFRAME - which will otherwise show through a DIV. You either have to use a windowed IFRAME yourself, or manually detect any such windowed controls and manually show/hide them.
-
Performance. No postbacks, for one.
-
Offline mode. Chris also mentioned this, and I think this is a big one. Writing a WinForms application that can run in disconnected mode is infinitely easier than writing an ASP.NET that can run in disconnected mode.
-
And more. And there are, of course, countless other benefits, things that just by their nature are easier to do with a WinForms application. There are even things that you can't do at all with a browser-based application - writing to a local file, for example - that are relatively simple in a WinForms application assuming you have the correct permissions.
It leads me to believe that perhaps ultimately the best approach might in fact be the hybrid approach, the first revision that Chris presented. In this case, a WinForms control in the browser, much like an ActiveX Control was embedded in the past. Your control is a first-class WinForms control, it runs in a sandbox (as opposed to the full control that was granted to the ActiveX object), and you can interact with it easily via client- and server-side script on the page. The best of both worlds, so to speak, and worse case scenario you can always detect browser capabilities and degrade the page accordingly.
Disclaimer: These were just first impressions and thoughts I had when I was thinking about making the case one way or another. I haven't worked extensively with WinForms, so it's possible that I just don't know how to do something that I said was difficult.