Candid Reaction to WPF and Silverlight

A little while back I shared with Jon Galloway my frustration with Silverlight. Now, if you don’t know Jon, come out from under your rock. He’s a Microsoft MVP, host of the Herding Code Podcast, and author of The ASP.NET 2.0 Anthology: 101 Essential Tips, Tricks & Hacks. He’s a longtime blogger, a Twitterer, code camp and .NET user group presenter and an open source contributor. Most importantly, within the context of this post at least, Jon works for Vertigo Software on apps like Video.Show and MicrosoftPDC.com and he has been working with Silverlight since its first release.  Back to the story – I was bad-talking Silverlight, Jon asked for specifics and I deferred the details until our next lunch. Well, we haven’t hooked up for lunch yet, so I emailed a pre-published version of this post to Jon along with a request for his feedback.

Full-disclosure: I offered Jon sushi and beer in exchange for his reply. Even though he’s really busy being famous, Jon’s a super good guy and he got back to me quickly. So, as you work your way through the post, Jon’s comments are prefixed with “JG:” and my consequent responses are prefixed with “BG:”.  

Level Setting: What the Heck Do I Know?

Let’s be honest. I hardly know a thing about this stuff – especially compared to Jon. My resume is not chockfull of WPF, Silverlight or Expression Blend goodness.  Now, even though I’m no expert, I’ve been around the block – albeit a short block:

I started using WPF in April 2008 and released my first WPF client application back in July. I found WPF development to be challenging, exciting and enjoyable. No kidding. Then came an in-house Silverlight 2 Beta 2 (turned RTW) line-of-business project which was equally challenging, exciting and enjoyable but there were also moments of frustration and disappointment. As for Expression Blend, I’ve primarily used it to produce basic layouts. At best, I’ve used it sparingly (and I only call this out because I make later comments about the separation of development and design.)

Though I only have a little more the nine months of hands on experience, I’ve been interested and kept up with the technologies through online tutorials, blogs, forum and podcasts for some time.

More Level Setting: What the Heck Am I Talking About?

If you’ve made it this far, you’ve probably come to the conclusion that I’m a fan of WPF and not-so-much a fan of Silverlight. Well, in general, I think both WPF and Silverlight are compelling offerings and though this post is not a glowing endorsement for Silverlight, it should, by no means, be interpreted as anti-Microsoft/anti-Silverlight banter. Very simply, I wish I more thoroughly evaluated and prototyped before promoting Silverlight as a good choice for our in-house line-of-business application. Hindsight being 20/20, I jumped on the Silverlight bandwagon based solely on the merits of my WPF development experience and my misconceptions. I take full responsibility for my choices as a developer/architecture but I wish I didn’t attempt to “light up the web” so to speak.

Below I offer comments and opinions around key Silverlight/WPF areas which I personally believe there is misunderstanding and/or possibly misrepresentation. Some of my comments come in the form of questions. Most of my notes are in response to my hands on experience with Silverlight/WPF but others are based on my research alone. The information below may be spot on or completely off the mark, but hopefully Jon will keep me in check. All the same, I hope you find this to be a worthwhile post and I look forward to your feedback.

Business Application Development

Is it just me or is every Silverlight application a cute game or video player?   Of course, I am exaggerating a bit, but I hope you get my drift – if you want to build a line-of-business application using Silverlight you’re on your own.

Until recently there’s been little support for developing business applications with Silverlight/WPF outside of what’s been generously shared by Billy Hollis and Jonas Follesoe.  With that said, Tim Heuer announced the launch of the long anticipated Application Corner earlier this month and Jamie Cool presented Microsoft Silverlight Futures: Building Business Focused Applications at PDC.  This is encouraging, but I still think the title of the PDC presentation says it all – if you want a non-video streaming, line-of-business Silverlight application, you’re going to have to wait. 

JG: Totally agree.  All your criticism is completely valid, but I think you can see from presentations like Jamie Cool’s PDC talk that Microsoft is starting to put more energy into business focused Silverlight applications. 

BG: At the risk of sounding completely unimpressed with the current Silverlight offering, I fear the attempt to fill the line-of-business gap may be coming too little too late. Case in point, after dedicating a couple of months to our in-house Silverlight implementation, we’ve abandoned the approach in favor of a web application solution. The decision was based primarily on Silverlight DataGrid bugs tied to common use cases.[1]  Now that a bad taste has been left in our mouths (and our pocket books) what are the chances that we’ll give Silverlight a second chance?

JG: Think of Silverlight as a 5-10 year investment, and this isn’t really an issue. I’d actually have preferred that Silverlight 2.0 shipped without any controls, because we can write those ourselves as needed, then followed with a Silverlight 2.5 or 3.0 that included the controls. I’d be interested in hearing about the reasons you were looking at Silverlight instead of a web app solution to start with. What were you hoping Silverlight would give you here?

BG: Good question. The reason for Silverlight was three-fold.  We’re betting Silverlight’s popularity will continue to rise (along with related work) so we made the strategic decision to get familiar with the technology.  So, it was first and foremost a business investment especially since the application was a snap to implement as a web application. The second part of the story is we had team member interested in working with Silverlight so I think employee satisfaction definitely factored into the choice.  The final piece of the puzzle was we really thought Silverlight was a viable solution.  Not to mention that Silverlight sure is sexy… Without getting too specific, our Silverlight project is a glorified data entry application which primarily uses an editable DataGrid with combo/text/check boxes to gather user data.  There’s nothing glamorous about that so why not jazz it up with Silverlight?

.NET Developers Aren’t Silverlight Developers

“If you are a proficient .NET developer, you’ll feel right at home using WPF and Silverlight.”  I’ve heard similar statements numerous times and, well, I am not sure I agree.  I won’t argue against the benefits of being able to write Silverlight code in the language of your choice while using the good ol’ .NET stack within the very familiar Visual Studio IDE, but that’s where the easy transition ends. The paradigm shift from web forms developer to Silverlight isn’t subtle.  For example, you might as well throw DataSet binding out the window as ObservableCollections are common place in WPF/Silverlight.  I swear I scratched my head and reran my application a dozen times before I realized that just maybe binding doesn’t work the same in WPF/Silverlight as it does on WebForms.  Anyhow, even though the tool, language and stack may be familiar, there’s still a steep learning curve.

JG: This is true. And yet – would you want Silverlight to follow webform paradigms? For instance, Silverlight is based on vector graphics, and that’s not even part of the webform world. I think that in the long run, it’s a good thing that Silverlight is based on WPF. Also – WPF has been out for a long time, comparatively speaking. I think you’ve touched on something, though – there isn’t a lot of clear guidance on Silverlight architectures, or on how you should make the transition from webforms development to this totally new paradigm.

BG: Good points.  Don’t get me wrong.  I certainly don’t want Silverlight to follow in the footsteps of webforms. However, since Silverlight is a web-hosted .NET technology and web developers are likely to be the first adopters, I think the learning curve is a bigger issue than it’s being presented to be.  

Silverlight to WPF, WPF to Silverlight

Rumor has it that Silverlight applications can be ported to WPF with little effort.  Since Silverlight doesn’t run on the desktop yet, you can see why a painless Silverlight to WPF migration is an appealing alternative. Since Silverlight is essentially a subset of WPF, I can understand why it is assumed that Silverlight would port to WPF without much issue, but I have my doubts.

For example, isn’t it true that some of the controls which are common to both Silverlight and WPF aren’t based on the same underlying code and therefore shouldn’t be completely compatible? Doesn’t Silverlight provide functionality which isn’t found in WPF?  How could this be ported? How’s about authentication?  I would think that Silverlight (on the web) and WPF would require entirely different implementations?  And maybe I’m making this up but since Silverlight solutions require special “Silverlight Class Library” projects whereas WPF can use mere “Class Library Projects” doesn’t it stand to reason that even though the code may be portable this isn’t the case for projects.

JG: Yes, pretty much agree. I think the expectations haven’t been set well here. How could a desktop app be run on the web without some changes? How could an app compiled against the full 220MB .NET framework run without any changes run against the 4.3MB Silverlight .NET framework? Also Silverlight applications are built to run on the web, consume web resources, run under limited permissions, have no filesystem access, and assume they’ve got internet access… WPF applications run on a desktop with filesystem access and must assume no internet access. So, I think the WPF = Silverlight story is good marketing, but it just doesn’t seem to make a lot of sense from a developer point of view. That being said, there are some architectures that will allow for “cross-platform” development, and the skills are mostly transferable.

Amazon Can’t Help You Learn Silverlight

Not so long ago, Adam Nathan’s colorful Silverlight 1.0 Unleashed was considered the Silverlight bible. As far as I’m concerned, you might as well throw that book away unless you want a history lesson.  I mean, with the shift away from javascript and the breaking changes in Silverlight 2.0 RTW, prior versions of Silverlight aren’t even around to be maintained.

As for Silverlight 2.0, there are no less than 8 Silverlight books which are recommended on the Silverlight Community Site.  As far as I know, all of these references (I’ve skimmed through half of them) are based on Silverlight betas rather than RTW.  So, you won’t, for example, find any samples which include a ComboBox control. I guess my question is, “What’s the new Silverlight bible?”

JG: I’m gonna argue with you on this. I know that Laurent Bugnion’s Silverlight 2 Unleashed was updated for the RTM because he personally verified some facts with me. From the Silverlight 2 books out there, it’s the best one I’ve seen. BTW, Jumping from ASP.NET to Silverlight 2 might be interesting to you. I haven’t read it, but it looks like it may address some of the questions you’re looking at.  Oh, one more thing – I’ve been surprised with the success I had in asking Silverlight questions on StackOverflow

Design vs Development Myth

A strong argument in favor of using Silverlight/WPF and XAML is that it accommodates designers and developers using their own tool(s) of choice and then bringing their respective work together at a later point.  This sounds great, but I’m hearing mixed reviews about whether or not this approach is practical. 

The biggest problem area, in my opinion, is around the fact that some coding can be done in Blend.  I’m specifically talking about events and triggers.  Since this same Blend/designer code could be implemented by a Visual Studio developer in a code-behind file, responsibilities and tools actually overlap. Rather than a firm separation, the line between designer and developers roles/tools is blurred. This could lend itself to a gnarly mess unless the designer and developer can come to an agreement on who’s taking care of what tasks right from the start. 

Also there are exactly two requirements which must be met before a designer and developer can come to any agreement.  Any guess what they are?  That’s right.  There must be a designer and there must be a developer.  I know my shop didn’t hire a designer to work with me on either my WPF or Silverlight project and I bet most shops would act accordingly. Not to mention that I highly doubt there are a lot of seasoned WPF designers looking for work these days.  This ultimately means the developer is going to be playing both roles and bouncing between two separate tools is cumbersome and a waste of time.

JG: Pretty much agree here, too. Although I don’t think I’d want to be doing design work in Visual Studio. I pretty much agree that this developer/designer workflow thing may sound good for CIO’s, but breaks down because designers haven’t adopted XAML and Microsoft hasn’t figured out how to get them interested in it.

BG: I don’t want to do design work in VS as the tool stands today.   We’ll see what the future holds.

Conclusion

WPF and Silverlight are new technologies and we, collectively, still have a lot to learn. At the rate in which Microsoft is releasing their products, we’re going to be learning and relearning together for a while. Based on my experience, it’s ill-advised to move forward with WPF or Silverlight (or anything for that matter) without sufficient understanding of the technology unless you’re willing to suffer the consequences. The problem is it isn’t always easy to get answers and come to an honest understanding. The bottom line is you need to do your own research, create your own prototypes and chose a sound solution based on the problem at hand.

Looking back, some of the poor judgment I passed on Silverlight was unfairly issued. Some of my frustrations could have been avoided if I did my due diligence and/or maintained reasonable expectations. Notwithstanding, I stand firm in my thinking that there’s confusion around some of the core Silverlight/WPF offering and I hope as more folks get involved with these technologies issues/questions/answers come to the surface.

I hope you found this post worth your time. Thanks for reading.

—————————-

[1]  A little more about DataGrid bugs: Silverlight developers may be aware that Microsoft issued the Silverlight 2 DataGrid December 2008 Release on Friday. (Great timing.) Hopefully the list of over 30 fixes somewhat justifies my frustration.  To quote the lead developer on our in-house project:

I think the biggest frustration is that Silverlight is in release version 2 yet there are major bugs still present.  At the very least I would have liked the buggy controls / validation / anything else that is still incomplete to have been held out of the release and instead placed in a “beta library”.  This would allow developers the transparency to know where Silverlight really stands.  This is my first experience developing with Microsoft technologies where I feel like the technology is really flaky.

On Friday evening I installed the DataGrid patch and tested my initial Silverlight prototype.  I am happy to report the majority of our issues are now resolved. However, we are still encountering issues — the biggest is around inserting a new row after a removal of another.  It seems the DataGrid “remembers” the deleted row and partially uses its state on the next insert. This results in some new rows rendering values which are inconsistent with the underlying ObservableCollection.  It’s strange behavior but at least we’re clear of “disappearing” rows at this point. Though, in my opinion, the DataGrid control can still use some help, my thanks goes out to the Silverlight team for listening to the community and releasing a number of fixes relatively quickly.  

Comments

  1. “I’d actually have preferred that Silverlight 2.0 shipped without any controls because we can write those ourselves as needed, then followed with a Silverlight 2.5 or 3.0 that included the controls”

    Why do you think every .NET developer wants to develop their own controls? Why do we have to wait for the next version? We waited for them when 1.0 came out and now you suggest to wait even more!? Silverlight 1.0 was just a fancy video player and was pretty useless for creating data centric business apps.
    Many developers want to use controls and concentrate on developing the business aspect of the application and not hand code controls themselves. Let the controls vendors do this job. If you want to create your own, go ahead but don’t be selfish and deny the millions of developers from being able to use readily made, thoroughly tested, polished controls.

    Make all options available and you have the freedom to use the features you want and let others use whatever they like. But to suggest to limit the features doesnt make sense.
    This attitude is also coming out from MVC purists. They don’t want any controls.

    It frustrates me when people want to impose their beliefs on others.

    I am also tired of all the Silverlight demos out there which heavily use the carousel control to show photos as if this control is so awesome.

    Many developers say they want to use Silverlight to create Intranet business apps in their companies. What’s wrong with XBAP? Full WPF in the browser. I don’t see what Silverlight is buying them.

  2. “I pretty much agree that this developer/designer workflow thing may sound good for CIO’s, but breaks down because designers haven’t adopted XAML and Microsoft hasn’t figured out how to get them interested in it.”

    I’m a designer that was asked to work on UI designs for a few WPF and SL apps. I worked for a Microsoft development shop and was the only designer on site (compared to about 50+ developers).

    Here’s my two cents on the Designer part of the workflow. At first, I tried using Expression Design and Expression Blend for my design work. Expression Design is a decent tool, if vectors is all you work in. My experience trying to work with bitmaps in Expression Design was sub-par. Even working in vectors using Expression Design was sometimes a chore -> Try creating a crisp 1 px horizontal line without anti-aliasing it. You can do it in code, but not the design tool. So I jumped into Expression Blend. Not much better. Even when I did use Blend, the developers didn’t want all code from Blend, and really just wanted the path data. So I went back to what I knew –> Fireworks and thanks to Infragistics, I used their Fireworks->XAML exporter and I was in business. Not perfect, but I was able to continue with the tools that I’ve been using for 10+ years.

    Designers, or at least the designer I know, don’t care about XAML. There isn’t anything for us to get interested in. Expression could export onto punch cards for all we care. Its the tool that allows us to be expressive that matters. This goes for both Expression Design and Blend. For me, what matters most is a tool that does its job well, doesn’t force me into yet another method of working, and allows me to easily prototype my designs.

    The last note I wanted to say regarding getting designers interested is there is a complete lack of Mac tools. I may have worked in a Microsoft studio, but when I got home, I like to work on my Mac. I can’t play around with Silverlight in my off hours. No play time, then zero interest. Sure.. I can run Parallels or VMWware and work with a half solution, but why? And if I can’t run it and play with, it means I won’t find cool things to get my designer friends interested. And then we dont’ blog about it, etc etc.. and it doesn’t gain interest. The original appeal to Flash was that everyone seemed to be playing with it (even back in the Flash 4 days), it was approachable, and your friends were doing cool things with it, and it spread. Right now, too many things are keeping Silverlight from being more than a developer tool. Just my opinion.

  3. Great comments, Abdu. Though I know where Jon is coming from, I questioned the idea of shipping 2.0 without any controls too. In my opinion, writing controls against a framework offers a means of validating the framework. If MS didn’t offer controls (to some extent dog food their own stuff), I would bet SL would be far buggier. Thanks for the reply.

  4. Abdu, I agree with you on the need for a full set of stable, well-tested controls out-of-the-box with Silverlight. This is what would make Silverlight a viable platform for writing LOB apps. I want to spend my time developing the business-centric parts of the app, not writing controls.

    XBAP’s are not an option for us because the apps we would like to write must run on the internet (as opposed to just an intranet). We cannot require that the .NET framework be installed on each client machine as is required by XBAP’s.

    When the controls and platform are stable Silverlight be a viable option for implementing cross-platform LOB browser apps. I’m excited by the prospect of implementing rich browser-based applications using full-featured platforms such as .NET or Java. It will be interesting to see whether Silverlight or one of its competitors fills this void first.

  5. Thanks for providing a designer’s point of view, John. From what I understand, XAML exporters are becoming more common — which is a good thing as I think that keeping designers inside their favorite tools is key. I’ll keep my fingers crossed that Mac tools will begin to surface too.

  6. @Abdu – Let me explain the “I’d actually have preferred that Silverlight 2.0 shipped without any controls because we can write those ourselves as needed, then followed with a Silverlight 2.5 or 3.0 that included the controls” comment.

    I’m not saying that I don’t want polished controls from Microsoft. My point was that there was a long lag between the Silverlight 1.0 release and the Silverlight 2.0 release, during which time we had – as you said – a glorified video player. During that time, we had Silverlight 1.1 Alpha, which had CLR support but couldn’t really be used because no users had it installed. During that time, we had no options – if Silverlight didn’t support it, you just couldn’t do it.

    Here’s what we got:
    Silverlight 1.0 RTW – September 2007 – Video, javascript programmability
    Silverlight 2.0 RTW – October 2008 – .NET framework, controls, lots of other stuff

    Here’s what I’d have preferred:
    Silverlight 1.0 RTW – September 2007 – Video, javascript programmability
    Silverlight 1.5 RTW – June 2008 – .NET framework
    Silverlight 2.0 RTW – October 2008 – Controls, lots of other stuff

    The benefit is that you’d get your full release with the controls at the same time, but in the meantime developers would have had options to build their own controls if they needed them.

    I’m sure that would have been more difficulty there, because if they ran into issues building the controls they’d have to worry about breaking the API they’d shipped with Silverlight 1.5, but the benefit is that other developers outside of Microsoft would be developing real world applications and giving them better feedback on what needed to be in Silverlight 2.0.

  7. Hi, Neat post. There is a problem with your site in internet explorer, would test this IE still is the market leader and a large portion of people will miss your magnificent writing due to this problem.

  8. Thanks for all your effort on this blog. Gloria really likes participating in investigation and it is obvious why. Many of us hear all concerning the powerful ways you deliver very important steps through the blog and even invigorate contribution from some other people on that subject matter and my daughter is now starting to learn a great deal. Take pleasure in the rest of the year. You’re carrying out a brilliant job.

  9. Excellent things by people, male. I’ve fully grasp ones material previous to in addition to you’re simply just too excellent. When i really including what exactly you’ve received in this article, really including what exactly you’re stating in addition to just how people claim the item. People allow it to become entertaining therefore you however take care of and keep the item smart. When i cant hang on to read the paper far more by people. It is actually some sort of terrific website.

closed