Why WarLight switched from Silverlight to Flash

The old-timers all remember back when WarLight was a pure Silverlight site. The original post explaining why the change was made is buried in an old forum post, so I figured I would document the switch here.

History

I first started writing WarLight with the Silverlight 1.1 Alpha. At the time I was just playing around with Silverlight to see what it was; I had no idea WarLight would balloon into something as big as it has. I liked what I saw in Silverlight, as it was quick, efficient and allowed me to easily share C# code between the client and server. This allowed me to get a prototype up and running quickly.

WarLight launched using the Silverlight 2.0 beta, and migrated to 2.0 RTM on launch day and then to 3.0 RTM shortly after it launched. Sadly, this is the last version of Silverlight that WarLight would ever see.

The Switch

Fast forward to September 2009. I had just finished adding the Single-Player mode to WarLight, and had decided that I enjoyed working on WarLight and wanted to continue with it. Silverlight was, unfortunately, the biggest thing holding WarLight back. Silverlight’s marketshare was less than 50% according to riastats.com, meaning that most players coming to WarLight were faced with an install prompt. Admittedly, Silverlight’s install rate rose very quickly – much more quickly than I expected. Getting to almost 50% in such a short time is unprecedented in terms of browser plug-ins.

Asking users to install a plug-in to use a website is a huge barrier to entry, and is unacceptable to me. Many users want to play from work/university/library computers where they don’t have Administrator access and can’t install anything. Many users also just don’t want to install things, which is understandable – my standard procedure is to immediately close the tab when a site wants me to install QuickTime, Java or Unity. (I have nothing against Unity, it just always crashes during install on my main PC for some reason.) And yes, I know Flash is a plug-in too. However, Flash’s 98% marketshare means that for the vast majority of users, no install is required.

The bottom line is that Flash is the de-facto standard for web-based games. Silverlight has definite potential as it’s more developer friendly and, in my experience, performs better. But Silverlight is new and I’m not willing to wait for its marketshare to be comparable to Flash’s.

I often get asked why I didn’t port it to a HTML/Javascript solution using HTML5’s canvas. That’s easy – canvas’s marketshare was far less than Silverlight’s (probably less than 10%), which is a big step in the wrong direction. At some point in the future I’d love to do this, but 2009 was certainly not the time.

Comparison of Flash and Silverlight

Both Flash and Silverlight have their advantages and disadvantages. Writing the same application in both has given me a good appreciation of the differences between them, at least as it compares to WarLight’s specific requirements.

This section specifically compares Silverlight 3.0 with Adobe Flex 4.0 running in Flash 10. Flex is required for an adequate comparison, as Silverlight has things like buttons, checkboxes, sliders, and a layout system built in. To get these things in the Flash world, Adobe provides Flex which is a layer on top of Flash.

• Layout: Comparing the flexibility of the layout systems, I prefer Silverlight’s. Silverlight’s objects fill to their parent by default, whereas Flex requires you to put width/height=100% all over the place. Although, being able to say width=50% in Flex is nice, which takes more typing to do in Silverlight. Flex’s VGroup/HGroup only let you set an alignment for the entire container, whereas Silverlight’s StackPanel lets you set the align for each object in the container.
  Winner: Silverlight.

• Mxml vs Xaml: Silverlight uses Xaml to design its UI whereas Flex uses Mxml.
  Mxml is nice since you can put event handling code right into the mxml file, but Xaml’s attached properties are a thing of beauty, since they avoid Flex’s problem of having a ton of unusable properties on every object.
  Mxml has hacks like a “width” attribute that sets either the “width” or “percentWidth” properties depending on whether or not you include a %. This is lame, as it’s unintuitive as soon as you try to set it via code.
  Some of the Mxml properties are considered “styles” which mean you can’t set them via a normal property assignment. You need to use the setStyle() method, which is unintuitive since they look just like properties. Silverlight has a similar issue with attached properties, requiring you to use SetValue(), but at least you can easily see in the Xaml which properties require this.
  Visual Studio was always slow to open Xaml files for me, sometimes over 10 seconds. I don’t use the designer, I had them always set to open as text, but I suspect some designer-related components were loading anyway that I couldn’t figure out how to turn off. Endless frustration!
  Xaml is just serialized .net objects, which makes everything intuitive and easy. You can import/export Xaml yourself very easily with XamlReader and XamlWriter, and you can even load Xaml at runtime. Mxml is statically compiled, and can’t be loaded at runtime.
  Winner: Silverlight. Xaml is just a well-designed markup language.

• Language: Flash uses ActionScript, Silverlight allows (almsot) any .net language but most people use C#. This is one of Flash’s weak areas, as ActionScript has decades of baggage that make it a frustrating coding experience. Although it’s clear that Adobe is trying, as they do support closures, first-class functions and garbage collection. However, the inability to share code between the client and other languages give this one to Silverlight easily.
  Winner: Silverlight by a landslide.

• Component Customization: Silverlight allows any object to contain any object. For example, you can easily put a list box inside of a button (not that you’d want to…). Flex is a more traditional UI layout system, which tries to cover the most common scenarios but ultimately leaves holes. You can still do more powerful things using skinning, but it’s a lot more cumbersome. I recall having to copy+paste over 100 lines of mxml just to have a button with two lines of text. Sad!
  Winner: Silverlight.

• Automated Testing: Both Flex and Silverlight have poor automated testing tools. I used the Silverlight Unit Test framework and was able to get it working successfully, but for testing an asynchronous app like WarLight, you have to do all sorts of crazy lambdas and callbacks just for basic operations. This makes maintaining state and looping within a test difficult, and also requires that you run your test code on the UI thread.
  With Flex, I used Selenium with a Flex plugin and it avoids the problem above, but required I write a bunch of plumbing code to give myself strong binding between my app’s UI and the test code.
  Winner: Only losers here.

• Error Reporting: Silverlight has a global error handler that gives you the exception object which includes details of the error, and a stack trace, even in retail builds of Silverlight.
  The retail version of Flash eats all errors. This is a problem for me, as being able to fix errors quickly is important to me. Flash required me to do a bunch of extra work in this area. Every entry point must do a try/catch in order to handle and report errors gracefully. What a pain!
  Even then, you have no stack traces in retail builds. Without stack traces, you often get back an error where the extent of the message is “1009.” 1009 is the Flash code for a null reference exception, but just knowing you have a null reference exception somewhere in your app is not enough to fix the problem. You can put an identifier on each error handler so you at least know the entry point, but that wasn’t enough for me.
  So I wrote a routine that would track stack traces myself. I wrote some rudimentary ActionScript parsing code that injects a PushStackTrace() call to the start of every function, and a PopStackTrace() at the end. Using this, I can track the stack trace all of the time, and when an error occurs I include it in the error report. This has been wonderfully useful, but it took a lot of work just to get back to what Silverlight does for free.
  Flex 10.1 added a global error handler, but you still don’t get stack traces even in 10.1, so it doesn’t solve the issue.
  Winner: Silverlight by a landslide.

• Performance: Although I haven’t taken measurements, there was clearly a noticeable and significant drop in performance after migrating to Flex. I believe this is specifically attributed to Flex, not Flash. The speed of constructing bunch of Flex objects (order details) and placing them into a scrollable panel (the orders list) made scrolling through the history of a WarLight game much slower than it was in Silverlight.
  Winner: Silverlight.

• Adoption: Covered above.
  Winner: Flash by a landslide.

• Bugs: I ran into bugs on both platforms. I’ve reported a few back to Microsoft and Adobe, but overall I wouldn’t say that either platform is more or less buggy than the other.
  Winner: Wash.

• Overall Winner: Flash! Flash is of course the winner, as WarLight uses Flash today. I’m not particularly tied to the Flash platform, and I’d be happy to move to something new in the future if the move makes sense.