Andrés Osinski

Some Thoughts on Silverlight

Some time I ago I began a project for a customer in an all-Microsoft shop. Given that the project very restrictive time requirements and a RIA design a decision was taken to develop the project with Silverlight

I have have always openly expressed mi preference for Free Software solutions above proprietary ones, and this preference still stands, however throughout this article I'll judge the platform on technical merits alone.

My initial impression came when installing the necessary development environment. Previous to this project I'd worked on several projects using Visual Studio 2008, by all means a very nice and capable IDE that ran well enough on a current, midrange machine

Visual Studio 2010 changed, and for the worse. I can't speak for the addition of new features, but there's one, single factor that makes it stand out from previous versions: it is slow. And I mean slow like a Java-IDE-from-5-years-ago slow. Half a minute to load up, 15 seconds to connect to a Team Foundation Server (don't ask, it's what the customer has). Start piling up a few open Silverlight windows and we're talking a couple of seconds between switching windows, and at least a 10-second build time for a medium-sized application. I understand that things are a lot better when working with WinForms apps, but for a new platform that's supposed to be highly productive for getting things up and running, this is unacceptably slow. The astoundingly good autocompletion features do not make up for this.

Let's go back to that last comment for a bit. If there's something which I think Visual Studio has above any other environment is the combination of the incredible autocompletion coupled with a very good language like C#. It competes very well in its niche as an application development language against similar languages. The problem, however, lies in the underlying applications framework, Silverlight itself. Yes, Siverlight is in many ways just a subset of the standard .NET library, which is not bad at all. The problem, in my opinion, lies with the presentation layer.

XAML, Or A Failure In Declarative Programming

This will probably enrage several of you, but XAML is a piece of garbage. It is touted as a declarative DSL with support for some level of logic, where it's theoretically possible to write CRUD interfaces without touching a line of code. This, in practice, is about as feasable as writing an GUI in SQL.

• There aren't good mechanisms for separations of content and style. Yes, there's the Style attribute, but it's a poor excuse for a well-executed styling mechanism. Even CSS, warts and all, is better for this.
• It is complex. Very complex, to the point where there's a strict dependency the IDE to get anything mildly complex done. The number of elements and attributes, the slight irregularity on the naming schemes of different attributes, the verbosity of each element.
• You can't depend completely on either the GUI designer nor text editing. Due to the above factors it become prohibitively difficult to write an interface on your own (we're talking literally thousands of lines of XAML code for rather simple stuff), yet the editor is very limited when it comes to describing fluid layouts properly. And slow. So slow.
• The C# compiler is a marvelously effective and productive tool. Not so the one for XAML. Parsing XAML is extremely slow, autocompletion is mediocre to downright bad, a surprisingly large numbre of errors are caught at runtime (difference with HTML being that to debug a Silverlight application you need at least 20 seconds to start up a debugging instance, and the no runtime changes are allowed), and interaction with your C# namespaces is painfully difficult and bureaucratic.
• In classical Microsoft tradition, the GUI toolkit contains items that just have no purpose being described on the interface. Specifically, Data Sources, a sort of dynamic connector to a database query that magically handles saving and updating data. I have a whole section dedicated to that, but let's just say it's not a good practice.

The worst offender of these is that Microsoft selling XAML as an easy, expressive method for defining a UI without writing "real code". The reality is that not only does writing a new screen require copious amounts of C#, but that the standard controls are inadequate, to the point where they're the greatest factor in contributing to delays in my project.

The issue falls squarely in the fact that behavior for many actions is ill-defined and buggy. How does a SelectionChanged even know when it's being triggered by the user instead of by the loading of data? Why don't click events work properly on custom controls? Why do I have to explicitly unload and reload certain resources to register when they should work properly just by changing them once? Such distractions have cost me days, and apparently few people have straight answers for many things (the standard response for many of these shortcomings is writing custom controls and intermediary Converter classes for things that take two lines in jQuery).

The DataSource and DataGrid: Convention Over Configuration, Failed

A big culprit of delayed projects is when things that are at first glance very simple are actually overly complicated. By and large, this is the main issue with using these very standardized components.

Most CRUD applications can be written as a grid with data feeding off a set of entities, a few rows and columns, and a couple of buttons to manipulate things. For this workflow, you use a DataGrid that takes its data from a DataSource, binding it to a query, filtering by whatever criterion you want, and automatically display the data.

So what problems does this entail?

• The Grid interface is slow. Clicks don't register properly when doing asynchronous operations in the background (and everything in Silverlight is asynchronous, to the point where forcing synced operations to enforce certain dependencies on interaction is very difficult), animations stutter, loading and reloading data is awkward when compared to equally featured HTML or (gasp) VB6 applications. The result is a diminished user interaction.
• Working within the Grid is annoying and difficult. There is no easy way to reference elements and controls within a grid (it's possible, but it'll take you 5 times longer than necessary and will be fraught with bugs). Binding of controls within the grid is buggy and your standard events don't cover the range of interactions you need. Many times things just don't work as expected and you need to spend hours coming up with a workaround, which many times implies adopting a different UI solution because your original idea is simply infeasable (something that's never happened to me before).
• The API is inflexible. It is extremely complicated to customize a grid to do some special things. Anything that's slightly complex requires yet more boilerplate of code.
• Silverlight's UI theming has nothing to do with the client's OS, unable to look like true desktop clients, yet much more difficult to alter than web applications.

All of this comes down to the fact that getting customized behavior out of this control is nowhere as simple as it should be.

Not a Polyglot

Part of the promise of .NET 4.0 was that the ecosystem would be getting more and more open to dynamic languages and newcomers like F#. This seems evident in the new documentation for the framework. The unfortunate reality is that, like I've said before, since languages are culture, it's very difficult to get a team up and running with a Silverlight project (which is already alien to most .NET developers) with IronPython or IronRuby. Almost no documentation is available, and nothing to speak of as far as code samples. Coupled with the fact that there is not much effort from the Microsoft evangelist to actually convert people away from C#, and we have an idea that's failed from the start.

This is truly a pity since Silverlight would be an excellent match for dynamic languages, given the tremendous amount of casting and anonymous classes that are necessary for manipulating so many data structures, and which currently presents my only objection to using C# in this context. The dyamism of the framework means that many errors will still not be caught by the compiler, and verbose blocks of code are needed where a simple Python one-liner would suffice.