Silverlight 3 Is A Lot Cooler, But Still Not Worthy Of Taking Seriously

by Jon Davis 4. August 2009 23:04

So now that the dust has settled over Silverlight 3, I want to take a moment to comment about what this release really means to me.

The new features of Silverlight 3 and its companion tools like Blend 3 are definitely very nice. I think Microsoft has been smart to finally open up some more doors for developers to do cooler things with things like [limited] 3D support and bit blitting (exposing a bitmap API). And I’m really glad that there’s cool new video & audio pipeline support feature, that puppy opens all kinds of doors to enthusiast uses of technology. (Check out this realtime synth made for Silverlight 3! This too.) Come to think of it those are the only Silverlight 3 features that stand out to me, the rest is really a bunch of “filler” stuff that I imagine Microsoft felt was suitably appropriate for the baseline architecture, gaps that needed filling. And I don’t say that in a complaining way, there were a lot of little things. I also really like the Blend 3 enhancements, like native Photoshop and Illustrator import support and the storyboarding. Very cool features there.

A lot of these are features that I felt needed to make it into Silverlight 2 before I could really feel believe that Silverlight could come close to competing head-on with Adobe Flash for enthusiast multimedia. Particularly the bitmap API support, the absence of that really boggled my mind, but I’m glad that there’s something there now—it’s no GDI+ but that doesn’t matter, you can do bit blitting of sorts now.

These things said, the power of .NET on the browser was what drove a lot of people to take an interest in Silverlight, and the majority of those individuals are curious about it, I believe, because of business reasons. For example, many of them have been using ASP.NET Web Forms for years, and would like to experience more of a RAD development life cycle “like the good ol’ VB5 ActiveX control days”. And to some extent, I am among them.

But, sadly, I still cannot recommend Silverlight to my peers or seek to harness the power of Silverlight for business application development for a few reasons. Among them are some things that we who have done HTML-based web applications for many years tend to take for granted, things that we expect to always be there for our users. For example:

  • Text should be selectable, unless selecting text has been disabled. (It’s fine if it defaults to being disabled, but it should be an easy toggle without changing the performance or other fundamental behavior of the UI.)
  • Right-clicking should do more than just say “About Silverlight”. In fact, whether I’m working with enthusiast software or business software, there are often times when I need completely control of that button. There are always no less than two buttons on users’ mice, dang it, I want to use them both for things. HTML DOM is smart enough to handle this, why can’t a fully-loaded .NET-executing multimedia plug-in? I don’t just want to be able to add menu items. I want that right mouse button to be MINE. Yes, I know Microsoft wants that right mouse button to be THEIRS—I do actually appreciate being able to right-click and confirm that a player is Silverlight, but I think there’s gotta be another way without stealing from the developer. Maybe I overlooked a right-mouse-button feature of SL.
  • If I print a page with Silverlight on it, it should print. If I want to just print the Silverlight bit, it should print. Not only that, but this is vector art. I want it in high DPI, automatically, based on vector art. The power is there, the flushing out of gruntwork is not. Lame. Think about all the beautiful analytics and dashboards that can be displayed in Silverlight that all go to utter waste when it comes to printing. I don’t see what the big deal is, a company as big as Microsoft should surely be able to figure out how to migrate low-res screen rasterization to high-res printer rasterization without reinventing any wheels.
  • Line-of-Business controls! Flush them out already! I for one do NOT like direction Microsoft took to make the Controls Toolkit a CodePlex function. While I know it’s untrue, it feels like the whole effort is what WE’RE doing for Microsoft, not what Microsoft is fundamentally doing for Silverlight, and with it not being a part of the product it definitely feels like something Microsoft isn’t officially supporting. Hence, I hesitate to assume any of it is part of Silverlight or the core Silverlight development experience, because it’s really not. I know, I know, my feelings on this one are awfully cheap and wish-washy. Still, I feel like biz app development suffers because of the lack of core controls. In fact, I don’t know if I could be confident in building a Silverlight line-of-business app without buying some suite from Telerik or some other big vendor. And that’s a lot of money.
  • Comparing the development experiences between HTML+CSS+Javascript vs. XAML+XAML Styles+C#, HTML+CSS+Javascript always wins. Now I believe this will change with the Dynamic Language Runtime, maybe in Silverlight 4, I don’t know, but right now when I go about cobbling together some HTML and CSS and Javascript I experience the most beautiful cooperation between these distinct yet carefully crafted and magically versatile and pliable technology melding together in a mesh of a colorful composite. Very seldom am I chastised for syntactical errors or casing, yet I find it effortless to produce valid XHTML, running Javascript, and predictable CSS. With XAML+C#, though, while I love the power and flexibility of C# and the beauty of a rich vector art multimedia engine that’s XML-powered, I find the flexibility of XAML+C# in Silverlight to be rather daunting. Take stylesheets, for instance. The styling capability in XAML from what I’ve seen (maybe it was WPF I saw and Silverlight has no styling capability, I don’t know) looked powerful but difficult to apply. The attributed syntax appeared to be a lot of work to get right. The isolated styling declarations appeared to be awkward; it was all very case-sensitive with proper casing if I recall correctly, and a bit more syntactically verbose. For these reasons, I cannot comfortably approach Silverlight from the perspective of “like doing web development, only applying XAML and C# instead of HTML and Javascript” because it’s not like that.
  • No windowing. Still no @#$% windowing support!! I just don’t get it, how can Microsoft miss this? Must we use Java applets to get versatile windowing? Must we create “workarounds” by using HTML windows and custom Silverlight instances for them? Both of these options are KLUNKY!! Not even the “save to desktop” feature intended to compete with Adobe AIR supports windowing, what is up with that?!!
  • Something about 400x300 default dimensions in VS really bothers me. Seems too small maybe. Way too small. Who’s using anything less than 1024x768 these days?
  • Still no serious REST verbs support. Only GETs and POSTs are still available with WebClient. LAME. We CANNOT built serious line-of-business “the right way” this way!!

To some limited extent, I’m whining about things I haven’t developed an alternate appreciation for. Fact is, I’m not a Silverlight developer [yet].

But meanwhile there remains the additional fact that companies don’t want to support a plug-in that users don’t likely have, except for Flash since everyone has that. The first and foremost reason why I cannot develop in Silverlight is because of the absence of executive staff support. They just plain don’t want the headache of supporting the plug-in. And I don’t know how Microsoft can fix that, but if they can fix these things, customers might just start getting compelled; I really only say that because Microsoft already hit the ball out of the park with pretty much everything else.



Add comment

(Will show your Gravatar icon)  

  Country flag

  • Comment
  • Preview


Powered by BlogEngine.NET
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 

Tag cloud


<<  May 2021  >>

View posts in large calendar