<story><title>Microsoft has Abandoned Silverlight and All Other Plugins</title><url>http://www.infoq.com/news/2011/09/Metro-Plug-ins</url></story><parent_chain><item><author>neilk</author><text>A question for those of you who work with Microsoft frameworks. Why do you believe in &lt;i&gt;any&lt;/i&gt; technology that MS gives you? How is it these people have any credibility left?&lt;p&gt;Their technologies are invariably doomed to obsolesence within about 2-3 years of their introduction. Those that the web doesn&apos;t make obsolete are eventually thrown under the bus by Microsoft themselves in about the same time frame.</text></item></parent_chain><comment><author>gecko</author><text>I think you&apos;re looking at it wrong.  Let me walk you through what I see/saw as someone who&apos;s been an active Linux, Windows, and Mac user since about 1996.&lt;p&gt;In 1993, I&apos;d write a Windows 3.1 app with Win16, a Mac app with the Mac Toolbox, and a Linux app with one of Athena, Xlib, or (I don&apos;t remember if this was around at the time) Motif.&lt;p&gt;In 1996, I would have made some trivial modifications to my Win16 app to make a Win32 app for Windows NT or 95 (and Microsoft made this a lot easier with things like message crackers and typedefs); my Mac app would need a recompile to target PowerPC, but otherwise be fine; and my Linux app still requires no changes either.  So far, so good.&lt;p&gt;By 2001, my Windows app still works perfectly.  It&apos;ll look dated unless I make some changes to the manifest to indicate that I&apos;m ready for the new common controls, but this is pretty straightforward to do; it&apos;s not a big rewrite.  I can start heavily using COM without rewriting my whole code-base.  My Mac app will have required a port to Carbon--significantly more work than the Win16 to Win32 migration, but not horrible, and my app&apos;s now native for the upcoming OS X.&lt;p&gt;But Linux?  Wow.  I mean, I guess I can keep running my app--it executes--but no one uses Athena, no use uses raw Xlib.  I really need to port to Gtk+ 1.2 or Qt 2.0 if I want to look anything vaguely close to acceptable.  And this is a &lt;i&gt;major&lt;/i&gt; rewrite for me to undertake; they look very little like their predecessors.  Yes, the toolkits are open-source, and yes, they still &lt;i&gt;work&lt;/i&gt;, but let&apos;s be real here: I need to rewrite.&lt;p&gt;Let&apos;s move forward to 2005.  My Win32 app &lt;i&gt;still works&lt;/i&gt;, without changes.  Granted, I might want to start using the nascent .NET, but Managed C++ and COM interop makes that pretty easy to accomplish piecemeal.  On the Mac side, the writing&apos;s getting on the wall that Carbon&apos;s going to die, so I&apos;m going to want to start porting to Cocoa, and that amounts to basically a full rewrite.  I&apos;m also going to want to start porting my app to Intel.&lt;p&gt;And on the Linux side, I&apos;ve got to move to Gtk+ 2.0 or Qt 4.0.  And that&apos;s again a &lt;i&gt;big deal&lt;/i&gt;.  If you weren&apos;t using Gtk+ or Qt back then, you should know that it was (at least in my opinion) a relatively large amount of work to upgrade.  Not a full rewrite, mind you, but Qt redid piles of classes, methods, and hierarchy, and Gtk+ introduced glib, reworked signalling, themes, and tons else I&apos;m forgetting.  It was a lot of work.&lt;p&gt;Jump to 2010.  My Win32 app fucking &lt;i&gt;still works&lt;/i&gt;.  Managed C++ is really mature right now.  And if I wrote C# or VB or anything in WinForms, it&apos;ll also still work, and it can use COM objects I export from my old C++ app, and expose COM objects to my old C++ app.  My Mac app, rewritten in Cocoa, still works fine, as long as I ported it to Intel, too; otherwise, users can&apos;t easily run it without installing Rosetta, an automated, if separate, install.  I&apos;m also going to be seriously thinking about trying to get it also running on Cocoa Touch for the i* devices, which have a radically different GUI toolkit.  On the Linux side, the GUI of my app should still be in fairly good shape, although G-d help me if I did anything involving sound or 3D effects, since that API&apos;s gone through many wholesale changes in the last few years.  And if I didn&apos;t write plain Qt and Gtk, but instead using GNOME and KDE, then...wow.  I&apos;ve had a lot of pain.  I went through to KDE 4, which was a &lt;i&gt;huge&lt;/i&gt; deal.&lt;p&gt;Now, we&apos;re leaving out that, in the 2005-2010 timeframe, Microsoft introduced WPF and Silverlight.  So let&apos;s assume, in addition to my old C++ app that still works, I&apos;ve now also got a few Silverlight and WPF apps I&apos;ve written.&lt;p&gt;Now it&apos;s 2011.  What happens on these three platforms?&lt;p&gt;On the Mac side, I&apos;m in the same place: I need to be &lt;i&gt;really&lt;/i&gt; thinking about Cocoa Touch, but my existing Cocoa app still works fine.  If I didn&apos;t port to Intel, my app is dead, but that wasn&apos;t hard, so let&apos;s assume I did it.&lt;p&gt;On the Linux side, having gone through the KDE 4 transition, I&apos;m now dealing with the GNOME 3 and/or Ubuntu-being-a-weirdo transition.&lt;p&gt;On the Windows side, in Windows 8, &lt;i&gt;my old app still runs.&lt;/i&gt;  My Silverlight apps and my WinForms apps and my WPF apps &lt;i&gt;still run&lt;/i&gt;.  The bad news is that they run in the legacy Windows desktop.  So now, what has to happen to fix that?&lt;p&gt;My C++ app&apos;s GUI is fucked.  Total rewrite.  Really total, even worse than the Gtk+ 1.2 to 2.0 transition.  WinForms, too.  They&apos;re not coming to Metro.&lt;p&gt;But my Silverlight and WPF apps?  Are you serious?  It&apos;s &lt;i&gt;very&lt;/i&gt; little work to get these running on Metro.  Metro uses XAML really heavily, and has a very Silverlight-like view of the .NET libraries, actually.  Most of the changes I&apos;m going to make are mechanical and look-and-feel.  This isn&apos;t &lt;i&gt;trivial&lt;/i&gt;, but it&apos;s at worst a lot easier (IMHO) than the movement from Gtk 1.2 to 2.0 or Qt 3 to 4.&lt;p&gt;So you know what?  At the end of the day, Microsoft looks &lt;i&gt;really good&lt;/i&gt; to me.  Great binary backwards compatibility, and really good toolkit compatibility.  They&apos;ve given me a really clean migration path from Silverlight/WPF to Metro that does most definitively not require a full rewrite.  This is better than both other platforms listed above.&lt;p&gt;Me?  I&apos;ll take it.</text></comment>
<story><title>Microsoft has Abandoned Silverlight and All Other Plugins</title><url>http://www.infoq.com/news/2011/09/Metro-Plug-ins</url></story><parent_chain><item><author>neilk</author><text>A question for those of you who work with Microsoft frameworks. Why do you believe in &lt;i&gt;any&lt;/i&gt; technology that MS gives you? How is it these people have any credibility left?&lt;p&gt;Their technologies are invariably doomed to obsolesence within about 2-3 years of their introduction. Those that the web doesn&apos;t make obsolete are eventually thrown under the bus by Microsoft themselves in about the same time frame.</text></item></parent_chain><comment><author>statictype</author><text>Their developer tools are really good. They have a reasonably language-neutral platform in .NET (which, contrary to what you say, has been healthy for - what - a decade now?).&lt;p&gt;Our company&apos;s codebase is written in C#. Some domain specific language parsers were implemented using F# (with Fparsec) and the framework can be extended using IronPython. At some points, we have IronPython code being called from F# code built on a framework written in C#. And it works without specifically having to handle it.&lt;p&gt;Visual Studio&apos;s debugger can seamless step between code written in C# and F#.&lt;p&gt;There are lots of things I miss about Unix dev tools but the Microsoft technology stack is not an unreasonable choice to make.</text></comment>