You pose some good, very-honest questions preaa. Here's my thoughts, "Why would you put your UI in painful XML tags when you can use Windows forms?" Once you get used to the XML, it actually becomes far easier and gives you a lot better control. Actually, you *can* still compose your gui by creating your widgets in your code-behind, but once you become as one with the XML, you find that you can weave a GUI as simple or as capable as you want, with non-rectangular elements, animation and other visual effects that are impossible with Windows Forms, and the binding facility is quite advanced. I've been spending the last decade creating a lot of desktop applications, and WPF is my #1 tool of choice. Nearly everything can be defined using the same 'language' (XAML) - and I am not limited to standard widgets. I've created some fairly sophisticated 3D CAD programs, a beating-heart animation (that reflects the measurements being taken of an actual patient's heart), and a geographical-display that shows aircraft moving across it, with drop-shadows and multiple cameras (all, still without leaving the world of XAML). I created one family of pretty 3D-effect buttons, and easily share it across all of my WPF projects while overriding certain of it's properties. I never liked using a "designer" to place controls onto my GUI, and am so comfortable with XAML that it takes me only seconds to type up a fairly decent form that responses as the user resizes the window, adapts to changing text values, etc. "If it were to separate UI completely with the behaviour, aren't the developers doing that already with clean layering architecture with the forms based applications?" WPF provides a way to achieve a far cleaner separation of presentation from domain behavior. In fact, you can have your graphic artists load up the same Visual Studio solution into, for example, Blend, and fine-tune the visual aspects, at the same time that the developers are working on the code. "load .. on a browser?" That (XBAP deployment) in my opinion, was an additional deployment option, that neither I nor most developers I know ever used. SilverLight, on the other hand, did seem to take off for a while and I felt it was an excellent solution for a time, until HTML5 and CSS3 provided more standardized solutions for the same problem-space and SilverLight got de-emphasized. I think it's safe to simply ignore that option. I see the world of desktop apps, and online apps, as usually serving two very different spaces. A lot of users do not want to

I see someone's had a similar experience as I. Coming into Ruby-on-Rails (RoR) after working with Python/Django, and C# ASP.NET-MVC, my productivity really schlowed to a crawl with RoR. The duck-typing is one factor: I much, much prefer to just have things explicit within the code structure so I can know what's going on. C# catches most of the errors that RoR happily lets slide and condemns you to hours of guessing and troubleshooting. Another huge factor is - with RoR, things rarely actually work. It seems there's a wealth of online information that is incorrectly typed, or that just doesn't work as claimed. Things break with various versions, or are incompatible with, or there're way too many ways to accomplish the same thing. I came to the conclusion that the reason we see more online activity with RoR is: nothing's working, and everyone is still googling trying to find something that does! It is probable that I'd have had a better RoR experience had it been my very first development platform: I got so spoiled with C# and ASP.NET-MVC that RoR is a horror-show of incompatible, non-working madness. James Hurst

James Hurst "The greatness of a nation and its moral progress can be judged by the way its animals are treated."
Mahatma Gandhi

I'd suggest - yes. Your articles should not be unworthy just because they're in Vs2008. Many (but not all) projects seem to load into later versions of Visual Studio without any problem. In fact, in a way it makes more sense, as I get responses to my Vs2012 projects like "can you please provide a Vs2008 version?" It's easier to go up a version than it is to go down.

James Hurst "The greatness of a nation and its moral progress can be judged by the way its animals are treated."
Mahatma Gandhi

I agree 100% - but you expressed it much better than I.

James Hurst "The greatness of a nation and its moral progress can be judged by the way its animals are treated."
Mahatma Gandhi

I really love that feature. That said, yes they need to be used sensibly to avoid getting ugly. Regions are a great tool for organizing your code, such that when you bring up a file you are looking at a small number of regions, which - ideally - are marked so as to direct you quickly to exactly where want to go. It's a topic that a dev team needs to discuss and settle upon standard practices for, early on. IMO

James Hurst "The greatness of a nation and its moral progress can be judged by the way its animals are treated."
Mahatma Gandhi

In several years now of building WPF applications, I have rarely seen a visible performance degradation due to WPF as opposed to Winforms or even C++. Yes, I generally leave my compute-intensive video analysis or neural-net computations in C++ and call those routines from the WPF app, but other than that WPF has been extraordinarily productive for me. The main exception was just before 3.5 sp1 came out, and I was doing very-detailed waveforms, that were animated in realtime and feed by 256 sensors. That was pushing the edge. I would love to see exactly where you're perceiving a performance hit, and profile it. I've used Red-Gates ANTS Profiler with good results -- it's a splendid tool (not free, but a heck of a bargain for my needs) and highly recommend it. Other than the animated-waveform project (which I wound up solving in WPF after all) I have never, ever seen a real performance hit in the GUI, relative to Winforms or even C++/MFC/wxWidgets, other than when I had made some coding mistake. I'm talking about the GUI action itself. I noticed amongst the other threads that you're loading something like 500+ objects into a ComboBox? That's not a level that ought to significantly impact your performance, visually - depending upon how fast that source is. But it does merit a think-through on the data-binding strategy. What I often do is handle the data-loading on the content-rendered event, after the view is already visible to the user and before he has time to slide his mouse over to your controls. You have hundreds of milliseconds during that time to play with, without the user perceiving it at all. On the other hand, if you're pulling data through a slow webservice or some such, it might make sense to kick off a work thread immediately, as early as possible, to get those results ready for the GUI. And of course for very large lists - virtual loading is a possibility to consider. There are, too, times when I don't use data-binding at all. It's a useful tool, but I think it's wise to keep an open mind rather than to adhere to the MVVM paradigm religiously. Best of wishes, James W. Hurst

James Hurst "The greatness of a nation and its moral progress can be judged by the way its animals are treated."
Mahatma Gandhi

I understand your reaction - I ran into it while I was giving a weekly training seminar on WPF at a client last year. After a couple of years of solid work building WPF apps (and Forms & HTML before that) I can confirm that yes, it's a bit of a learning curve at first. And that it's well worth it, depending upon the characteristics of the project. With the right orientation, one can become more proficient in forging great-looking functional dialogs and custom controls, then with other technologies (incl HTML). The more you utilize it, the more you discover it's hidden power. Eg, with the right tools it's far easier to globalize. You can set thematic properties that apply across your entire project. It's easy to make layouts that respond well to when the user resizes the window. At this point I only use Blend (or ZAM3D) for real graphical portions, or animations: it feels effortless to whip up a competent dialog just by typing in raw XAML. I think it does merit a good introduction, and a good set of books or tutorials, to get properly oriented. That's just my opinion.

James Hurst "The greatness of a nation and its moral progress can be judged by the way its animals are treated."
Mahatma Gandhi

The release version - not at all. But once I installed the SP1 Beta, it crashes about once a day. Sometimes erratically, and there is one pattern that reproduces consistently: whenever I try to change the command-line argument for it to pass to my program on launch, VS 2008 simply disappears instantly. Thus I'm utterly unable to set launch options. :^)

James Hurst "The greatness of a nation and its moral progress can be judged by the way its animals are treated."
Mahatma Gandhi