Related
There has been a lot of talk surrounding the likes of WPF. I am wondering if WPF will become a new standard for graphical interactive user interface design. Is this where we are headed in terms of windows interfaces? Will it really take off like everyone says it will?
See also
Learning Windows Forms vs. Windows Presentation Foundation
(Contains links to many other useful posts on WPF).
I think there are plenty of applications still done in Win32, MFC and of course, WinForms. I think it would be a wise choice to add WPF to your tool belt. Should you drop everything and learn it today? That's up to you. I am seeing more demand for WPF. It's not overwhelming, but neither was C#/WinForms in 2001.
So the long winded answer is that you just have to take the chance. No one knows if WPF apps will dominate the market. I'm leaning towards the possibility and I'm also thinking Silverlight may be a real player in web apps moving forward. Since there are transferrable skills between the two, I'm hedging my bet a little bit by continuing to learn WPF.
Please see also Is it better to use WPF over WinForms
Sorry it's not a concrete answer.
You're asking us to predict the future :)
I think a better way to approach this is to look at the other technology you could learn if you didn't learn WPF. I would weigh the various tradeoffs and pick the one that was more valuable to me.
For instance if the choice was WinForms or WPF I would certainly go with WPF. WPF has a steeper learning curve than WinForms. However once you get past that learning curvie it is so much easier to work with. WPF can do in a few lines what took several hundred lines of a custom control in WinForms.
WPF is an ultimate graphic platform for Windows. Win32's GDI was a "first try", WPF is a "permanent structure". For the combination of Windows and flat displays (f.e. 3d displays might require something else), it will never be replaced. So learn it, it is a good commodity.
There is hell lot to learn in WPF. You need to die and reborn as a GUI programmer.
But is it worth the effort. Why?, Here is my answer.
Since you are asking this question, I assume you are Microsoft technologies based programmer.
As the direction of MS is towards WPF for GUI development, I see no choice. Win Forms will last long for probably 2 years more. Since the cool look and feel of WPF make users to ask for more and more WPF applications than Win Forms. As you know for many users GUI is the S/W :)
Now if you are non MS based programmer, probably from Java, I say WPF has lot of similarities with Java Swing. But it is a very-very big super set of Swing.
To have Swing catchup with WPF might take at least 2/3 years and by that time WPF might be ruling the word and I don't expect Swing to be much easier than this, if not difficult.
As silverlight is kind of platform independent and as it's model is similar to WPF, I predict WPF is going to rule at least for next 6/7 years if not a decade.
I believe and hope MS would make things much more easier for the programmers so that learning curve would be shortened or delegated to GUI artiists (using expression blend).
Hope I answered your question.
Microsoft has a habit of throwing everything in the wall and seeing what sticks... The Pocket PC platform, J#, and so on. With regards to WPF, it is too early to tell if adoption will increase in the future.
If you have programmed .NET Winforms and/or Webforms, the learning curve is not that steep. I would suggest dabble with it but don't throw all the eggs in the proverbial WPF (or even Silverlight) basket. As the others have noted, better to treat it as just another tool in your arsenal.
WPF has been around for a few years now and Microsoft's decision to rewrite Visual Studio (2010) in WPF is a good sign that it is here to stay. Remember, this is one of the most popular IDEs on the market and a sign of intent from the guys at Microsoft.
My organization adopted the technology last year and while it has a steep learning curve - you really have to learn to think in different terms - it has paid dividends in the richness of applications we are able to develop. I love winforms and am a big fan of asp.net but what blows me away about WPF is that you are provided with the building blocks and the possibilities are endlesss...
If I were you I would learn WPF for the experience and reap the rewards later. Don't forget - you'll also be learning the core of Silverlight if you adopt WPF - these are two technologies that in my humble opinion are going nowhere!
Using WPF is way better then WinForms and you need to have different mindset.
All I can say is Microsoft should have used HTML syntax when creating WPF and Silverlight applications so that front end coulde reused or at least for silverlight apps so that people that develope on Desktop could reuse the same code when writing browser apps that could be used anywhere.
If HTML5 becomes better I'm sure it will become popular as trend is toward open source (cheap technologies). No doubt WPF is far better for developing desktop apps then anything else I've used and c# is more powerfull as language (not speed) and how it's used.
Yes start learning it. It's applicable to Silverlight (though not a 1 to 1 mapping), it's also a very similar model to Abobe Flex's paradigm of MXML So you'll be getting 3 wins for the price of 1.
We're starting to see work come in that calls for it, so there's definitely a good reason to have it on the old utility belt.
I am begining to learn it Matthew MacDonald has writen a super book about it. I recommend that book to everyone (Infact I was surfing internet to learn WPF till I came across with his book and one more thing "stay away from Microsoft site (MSDN)"
Yes, if you will be designing desktop applications on the Windows platform, WPF is the emerging standard. WPF replaces the Win32 API that has dominated the Windows desktop until now, and Microsoft expects a similar lifetime for the WPF platform.
Besides, it's way cooler.
And then there is Silverlight, of course.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Most restrictions and tricks with windows forms are common to most programmers. But since .NET 3.0 there is also WPF available, the Windows Presentation Foundation. It is said that you can make "sexy applications" more easy with it and with .NET 3.5 SP1 it got a good speed boost on execution.
But on the other side a lot of things are working different with WPF. I will not say it is more difficult but you have to learn "everything" from scratch.
My question: Is it worth to spend this extra time when you have to create a new GUI and there is no time pressure for the project?
After three months of trying to hammer out a line-of-business (LOB) application on WPF, I reached a point of considering turning back to Windows Forms for my project, and in researching other people's opinions, came across this thread...
Yes, WPF is a brilliant technology and it has benefits that span far beyond mere eye-candy... the templating and binding capabilities are great examples. The whole object model offers more flexibility and broader possibilities. That doesn't, however, make it the defacto platform for future LOB applications.
The "problems" which WPF solves in terms of separating GUI from business logic aren't problems which can't be readily solved in Windows Forms by simply starting with the right architecture and mind-set. Even the object-path binding capabilities of WPF can be reproduced in Windows Forms with some very simple helper classes. The data template capabilities of WPF are very nice, but again they're nothing that you can't simulate in Windows Forms on those rare occasions when you absolutely don't know exactly what objects you're going to represent on any given part of the screen.
Where Windows Forms races ahead is in terms of maturity. You can't swing a dead cat on Google without hitting some blog where someone has solved a Windows Forms problem for you. WPF, on the other hand, has comparatively less learning resources available, fewer custom controls available, and hasn't had as many of its teething problems solved.
At the peak of making a WPF vs Windows Forms decision has got to be the maturity of the development environment. Windows Forms editors are slick, responsive and intuitive. Feedback about errors gets to you instantly, the solutions are usually obvious, and the compile->debug->edit cycle in Windows Forms is very quick.
WPF applications, on the other hand, have comparatively pathetic design time support, with the design view all-too ready to chicken out at the first encounter of an error, often requiring a project build after the fix before the designer is willing to kick in again. Drag'n'drop of components from the toolbox might as well not be supported, given the vast range of circumstances under which it either doesn't work at all, or yields completely unintuitive results. Despite the promise of the WpfToolkit, there still isn't a usable DataGrid for WPF that yields any kind of resonable performance or design time friendliness.
Debugging WPF applications is a bit like the old ASP.NET debugging paradigm... hit F5 -> wait -> launch -> error -> stop -> fix -> hit F5 -> wait -> launch -> error -> groan -> stop -> fix -> hit F5.... All XAML which your program is running is locked, and tracking down XAML specific problems is often tedious.
The bottom line, simply put, is that the development tools for Windows Forms are going to have you banging out front-ends in a fraction of the time of a WPF application... especially if you're creating master-detail grids or spreadsheet like interfaces, which most LOB have. With Windows Forms, you start with 90% of the work already done for you.
I'm a huge fan of the WPF architecture. I just wish the design-time tool-set didn't feel like a pre-alpha debug-build.
Edit: This answer was posted about .NET 3.5 + Visual Studio 2008, but .NET 4.0 with Visual Studio 2010 ships with a WPF data grid. While many improvements have been made to the new WPF development experience, my answer here remains unchanged, and I'd like to add the following suggestion:
If you're in a rush to do RAD development, go with Windows Forms. If you're looking to produce a well architected, maintainable, scalable, resource firendly, multi-user Line-Of-Business application, consider ASP.NET MVC + HTML 5 + jQuery... My projects with these technologies have resulted in better outcomes, sooner, for my customers. MVC offers all of the same templating that WPF does, and jQuery enables animations and complex interactions. More importantly, an ASP.NET MVC + jQuery solution doesn't require your end users to have modern desktops with decent graphics hardware.
I'm seven months into using WPF on what has now become a core system for my customer, and I'd like to share some more thoughts with you about the experience of learning and using WPF as a line of business presentation platform.
In general, the comments I made above still hold... The design time support for WPF isn't here yet. If you're in a big rush to get a rich-client application out of the door, go with Windows Forms. Period. Microsoft aren't in any hurry to discontinue the GDI / Windows Forms platform, so you can count on good support for a fair time into the future.
WPF is not easy to master, but that shouldn't be where you leave your descision about whether or not to invest your time and energy into learning WPF. Despite its present lack of maturity, WPF is built around some useful, modern concepts.
In WPF, for example, your investment in well-written business objects with sound validating logic is a solid investment. Unlike Windows Forms, WPF's data binding is briming with features that allow interface controls to react to invalid user input without writing GUI code to detect those errors. This is valuable.
The styling and templating capabilities in WPF have proven to be valuable too. Despite the common misconception that the only use for styling and templating is to create on-screen eye-candy, the truth is that these features significantly simplify the coding of a user interface which gives rich feedback - like buttons that disable/enable themselves base on the state of the underlying business logic layer, or tooltips which intelligently find their text based on the state of the object under the cursor, etc.
These all add up to incredibly valuable features for "nothing fancy" business applications, simply because they make it easy to keep the interface congruent with the underlying data.
In a nutshell:
In Windows Forms you design your user
interface, then write code to drive
that user interface, which generally
also includes code to drive your
data objects.
In WPF you invest in the business layer that drives your data objects, then design an interface that listens to your data objects.
It's a seemingly subtle difference, but it makes a huge difference in your ability to re-use code... which begs the question: "Is the Windows Forms vs WPF question actually an investment decision?"
(This seems to have become my favourite thread.)
Are there any compelling reasons to use WPF
Absolutely! WPF is absolutely incredible! It will be a major benefit for practically any project because it has so many features and abilities that Windows Forms lacks.
For business applications the biggest wins will be:
The fantastic data binding and templating make the biggest difference. Once a decent data model is in place, it only takes a few clicks to create a data template and use Expression Blend to configure exactly how your object will look using drag-and-drop. And binding to things like color or shape is trivial.
Screen layout is incredibly flexible. Not only can everything in WPF smoothly adjust to container size and shape changes, but items can trivially be enlarged and rotated, and even extend outside their containing frame.
Ordinary objects can be presented any way you like, can easily have different presentations in different screens, can share presentation, and can adapt their presentation to changes in data values.
If you need to print, rendering to the printer is trivial. Properly configured, WPF makes Crystal Reports or SQL Server Reporting Services (SSRS) look like a child's toy.
Your user interface will look and feel much more dynamic, including nice features such as buttons that animate when you pass the mouse over them.
For utilities and games, other advantages come to the forefront:
You can easily add shapes, lines, and arbitrary drawings to your application without using an external editor. Every component of these can be data-bound and animated, or controlled by code. In Windows Forms you ususally just have to import a bitmap and use it as-is unless you want to go to a lot of work.,
Animations are cool! Users will be really impressed, as long as you don't overdo it. They can also help people see what is going on and reduce the need for hilighting. For example, when dragging an object you can animate the target to show what will happen if you drop it.
Colors, gradient fills, brushes, fancy fonts, rotation of any objects, tile brushes, etc. Anything you want graphically is yours for the asking.
Incredibly customizable. I needed to draw railroad tracks for one application, so I could drop a train on them. A couple of hours later I had railroad tracks I could draw anywhere on the screen using Bézier curves, and they would join and switch automatically.
The bottom line is that any significant-size GUI you could build in Windows Forms can be built in WPF in a third of the effort (or less) and look way, way better.
Does WPF require more resources (RAM in particular)
You do pay a price compared to Windows Forms, but it is a small one.
RAM can go up or down depending on your implementation. WPF stores its data more efficiently so individual objects are smaller, but there tend to be more objects in WPF than in Windows Forms so this balances out, and either one can come out ahead.
CPU will go up compared to Windows Forms. In my experience, the actual update of WPF objects onscreen takes about twice as much CPU as normal Windows Forms rendering. If your application spends most of its time updating the screen, WPF may not be for you. But in that case you're probably not using Windows Forms either: Most serious games are written directly to DirectX.
Disk usage will be slightly less for WPF because it takes so much less code than Windows Forms. The data will be the same size, of course.
One more note about CPU use: Animations and transforms (motion, translation, etc.) is actually more efficient on WPF than in Windows Forms because of its retained mode storage. It is the initial getting of the objects up there that is slower.
Maintenance overhead
WPF is a huge win over Windows Forms when it comes to maintenance. Since everything is done in 1/5 as much code as before, there is 1/5 as much to maintain. Plus all the boilerplate stuff is gone so you can focus on the code that actually does the work.
Benefits of XAML
XAML is the core of WPF. Although WPF can be used without XAML, XAML makes it incredibly easy to use. XAML has HTML's ability to easily specify a user interface, but its built-in tags are much more powerful, and you can easily define your own. (In fact, it is normal to do so).
Some specific advantages of XAML:
Your entire UI is defined in a text file that is easy to read and manipulate, both for users and tools
MarkupExtensions allow Bindings to be specified in a clear and simple way
Type converters allow properties with complex types to be easily specified. For example, you can say Brush="Green" or you can specify a radial gradient brush with three stops.
You can create your own elements
You can easily leverage WPF's powerful "attached properties"
Other insights
I dreamed of something like WPF for many years. Many people have implemented portions of this functionality, but to get it all in one place and at such a price ($0) is amazing.
WPF is a huge paradigm shift from Windows Forms and will take some getting used to, but the time spend learning it will pay itself back many-fold.
WPF still has a few warts even five years later, but its power will totally blow you away once you experience it. If someone tries to drag you back to Windows Forms, you'll only go kicking and screaming.
Tips:
- Do get a copy of Expression Blend for development
- Do edit XAML by hand occasionally
- Don't give up when it seems strange at first
WPF enables you to do some amazing things, and I LOVE it... but I always feel obligated to qualify my recommendations, whenever developers ask me whether I think they should be moving to the new technology.
Are your developers willing (preferrably, EAGER) to spend the time it takes to learn to use WPF effectively? I never would have thought to say this about MFC, or Windows Forms, or even unmanaged DirectX, but you probably do NOT want a team trying to "pick up" WPF over the course of a normal dev. cycle for a shipping product!
Do at least one or two of your developers have some design sensibilities, and do individuals with final design authority have a decent understanding of development issues, so you can leverage WPF capabilities to create something which is actually BETTER, instead of just more "colorful", featuring gratuitous animation?
Does some percentage of your target customer base run on integrated graphics chip sets that might not support the features you were planning -- or are they still running Windows 2000, which would eliminate them as customers altogether? Some people would also ask whether your customers actually CARE about enhanced visuals but, having lived through internal company "Our business customers don't care about colors and pictures" debates in the early '90s, I know that well-designed solutions from your competitors will MAKE them care, and the real question is whether the conditions are right, to enable you to offer something that will make them care NOW.
Does the project involve grounds-up development, at least for the presentation layer, to avoid the additional complexity of trying to hook into incompatible legacy scaffolding (Interop with Win Forms is NOT seamless)?
Can your manager accept (or be distracted from noticing) a significant DROP in developer productivity for four to six months?
This last issue is due to what I like to think of as the "FizzBin" nature of WPF, with ten different ways to implement any task, and no apparent reason to prefer one approach to another, and little guidance available to help you make a choice. Not only will the shortcomings of whatever choice you make become clear only much later in the project, but you are virtually guaranteed to have every developer on your project adopting a different approach, resulting in a major maintenance headache. Most frustrating of all are the inconsistencies that constantly trip you up, as you try to learn the framework.
You can find more in-depth WPF-related information in an entry on my blog:
http://missedmemo.com/blog/2008/09/13/WPFTheFizzBinAPI.aspx
WPF requires either Windows Vista or Windows XP SP2, which is not an onerous requirement, but it is a relevant one. If you want to run on Windows 2000 (which some people still do), then WPF won't work for you.
WPF is also a newer technology and not as proven as Windows Forms so you might choose Windows Forms as a less risky option, particularly for larger applications.
That being said, yes WPF is the future. Visual Studio 2010 is being rewritten in WPF, which will probably be the largest WPF application to date and it will also be a real test for the technology.
Obviously, legacy Windows Forms applications would be another situation where it is the correct choice.
As others have said, there are advantages and disadvantages either way you go here. The advantages of WPF, as others have said, include:
The ability to make very rich UIs relatively easily.
Easier animation and special effects
Inherent scalability (use the Windows Vista magnifier tool on a WPF application, and on a Windows Forms application: Note that in the WPF application, all the vector art scales beautifully)
(OPINION ALERT) I feel it's "easier" to do document-oriented systems in WPF
However, there are drawbacks to WPF, where Windows Forms comes out on top:
WPF's in-box control suite is far more limited than that of Windows Forms.
There's greater support in the third-party control space for Windows Forms. (That's changing, of course, but think about it: Windows Forms has been around since 2001; WPF just a few years. By advantage of time, Windows Forms has greater support in the community.)
Most developers already know Windows Forms; WPF provides a new learning curve
Finally, bear in mind that you can create great, attractive and engaging UIs in either tool, if you do the work (or use the right third-party tools). At the end of the day, neither is necessarily better in all circumstances. Use what feels right for the project.
The programming model for WPF is more open and flexible than Windows Forms is, but like ASP.NET MVC, it requires a little more discipline in terms of correctly implementing Model-View-ViewModel patterns.
My first LOB application with WPF ended up as an utter failuire, because it was a resource hog which brought my end-user's very-low-end laptops grinding to a halt... and this was ultimately because I just lept in with WPF + LINQ to SQL and expected a good result... and this is where WPF diverges so strongly from Windows Forms... In Windows Forms, you can get away with that sort of thing. WPF is much heavier on resources than Windows Forms, and if you don't architect your application to be lean, you end up with a 800-pound gorilla.
Don't shy away from WPF... explore it. But be aware that the acceptable sins of Windows Forms coding won't produce good results in WPF. They're fundamentally different engines, which lend themselves to fundamentally different coding patterns.
Last Word: If you do go ahead with WPF, get well acquianted with data virtualization for use with lists and grids. What is a simple data-bound ListItem or GridCell ends up being a hefty logical + visual object-graph in WPF, and if you don't learn how to virtualize, you application won't perform well on large data sets.
There is a very steep learning curve to WPF, and I recommend you get the obvious books first (Adam Nathan,
Sells/Griffiths, and
Chris Anderson) and
blogs (Josh Smith, etc.). Just be prepared for it, and make sure your project allows you the time to learn WPF.
In addition to learning the technology, spend some time learning the patterns used to construct WPF applications. Model View ViewModel (MVVM) seems to be the one that has gained a great deal of acceptance.
Personally, I think WPF is worth it but be forewarned. Also note that you effectively restrict your users to Windows XP SP2+ and Windows Vista. We've made that decision, but you may have some different requirements.
Both of technologies have their pros and cons. In a large application with a "classic" UI I'd use Windows Forms. In an application which require a rich user interface (skinning, animations, changing user interface) I'd choose WPF. Please check the article WPF vs. Windows Forms comparing WPF and Windows Forms.
Aside from the flexibility in UI design, there are some technical advantages to WPF:
1.) WPF doesn't rely on GDI objects. Well, I think it uses 2 GDI objects for the instance of the window itself, but that's practically nothing. I've been involved to a certain extent in a very large internal Windows Forms application. The people in our office sometimes run 3 or 4 instances of it simultaneously. The problem is that they frequently run into the 10,000 GDI object limit inherent to Windows 2000, XP and Vista. When that happens the entire OS becomes unresponsive and you'll start to see visual artifacts. The only way to clear it up is to close applications down.
2.) WPF utilizes the GPU. The ability for WPF to off-load some of the UI processing to the GPU is brilliant. I only expect this aspect of it to get better with time. As a former OpenGL programming hobbyist I can appreciate the power that comes from the GPU. I mean, my $100 video card has 112 cores running at 1.5 GHz each (and that's not top of the line by any means). That kind of parallel processing power can put any quad-core CPU to shame.
However, WPF is still pretty new. It won't run on Windows 2000. And in fact, a WPF application can be slow to start up after a fresh reboot. I talk about all of this on my blog:
http://blog.bucketsoft.com/2009/05/wpf-is-like-fat-super-hero.html
I think it is worth learning WPF. Once you are up to speed, design work on your forms is much easier IMHO. I wouldn't worry as much about the 'sexy' stuff. Most of this is just a fad. You can make 'normal' Winforms-style applications very quickly and easy in WPF.
The whole concept lends itself to easier design IMO.
I don't agree with some of the answers here. WPF is really well suited for line of business (LOB) applications. (The frog design LOB client is the best example). And besides all the possibilities to have your UI be eye candy (which is not necessary in business applications), WPF offers a lot more for you.
The data binding and templating features are just superior to Windows Forms. It also offers a far better way for separating code and presentation.
We've successfully used WPF for 2 LOB applications in teams with no more than 2-3 developers.
The biggest problem you will face is probably the steep learning curve of WPF (compared to Windows Forms) which will decrease development speed with developers not used to WPF.
We are currently rewriting our application in WPF from Windows Forms. Yes, there is a steep learning curve and you have to "re-learn" some things, but it is so worth it. And combined with WCF, we are finding we are writing less code, faster, and more robust than ever before.
Stick with it for a while, read Adam Nathan's book, and check out the ever growing library of third-party controls like those from Telerik and ComponentOne. One negative, in my view, is that the design tool, Expression Blend, is very awkward to use. The latest version is still in beta, but it just doesn't feel right to those of us who have used Visual Studio for years. Yes, it's mainly for designers, but some things you just can't do in Visual Studio.
Consider WPF if interface design is important to you, because WPF can deliver better UI experience. But Windows Forms has on its side the years of evolution, so it's proven to work and you can find many versed programmers for that platform.
Also portability may be an issue, WPF only works with Windows XP SP2 and up.
Also, WPF has a steep learning curve, meaning it's not easy to deliver a quality product without having specific WPF experience.
Well, one answer is "when you have to support 1.1 or 2.0", since WPF is part of .NET 3.0. There are known OS limitations for WPF, and there is an obvious skills issue: if you have a team of developers that know winforms, then it may be easier to turn out robust code with winforms. However, if you are writing a lot of UI code it is probably worth beginning to pick up WPF at some point.
WPF also shares a lot in common with Silverlight, so it has transferable benefits.
WPF comes with many advantages such as superb data binding features,
separation of concerns, separation of design and logic etc...
As a developer I enjoy the ability to define my UI using XAML as opposed to
being tied to the Windows Forms designer and I feel good knowing I can count
on another designer to make my app look good.
Personally I don't care older versions of Windows are not supported,
but one of the big problems with WPF is that is is not (currently/ever) supported
by Mono (http://www.mono-project.com) so WPF apps will not run on Mac OS or Linux.
(Altough Silverlight applications will).
If you have the time and resources to invest in learning WPF, do it!
Even if you're going to be writing Silverlight applications to support multiple OS's.
If you need desktop applications to run on multiple OS's stick with SWF.
There are many differences. We loved WPF for:
The declarative style of programming.
Animations and state transitions
Expression Blend is a great tool
Good style support.
However, we stuck with Windows Forms because:
The extra time it takes for a
developer to learn WPF when they
already know Windows Forms.
WPF will not run on Windows 2000 or
lower.
The biggest consideration when deciding which one to use is to consider what .NET Framework your target audience have installed. I find that more people have the lower .NET Framework versions that only support Windows Forms, but that's just my personal experience.
The advantages of WPF is that it is much easier to create nice looking GUI's with custom controls and animations. WPF also helps further serparate the presentation and logic layers. If you have designers, it allows you to farm of 95% of this work to non-coders and allows the coders to work on logic. The disadvantages are the software costs for Expressions Blend, and the lack of any of the Visual Studio code profiling tools working well as they tend to get caught up in the frameworks calls in trying to render XAML. I am sure there are others but these were the only two we really saw.
The main consideration is if you wish to require your customers to have to install .NET 3.0 or even better .NET 3.5 SP1. You will get some niegative feedback
WPF makes it much easier to hand off the forms design work to an actual designer, not a developer in designer's clothing. If that's something you'd like to do, WPF is your answer. If the classic Windows styled buttons are fine, then Windows Forms is probably the way to go.
(Multiple answers make the claim that you should use WPF if interface design is "important to you" but that's pretty vague. Interface design is always "important".)
If you have an MSDN license, check out Expression tools. It's designed explicitly for WPF, exports directly to Visual Studio and it may help ease your transition.
If you only care about supporting Windows and don't mind the time it takes to learn it, go with WPF. It's fast, flexible, easy to reskin, and has great tools to work with it.
As a side bonus, Silverlight is based on WPF and starting with either lets you gain the know how for working with the other. If things continue to go web based, having prior knowledge (and a library of existing code) to transfer easily to the browser (or Windows Live Mesh) might help give your software an extra lease of life.
If you decide to go with WPF, considering pros and cons already explained in the above answers, I highly recommend going through this dnrTV episode with Billy Hollis
In DotNetRocks episode 315, Brian Noyes discusses this extensively.
There is a known issue with text rendering in WPF. Many users report that the heavy use of anti-aliasing and pixel-blending used causes blurry text. This is a big deal breaker in some circumstances and, as far as I know, has been acknowledged by Microsoft at some level.
For the last 3 1/2 years I've been doing Windows Forms development (at two companies). Both applications were used extensively and ended up having GDI problems. Large Windows Forms applications will eventually run out of GDI resources - causing the end user to have to reboot.
Scott is complaining about Expression Blend and how it doesn't make sense to him as a developer. My first reaction to Expression Blend was like that. However, now I see it as an invaluable tool, but it really depends on what type of developer you are.
I am user interface developer that has had to perform the Integrator role, and I eventually found Expression Blend invaluable to create styles, and control templates in a WYSIWYG manner. I almost always have Expression Blend and Visual Studio up an running on the same project at the same time.
I also think that playing around in Expression Blend and taking a look at the XAML that gets spit out is an excellent way to learn the WPF API ... much like using the designer in Windows Forms and checking the C# code it spits out is helpful in learning how to use whatever you are designing there.
Expression Blend is helpful. Just give it a try, especially if you are working on the visuals for the application.
A quote from an earlier post from Mark:
In Windows Forms you design your user interface, then write code to drive that user interface, which generally also includes code to drive your data objects.
In WPF you invest in the business layer that drives your data objects, then design an interface that listens to your data objects.
I would argue that this is more of a design choice, rather than whether or not you are using Windows Forms or WPF. However, I can appreciate that certain technologies might be better suited for a particular approach.
Only if you don't have WPF expertise and you don't want to invest in it :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
WPF vs WinForms. What do you think about the future of the Windows Forms platform?
Count the # of times VS.NET 2008 crashes on you during a day of WPF UI development and how many times it crashes on you during winforms development. (here it's almost impossible to do serious wpf development, it crashes alot even after sp1). Winforms also has a lot of mature controls. Sure it doesn't have the fancy shiny 3d stuff of wpf, but for LoB apps, you don't need these anyway. Add to that the blurry text issue of wpf, and you'll understand that wpf has a long way to go before it's mature enough to replace winforms.
I am currently working with my third client to deploy develop a WPF application. The first was a LOB application for one of the 3 major shipping providers in the US, the other two for smaller companies.
I find Visual Studio to be perfectly stable, but I also never use the designer in Visual Studio. Expression Blend is perfectly stable, if not missing many features expected by designers.
WPF uptake is surely slower than language features introduced into Visual Studio & .Net, but it is far superior to WinForms in many ways and will be the future.
Go learn the WPF mindset and you'll never go back.
Windows forms is Honda.
WPF is Orange County Chopper.
It costs more to build a custom hand made chopper, it takes a lot more skill for a worker to do all those components by hand, it requires artistic sense, dedication and allot of work, compared to a worker in a Honda factory that only presses 3 buttons and a bike comes out.
The result?
An Orange County Chopper is unique, beautiful, stands out of the crowd, and makes it's owner prowd, but it is also harder to manufacture, costs more, requires more talent on the builders side and not everyone can do it.
And the point of this rant is?
Use WPF if you want to stand out of the crowd and your clients can afford it ;-)
My own opinion is that the adoption of WPF is pretty slow at the moment.
I have to agree with both posts above. Further, until Microsoft starts really pushing WPF in its own products, it's not really going to take off. In my mind, Microsoft dogfooding WPF is what will lead them to really address the issues that are holding it back: the crashes, text issues, and lack of pre-built controls.
I gave up on WPF because the visual editor in VStudio 2008 is so unbelievably slow!
I think WPF is firmly targeted at a group of developers who are not inclined to adopt it. I don't believe WPF was made for CRUD apps. CRUD is much harder in WPF than WinForms. I have seen examples of databinding which I just don't like. You have to run through an intermediate technology (like CSLA) to make it work well.
No, I think WPF was designed for developers who want to ship super slick, super fancy media IDEs to the public. Unfortunately, this is precisely the group which is most stuck on C/C++ and most unreceptive to managed code. For this reason, you have to question Microsoft's market-thinking.
On the other hand, Microsoft eats its own dog food, and new flavors of puppy chow are often a response to strong internal presures for better stuff. You can see why the Windows Media group and the Zune group both would like and want WPF.
I have worked with WPF on a couple of applications (one LOB, one controller UI) and I find it is very elegant and a productive tool to use. The databinding and nested control element container model are very powerful.
It is very different from Winforms and has a big learning curve. Once you have made some progress along that learning curve, though, you will never go back to WinForms - at this point when I think of using WinForms I think, "ugh!"
I guess you have to look at what WPF offers over Webforms. The only thing that comes to mind is more possibilities GUI wise, but that again make WPF a bit more complex. Most Webforms applications aren't made to look good, they are meant to perform certain operations in an easy and understanding way and there WPF doesn't really give you much over Webforms.
Maybe silverlight could give wpf a push. There are a lot of interesting possibilities with full screen siverlight apps(Photo apps, office apps, report apps...) and they would of course be easily ported to WPF apps.
I have used both WinForms and WPF and I will have to agree that WPF still needs a lot of work in order to become the UI platform of choice for LoB applications. Currently WPF is useful for creating UI with rich effects and animations, but even then there are problems.
I've seen MS's demo of a healthcare app using Silverlight and it is gorgeous. I would say that without a doubt it is the future as it builds upon the experiences of WinForm and restructures things to get around the problems of WinForm.
That said, at present WinForm is obviously more mature and probably has a shorter time to market due to the stability of the platform and wealth of resources, tools and knowledge.
I would expect that WinForm apps will slowly peter out within another decade but for now it is still a very viable platform.
Although the learning curve for WPF is a bit long I think people have started to take it under serious consideration for building new applications. But still we need a serious motivation for migrating from Winforms to WPF.
It seems that Silverlight/WPF are the long term future for user interface development with .NET. This is great because as I can see the advantage of reusing XAML skills on both the client and web development sides. But looking at WPF/XAML/Silverlight they seem very large technologies and so where is the best place to get start?
I would like to hear from anyone who has good knowledge of both and can recommend which is a better starting point and why.
Should you learn ASP.NET or Winforms first? ASP or MFC? HTML or VB? C# or VB?
Set aside the idea that there is a logical progression through what has become a highly complex interwoven set of technologies, and take a step back and ask yourself a series of questions:
What are your goals; how do you want to balance profit against enjoyment
Are you short term oriented or in for the long haul
Are you the type of person who likes to get good at something and do it a lot or do you get bored once you fully understand it?
The next and hardest step is to come to accept that any advice you are given is bound to be wrong; and the longer the time horizon the more likely it is to be incorrect. If the advice is for more than six to 12 months, the probability the advice is wildly incorrect approaches 1.
I can only tell you my story, quickly. In 2000 I was happy as a consultant working profitably in C++ on Windows applications, writing about ASP.NET and WinForms. then I saw C# and the world turned upside down. I never went back.
Two years ago I had the same kind of revelation, only an order of magnitude bigger, stronger and with more conviction about Silverlight. Yes, WPF is magnificent, and it may be that I'm all wet about this, but I believe in my gut that Silverlight changes everything. There was no doubt then and there is no doubt today that Silverlight is the most important development platform for Microsoft since .NET (certainly) and possibly since the switch to C++.
In a nutshell, here is why. I don't understand where its limitations are. With most platforms I do: you can do this, but you can't do that. WPF is a pretty good case in point, as was ASP.Net and WinForms and, well really everything until now.
With Silverlight, I don't see the boundaries yet. Silverlight has already leaped off the desktop onto phones, and I don't see any reason for it to stop there. Yes, it is true, it is bound by the browser, but I see that less as a jail cell than as a tank in which Silverlight will be riding over lots of terrain (it must be very late, I should go to bed).
In any case, for now, learning Silverlight is a gas, there is a lot of material on the Silverlight.net site, and what is the very best thing about learning Silverlight is that if you don't see what you need you can holler at me and I'll make sure you get it pretty quickly.
Enjoy, good luck and the dirty little secret is you'll be fine whichever you choose. It's all just software.
-jesse
Jesse Liberty
"Silverlight Geek"
I'd say go with Silverlight first!
I have programmed with WPF and Silverlight before.
But as Silverlight is a subset of WPF if you go in too deep and try to switch to writing Silverlight applications, you'll be scratching your heads looking for that "tag" you learned to love in WPF but is not available in Silverlight.
When you master the basic things in Silverlight first, the extra mechanism/trigger/whatever features in WPF will simply add to most of what you've already known.
Silverlight in WPF differs at the features level, not just some missing controls or animations. Take the WPF triggers mechanism for example, is not available fully in Silverlight.
So learning the smaller subset first, you can extend that knowledge to the full set later, but if you started at the full set and gets addicted to some of the niceties available, you'll have trouble down the line when someone asks you to port your designed-utilizing-WPF apps to Silverlight.
I'll go against the grain and say learn WPF first.
Here's my reasoning:
Much more resources are available for WPF than Silverlight, such as books, blogs, and msdn documentation
WPF Books
You're not dealing with a Beta, moving target
You don't have to deal with working with only asynchronous calls
Not limited by lack of features such as Merged Dictionaries, Triggers, TileBrushes, etc.
You don't have to worry about re-learning to do things correctly because of lacks of features in SL
Silverlight is a stripped down version of WPF so it should have fewer things to learn inside. On the other hand, the two platforms have different targets (web & rich client) so I guess it depends on what app you're going to build.
If you just want to learn for yourself (no app in the close future) I'd pick Silverlight because it would be less to assimilate. Still, Silverlight is pretty much a moving target, much more than WPF, so you'll have to keep up with some changes from time to time (the joys of being an early adopter :)).
WPF has lots more stuff that you will probably want to use at some point but I would wait for the needs to arise first.
Every industry expert I've heard on podcasts, blogs and interviews recommend learning Silverlight first and then gradually moving to WPF which is a huge UI framework.
Silverlight is light and allows you to work on smaller subset of controls and features such that you get your head around this new UI building paradigm based on,
Templating
DataBinding
Styles
Update: 07/2011
I hate to mention this, but in recent times Microsoft has put more focus on HTML5, Javascript and CSS by bringing forward powers of IE 9 and IE 10, as well as the upcoming Windows 8.
More and more developers and CTOs are skeptical about Silverlight as a LOB application platform as the time passes by, we are suspecting Silverlight will be limited to Windows Phone and niche, domain areas like healthcare of graphics related applications rather than a regular LOB app.
As it seems right now, as of summer 2011, the future might look fragmented with more opportunities for pure web technologies (HTML5, JS and CSS) as opposed to a plugin and OS-specific UI technology.
I would start by learning XAML, by reading a few tutorials and playing around with XAMLPad. This will give you a feel for the basics before actually building an app.
I would start with WPF and doing very simple control familiarizaton samples. You goal should be to learn XAML and Binding. So if you just create some basic WPF window apps will bootstrap your learning speed. Then eventually you can move to silverlight. Yeah as other mentioned here Silverlight is a subset of WPF.
Well, it depends on what you are going to be working on. If you are working on client/server, then I would go with WPF. If you are working in an environment where you can guarantee that .Net is installed on all of the machines, then I would go with WPF as well, because you can use what is called an XBAP, which is a WPF application that is run through the browser.
It's really up to you. However, I would state that silverlight is not RTM yet, and WPF is. WPF has a lot of books out on the subject, where silverlight does not. It may be easier to get the whole Zen of WPF by reading a few of those books, and then dive into which ever one you would like to play with.
Just keep in mind that silverlight has a subset of the controls of WPF, a paired down .Net framework, and does not do synchronous calls. As long as you know that up front, you can start learned the core of the whole foundation and tailor your practical experience later on to whichever technology is best for you.
Some tips at Getting started with Silverlight Development
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I had a discussion with some colleagues mentioning that there are not too many projects that we do which make use of WPF for creating UI for a windows application (we almost always use Windows Forms instead).
Are your experiences the same - i.e. there is not too much adoption of this technology?
Why do you think that is? And will we have a time when we see much more of WPF?
Have a look at this survey it was done by a Windows Forms Contol Vendor in Australia.
Personally I have worked on two commercial projects in the last year that were using WPF to varying degrees.
The adoption of WPF is on the rise. Microsoft I believe is putting all their eggs into the WPF basket.
WPF Rocks in terms of what the technology can do. It's simply the best UI building technology on the planet (my opinion). But, but there is a huge initial and long term investment in learning and getting your head around it. Also from tooling perspective it has barriers like unusable Cider designer, you've to get blend to do styling etc.
I am sure it will become popular, but would take time. But right now it's not so popular.
Check this thread on WPF
Check this conversation on msdn forums about WPF for LOB apps
Absolutely - the adoption is tiny. There was lots of hype but it does not seem to have materialized.
I used WPF for one project and I can certainly say it left a very unfinished taste in my mouth. It was far too difficult to acheive simple things and the whole thing had very many rough edges - the reasons behind them certainly existed but were not obvious or even visible at all. The Visual Studio designer completely bugged out for most of my pages and I never did figure out why...
All in all, I'd say WPF is barely beta-quality from a developer friendliness standpoint.
WPF has a steep learning curve, and the development tools for it (expression studio/web) are expensive, so, I'm not surprised that the industry has not jumped on it. However, in terms of Windows programming, it is much more robust and powerful than Windows Forms, so I would like to see its popularity grow over the next few years as Microsoft makes improvements to WPF, WCF, and .NET in general. If MS would decrease the price of its Expression products, I would expect to see the framework's popularity grow much faster.
Another troubling thing about WPF is the total lack of good online tutorials for the framework. I'm trying to learn WPF at home, and I have found it to be a pain in the neck. I had to fork over a ton of cash for the development tools, and then I had to pay more money for a good book because there just isn't enough online to really get me into the framework and its languages. I can learn quite a bit about Java for free just by visiting the Sun website, but for WPF, I have to get a book. There is also a terrible lack of reference materials, in my experience, for WPF. To me, it reminded me of programming in VB6. Unless these things are remedied, I wouldn't expect to see any rapid growth in the framework. I do believe the main driving force behind the industry's adoption of the WPF and WCF technologies is MS support.
Though WPF was introduced few years ago it was too raw to use it in the real world apps. Major problem that stops WPF from wide adoption is a lack of RAD tools and out-of-box components. Currently we have Blend, more or less working Cider, but usable versions of these tools came not so long ago. Another reason is a completely different architecture which leads to longer development time as compared with WinForms due to prolonged learning\adoption period for developers.
I think we will see rising of WPF in the next few years.
People usually jump the technology bandwagon when there is a a real productivity to gain. Something to compensate for all the productivity loss that normally occurs when you adopt a new platform. WPF is just not there yet. It still takes more effort and more time to build a WPF app than a Forms app, and by a long shot.
Combine this with less documentation on the net about WPF than Windows Forms, less people with WPF experience, less blogs on WPF, less books on WPF, less tips/tricks,etc.
And don't get me started on XAML. Is it XML? is it a script? is it a code? Why did they decide that a hyperlink is just a label property? A lot of things still need to be ironed out there.
I cannot afford to build my next project in WPF, it will cost me a lot more to do it (in manpower and time), with nothing to show for in return. At the moment all we do in WPF is pure-research-inhouse-hobby projects.
I'm currently working on a WPF project - my first one. The learning curve has been incredibly steep, but in the end I think WPF is a great technology. The potential is fantastic, especially for advancing the state of data visualisation. I really like the data binding features, and the potential of styling. But it really does take a while to get your head around this.
I think that Silverlight adoption will eventually drive WPF adoption back on the desktop - or maybe there won't be a desktop as much of what can be accomplished with Silverlight will replace many previously desktop applications.
I am playing around with WPF and I must say I am not impressed. I seek a technology which will help me be productive in creating business applications. I remember building my first classic ASP website and being disgusted at the spaghetti code required to build a simple app. Viewing a single page I found HTML and java script mixed with vbscript with include files and calls to com objects--in short, a bloody illogical mess. In my view, it is important to have a simple and VISUAL development model with standards. I built many VB6 and .Net windows apps and they have a simple metaphor for development, making them easy to debug and modify by developers who did not write the original app. Forms encapsulate presentation logic, modules and classes in referenced assemblies encapsulate business logic and data logic. ADO.Net and other tools make data access robust, scalable, dynamic and customizable. Resizing windows controls and graphics to suit monitor resolution or client preference is easily done with Win Forms.
It may be that WPF has many advanced features in graphics, but for most business apps, form should follow function--in other words, I am not putting goofy animated graphics on my banking windows app.
One of the reasons I have not liked web development is because of the wide variety of ever-changing and complex technologies required for relatively simple applications which don't deliver enough significant change in actual functional results.
Oh well, that's my two cents.
' )
We deployed a pretty major WPF application for a large investment bank I worked for. It turned out extremely successful, involving 3d visualization of OLAP data that allowed quicker trend analysis. It's being used extensively.