Some Thoughts on Silverlight

Andrés Osinski

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

I have always expressed openly my 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, given that there's already many enlightened voices out there to warn us about the perils of working on proprietary platforms.

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.

But 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 alternatives. The problem, however, lies for the most part in the underlying applications framework used for the project; Silverlight itself. Yes, Siverlight is in many ways just a subset of the standard .NET library, which is not bad at all. The issues here have mostly to do with the presentation layer.

XAML, Or A Failure In Declarative Programming

Many will probably disagree with me on this, 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 a GUI in SQL.

There are no good mechanisms for separating content from style. Yes, there's the Style attribute, but it's a poor excuse for a well-executed styling system. Even CSS, warts and all, is better for this.
It is complex. Very complex, to the point where there's a strict dependency on the IDE to get anything done. The number of elements and attributes, the slight irregularity on the naming schemes of different attributes, the verbosity of each element, all pile up to make even the slightest of edits require opening up the IDE.
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 without the designer (we're talking literally thousands of lines of XAML code for rather simple stuff), yet it's very limited when it comes to describing fluid layouts properly. And it's slow. So slow.
The C# compiler is a marvelously effective and productive tool. Not so the one for XAML. Parsing XAML is sluggish, autocompletion is mediocre to downright bad, a surprisingly large number of errors are caught at runtime (difference with HTML being that in order to debug a Silverlight application you need at least 20 seconds to start up a debugging instance, and no runtime changes are allowed), and interaction with your C# namespaces is painfully difficult and bureaucratic.
In classic 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 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 of these problems (the standard response for the majority of these shortcomings is writing custom controls and intermediary Converter classes for things that would 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 the control automatically handles the rest for you.

This should actually be a great boost to productivity, since you can take the hassle off saving and retrieving data and presenting it. And for the most part, it actually works very well: define your entities, create a providing Web Service, and you're good to go. For 70% of the use cases this works marvelously well. Unfortunately, it's disastrous for the remaining 30%.

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 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 can end up in 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 difficult to customize a grid to override default behavior. Anything that's slightly complex requires yet more boilerplate code, and we're not talking about the sort of API that fits in your head, so expect to be looking over Stack Overflow and the Silverlight Forums very frequently for answers to simple questions (and not finding the answers to what you need way too often).
Silverlight's UI theming has nothing to do with the clients OS, unable to look like true desktop clients, yet harder to style than web applications.

All of this comes down to the fact that getting the DataGrid and Datasource to do what you want it do 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 community and 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 functions that are necessary for manipulating so many data structures, and which currently presents my only objection to using C# in this context. The dynamism 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.

Opinions Bottom-up

It's interesting to note that despite my comments and what I consider to be some pretty egregious faults in Silverlight, you'll find people practically lining up to praise this framework. And to be honest, it's not the worst thing as far a RIA apps go by a long shot (I'm pretty certain it's much better than Eclipse RIA, and possibly comparable to Flex).

While it fares favorably against many technologies, it just doesn't hold its own against modern web technologies like Django, Rails, and similarly inspired web frameworks. There's more boilerplate, less flexibility, and many of the advantages of a RIA platform are lost against the sort of dynamic web applications that jQuery with extensiones can help you create. It's better than ASP.NET, probably, but I don't believe it's good enough when we lose so many things in the process, such as

Depending on a proprietary platform running on a single operating system. Silverlight for Mac OS and Mono just don't count. Trust me on that. It's very easy to write platform-dependent code on Silverlight.
Spending thousands of dollars on your development platform, which will be outdated in a couple of years and requires a substantial investment in a vertically-integrated set of solutions that don't work well with anything else.
Limiting the amount of community support. For a platform that counts with commercial support, the amount of extensions, tutorials, and tips just pales in comparison to the level of documentation and support you can get with jQuery, Django, or other FOSS solutions. IRC is still the best support line available for developers.

In my experience, most of the praise comes from people already locked into other Microsoft platforms who have never had the pleasure of trying better alternatives, and given that a significant number of these people have no interest in looking outside this walled garden, it will effectively be one of their better tools for getting things done.

In conclusion, on purely technical grounds, it is a decent platform, albeit flawed in pretty important ways. If you work with .NET most things will not seem to alien. For everyone else, stay away. And when you factor in the matters of using a privative platform for in the days of the Open Web, everyone should probably disregard this platform, instead favoring web clients when possible and native clients when necessary.

Comments

Ben: I must admit that after reading the article I felt that my personal opinion on XAML was not that wrong at all. Although I should say that I haven't go as deep as you did the conclusions that you have come up are quite the same I had a few years ago. Having developed lots of complex GUI with native code I was attracted to the whole idea of XAML. Mostly because I thought I was going to be able to do very complex and attractive GUI interfaces. A few days after I started my first project, the whole code was unreadable a complete mess, that was it. Have I tried AIR ? Yes I did, and trust me you don't want to know what I think. But what about XUL, same sh*t as AIR and XAML but with no IDE, there is one I think which hacks a scintilla editor inside mozilla, epic fail ! Back a few years ago I think it was year 2001 I was in a discussion about the newly adopted XML and XLS engines on IE5.5, Back then I was developing an application based on pearl+discus (now discusWare) we where talking about how the presentation and the content where going to be separated in the future allowing more control over the content, back then we thought things we're underway, and then it came CSS and so many other modification of the standard, many do help to keep content and style separated, but we're far form the reaching the paradigm. Ben.

Norman: Great Article! Thanks for taking the time to describe the situation that well. I enjoyed reading it.