Good riddance! I spent the last 5 months at a gig working on a massive Silverlight 4 application. I've been a web guy forever, but I took this job thinking it would be good to learn how the other half lives. After experiencing the pain and drudgery of working with Silverlight, I couldn't be happier that it's going away.
The most maddening part of working on a Silverlight app was that things that are dead simple with HTML/JS/CSS are tons of work with SL. I was always amazed at the gymnastics required to get even simple UI functionality to work.
Xaml itself was a problem. Why in god's name to we need another superset of XML? Especially with all that atrocious binding syntax.
And also, every time you want to see a UI change you have to build the XAP. When you have tons of Xaml is takes forever to compile to see a minor change!
Interesting... I as a Silverlight dev now learning JS/HTML/CSS would say the complete opposite. I find it very difficult to create similar layout functionality like DockPanel and friends. Any tips?
You know it's interesting that you're seeing lots of pain going the other way. I realized part of my issue with Silverlight was just how different it was from what I was used to. I don't like things I don't understand :) That being said, I did like the Stack Panel and the Dock Panel. I liked them because they worked more closely to the way HTML layout works. It was the Grid that I despised. The markup was tough to follow (putting Grid.Row="" and Grid.Column="" for each element inside the grid was stupid) and ultimately positioning in Silverlight was very much about absolute position and fixed dimensions.
As far as tips - vertical stack panels are just a series of unfloated divs (or other block element). Horizontal stack panels are a series of floated divs.
Vertical positioning with HTML/CSS can be tricky, especially in older browsers. line-height and padding/margin are you friends :)
I was a ruby on rails dev for about 3 years up until a year ago, when I got hired by Microsoft. I now work almost entirely on the XAML/C# stack. Honestly, I really like it. There are some very key improvements in the stack that I see over HTML/JS. Javascript is a great language for small and simple scripts, but for larger js-heavy applications it gets pretty hairy quick. Likewise, html is a fantastic markup language for webpages, but for embedded applications it's horrible.
Silverlight in itself was never meant for the web, it was meant for more robust desktop applications, and it shows. The C#/XAML stack works great for complex applications. Likewise, html/js aren't that fantastic of languages to work with when doing embedded applications; but they're a great team for the web.
I see your gripe with the REPL loop and binding but . . .
Would you be willing to share what was easy with HTML/CSS/JS that was tons of work with SL and what gymnastics you had to go through? I'm genuinely curious.
For one thing, with Prism, binding events to view model methods was a giant pain, specifically if you wanted to pass event args. I know I ended up having to write a number of attached properties to handle different event binding scenarios. With jQuery it's a cinch to handle user interaction. (I guess my major gripe in this case is with Prism, which is perhaps separate from SL).
Further, text wrapping and layout were my biggest pain points in SL. I wasn't used to having fixed dimensions on everything. That really bugged me.
Finally, I didn't like the visual state manager at all. There's not really an analogous equivalent in JS/HTML, but for a "rich" internet platform it certainly didn't seem like the way to go to me. I have to run now, but I'll try and think up some more of my pain points and edit as appropriate.
The most maddening part of working on a Silverlight app was that things that are dead simple with HTML/JS/CSS are tons of work with SL. I was always amazed at the gymnastics required to get even simple UI functionality to work.
Xaml itself was a problem. Why in god's name to we need another superset of XML? Especially with all that atrocious binding syntax.
And also, every time you want to see a UI change you have to build the XAP. When you have tons of Xaml is takes forever to compile to see a minor change!