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
Related
I know such questions have been discussed here but have never seen them to be put it in this new light. We all know that WinForms isn't updated anymore by Microsoft. For client apps they are pushing WPF now. And people say WPF is harder to learn (I don't know, haven't tried really. And when I've tried I didn't much like it). But on the other hand, could that be it is just WinForms is perfect and there is nothing more to be done here?
WPF is in deed much harder to learn as WinForms. However it is really powerfull and gives you a lot of new possibilities. (I like the DataBinding-features and Templating really a lot).
WinForms on the other hand is very stable and is built on Win32. I'm sure it will be supported for a long time in future. But for me it's clear that microsoft will not extend the features if they have a new concept out there. Would you extend your old app, if you have a new one?
For me, I have switched already some years and I have never regreted the change. However, I have a lot of clienst with WinForms-apps, I built before and I don't have any hurry to update them to WPF. I never had a problem with WindForms, it is really a good and reliable product. As for your question: I think really WinForms is complete. It represents its time and has the features, this time had to offer. However, it's not perfect, no software can be perfect. Furthermore, I know also a lot of companies, developping new Apps with WinForms. MS will surely not letting die a technology for which so many apps exists. Look at XP, it will live longer than Vista.
Hard to learn is subjective.
I started learning winforms and WPF about the same time and I definitely feel more confident using WPF and feel I have picked it up quicker simply because I didn't have to "unlearn" winforms.
Sure, some WPF concepts are harder to understand at first but once they click into place you will start making progress and won't look back.
Saying that both technologies are great. Winforms Ace card is that it is mature, stable and easier to find help for.
Saying this, your question has a hint of "I'm not sure which one to choose so need someone to tell me" - The best advice is pick one and get on writing your application. Great applications can be written in both WPF and Winforms.
WPF is definitely better than WinForms, when you develop any LOB application its a high priority that how well you manage your code/project. When using WPF you have the power of following:
Separating your view from logic (the power of xaml, easier to read and design)
You can implement MVVM which gives you great control of your code. When working with multiple teams on a big project its a big plus.
On top of all that you can choose to use a framework like MVVM light, or use Prism 4.0 which not only helps implement MVVM but has other features too.
Another big advantage is, once you develop an application in WPF, you'll be able to develop in Silverlight with great ease. and with Silverlight 4 you have the capability of running your app out of browser without coding. Same app will run on desktop, cloud, web.
Finally I would say I wouldn't use WinForms because its 2011, WinForms is 90s...
For the past 5 months or so, I've spent time learning C# using Andrew Troelsen's book and getting familiar with stuff in the .NET 4 stack... bits of ADO.NET, EF4 and a pinch of WCF to taste.
I'm really interested in graphics development (not for games though), which is why I chose to go the .NET route when I decided choose from either Java or .NET to learn... since I heard about WPF and saw some sexy screenshots and all. I'm even almost done with the 4 WPF chapters in Troelsen's book.
Now, all of a sudden I saw some post on a forum about how "WPF was dead" in the face of something called Silverlight. I searched more and saw all the confusion going on at present... even stuff like "Silverlight is dead too!" wrt HTML5.
From what I gather, we are in a delicate period of time that will eventually decide which technology will stabilize, right?
Even so, as someone new moving into UI & graphics development via .NET, I wish I could get some guidance from people more experienced people. Maybe I'm reading too much? Maybe I have missed some pieces of information? Maybe a path exists that minimizes tears of blood?
In any case, here is a sample vomiting of my thoughts on which I'd appreciate some clarification or assurance or spanking:
My present interest lies in desktop development. But on graduating from college, I wish to market myself as a .NET developer. The industry seems to be drooling for web stuff. Can Silverlight do both equally well? (I see on searches that SL works "out of browser").
I have two fair-sized hobby projects planned that will have hawt UIs with lots of drag n drop, sliding animations etc. These are intended to be desktop apps that will use reflection, database stuff using EF4, networking over LAN, reading-writing of files... does this affect which graphics technology can be used?
At some later point, if I become interested in doing a bit of 3D stuff in .NET, will that affect which technologies can be used?
Or what if I look up to the heavens, stick out my middle finger, and do something crazy like go learn HTML5 even though my knowledge of it can be encapsulated in 2 sentences?
Sorry I seem confused so much, I just want to know if there's a path of least resistance that a newcomer to graphics-technology-adoption can take at this point in the graphics world.
I understand your confusion (having been there myself), but first let me start by saying Silverlight and WPF are not dead yet! And you would not be wasting your time in learning either!
There are quite a few (terrifying) posts to the contrary, but if you keep searching you'll also find those that support WPF/Silverlights extended life in development, one for example is http://www.wpfblogger.com/post/Silverlight-is-not-dead-clarifies-Bob-Muglia.aspx (this is a nice summary of what Bob Muglia said - there's a link to his full statement). Another assurance is that Microsoft has invested quite a bit in WPF themselves in designing VS2010 in it, so its not likely that they're about to give it the boot.
As for your hobbies and projects, if you intend on sticking to desktop clients I recommend WPF of which Silverlight is a subset, so you'll find that the transition isn't anything major on the face of it (there's a few more controls and such in WPF that aren't in silverlight and gives more flexibility for desky stuff [here's an article you can read if interested - http://briannoyes.net/2010/06/01/WPFNdashIrsquomNotDeadYet.aspx ]), this should be able to handle most of your stuff including playing with 3D objects (to create them I'd use something like Blender 3D, its free but the learning curve for a first timer is kinda steep).
Lastly, it probably wouldn't be a bad thing to learn HTML5, but booting out Silverlight to do it probably isn't the way you want to go. There's bound to be ways in which Silverlight will enrich the browsing experience even with pages using HTML5 in the future, so don't kick it all out yet :)
My present interest lies in desktop development. But on graduating from college, I wish to market myself as a .NET developer. The industry seems to be drooling for web stuff. Can Silverlight do both equally well? (I see on searches that SL works "out of browser").
The industry likes the web because deployment is easy and you usually don't have to support users running different versions of your application. Still, are reasons to choose WPF over SL (performance, things not yet implemented in SL). I'd say stick with learning XAML + C#. You'll be able to leverage it for WPF, Silverlight, and Windows Phone programming.
I have two fair-sized hobby projects planned that will have hawt UIs with lots of drag n drop, sliding animations etc. These are intended to be desktop apps that will use reflection, database stuff using EF4, networking over LAN, reading-writing of files... does this affect which graphics technology can be used?
Either way, database access should be done through services (not directly from a WPF app). There will be differences, but they should be mostly similar.
At some laaaater point, if I become interested in doing a bit of 3D stuff in .NET, will that affect which technologies can be used?
Silverlight 5 will have 3D support. Beta should be announced by this year's MIX conference and released by the end of the year. In the meantime, you can check out the WPF 3D API.
Or what if I look up to the heavens, stick out my middle finger, and do something crazy like go learn HTML5 even though my knowledge of it can be encapsulated in 2 sentences?
While SL is nothing like web programming, I think there is an expectation in the market that SL programmers should have a little ASP.NET (Web Forms or MVC) experience too. (Because, hey, you should know how to work with the environment its hosted in.) I think HTML5 is still a ways off since HTML5 applications will require users to have the latest browsers which are just coming out. Still, couldn't hurt to know it :-)
Fear not, WPF and Silverlight is going to be strong in Line of Business applications, there are some serious security features added even in SL5 and it ties in nicely with all the existing Microsoft infrastructure most corporations have.
It's a similar thing to all the bloggers crying the end of Flash after seeing some planned HTML5 features (and yet not even the codec for the video tag is settled), but upgradeable runtimes to support any browser (IE6 corporate market share is still sky high...) and the really nice Microsoft developer stack (VS + Blend) makes these technologies more resilient than people only using cutting edge technology would think.
Having used Flash for years before Silverlight I can tell you that developing custom UI with SL is a really pleasant experience, so if you're less into multimedia and games (which are areas where Flash still has edge), this is the place to be for you.
And there's Windows Phone 7, with the Nokia strategic partnership I doubt no one would want to get anything developed.
These being said, if you have the chance don't be afraid to venture off to learn some completely different programming languages, for me personally learning Ruby on Rails changed the way I look at backend development, and some of these eye opener ways of doing things more efficiently transfer nicely between environments.
WPF and Silverlight are definitely alive and well. Also, don't let people fool you into thinking it has a "steep learning curve" (which is a common myth.) WPF isn't a walk in the park, granted, but it is also not the hardest thing to learn.
I recommend the book "WPF 4 Unleashed" by Adam Nathan.
http://www.amazon.com/WPF-4-Unleashed-Adam-Nathan/dp/0672331195
It will teach you everything you need to get started with WPF (and Siverlight, which is WPF-based.)
Yes, silverlight can do desktop and web environment equally well, and is your best bet right now. As for 3D designs, you might want to learn XNA. Its quite easy to use.
It is time to write the GUI for my project, and I am wondering what technology to use. I did most of my .NET GUI development in .NET 1 & 2, so I know Windows Forms reasonably well. I am vaguely aware of WPF, but not yet attempted to "get into it".
Are Windows Forms dead or dying? Is WPF a good technology to learn? Is it the future, just a phase, or a technology that can walk hand-in-hand alongside Windows Forms?
Also, any experiences will be good to hear, especially from people who have used both extensively. How did you find implementing a similar feature in both frameworks?
Are WinForms dead or dying?
No. It is not significantly developed further (i.e. no new major additions), but it is fully supported in .NET 4, for example.
Is WPF a good technology to learn?
Yes.
Is it the future, just a phase, or a technology that can walk hand-in-hand alongside WinForms?
It is intended that you eventually move over to WPF, but it is also understood that there are large existing codebases written in WinForms, and there's no business case for rewriting them in WPF. Hence WinForms remains supported.
Also, any experiences will be good to hear, especially from people who have used both extensively. How did you find implementing a similar feature in both frameworks?
Broadly speaking, WPF is much more expressive. If you look at frameworks as set of Lego bricks that can be put together in various ways, WinForms bricks are much larger - each one does a lot - and therefore there are fewer ways to put them all together. Quite often, when you need something-but-not-quite like what an existing brick does, you have to write your own from scratch. In WPF, the bricks are significantly smaller, and can be combined in many interesting and even surprising ways.
For a concrete example, consider how WPF Button is a container that can host arbitrary content - not just image+text as in WinForms, but absolutely any other WPF control or set of controls.
WPF is also much easier to write dynamic layouts in compared to WinForms. The latter has layouts, too, but the problem is that they're a royal PITA to work with in visual designer, and writing WinForms component initialization by code is very tedious. With WPF, you just write XAML markup by hand, and layouts (and control trees in general) are very naturally represented in XML.
Partially stemming from the above, I find that WPF is easier to localize. For one thing, it's because you really do need dynamic layouts for localizability (since you don't know in advance the length of the strings in all locales). WinForms solution to this is to consider not only text labels, but also control position and size, as "localizable property" - so the translator is supposed to rearrange controls on the form himself if he finds that strings don't fit. In WPF, dynamic layouts are the default approach, so localizer just deals with strings.
WPF binding framework is rather powerful (even if verbose, thanks to lack of inline converters), and heavily promotes MVP, and, in general, model/view separation. This is possible to achieve with WinForms in 2.0+, and I try to do that there as well, but it's more tedious, especially with respect to null handling, and sometimes can be rather buggy.
One particular pain point is the way WinForms designer interacts with source control. There are two similar problems here. First of all, designer serializes edited form as code, and sometimes very minor changes in layout can make the designer generate completely different code (this is particularly noticeable if you edit toolbars) because it shuffles the code lines around - i.e. in reality it changed a single property value on one line, but it also reordered everything. This leads to very much noise in history (it's nigh impossible to tell what exactly was changed when looking at diffs), but more importantly, it means that merging such files is a major headache. This usually happens when two people work with the same form at the same time, and then one commits his changes, and the other one tries to commit, finds out that the file was changed in the meantime, tries to merge, sees the diffs, and jumps out of the nearest window.
A very similar problem happens when you use WinForms localizable forms, which pushes some properties to a resource file. Again, the designer very much likes to reorder property values in resource file for any trivial change, with all the same problems as described earlier.
Now as to deficiencies in WPF. A major one is that it's quite a bit more complicated, and may feel unfamiliar to someone with experience only with WinForms, VCL, VB, or other similar "traditional" frameworks. Another problem is that documentation, in my opinion, is not perfect - it usually gives a decent overview, but rarely covers corner cases, some of which can be pretty important. This is the case for WinForms, too, but there are fewer possible combinations there, so fewer corner cases as well.
There's also the issue of third-party components. WinForms had been around for a long time now, and there are plenty of those available for it, and a lot of them are very mature. WPF is comparatively young and still going through growth pains, and so do most third-party solutions for it.
One particular pet peeve of mine in WPF is the way it antialiases text - which is perceived as being of much worse quality compared to plain Windows ClearType by most people, especially on small font sizes; see this bug report for more info. This is fixed in WPF 4, but that isn't released yet, and even when it will be, chances are that you'll want to stick with the tried and true 3.5 SP1 for some time; and the fix isn't backported.
WinForms aren't dead or dying...they just can't provide the same User Experience that WPF can (without A LOT of work). They're just older technology.
WPF is a good technology to learn. It provides the ability to provide a much richer User Experience with less work.
The model for working with WPF is definitely different than WinForms. I've used both (WinForms more heavily than WPF/Silverlight) and the most difficult transitions for me were:
XAML, which isn't as bad if you have experience with another markup language like MXML.
DataBinding
Interface Event Handling (MouseOver effects, Timelines, etc.)
WinForms is far from dead/dying. WPF is simply a newer way to tackling the UI as it promotes things that were more difficult in WinForms. Things like separating the model behind the UI from the actual UI so it can easily be tested is a big factor.
It's definitely worth learning, but make sure to learn "the WPF way" of creating the screens rather than just fitting your WinForms-way into it. It's a different way of coding.
Perspective from 2016:
I don't often advocate chiming in on a question this old, but thought an epilogue may be appropriate on this one. Why? Because even now (2016), I hear developers in corporate environments still asking this question.
Yes, seven years later, WinForms is still alive in corporate environments, and still supported by Microsoft. Google Trends shows a slow, steady decline in interest since mid-2005, with current interest about one-third of 2005's.
WPF made a splash about 2009, but never fully took over as the de facto standard for new UI development. Google Trends shows WPF interest peaking from 2009-2011, then declining faster than WinForms. Current search interest is about half of 2011's, but still nearly double WinForms' current search interest.
So what ARE developers using now? Web-based UIs have exploded in popularity, largely due to the rise of mobile browsing. You could argue over the best way to go about writing a web UI (AngularJS + WebAPI? ASP.NET MVC? React? All are trending upward on Google Trends). Whichever technology you use, it's hard to deny the appeal of writing a (responsive) UI once and having it work on just about all devices and platforms. Cloud hosting services furthered the push to the web by offering virtually instant/infinite scaling with low up-front infrastructure investment.
So today, I'd heartily recommend moving toward a web UI, as it may improve the shelf-life of your app--which often need to last very long in corporate environments. Alternately, if you're a Microsoft-based developer doing mobile development, Xamarin is worth a look.
WinForms will probably be around for a long time to come in corporate environments. They work well enough for many purposes. Many projects are based on WinForms, and many companies will stick with that technology for the duration of projects rather than mix and match.
Having said that, WPF is the future. It is a much more efficient, much more capable UI technology and well worth learning.
WinForms and WPF can coexist in a single application. That will probably be the most common way for them to be introduced to a company (that, and small proof-of-concept projects).
Certainly not.
Winforms are easier to use (Considering you don't know WPF yet) and WPF is quite a departure from the Winforms model.
If you want a simple GUI (standard form stuff) go with Winforms. If you want something a bit more flashy and have the time, go for WPF.
I'm sure there will come a point in the future where WPF is the defacto standard. But for now, I stick with Winforms if I want something quick and clean.
It's worth mentioning that a lot of applications are already using Winforms - meaning maintenance work will often crop up involving WinForms, so don't rite it off just yet.
WinForms is not dead. Google "winforms C# jobs" and you'll find plenty. WPF is the hot stuff but it's still relatively new. It won't be mainstream for another two to three years IMHO.
Here is a good blog post about WinForms and WPF. The overall idea is to choose wisely, meaning that there isn't one winning over the other. Each have a different subset of features.
Making the decision between WPF and WinForms however is a different story. Sure, WPF is the new hotness and WinForms is old and busted but is it the right choice? Obviously "it depends" on the situation and Microsoft is continuing to deliver and support WinForms so it won't be going away anytime soon. So what are the compelling factors to choose WPF over WinForms? Karl hints at choices of WPF over WinForms in his WPF Business Application series, but the reasons might be subtle for some.
I personally prefer WPF because I started as a Web Developer and find the markup XAML to be more natural.
I think it's definitely worth learning WPF before it becomes more mainstream, it's always good to improve your skillset and to have experience and knowledge of newer technologies is always a plus, especially if WPF is to be more widely used in future.
Also, whilst writing xaml mark-up is very different to creating forms, it's not a million miles away from writing html and will probably not be too much of a departure for you if you've done any web development.
Whilst WinForms is an older technology that doesn't mean it will ever disappear though, we still have applications where I work that are written in VB6. Only half of our development department work with .NET - we're split into 3 teams, one team is still using .NET 1.1, another team is using .NET 2 and the team I'm on is using .NET 3.5 (you could say we're the lucky ones!)
We started using WPF for a new project and frankly, it's hard to go back to WinForms. Lots of neat stuff that I can't go withouh anymore.
One word of advice though. Even though you can do much more complex layout with WPF (like it's mentionned, a button, or almost anything really, can host other stuff like image, textbox and even more), some other 'basics' stuff found within WinForm are hard to reproduce.
Example : Before the WPF toolkit came out, WPF didn't have datagrids and datetime picker, so you had to do it yourself. Also, it still doesn't have MaskTextBox, you have to do it yourself or download it from third parties. Last one I ran into which I actually find annoting is with Treeview : the lines between leaves and parents doesn't show.
That being said, still much better than WinForm on most aspects.
we start using wpf in a new project we have
the new application includes a lot of legacy code in winforms.
whenever we want to use old dialog of winforms it is possible.
when you getr use to WPF you don't realy want to go back to winforms. it is just much more easy to do GUI stuff that woul take you lot of time in winforms.
any way it take some time to learn the stuff and be able to use all it's abilities (not just UI but also data binding and commands pattens).
having somone experienced that can help with first architecture can be very helpful.
I am beginning to heavily invest in WPF and was wondering what those more knowledgeable than myself thought as to the wisdom of this decision. Is WPF the way forward?
Yes, it is the way forward.
WPF and using XAML for interfaces has completely revolutionised the way in which we develop said interfaces for our customers. The possibilities are endless, the learning curve is large, but with merit.
We can now do things in XAML that we couldn't dream of doing 3 years ago with WinForms - or things that take a few lines of code and an hour of logic that would have previously taken a full week of logic and four class files.
It's definitely the way forward for MS development, however there will always be people using WinForms.
They even developed VS2010 with WPF, that must give it something, right? ;)
Microsoft itself has begun developing its enterprise applications in WPF. They are invested in keeping it going for themselves, no reason to believe that the rug will just get pulled. Also, WPF has the Silverlight subset, which doesn't seem to be losing steam.
XAML is a nice, declarative method of setting up your interfaces with a lot of slick value conversion done for you and the opportunity to add more behind the scenes. It's possible to separate it from WPF, however (although they generally go hand in hand).
I understand that .Net 4 has made some progress toward using the XAML declarative language in Workflow Foundation and in Windows Communication Foundation, which will be interesting, given that those two are already fairly heavily declarative XML driven.
So, XAML is definitely the way forward for MS, especially given that at the core it's nothing more than a way to construct an object graph - any object graph.
WPF is also going to take some strides - for instance, inclusion of the much missed DataGrid (there are excellent commercial alternatives already), and more complex pixel shaders which should push more work to the hardware and increase rendering and startup speed of WPF apps.
As to whether WPF is THE future? Yes, for people who are tied to Windows, who value stylus input and handwriting recognition and who can find space in their development budgets for attractive UI development.
Against Flash, Flex, DHTML in general? I don't know. I'm inclined to think not - most applications don't need the full power of fat client development and don't care that much about pixel shaders et al, happily trading it against the accessibility of web.
Silverlight and XAML are not seamlessly cross compatible, and WPF doesn't transfer automatically to the web. (Yet?) Nevertheless I took the gamble on skilling up, and have found it to be time well spent. If nothing else, it's fantastic for prototyping.
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.