4 ms·

The big advantage I could see is that it runs C#, which has broader application than ActionScript. My impression is that Silverlight's whole packaging & delive

by lmkg 6y ago

The big advantage I could see is that it runs C#, which has broader application than ActionScript. My impression is that Silverlight's whole packaging & delivery model was envisioned to be more wide-spread but didn't take off. Microsoft was thinking that you could write one program, and then easily package & distribute it as a web app (via Silverlight), or a Windows Phone app, or a native Windows app, or an Xbox app. But... Windows Phone died, Xbox never grew from a game platform into a home multimedia platform, and C# did not achieve popularity for user-facing desktop apps. Plus Microsoft churned Windows APIs a few times. I could easily see an alternate present where Silverlight was more successful for a longer time, if the timing was different or if a few events broke a different way. But I doubt that alternate present is better than this one.

muststopmyths 6y ago
Originally Silverlight was purely a web play. With Windows Phone 7 they used it as a UI layer for just about 1 year, but Windows Phone 8 stopped using silverlight in favor of WinRT(~2011/12). Xbox never supported silverlight as a development platform in any of its iterations. You may be confusing the WinRT/UAP/UWP fiasco with silverlight.
- lostmsu 6y ago
  In some sense they are all sides of the same fiasco, like Google's Allo and Duo.
cm2187 6y ago
On C# not achieving popularity for desktop apps, I think the problem is rather the lack of new desktop apps rather than C#, all new development tends too be web based even for internal apps. The problem is still deployment. I think client side blazor has a potential for creating internal applications quickly with zero deployment required without havint to touch javascript.
- alkonaut 6y ago
  Yeah if you look at business facing apps I think between the apps that can be web (so they will) and the apps that can't be C# because of perf (games etc) you have a pretty small selection left. That doesn't mean C# has failed in that niche, far from it. But it's not a very visible niche because it's not what consumers use. The use case is bespoke LOB/PoS/Internal apps. Just like VB.
  - cm2187 6y ago
    I agree. But it's not a small segment. It's not very visible from the outside but the number of internal developers in large companies is huge. And it's a segment where they don't care so much about load time (intranet, no quick browsing) and where using the same language for front end and back end is appealing.
regularfry 6y ago
Not just C#. IronRuby and IronPython both got subsumed into Silverlight, and a lot of work went into a dynamic language runtime layer to allow that to happen. That whole era was full of "could have been"s that ended up not being because someone lost on the Microsoft internal politics merry-go-round.
yellowapple 6y ago
> and C# did not achieve popularity for user-facing desktop apps. It didn't? Because a lot of desktop apps I've used seem to use it, and lately it's even become a reasonable cross-platform option. I know for sure it's pretty common for games; besides Unity, I know e.g. The Sims 3 (and maybe 4?) uses it pretty heavily (including for mods), as do some more recent games like Mount & Blade II: Bannerlord.

by lmkg 6y ago

muststopmyths 6y ago

Originally Silverlight was purely a web play. With Windows Phone 7 they used it as a UI layer for just about 1 year, but Windows Phone 8 stopped using silverlight in favor of WinRT(~2011/12). Xbox never supported silverlight as a development platform in any of its iterations. You may be confusing the WinRT/UAP/UWP fiasco with silverlight.

lostmsu 6y ago
In some sense they are all sides of the same fiasco, like Google's Allo and Duo.

cm2187 6y ago

On C# not achieving popularity for desktop apps, I think the problem is rather the lack of new desktop apps rather than C#, all new development tends too be web based even for internal apps. The problem is still deployment. I think client side blazor has a potential for creating internal applications quickly with zero deployment required without havint to touch javascript.

alkonaut 6y ago
Yeah if you look at business facing apps I think between the apps that can be web (so they will) and the apps that can't be C# because of perf (games etc) you have a pretty small selection left. That doesn't mean C# has failed in that niche, far from it. But it's not a very visible niche because it's not what consumers use. The use case is bespoke LOB/PoS/Internal apps. Just like VB.
- cm2187 6y ago
  I agree. But it's not a small segment. It's not very visible from the outside but the number of internal developers in large companies is huge. And it's a segment where they don't care so much about load time (intranet, no quick browsing) and where using the same language for front end and back end is appealing.

regularfry 6y ago

Not just C#. IronRuby and IronPython both got subsumed into Silverlight, and a lot of work went into a dynamic language runtime layer to allow that to happen. That whole era was full of "could have been"s that ended up not being because someone lost on the Microsoft internal politics merry-go-round.

yellowapple 6y ago

> and C# did not achieve popularity for user-facing desktop apps. It didn't? Because a lot of desktop apps I've used seem to use it, and lately it's even become a reasonable cross-platform option. I know for sure it's pretty common for games; besides Unity, I know e.g. The Sims 3 (and maybe 4?) uses it pretty heavily (including for mods), as do some more recent games like Mount & Blade II: Bannerlord.