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.

16 thoughts on “Why WarLight switched from Silverlight to Flash”

  1. So you judge flash by a winner but still ranked silverlight higher in every category? That makes no sense whatsoever. I still remember recently even with firefox having to install the flash plugin to make it work. Not sure if this is the case or not anymore.

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

    That makes no sense whatsoever since that the previous was won by silverlight.

    I love Silverlight and Flash don’t get me wrong. But this doesn’t seem like a far comparison especially when silverlight has won most of the arguments. Not to account for the bullshit category above, silverlight beat flash 6 to 9 in your own words.

    I’m not pissed about you using flash. It just seems like this is a bullshit argument. Silverlight is great and flash is great. Silverlight is wonderful to work with, flash imo not so much. If you’re saying flash is better you need to meet your own categories.

    1. By “Covered above” I’m referring to the section titled “The Switch”, not the point immediately above.

      I’m not saying Flash is better, I’m saying it’s a better fit for WarLight. Almost all of the points Silverlight won only affect the developer, not the end user. Ultimately users don’t care whether the developer’s experience was friendly or not, they only care about their own experience. And having to install a plugin to use a website is not a friendly experience.

      1. Yes, I agree with that. Thank you for clarifying your intentions. It was not meant as a hostile response but I can see how it may be taken that way. Kinda drunk and the end of a work day working from home but oh well. It really upsets me that such technology can be ruined by an experience. I still experienced the same with Firefox not too long ago and if you don’t get someone to install silverlight someone else will (Netflix more than likely.). Same thing you can say about anything. Most users do have flash installed and not silverlight. My friend today started talking about Windows 7 phone and it’s lacking sales (This doesn’t make me look any better because it’s a MS product. :D) but that is really a customer point of view. iPhone just works and Android is coming up because it just works. No one besides developers it seems is giving this platform a chance.

  2. With regard to Automated Testing – I wonder if the newly released Visual Studio 2010 Feature Pack 2 will make automated testing easier. Using the Microsoft Visual Studio 2010 Feature Pack 2, you can test Silverlight 4 applications using coded UI tests or action recordings.

    The Coded UI Test Editor lets you easily modify your coded UI tests. Using the Coded UI Test Editor, you can locate, view, and edit your test methods, UI actions and their associated controls in the UI control map.

  3. Why do you have to ‘switch’? It’s great that you know two technologies, use each when it is most useful. You stopped at Silverlight 2. Silverlight 4 and 5 are far more matured and I agree Silverlight 2 and the available frameworks at the time were not very good at all but the platform has matured and there is another wrong with another tool in your arsenal.

    1. The “switched” is really in context to this one application, not my life as a whole. I would still consider Silverlight for a new project, but I’ve been working on WarLight for three years and I have no plans at the moment to start a new project.

      I did consider trying to publish WarLight to both platforms and let users choose which they’d like to use. This would only be possible if I could do it from one code base, since maintaining duplicate code bases would have taken too much work. In the end, trying to abstract out the UI was too much hassle for the benefits it would have provided so I dropped it.

  4. Silverlight’s Dependency properties are the anti-pattern from hell. They look great at first, until you use them in large scale systems and then the performance problems kill everything.

    1. Unfortunately it’s all pretty integrated into my build system, so it would be a lot of work to provide you with a complete system. However, here’s the key part. This is C# code to inject a call to RecordFunctionStart to the beginning of every function:

      contents = Regex.Replace(contents, @”function\s*(?\w*)\((?.*)\)\s*:\s*(?[\w\.\*]+)\s*{“, match =>
      {
      var funName = match.Groups[“Name”].Value;
      return match.ToString() + ” ErrorHandler.RecordFunctionStart(\”” + className.Replace(“\\”, “\\\\”) + “:” + funName + “()\”);”;
      });

  5. You mention why you didn’t port warlight to HTML5 canvas above. But why didn’t you port it to SVG? I believe it was already well supported in 2011.

Leave a Reply to Fizzer Cancel reply

Your email address will not be published. Required fields are marked *


*