Silverlight Impressions

It’s no secret that Microsoft’s relatively new Silverlight is intended as a competitor to Macromedia’s (now Adobe) long-time rich-web media stalwart Flash. Having been a Flash developer for a very long time, I recently wrote a smallish Silverlight application for a project we’re working on for work, and I have a number of things to say about the experience relative to that of developing webapps with Flash.

Overall, the most glaring, obvious, and often painful differences lie in the obvious question of maturity. Silverlight’s API is constantly shifting, and the documentation is little to no help at this point. Little things, and sometimes huge issues, haven’t been totally thought through just yet (though given Microsoft’s track record it’s in question if they ever will be), and flux is always frustrating to deal with. However, some of the issues are more inherent to the platform itself, laying mostly in the nature of its development and its integration with browsers and with code. Here’s a more detailed breakout.

Silverlight is very young. It’s not even out of beta. Therefore, it should be expected that the API and XML schema will shift here and there. That’s little comfort to the developer, however. The latest preview edition of Microsoft’s Expression Blend 2, the official application for developing in Silverlight, provides almost no correlation between the WYSIWYG/graphical options it provides for interface development, and what the Silverlight schema actually represents. Triggers appear to be unsupported, though Silverlight supports them, and there is no way to add events to objects. There are countless other discrepancies between Blend and reality, many of them too grave to even think about. Therefore, designers and developers alike are stuck editing XAML markup, which isn’t the most delightful task. “Fine,” thinks the average developer, myself included, “if I can’t use Expression Blend I might as well just edit in Visual Studio and avoid the shortcomings and annoyances of Blend’s XAML editor.” That’s a bad notion — Visual Studio doesn’t as of yet recognize the Silverlight schema and as such will live-compile everything as errors. You’ll get a productivity rate of about one word per minute. To add insult to injury, the MSDN documentation is very poorly written; I’m pretty sure they took the full Avalon XAML documentation, and appended all the caveats, issues, exclusions, and other miscellenia to the end of each page. It makes for poor reading. This issue, though, brings us to the next topic of discussion:

Silverlight is mini-WPF. This is both a strength and a weakness. XAML is a reasonably well structured language which accomplishes its goals fairly well. I don’t have too much of a problem with it. It also eases the transition for any developers who are already developing for WPF (which, as far as I know, is an extremely scant few) into developing Silverlight. However, in order to make WPF web-friendly, a lot of things were cut. Some things that don’t even seem to be very heavy were cut. Complaints about lack of support run the gamut from simple things like animating clipping areas, to even simply having geometry as clipping area, rather than what are effectively polylines. However, larger than this is a more serious problem, which is that…

WPF (and therefore Silverlight) just wasn’t built for the web. WPF is a desktop creature. There are a whole slew of things to consider when developing for the web, the largest of which is bandwidth. Flash may not have a built-in preload manager, but at least it provides the mechanisms with which, with minimal knowledge and 2-3 lines of code, you can build one. Silverlight provides virtually none of these things. The only way to preload things is to use the Loader object, which works asynchronously, requires a separate instance for each element to be downloaded, and requires extensive knowledge and coding to get to work. This becomes a serious issue, especially because images are essentially just standard html images. Blend may claim that you can apply effects and animations regarding skewing and transparency, but it’s just wrong. This leads me to my final conclusion on flash’s advantages (outside of simple maturity and installed base):

Flash’s main advantage is that it is a single, self-integrated package that is both developer and designer friendly. It was built from the beginning for the web, it has a solid IDE that works for both designers and developers (unlike Silverlight’s Blend vs Visual Studio model), and requires jumping through less hoops (there is no markup to edit by hand). Everything from the development experience down to the consumer experience is provided in one simple, neat package. Silverlight’s deployment requires four or five javascript files (why aren’t these part of the plugin itself?), along with any collateral content, such as images, to be deployed as individual pieces. Flash also allows far more flexibility from a design perspective, as Blend isn’t particularly any good at drawing any shapes outside of elementary geometric elements.

In a final stroke of irony, Flash trumps Silverlight at one of the elements WPF was greatest boasted for: developer/designer integration and separation. Silverlight requires events to be wired up in XAML (which right now is even greater a task given Blend’s complete inability to do so for you), and thus there is programming being done in XAML. Flash, conversely, allows for developers to wire up events without touching anything design-side.

Overall, Silverlight is a decent platform. Once it matures, we’ll get a better sense of its capabilities and pitfalls. Right now, however, it simply has too many of the latter for me to be greatly interested in developing extensively for it.

0 Responses to “Silverlight Impressions”

Comments are currently closed.