4 ms·

What's wrong with Silverlight? Just curious about your experience. I'm doing ASP.NET web forms at work and would much rather use Silverlight for a few things.

city41 16y ago
There's not that much "wrong" with Silverlight. But I honestly can't find much "right" with it either. It just feels like Microsoft forked off and created this new platform that at the end of the day doesn't offer much benefit over HTML/JS/CSS. Granted, MS started Silverlight well before HTML5 started coming into form. Absolutely, C# is far more pleasant than JS and XAML is a nice alternative to HTML+CSS. All in all XAML was well thought out IMO. And since I'm knee deep in Silverlight right now, it's easy to forget how frustrating HTML/CSS/JS can be across all browsers. It's also easy to forget how difficult it is to test JavaScript code. My problems with Silverlight are: -- I really don't think it's going to become a dominate player, making my investment in Silverlight skills not nearly as effective as if I had taken this time to continue brushing up on my webapp abilities. -- It has its own CLR, making a lot of the .NET tool stack incompatible. There is still not an ideal way to test Silverlight components and especially no ideal way to integrate tests into your build tools. Silverlight is waaaaaaay behind here. There is a lot of people out there trying to solve this problem, but so far all the solutions (I've tried most of them) have serious drawbacks. Jeff Wilcox's Silverlight test framework is the best one so far, but it's very slow, cumbersome and buggy. -- Silverlight is incompatible with mobile devices. I have no hope of ever making this app work on the iPhone, Android or Blackberries. I suppose there is hope it will work on a Windows 7 Phone, but that's not enough. My Boss doesn't think this will ever matter to us, I'm not so sure. If we ever do decide we want a mobile version of our app, then at least the frontend of it will have to be completely rewritten from scratch. -- Absolutely everything in Silverlight is asynchronous. This isn't a real problem, per se, and is a good boon sometimes, but there are times when it's a pain in the butt. -- We have found the Mac Silverlight plugin and the PC Silverlight plugins have significant differences. Currently our app has serious flicker issues when ran on a Mac. We're not doing anything hacky, home brew, anything like that. The stuff that looks bad on the Mac is pure Silverlight code the way Silverlight was intended to work. I simply think the Mac plugin has more bugs and is a lower priority. I have no idea where Moonlight stands, but I have a feeling similar issues would occur. If I have to fight to get my app to run across all Silverlight plugins adequately, then IMO a major selling point of Silverlight is gone and I might as well just use HTML and fight to get it to to work across all browsers. At least dealing with browser issues is a common problem with a lot of solutions out there (a framework like Rails will even hide a lot of it). Dealing with Silverlight plugin issues? My only resource is the Silverlight forums and Microsoft Connect. I'm not nearly as hopeful there. -- We are forced to use the Microsoft stack. Yes you can host a XAP file in Apache on Linux, no problem. But if your Silverlight app needs to work with data, there's a very good chance you are going to choose WCF RIA Services (which we did). Bam, use IIS to host the app now or take the gamble with Mono. Not a gamble I want to take. I much prefer Apache over IIS. -- And ultimately, my real problem is as I write this app I just don't see any huge compelling features of Silverlight that makes all this worth it. Just about anything Silverlight can do, an equivalent modern webapp can do as well. Yes Silverlight does allow you to do this from the comforts of Visual Studio, C#, Blend and XAML. Much nicer waters to swim in than JS, without a doubt. But I just don't think I care. I think I'd rather deal with the current state of HTML/JS/CSS and end up with an app that potentially could be used on any device (within reason), can be hosted in Apache running on Linux, and can be a far lighter experience for the end user to boot.
- Qz 16y ago
  I like C# but XAML drives me nuts. Getting binding to work is like pulling teeth. I've taken to prototyping stuff in Flex because MXML binding is ridiculously simpler, although there's a bunch of C# stuff I'd love to get back...
  - city41 16y ago
    I dislike what INotifyPropertyChanged imposes on my code. I also hate that faulty binding can't be found at compile time, but that might be expecting too much. I also dislike how binding is all or nothing, this isn't possible Text="{Binding PercentageOfFailure}%" But that also might be asking too much and even the idea that my view model should be formatting my data is a valid one.
    - Qz 16y ago
      That's why I like binding in Flex -- making something bindable is as simple as plopping [Bindable] in front of it. And binding also isn't all or nothing, you can easily do something like text="{loan.interestRate}%". It also has code completion for anything you put in the binding, although not quite as robust as elsewhere.
      - city41 16y ago
        Interesting. I actually don't know the first thing about Flex. I think you've inspired me to look into it.
        Qz 16y ago
        Flex 4 is pretty interesting -- they separated layout from the core of container components. So for example in XAML you have Grid, Canvas, Stack, etc. In Flex 4 you just have Group, which then has a layout property -- there's a few basic ones like basic(canvas) vertical, horizontal, and tile, but you can easily code your own... and then switch them on the fly. Flex is basically a really damn good system for UI coding and design, but the ActionScript that backs it up is pretty weak compared to C#. If I could mix C# with MXML I would be in coding heaven...

city41 16y ago

There's not that much "wrong" with Silverlight. But I honestly can't find much "right" with it either. It just feels like Microsoft forked off and created this new platform that at the end of the day doesn't offer much benefit over HTML/JS/CSS. Granted, MS started Silverlight well before HTML5 started coming into form. Absolutely, C# is far more pleasant than JS and XAML is a nice alternative to HTML+CSS. All in all XAML was well thought out IMO. And since I'm knee deep in Silverlight right now, it's easy to forget how frustrating HTML/CSS/JS can be across all browsers. It's also easy to forget how difficult it is to test JavaScript code. My problems with Silverlight are: -- I really don't think it's going to become a dominate player, making my investment in Silverlight skills not nearly as effective as if I had taken this time to continue brushing up on my webapp abilities. -- It has its own CLR, making a lot of the .NET tool stack incompatible. There is still not an ideal way to test Silverlight components and especially no ideal way to integrate tests into your build tools. Silverlight is waaaaaaay behind here. There is a lot of people out there trying to solve this problem, but so far all the solutions (I've tried most of them) have serious drawbacks. Jeff Wilcox's Silverlight test framework is the best one so far, but it's very slow, cumbersome and buggy. -- Silverlight is incompatible with mobile devices. I have no hope of ever making this app work on the iPhone, Android or Blackberries. I suppose there is hope it will work on a Windows 7 Phone, but that's not enough. My Boss doesn't think this will ever matter to us, I'm not so sure. If we ever do decide we want a mobile version of our app, then at least the frontend of it will have to be completely rewritten from scratch. -- Absolutely everything in Silverlight is asynchronous. This isn't a real problem, per se, and is a good boon sometimes, but there are times when it's a pain in the butt. -- We have found the Mac Silverlight plugin and the PC Silverlight plugins have significant differences. Currently our app has serious flicker issues when ran on a Mac. We're not doing anything hacky, home brew, anything like that. The stuff that looks bad on the Mac is pure Silverlight code the way Silverlight was intended to work. I simply think the Mac plugin has more bugs and is a lower priority. I have no idea where Moonlight stands, but I have a feeling similar issues would occur. If I have to fight to get my app to run across all Silverlight plugins adequately, then IMO a major selling point of Silverlight is gone and I might as well just use HTML and fight to get it to to work across all browsers. At least dealing with browser issues is a common problem with a lot of solutions out there (a framework like Rails will even hide a lot of it). Dealing with Silverlight plugin issues? My only resource is the Silverlight forums and Microsoft Connect. I'm not nearly as hopeful there. -- We are forced to use the Microsoft stack. Yes you can host a XAP file in Apache on Linux, no problem. But if your Silverlight app needs to work with data, there's a very good chance you are going to choose WCF RIA Services (which we did). Bam, use IIS to host the app now or take the gamble with Mono. Not a gamble I want to take. I much prefer Apache over IIS. -- And ultimately, my real problem is as I write this app I just don't see any huge compelling features of Silverlight that makes all this worth it. Just about anything Silverlight can do, an equivalent modern webapp can do as well. Yes Silverlight does allow you to do this from the comforts of Visual Studio, C#, Blend and XAML. Much nicer waters to swim in than JS, without a doubt. But I just don't think I care. I think I'd rather deal with the current state of HTML/JS/CSS and end up with an app that potentially could be used on any device (within reason), can be hosted in Apache running on Linux, and can be a far lighter experience for the end user to boot.

Qz 16y ago
I like C# but XAML drives me nuts. Getting binding to work is like pulling teeth. I've taken to prototyping stuff in Flex because MXML binding is ridiculously simpler, although there's a bunch of C# stuff I'd love to get back...
- city41 16y ago
  I dislike what INotifyPropertyChanged imposes on my code. I also hate that faulty binding can't be found at compile time, but that might be expecting too much. I also dislike how binding is all or nothing, this isn't possible Text="{Binding PercentageOfFailure}%" But that also might be asking too much and even the idea that my view model should be formatting my data is a valid one.
  - Qz 16y ago
    That's why I like binding in Flex -- making something bindable is as simple as plopping [Bindable] in front of it. And binding also isn't all or nothing, you can easily do something like text="{loan.interestRate}%". It also has code completion for anything you put in the binding, although not quite as robust as elsewhere.
    - city41 16y ago
      Interesting. I actually don't know the first thing about Flex. I think you've inspired me to look into it.
      - Qz 16y ago
        Flex 4 is pretty interesting -- they separated layout from the core of container components. So for example in XAML you have Grid, Canvas, Stack, etc. In Flex 4 you just have Group, which then has a layout property -- there's a few basic ones like basic(canvas) vertical, horizontal, and tile, but you can easily code your own... and then switch them on the fly. Flex is basically a really damn good system for UI coding and design, but the ActionScript that backs it up is pretty weak compared to C#. If I could mix C# with MXML I would be in coding heaven...