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. 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
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.
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.
 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.