Developers final take on writing an app in WPF (XAML) vs Windows Forms

Desktop apps came before Web Apps. This is a no brainer, the internet came into existence way after Desktop applications, and the initial internet consisted only of web pages. Web apps came later.

The presentation of Desktop apps have a history of being rigid, boring yet functional, for the most part strongly resembling the operating system, they’re installed on.

I know WPF is not a new kid on the block, but it is imo one of the most brilliant and under rated offerings so far released by Microsoft.

In essence a lot of developers have simply boycotted WPF and still opt for traditional Windows forms, but if the tech is so much better, then why?

Why WPF is not getting the attention it deserves?

This is the short list of reasons why WPF has yet to really capture the hearts of MS developers and become the defacto way of building modern UI’s.

  • WPF (XAML) and Silverlight were bundled at launch. Now I know Silverlight takes a lot of flack as being an epic failure. However consider the following. The internet presentation at the time had come from HTML 4, XHTML was the defacto way of coding, and everything was becoming web based. It was another golden era for browsers. Tons of new competition, and the W3C was finally the authority it was supposed to be all this time. Mobile application development was on the rise. Most of the front end web logic was being powered by Js.   Just to be clear, this was before JQuery!

    Everyone was questioning, do we really want to consider using this “messy” and “delinquent” scripting language to power the next generation of the web. Let’s call it “Web 3”. Let me remind you how fast technology changes, this is at the time when Active-X was still semi acceptable, and Flash was the cool kid on the block.

    So in essence, Microsoft back at the drawing board said “Look guys, our desktop apps look dated, Active-X has no future and HTML+JS isn’t ideal” Putting their heads together – their brightest engineers brought us WPF and XAML – XAML a descriptive XML based language. WPF and XAML would be used to build stunning desktop applications, Windows phone applications, and this would spill over to the “Write Once Deploy Everywhere” Web, in the form of a plugin called Silverlight, which could be theoretically installed in all major browsers. Interestingly enough IE was supposed to support XAML OOB, completely replacing the need for any HTML or Js.

    Sounded good in theory, however at the time not only Microsoft was at the drawing board. Elsewhere steps were being taking to improve upon the dated status quo. Many Js frameworks were on the rise, most noticeably JQuery. Google hard at work developing Android decided to harness the power of HTML for their “Write Once Deploy Everywhere” strategy. And HTML too was being challenged – HTML 5 was born. HTML 5 had 1 major mandate, to allow for responsive web design, to make it easier to cater for all screen sizes on any device. Getting inline for the myriads of devices to enter the market place.

    A few years in, and Microsoft realised that raw HTML5 had taken the lead for presentation, and since JQuery, I guess a lot of developers found new love for Js. Many advocate Js. Silverlight was retired.

    Microsoft never retired WPF or XAML, but since WPF was not widely used at the time, a lot of developers assumed it had been retired too.

  • There was confusion if XAML was a competitor of HTML. A lot of developers simply don’t trust the longevity of XAML.
  • Developers have learnt to embed web browser controls to do UI with. Thus truly harnessing write once, deploy all.
  • Desktop applications are on the decline.
  • Developers are familiar with Windows Form, and refuse to learn a new (and complex) WPF.
  • Deadlines🙂
  • The confusion between Visual Studio and the need for an additional tool called Blend. Most developers take 1 look at Blend, and think yeah – this looks like Flash. There is no way in hell I have the ability to learn this!

 

 

 My Experience with my first WPF Application

I remember on 2 occasions I’ve opened up Blend before and indeed it did look complex. Both times I’ve gone back to Windows Forms just because I’ve had to get the job done quickly and no time to experiment. This time was different. I decided no matter what I would do what it takes to learn WPF.

What I found is that WPF was less complex than I imagined, and my app even has some animation effects and cool stuff.

It took me just 3 days to become familiar with Blend. I still find it a bit strange to have to use 2 IDE’s for 1 application, but really this is nothing to complain about.

So what do I really think about WPF?

What I’ve noticed before as a Win Forms developer is you develop much lower expectations for your user interface. You end up developing these formal business looking applications. The UI’s look boring, and you focus on the functionality.

When it comes time to develop a new screen, most of the design considerations are where you will place your components from the standard toolbox. – Welcome to Win Forms development! Ah the joys🙂

One thing I’ve noticed about WPF is that it sets you free. In a way it is a bit scary, but at the same time very exciting.

When I develop a new screen in WPF much more possibilities are flying around in my head. It’s exactly like developing for the web. Suddenly you can get your designs down to the pixel level (if you want). Create interesting buttons with rounded corners and gradients, however overs, etc. Have a list of items in a WrapPanel, like div floating in HTML.

Simply put you can really fine tune the design experience. You also get storyboards and animations – so pretty much everything you need at your finger tips to create a UI exactly as you want it, all you need is time and imagination.

C# in the background

What I really like about WPF is that I can continue using C#. Let me be clear, I’ve seen a good few languages, and nothing beats the elegance and power of C#.

The controls however have not just been lazily ported across from Windows Forms.

Take a Winforms Datagrid, typically you go to the DB -> ORM your data across and then convert this to a Datarow.

In WPF each row IS your ORM type. You don’t type cast it in our out.

So for example : client myClient = DataGrid.selectedItem AND NOT client myClient = getClientByID(DataGrid.selectedItem.Columns[“ID”]);

Things like this make working with WPF a breeze.

Final thoughts

If you’re not working in WPF and still using Win Forms you’re missing out.

Go ahead, dive in and give it a try.

 

 

One thought on “Developers final take on writing an app in WPF (XAML) vs Windows Forms

  1. I just got into “moving” new desktop executable projects to WPF instead of WinForms. It might be just the experience but I’m quite slower in WPF (though I’m faster with WPF than ASP.Net despite my “bonding” time with ASP.Net). I think I know the reasons:
    1.) In Winforms, you think of the grid, the textboxes, the buttons and their functionality. The layout is an afterthought and is done purely using anchors. WPF forces you to think of layout first, then the controls and then the functionality. WPF also forces you to think how one panel affects another panel. The Lines-Of-Codes written by the programmer is actually longer in WPF because of the “panel over another panel over another”.

    Here is an example of one line of Winforms that has to be a 10-line XAML for the same effect.
    http://social.msdn.microsoft.com/Forums/en-US/cce74dbe-5f4d-47ff-a6b9-bb669a015867/wpf-anchoring-equivalent

    2.) In Winforms, you drag and drop a DataGridView and set its datasource to a DataTable (untyped) which might come from a SQL Database, DBF, Excel or all of the above. In WPF, I had to write a custom method for this because DataSource is missing.

    3.) In Winforms, the default DataGridView is more beautiful (by a lot) than the default ListView with GridView.

    4.) A standard WPF has close to double the amount of DLLs referenced to be loaded than a standard WinForms. This actually lowers debugging execution time.

    Needless to say, I’m using WPF as custom controls for things WinForms simply can’t perform.

    1.) WPF 3d is awesome. I’m faster with it than programming directly with DirectX, GDI+ (the Winforms Graphics library) or OpenGL.

    2.) Custom Controls particularly textboxes, schedulers, calendars and custom grid. I hated every moment having to use third party dlls just to get a spellchecker. Now I only have one dll (WPF Controls) and one .exe (the Application).I rewrote in WPF the entire (and I mean all) ComponentOne Winforms Control (Except C1BarcodeReader and C1Ribbon) in two days… all thanks to XAML. It was not a special feat, I’m convinced anyone can do it.

    3.) Game-like canvas for interactive analytics and simulation. I had a better experience with XAML than the HTML5 canvas (because of the javascript). GDI+ in Winforms was more horrible but is better than Java’s Swing.

    Conclusion:
    Winforms is for Rapid Application Development (Less Code, Do More). WPF is for creating components that make RAD better. No more 3rd party tools for me (no C1, No Telerik, no need!).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s