I'm Confused - WPF & Silverlight

I hope you'll forgive me if my question strays a bit from the main focus of this forum. The conversation that sparked this question did take place here in a CSLA-related thread.

I'm confused about WPF and Silverlight...

I've been researching WPF and Silverlight because of a UI suggestion you (Rocky) made for my business objects in a different thread. That research has led to some confusion.

A few years ago when I first read about WPF, the article said Microsoft was going to combine the best features of Windows forms and ASP.NET into one technology that would be used for both Windows development and web development. I remember thinking.....if such a silver bullet is possible, that sounds awesome!

Later I read about Silverlight, which was described as WPF's little brother who was smaller and more portable for the web. And I was puzzled by this overlap between WPF and Silverlight because it seemed contradictory to the idea of moving to one programming technology for both Windows development and web development.

From what I've been reading this week, it appears the lines between WPF and Silverlight have become even more blurry (like Silverlight running outside the browser, accessing databases, etc). And some people on the web are predicting Silverlight will eat it's big brother (WPF) in the next year or two. Other people seem to think we're back to 2 technologies again - WPF replacing Windows forms and Silverlight replacing or enhancing ASP.NET.

So now I'm totally confused about the differences between WPF and Silverlight and what Microsoft's intent is for both of them. I am not seeing a clear path ahead for either technology, which makes it feel unsafe to switch to either one right now.

Can anyone provide any information that might help clear my confusion?

If it's any consolation I feel exactly the same Jason, it's confusing the hell out of me! 

On top of that I can see absolutely no good reason for leaving behind winforms (Microsoft that is, rather than CSLA), which as far as I can tell do the job absolutely fine on the desktop.  If there's one thing my clients really don't want, it's their users spending any more time on the internet, which they see as inevitable if their software is browser based.

[pulls up a seat and waits for someone who knows what they're talking about]

Here's what I know and opinion,

Silverlight is more light a runtime environment for you application, which can be hosted in a sandbox or in the browser, or comming soon...a sandbox outside the browser.

PROs: WPF is a markup language for defining forms that provides more flexibility than WinForms. For example people love to show silly stuff like buttons embedded in pictures embedded in buttons in demos. But where WPF will have the biggest effect is likely to be in making you application look spectacular, it can give it the nicest dress at the ball, regardless of whether it works, or even does its job well. Eventually, if you have software in the commercial market you will need to put that better dress on your product or it will begin to look dated.

CONs: However, until third parties (artists and designers) start delivering cool widgets and skins for WPF, its not going to be that attractive to the average business application developer in regards to improving the appearance of their applications, as they typically aren't artist and designers, and don't have time to learn how to use the new design tools, and need to turn out new applications quickly all the time. WPF currently lacks a lot of the drag-and-drop abilities provided by WinFrom controls.

Counter point: Some gurus (Rocky Lhotka and Billy Hollis, etc) say that WPF even in buiness application development can make you more productive, but you need to invest a lot time leaning how it works and how it should be used.

Where I am...holding back as long as I can to work with WinForms, as I like its drag-and-drop and I've got a lot invested in it already, and whiz-bang is not needed for the busines form-like applications I deliver. Also, I use offshore developers, who I haven't the extra time to guide them through how to manage the complexities of this new UI. Moreover, the WPF code ends-up in your main form, not the code behind file, and it's hard enough to get everyone on the team to write well formatted and standardized code that is easy for eveyone to maintain, without having the IDE sticking markup text everywhere in that file.

But again, the gurs say WPF is the way forward, and while I hope business applications will revolt against WPF and encourage Microsoft to develop WinForms for years to come, I realize I may actually have to move to it sooner rather than later, (probably middle to late next year). In the meattime, I'm hoping Rocky will follow through with his promised eBook for later this year on using his current version of CSLA with WinForms.so that I can live without WPF for another 12 to 18 months.

Cheers,

Des

 

 

Hmm... I had heard SL was supposed to be a subset, but that they added some new features (VSM) to make up for a lack of Wpf goodies. The new features ended up being "better" than the Wpf way, so they are planning to porting them into Wpf... so SL is being developed more rapidly, taking what it can from Wpf, but sometimes finding better ways to do things.

DesNolan:

I hope business applications will revolt against WPF and encourage Microsoft to develop WinForms for years to come, I realize I may actually have to move to it sooner rather than later, (probably middle to late next year).

Ack... WinForms, while having better tooling, is no where near as flexible and powerful as Wpf. The tooling will be there (soon I think too), but Wpf is definatly a better, more consistent technology.

I'm not sure what you mean by Wpf code "ends up" in the main form.. I use code behind files extensively. I do like that I can do more using Xaml than I could in WinForms, because anything in Xaml could conceivable be "toolable," meaning its code I won't have to write.

I think this is a typical Microsoft thing: No clear strategy, two separated development teams (with great and fantastic developers) trying to beat each other...

Or if you put it in another way: Simply bad management!

 

There's no question that the positioning of these two technologies is hugely confusing, and it's not really clear to me why Microsoft is allowing this to continue.

Nominally, Silverlight is supposed to be the lightweight, sandboxed version of WPF, but as others have mentioned, development on the two products is occurring independently, with some amount of feature synchronization back and forth.  I really hope they've got a good reason for doing this, but in the mean time, it's creating a really uncomfortable situation for architects and developers.

I'd much rather see them develop Silverlight as a true subset of WPF, reserving the "heavy" and non-sandboxed features for namespaces that are only available in WPF.  They need to ensure that control vendors can sell controls that will work in both environments, too.

In the mean time, the existence of both of these technologies without any cogent statement about how they're going to coexist as they move forward creates the impression that both technologies are pretty unstable with respect to product management.

Hi,

The following is the official Microsoft site for WinForms and WPF

http://windowsclient.net/Default.aspx

And the following is a paper from that site by two Microsoft writers putting both technologies in perspective

http://windowsclient.net/wpf/white-papers/when-to-adopt-wpf.aspx

Des

If u take a look at the "Composite Application Guidance" framework u can see that (with the help of a projectlinker tool) WPF and Silverlight are close related, only the xaml file is a bit differend with namespaces. Ok and several business parts, but using CSLA 95% of the code works on both platforms.

For what it is worth, here's my take.

The long-term goal is for Silverlight to be a true subset of WPF (which means WPF would be a true superset of Silverlight). That is not the case now, and won't be the case in .NET 4.0 or Silverlight 3.0.

So now, and into the foreseeable future these two technologies have large regions of overlapping functionality, but each have unique elements that are unavailable in the other technology. Clearly Silverlight is smaller and simpler, and WPF is larger and more complex.

To mitigate some of this today, you should get the SilverlightToolkit and WPFToolkit from CodePlex. And .NET 4.0 and SL 3.0 will help, but won't completely solve the mismatch.

Given all that, my default start position is, and will be, Silverlight. I'll only fall back to WPF if there's some specific requirement (business or technical) that prevents Silverlight from meeting my needs.

This is strategic. If Microsoft does achieve the true superset/subset goal, then you can't go wrong by targeting SL, because that code is then guaranteed to run in WPF. But the reverse isn't true, so starting with WPF pretty much prevents future use of SL.

But it is also tactical. SL deploys in a simpler manner than WPF. ClickOnce is good, but it still isn't as smooth as the browser-based SL model.

And SL is smaller and simpler. I keep working in SL, and rarely do I miss anything from full .NET. Now maybe this is because I'm doing CSLA coding, and my server is .NET and my objects are mobile - but I find that SL has everything I've been needing to build my UI and business layers, and .NET provides what I need to build the data access layer.

If I needed to do Office integration or something more extensive on the client I'd obviously have to switch to WPF, but most of the apps I've been working on haven't had those requirements.

Taking this thread to the next step, is it useful to use the Patterns and Practice "Smart Client" of Composite Application Guidance for WPF and Silverlight, aka Prism (http://compositewpf.codeplex.com/), with CSLA? Is the Prism functionality redundant to the capabilities in CSLA, or complimentary?

Like others, I'm looking which way to move forward, and "Smart Client" is the technology buzzword management is very interested in using.

Thnks in advance for any thoughts and opinions.
MBB

Prism and CSLA .NET are complimentary.

Prism is a UI framework designed to help you create powerful XAML-based
interfaces.

The focus of CSLA is to help you create a powerful business layer -
something Prism doesn't do at all. CSLA .NET only has a tiny bit of UI help
in the form of some controls that fill in gaps in XAML.

You'll have to decide for yourself whether Prism has value to you. It is
simpler than CAB, which is a step in the right direction. But I keep looking
at these UI frameworks and wondering why such a complex solution is needed
for such a simple problem.

But then again, part of CSLA's complexity is for the same reason - it is not
a targeted solution. Any solution that works for 2+ organizations is, by
definition, more complex than something created to solve one organization's
specific requirements.

I keep creating simple UI frameworks for my needs. Each one takes just a day
or two to build, and they are typically very simple. But they are designed
to make that application work, not to make _any_ application work, and I
guess that's the challenge with something like Prism.

Thx Rocky,
That verifies what I suspected. Getting comfirmation allows me the freedom to invest more time into Prism.

This application has a variety of data entry screens and needs to allow users to navigate to related information/entry screens. A good UI framework will have a lot of value for this, just like CSLA has a lot of value for the business and data.

The comment about complexity brought on a laugh. If done well, complexity in the framework can greatly simplify the specific application code, provided the pattern of the framework is actually used in the development.

MBB

Honestly.

I'm 55 and pouring what's left of my so-called life into a technology that has a shorter lifecycle than me is troubling at best.  I hate do-overs (since I'm not getting one).

All kidding aside, while I was leaning to WPF, Silverlight looks like the obvious choice for me because it gives me the best flexibility for an uncertain future.

OTOH, it simply doesn't look like it's ready for prime time as hand coding all kinds of code in a designer-less environment seems even less productive.  Reminds me of HTML and notepad.exe.

Since Rocky has never steered me wrong, I'll guess I'll try SL.  But it scares the hell out of me.

As for distinct design teams, does anyone remember the Lisa and the Mac?  I don't suppose the Lisa guys were bitter or anything.

I did see (once in the 80's) a coding team of six people writing COBOL code using Edlin on PC-DOS 1.x on the 25th floor of a highrise in Manhattan (insurance industry, of course). 

I told them that IBM had a full screen text editor and I thought that might help them and they looked at me like I had two heads.  The ROI on those guys in that real estate must have been *pretty* small.  :)

Well, if you target SL, it should be exteremly easy to move to Wpf, if you have a need. The other direction, not so much, but still doable.

I don't think this is like Mac vs. Lisa though.. SL continues to get features already in WPF, and the new features introducted into SL are also making their way into Wpf. So the teams are talking to and learning from each other... I wouldn't be suprised if SL does end up being a proper subset of Wpf, like it was supposed to be. Wpf will be able to do things SL can't, simply because SL is sandboxed and Wpf is not, so for a full-fledged desktop app I don't see Wpf going anywhere.

We find SL a good platform. Xaml is good stuff and Expression Blend a powerful tool. Hand coding xaml can be easy as long but you need the preview feature. Csla works well, although it can seem rather involved. We put our SL and .NET code in the same source file, otherwise one would end up with too many files open, we have a macro which switches from SL to .NET version. SL3 has added a lot of nice stuff.