My first real experience with Silverlight

Back in 2004, when I was writing my book, I was all over everything new in the .NET world. It was partly out of never ending curiosity, but partly because I had to know what was in the pipe to avoid making the book obsolete before it was released. These days, I'm a bit more measured. I still watch carefully (really guys, seeing ASP.NET MVC final would be awesome!), but I'm a little more content to just let things evolve and be released as final before jumping in.

The one aside was working on the data-backed DeepZoom in October and November, and I definitely plan to revisit that.

Since Silverlight 2 went final, I've been ramping up my knowledge about it so I could realize some ideas that I had in my head (and with the holidays and a vacation, that means only one month of really getting into it). Like any new development platform, I find it easiest to learn by having a real and practical goal. In this case, it was to build a multi-file upload control. Yes, it has been done and there's an open source implementation, I realize that. But you know how it is, sometimes you want to just do it yourself, and in a way that makes the most sense to you. So that was my weekend project.

The overall experience isn't bad, though I'm still annoyed at the split between Visual Studio and Expression Blend. It reminds me of the days when ImageReady was a split app from Photoshop. It just doesn't make a lot of sense. I've also got an issue where exceptions thrown in the Silverlight app aren't caught by the debugger, but instead passed to the browser. I know the debugger works, because I can drop in break points and step through code, but I can't figure out why the exceptions fall through. That's annoying.

But despite all of that, you can see just how powerful it really is. The stand out pieces to me are the full network stack in the class library, the threading and, above all, dependency properties. Building in this notification system between properties on objects is just awesome because it very nearly eliminates all of the plumbing code one normally associates with any form-based app. The architects of WPF and Silverlight deserve a gold star for this feature.

It's fun stuff to dive into. There's a certain art to layout and style that's definitely new to XAML editing, but the general nature of it forces you into solid practices, compared to HTML/CSS where even experienced people will debate about how to roll. It's not inflexible, but I kind of like being "forced" into the practices. One less thing to think about.

If the next iteration of the tools are more integrated, that would be a huge win. If I can get exceptions to throw in the debugger, I'd be pretty content with how things are today even.


  • I had great hopes that I wouldn't have to do CSS/HTML gymnastics anymore in order to make things look "right" on the page. Well, that is until I discovered crappy text rendering engine goes along with Silverlight. This notwithstanding, I am still forging ahead on some on a pure Silverlight line of business application with technology better suited for making widgets.

    I don't mind too much using having to switch over to Expression Blend to edit XAML; I've been doing this with Dreamweaver since Visual Studio has never been any good at WYSIWYG editing of CSS/HTML.

    For those lacking the balls to completely forego CSS/HTML development (ha, what an oxymoron), how does the idea of NEVER having to deal with the postback weirdness and absurdity of web forms sound?

    Yup, that's right, no more web forms in MVC. But wait, so you are saying it "is" ok to mix code and HTML now and a nevermind all the codebehind hype?

    'cuse me sir, when's the next bandwagon running?

  • If you're doing MVC right, you aren't mixing code and markup at all.

  • A multi-file upload control is a good choice for a Silverlight project. I was thinking of using Flash for that but eventually found a good AJAX version to use in my ASP.NET web application.

Comments have been disabled for this content.