Thoughts on Silverlight

I attended a local user group yesterday evening and saw a presentation on Silverlight, Microsoft's web app environment. The presentation was quite good; it gave us a lot of information about Silverlight and the presenter knew his stuff. He walked us through the construction of a simple Silverlight application, showing us the support in Visual Studio.

Silverlight is an odd duck. It is not a standard Windows application, nor is it a standard web application (read that as "ASP.NET"). Originally built to compete with Adobe's Flash, Silverlight has become much more than a video player. Microsoft has extended it, giving it useful controls and widgets and making it more capable.

-- I'll digress here and say that Microsoft's extension strategy is not the "embrace and extend" strategy that developers dislike. SIlverlight, from what I know, was never "Flash-compatible". Microsoft is not "corrupting the X standard" (in this case the Flash API) with proprietary extensions. With SIlverlight Microsoft has created a competing technology (version 1.0) and improved it (version 2.0) with extensions of its own. This kind of innovation is more welcome than the "embrace and extend" innovation that Microsoft used with Java. -- End of digression.

Silverlight is quite different from Microsoft's ASP.NET platform. The biggest difference is in screen layout. (I still use the term "screen", showing my development roots.) Silverlight defaults to a dynamic layout, not the fixed-position layout that old-school Visual Basic and Visual C++ programmers know and love. The new model requires a re-thinking of screen design, and while some may complain, I think that it is the right thing for Microsoft to do. Silverlight apps live in the web, and the web uses dynamic screens, not the known, fixed windows of a PC application.

Yet Silverlight has its faults. The construction of a simple app, even something like "Hello, world!", requires a fair amount of typing and clicking. The presenter showed us that he could bind a data source to a grid with only four mouse clicks, but he had done a but of work in advance. The effort is not terribly large, and it is less than previous Microsoft platforms, but I think the advantage still goes to other tools such as Rails. (Although Rails requires more effort on the screen layout side.)

My other complaint with SIlverlight is its use of XML, specifically the XAML configuration files. This is my personal bias against XML for configuration files, and less of a technical complaint. I find XML files hard to read -- that is, my internal XML parser is inefficient. Microsoft has provided support for constructing and editing the XAML files with Intellisense type-completion and syntax checking, and those help, but it still leaves me with my internal parser for reading the files.

Overall, I'm impressed with Silverlight. For Microsoft shops, I think that it is the way to go.