Winforms Vs. WPF Vs. Java UI's
I've been coding academically, professional and for fun for close to 10 years now. I've been working with Graphical UI's since first year university so going on 7 of those 10 years now. University was focused on Java in terms of designing graphical UI's and I spent 5 years at it.
So I left University with a strong skill set for designing UI's in Java. My first job as a developer exposed me to Windows Forms applications, and then I worked a little more with them when I went from that company to my current position. And lately we've taking a transition into Silverlight (WPF with more restrictions) and my projects at home working with WPF.
Getting into WPF was an interesting experience and I thought that this would be a good time to give a run down of my personal experiences with each of them. I don't consider myself a "master" in any of these, though I would say I'm highly proficient with Java UI's, and I remember enough of my struggles so this will be sort of a newbie's guide to choosing a programming language/framework.
Java was actually the easiest one to learn. This was in large part due to the environment and approach. It was the scariest also. We learned to code the UI. I didn't have any designers to help at any step of the way. That was the scary part. The reason it was the easiest however is because we were taught how to find what we needed from Sun's online Java API. I didn't always know what I needed, but I knew where to find it and examples to boot. I'll take this chance to point out that I also feel Java's libraries are much better laid out than Microsoft's. To this day I can't qualify that statement, just that Microsoft has a very similar online API and I can never find what I want there unless I knew what I was looking for to begin with. So what were the pro's of Java? I may need to look into what NetBeans offers in terms of a UI designer, but no such thing was available to me (or I didn't go out and find one) so I learned it inside and out. I used the GridBagLayout and manually specified my anchors, positions and weights. I manually added and created event listeners. In short, a simple application still forced me to work my butt off. OK, so that actually sounds like the con's, but really it is both. Most of my understanding of Windows Form and WPF applications still comes from my Java days where I needed to actually understand at some level what was going on to survive. It may be inaccurate when applied to MS languages, but I've never needed to dig that deep into how the Microsoft framework actually drives these things because of all of the flashy tools. So, Java, great if you want to really control how the UI will look and feel, terrible if you don't care. Java had other layout managers than GridBad, but they didn't handle very much in an elegant fashion. Perhaps things got better over time, I don't know, haven't written a Java app in 2+ years now.
Windows Forms was great. As long as you wanted to design something the UI had a common sense means of providing. However, coming to Windows Forms either from another language or being new to it was a bloody nightmare. .Net and their "partial" classes made understanding exactly why an application worked all the harder. I double click on a button in the designer and I'm automatically re-directed to the code-behind with a stub of what looks an awful lot like the code to handle the business end of pressing the button, but nowhere in sight is the code that actually calls it. How did I get here? And what do I do if I want to listen for double clicks instead of single clicks? I know these things now... I have to crack into one of the other partial code classes which isn't even visible in the project in visual studio. If you find programming so hard that someone needs to hide the nuts and bolts in another file so you feel comfortable... you're in the wrong profession. Honestly, unless making writing a UI look simpler than it actually is their goal, I sometime still feel they missed the boat here.
Until I saw WPF I was completely confused as to why they would do any of this. This was the beginning I guess of the MVVM pattern Microsoft wanted us to digest. Though it was more poorly delivered than the current implementation. But what was it good for? Easy, quick screens, one-off applications, or applications which required only the most basic of functionality. I've made a lot of such programs, when I didn't need anything fancy I was grateful not to have to write as much as I would have in Java. The second your screens are complex enough that the bulk of your screen elements need properties or event handlers that aren't handled through the designer, you now have 3 files/screens you need to manage to get the job done. You're going to use the designer to place the elements, you're going to use the code in the designer file to add the more complicated elements, and you're going to dump your business logic in the other code file. Of note, Microsoft is leaving this technology in the dust, it is getting none of the big advantages brought into the technology by WPF and Silverlight. None of the hardware acceleration, no new features, Windows Forms is the past and WPF is the future seems to be the message.
Which leads us to WPF/Silverlight. Now we have yet another interation of Microsoft's MVVM pattern. So what has changed? I now have yet a fourth file. The designer, instead of laying directly over code instead lies over an XAML file. Do I need the Xaml? No, I can write it in C# if I so desire and lose the designer entirely, but then to be in keeping with the MVVM pattern it would still be in a fourth file. We still have things that automagically generate and worse, if those automagical links are in the XAML, then there won't be a code file anywhere which actually shows how you got from one place to another (ie... nothing which is compiled). This is a damned confusing nightmare. I always prided myself on my ability to pick a new programming language with minimal effort. I had to take several stabs to find the motivation to stick with this long enough to get where I am today (which isn't very far). This was because in other languages there were compilers that caught obvious errors. XAML will let me bind to arbitrary and non-existent fields, I can even bind the wrong data types or to the wrong attributes. Does it error out when I compile? No. Does it error out at runtime? No. It just doesn't work. My application fires, my UI loads and anything I screwed up is just a visual element which does nothing.
This RecipeTracker project has had a number of little things holding up my development, one night I bound a field to the wrong parameter in the XAML, I shove breakpoints everywhere and find nothing. No code is called, even though my application is running and my screen is displaying. After hours and referencing back and forth between another project where I have a similar example running, I FINALLY notice the error. Then another time I defined a member incorrectly I said "public ICommand doSomething;" when it needed to say "public ICommand doSomething {get;set;}". Again, everything looked fine, everything compiled fine, and absolutely nothing. Other bindings in the same screen worked. Not so much as a warning. Damn infuriating. I can live with it compiling without errors, I don't understand why there are no errors at runtime for binding something to a non-existent datasource, or binding to an unusable data source or any of the other dozens of errors I had in my code without knowing.
So what is good about WPF/Silverlight? I like what Microsoft is trying to do. They are trying to separate UI from code as much as possible. I think they simply went too far on decoupling them. The notion that I say that I'm binding the command of a button to a certain event and none of compiling, running the application or trying to fire the event trigger an exception of any sort is a little beyond absurd. If said I wanted to bind it to something, one would hope I had the sense to intentionally provide that thing and that it should work.
But , with this design it is great for larger teams to work on larger projects. While the UI designer and code may need to agree on the names of the objects to bind, ultimately one can work on their piece completely independent of the other. Also, WPF and Silverlight leverage hardware acceleration for rendering their screens so less UI code is tying up the processor, they have more functionality, more visual controls and the Data Binding works spectacularly, and lastly, WPF and Silverlight designs (xaml files) and pretty much cross-compatible so porting for a desktop to a web app with the same look and feel should be minimal work on at least one front.
At the end of the day, there isn't a clear winner, especially if you haven't decided on a programming language yet. Windows Forms is great for desktop only application that require little or no functionality above and beyond what the designer spoon feeds you. Java applications are great for the small to mid size projects with just a few hands working on the code, but where greater flexibility is frequently needed and WPF/Silverlight are ideal for larger projects with multiple people or simply the requirement for more feature rich applications. I harped on WPF a lot, but really the lesson is, don't go into it thinking it will be like every other designer you've used before. Personally, I could live without it for either my current project or the next one, but I want to learn it for my side business and for work, but once I'm familiar with it I probably won't know how I lived without it.
So I left University with a strong skill set for designing UI's in Java. My first job as a developer exposed me to Windows Forms applications, and then I worked a little more with them when I went from that company to my current position. And lately we've taking a transition into Silverlight (WPF with more restrictions) and my projects at home working with WPF.
Getting into WPF was an interesting experience and I thought that this would be a good time to give a run down of my personal experiences with each of them. I don't consider myself a "master" in any of these, though I would say I'm highly proficient with Java UI's, and I remember enough of my struggles so this will be sort of a newbie's guide to choosing a programming language/framework.
Java was actually the easiest one to learn. This was in large part due to the environment and approach. It was the scariest also. We learned to code the UI. I didn't have any designers to help at any step of the way. That was the scary part. The reason it was the easiest however is because we were taught how to find what we needed from Sun's online Java API. I didn't always know what I needed, but I knew where to find it and examples to boot. I'll take this chance to point out that I also feel Java's libraries are much better laid out than Microsoft's. To this day I can't qualify that statement, just that Microsoft has a very similar online API and I can never find what I want there unless I knew what I was looking for to begin with. So what were the pro's of Java? I may need to look into what NetBeans offers in terms of a UI designer, but no such thing was available to me (or I didn't go out and find one) so I learned it inside and out. I used the GridBagLayout and manually specified my anchors, positions and weights. I manually added and created event listeners. In short, a simple application still forced me to work my butt off. OK, so that actually sounds like the con's, but really it is both. Most of my understanding of Windows Form and WPF applications still comes from my Java days where I needed to actually understand at some level what was going on to survive. It may be inaccurate when applied to MS languages, but I've never needed to dig that deep into how the Microsoft framework actually drives these things because of all of the flashy tools. So, Java, great if you want to really control how the UI will look and feel, terrible if you don't care. Java had other layout managers than GridBad, but they didn't handle very much in an elegant fashion. Perhaps things got better over time, I don't know, haven't written a Java app in 2+ years now.
Windows Forms was great. As long as you wanted to design something the UI had a common sense means of providing. However, coming to Windows Forms either from another language or being new to it was a bloody nightmare. .Net and their "partial" classes made understanding exactly why an application worked all the harder. I double click on a button in the designer and I'm automatically re-directed to the code-behind with a stub of what looks an awful lot like the code to handle the business end of pressing the button, but nowhere in sight is the code that actually calls it. How did I get here? And what do I do if I want to listen for double clicks instead of single clicks? I know these things now... I have to crack into one of the other partial code classes which isn't even visible in the project in visual studio. If you find programming so hard that someone needs to hide the nuts and bolts in another file so you feel comfortable... you're in the wrong profession. Honestly, unless making writing a UI look simpler than it actually is their goal, I sometime still feel they missed the boat here.
Until I saw WPF I was completely confused as to why they would do any of this. This was the beginning I guess of the MVVM pattern Microsoft wanted us to digest. Though it was more poorly delivered than the current implementation. But what was it good for? Easy, quick screens, one-off applications, or applications which required only the most basic of functionality. I've made a lot of such programs, when I didn't need anything fancy I was grateful not to have to write as much as I would have in Java. The second your screens are complex enough that the bulk of your screen elements need properties or event handlers that aren't handled through the designer, you now have 3 files/screens you need to manage to get the job done. You're going to use the designer to place the elements, you're going to use the code in the designer file to add the more complicated elements, and you're going to dump your business logic in the other code file. Of note, Microsoft is leaving this technology in the dust, it is getting none of the big advantages brought into the technology by WPF and Silverlight. None of the hardware acceleration, no new features, Windows Forms is the past and WPF is the future seems to be the message.
Which leads us to WPF/Silverlight. Now we have yet another interation of Microsoft's MVVM pattern. So what has changed? I now have yet a fourth file. The designer, instead of laying directly over code instead lies over an XAML file. Do I need the Xaml? No, I can write it in C# if I so desire and lose the designer entirely, but then to be in keeping with the MVVM pattern it would still be in a fourth file. We still have things that automagically generate and worse, if those automagical links are in the XAML, then there won't be a code file anywhere which actually shows how you got from one place to another (ie... nothing which is compiled). This is a damned confusing nightmare. I always prided myself on my ability to pick a new programming language with minimal effort. I had to take several stabs to find the motivation to stick with this long enough to get where I am today (which isn't very far). This was because in other languages there were compilers that caught obvious errors. XAML will let me bind to arbitrary and non-existent fields, I can even bind the wrong data types or to the wrong attributes. Does it error out when I compile? No. Does it error out at runtime? No. It just doesn't work. My application fires, my UI loads and anything I screwed up is just a visual element which does nothing.
This RecipeTracker project has had a number of little things holding up my development, one night I bound a field to the wrong parameter in the XAML, I shove breakpoints everywhere and find nothing. No code is called, even though my application is running and my screen is displaying. After hours and referencing back and forth between another project where I have a similar example running, I FINALLY notice the error. Then another time I defined a member incorrectly I said "public ICommand doSomething;" when it needed to say "public ICommand doSomething {get;set;}". Again, everything looked fine, everything compiled fine, and absolutely nothing. Other bindings in the same screen worked. Not so much as a warning. Damn infuriating. I can live with it compiling without errors, I don't understand why there are no errors at runtime for binding something to a non-existent datasource, or binding to an unusable data source or any of the other dozens of errors I had in my code without knowing.
So what is good about WPF/Silverlight? I like what Microsoft is trying to do. They are trying to separate UI from code as much as possible. I think they simply went too far on decoupling them. The notion that I say that I'm binding the command of a button to a certain event and none of compiling, running the application or trying to fire the event trigger an exception of any sort is a little beyond absurd. If said I wanted to bind it to something, one would hope I had the sense to intentionally provide that thing and that it should work.
But , with this design it is great for larger teams to work on larger projects. While the UI designer and code may need to agree on the names of the objects to bind, ultimately one can work on their piece completely independent of the other. Also, WPF and Silverlight leverage hardware acceleration for rendering their screens so less UI code is tying up the processor, they have more functionality, more visual controls and the Data Binding works spectacularly, and lastly, WPF and Silverlight designs (xaml files) and pretty much cross-compatible so porting for a desktop to a web app with the same look and feel should be minimal work on at least one front.
At the end of the day, there isn't a clear winner, especially if you haven't decided on a programming language yet. Windows Forms is great for desktop only application that require little or no functionality above and beyond what the designer spoon feeds you. Java applications are great for the small to mid size projects with just a few hands working on the code, but where greater flexibility is frequently needed and WPF/Silverlight are ideal for larger projects with multiple people or simply the requirement for more feature rich applications. I harped on WPF a lot, but really the lesson is, don't go into it thinking it will be like every other designer you've used before. Personally, I could live without it for either my current project or the next one, but I want to learn it for my side business and for work, but once I'm familiar with it I probably won't know how I lived without it.
Comments
Post a Comment