Related
Taking into account that I'm not familar with both of these technologies what should I start to learn? It seems I should use WPF as it allows "much more"?
Should WPF be used instead of Winforms? Is WPF substituting Winforms?
Like everything else,..it depends. Are you a professional or hobbyist? If you're a hobbyist then learn both. Winforms first, then WPF/SL because,...well,...why not? It's good to have a solid background understanding.
If you're pro then don't waste your time with WinForms, the time you'll spend learning the intricacies and of everything will not likely translate to any real benefit for your career unless you enjoy working in customer support or on legacy systems. Some do but most probably don't.
The learning curve of WPF and Silverlight is a little steep at first but it's not as bad as some say and if you've done any decent amount HTML in the past and you're used to declarative UI, it's really quite straight forward. Much easier than CSS anyway!
It's also worth considering that given the current direction of MS platforms and WinDev at Redmond, some might argue that you should take a look at WinRT and 'Metro style' apps right now too. Google/Bing the Build 2011 sessions and start there.
Good luck with everything :-)
HTH
Depending on your background WinForms could be easier to get a hold of initially, generally WinForms is easier to pickup and learn compared to having to learn WCF. There is a lot of legacy WinForms applications still out there that will be around for a long time.
There's plenty of related questions on the bottom right of the page.
Here's one such https://stackoverflow.com/questions/2703681/winforms-vs-wpf.
With all that said, if you're starting fresh it might help to learn WPF straight away so you don't have to re-learn things later on. So it really depends where you want to focus your career for the next little while (you can always learn the other if you need to, many have done that).
WinForms are much older than WPF, they exist since Win95 if i can remember. WPF is released as a module of .NET 3.5, it allows you to do powerful animations, complex graphic effects and a lot of beautiful things and which make life a lot easier :).
In general, WPF is the future. SO it's up to you ;)
Take a look at some WPF tutorial websites, for example, like this one: http://www.wpftutorial.net/WPFIntroduction.html, and see if you feel like you are going to go with WPF.
Besides, if you are familiar with mark-up language, XAML shouldn't be too hard for you to learn. And then from there, you can try building some simple WPF applications, and probably you will start to love it once you feel the beauty of WPF.
As for Winform, it's kinda old .NET technology. Not that it's totally not worth using/learning it. There are still large numbers of .NET application out there using Winform as its UI. It's still a good way to get familiar with .NET controls and some basics. But for the long term, you probably should focus more on WPF.
I was not so lucky as you to pick between WinForms and WPF, so I learned WinForms five years back and WPF a year back.
I do not regret it because there are a couple of things that WPF cannot do and we have to fall back to WinForms. Other times, there are WinForms components that you end up using in your WPF application because it is something that is developed by someone else.
At the end of the day, I was really happy how I could appreciate the ease of communication between the view and the view-model because I knew how difficult and mixed up it was in WinForms. So my two cents worth of advice is, do learn WinForms because it helps you appreciate WPF.
WPF is designed to replace WinForms which became obsolete years back. However, as you can see, the older .NET 2.0 stack is still in use because of Windows XP and WPF is present from .NET framework 3.5. So, learn both but your focus should be WPF.
I created this around July this year using WPF: http://www.youtube.com/watch?v=Y4qfFrZGKlA
Winforms are easier to understand, in my opinion. WPF is more designer's stuff than programmers.
Anyway, WPF is more modern technology, more beautiful, and if it's what you're seeking, you may skip the winforms part.
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.
For a developpeur who as to do a project with WPF or Silverlight (xaml code), is it trial to learn some design (basics) and to handle blend? Beacause in France there isn't much blend professional (compare to photoshop users) and the price/day of a blend designer is very high.
What I am sure is there i ain't no artist, but it could be interesting/fun to learn something that different then pure code. So my question is mainly for designer or developpers that had to learn some design, is it that hard for a custom design?
The principle of design are not difficult to learn but they're not always easy to put into practice and that's why it's considered an art rather than a skill. Certainly WPF/Silverlight is a designers dream as far as desktop UI is concerned since it's VERY flexible so you'll find few restrictions on what is possible when compared to other technologies. Blend works well with them too and it's not that tough to learn.
To start learning design as a developer, i'd suggest you take in as much material as possible and pratice,..a LOT. Read design blogs like the ones here and read plenty of books. Some good starter books are The Non Designers Design Book, The Design Of Everyday Things and Don't Make Me Think. I know they all really help when i started to look into UI and interaction design.
Hope that helps.
A great way to find your way in the design world is the Principles of Design Series on Microsoft Showcase. These videos explain things like Rythm and Unity.
There are a lot of other videos that should help to find your way around Expression Blend and Silverlight.
One thing that works for me all the time is to look what others do and use that for inspiration in you own design. Just google-image or bing-image for you are designing or see if it is in the Infragistics UX explorer.
I understand your question as I went through the same thing. I've done plenty of web sites over the years, but I never felt as though they had the "zing" a good graphic artist could provide. Because of this, I had concluded some time ago that to really take my skills to the next level I had to learn at least some graphic design, but I never did anything about it.
That changed when I started learning WPF. I quickly decided that I needed to learn some basics, especially when I started using Blend which was a whole new world after living in Visual Studio for so long.
To jump start my graphic artist education, I took an introductory course at our local community college. It was worth every penny: I was exposed to principles of design and some key software products like Adobe Photoshop and Illustrator. Understanding them made Blend finally "click" for me. The experience has proven invaluable to me as a WPF developer, and I would recommend it to anyone interested in UI work.
WPF Silverlight have a lot of power however even when mastered it takes a lot of time to design a simple form say using a tab control using lots of grids with rows and columns and stack panels than it would on a normal desktop. Also it can be quite sloppy looking back at the XAML code just from a design point of view unless your using lots of windows which i try to avoid, i would rather have a tab control with each tab acting a a window. Anyway from a design point of view it is much more time consuming than a desktop application. You will find a lot of developers will use it as they are not good in code behind. So it depends on the program you are writing. ?You can make your program look very good from default controls and the listview is always a great control. Many will disagree because they think they are great developers and most likely will talk the usual no one want's to hear!
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.
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