Although I’ve half-written blog entries on this before, I’ve scrapped them because at the time I would have been speaking out of turn. Then I thought Microsoft had said enough that everyone got it and a blog entry would be pointless. But today someone I respect said that enterprise customers were still confused about Silverlight, so here is my take on the situation.
Keeping this brief, Microsoft took the presentation technology it had developed for Windows Vista called the Windows Presentation Foundation and created a portable multi-platform/multi-browser application framework called WPF/E (for Everywhere). When it was formally launched WPF/E was renamed Silverlight, and Microsoft proceeded to market it as an alternative to Adobe Flash for Rich Internet Applications. Besides the strong support for video, which HTML lacked, Silverlight made it easier to target multiple browsers than trying to do so with HTML because the browsers had fragmented in their support for HTML (and yes I realize that Internet Explorer was a primary offender). Along comes HTML5 with its Video tag and a commitment from all the major browsers, including IE, to conform to the standard and 90% of the justification for both Silverlight and Flash is gone. Yes there are some scenarios where Silverlight is likely better than HTML5 Video for now, but it is a niche market. Especially since the trend in mobile devices, particularly the iPhone, iPad, Windows Phone, and Metro browser in Windows 8 don’t support plug-ins (such as Silverlight or Flash). So Silverlight the multi-platform/multi-browser application framework is DEAD. Of course Microsoft doesn’t use that word because it is still available, supported, etc. and in fact they only recently released Silverlight 5. But strategically a Microsoft-proprietary multi-platform/multi-browser application framework makes no sense and they won’t move forward with it.
On the other hand, the Silverlight code base is doing just fine. At least I think it is. In Windows 8 they just call it XAML, but I have reason to believe that it is actually the Silverlight code base. That’s what “we” should have called it for Windows Phone 7 as well, and the Windows Phone team did not want to call it Silverlight specifically because of the multi-platform/multi-browser association. But Silverlight was in its ascendency at the time, Visual Studio and Expression Studio were late in their development cycles and had little runway for change, and we (DevDiv) did not want to further fragment (beyond WPF and Silverlight) the XAML world. Plus with Silverlight being “hot” and Windows Phone having no traction we felt that using the name Silverlight for the XAML support in Windows Phone would be a net positive (even though it causes confusion). So we won the argument and Windows Phone uses both the Silverlight code base and name. It probably did help that first year, but at this point it just adds to the confusion. For Windows 8, with no desire or benefit of associating with the Silverlight strategy, it makes perfect sense not to call its XAML support Silverlight. And it wouldn’t surprise me if Windows Phone 8 drops the Silverlight naming in favor of just calling it XAML as well.
Its clear, OK.
But can Microsoft help us, traditional desktop developers, to leverage our skills and expand to the connected webified world ? I mean, can I program a browser-delivered multiplatform app using C# and Xaml ? or I should forget that completely and go to the wild world of JS/CSS ? What about MSIL2JS/Volta ? Script# ?
On the other hand, will there be RiaServices for WinRT Xaml ?
and, is CoreCLR for Mac dead ??
MonoTouch (http://xamarin.com/monotouch) is essentially a C# mono implementation of the CoreCLR that runs on iOS (and Android). As long as you’ve abstracted your GUI layer, you should be able to transfer most of your business logic 1:1. Admittedly, you lose XAML and the Silverlight GUI framework, so it may or may not be applicable for some businesses. Luckily with mine, almost all of our core work is abstracted nicely so we’re looking at having the vast majority of our work 1:1 compatible with all desktop, phone, and tablet flavours (linux, android, max, windows)
I totally agree, Silverlight developers need to move on(myself included).
HTML5 addressed the browser just fine. Not as good as Silverlight in some respects, but better in others. If you want reach with “Good Enough” richness, HTML5 is you markup language.
The only problem I see is that Metro is way too Cloud focused for security concious customers. However, I think Windows 8 Server, with its private cloud capabilities will address that concern.
It’s actually a very exciting time in DevVille, lol!
I’d like to offer a prediction/suggestion. XAML becomes part of MS Open Source as an alternative to the controls for HTML5 & jQueryUI. XAML is lightyears ahead of both in terms of controls, features, etc. It would be a great opportunity to use XAML for more sophisticated RIA apps on ANY platform. Comments?
From a technical point of view, there were plenty of ways for XAML to go that would have
been fantastic. Apple will never allow it. Unless and until people stopped buying iPhones and iPads and perhaps MSFT or maybe even MSFT/Android or some other scenario wins the day and Apple headquarters is a museum, then it’s not a feasible business strategy.
Developers would have no choice but to ignore XAML based browser development UNLESS it’s some kind of weird “compile to HTML5” alternative. Adobe went down that road.
Apple simply ran out the clock on Silverlight. Even if they thought it was better, stronger, cooler, more productive and so on… they have their reasons and their opinions. They had the leading smartphone and Android users weren’t going to get it any time soon so they just waited it out.
“But strategically a Microsoft-proprietary multi-platform/multi-browser application framework makes no sense and they won’t move forward with it.”
Yes, I always felt that too. Cross-platform and cross-browser do not make sense in MS strategy.
But then again, why did Microsoft come with Silverlight as a cross-platform framework anyway?
In response to Flash, but why?
It’s like Microsoft is doing again another step back just because market is not in their favor, not because it’s bad.
Basically three reasons:
1) Rich Internet Applications were where most development focus was moving and Flash was capturing most of that movement. Effectively this meant that Adobe (Flash, AIR, Flex, etc.) would become the app platform for future applications. If Adobe had succeeded in becoming the platform you could follow that to various conclusions. They could create a custom OS (using Linux, OpenBSD, or anything else) with their technology stack on it and offer it as a complete Server or even Client offering in competition with Windows. Perhaps then they’d make their best ideas available first, or even exclusively, on their own operating system making it more attractive to customers than Windows. Microsoft couldn’t let that challenge go unanswered.
2) There was no HTML5 and the browsers were fragmented in their support for earlier standards. That made it difficult for developers to create websites that worked across browsers, particularly Rich Internet Applications using AJAX. That was one of the things pushing people to Flash, and the ey reason Microsoft felt it necessary to go multi-platform/multi-browser with Silverlight rather than embrace standards as the basis for its
3) Responsibility for addressing the web as a platform is split between Internet Explorer (which is in the Windows organization) and Developer Division (in Server and Tools) which is responsible for IIS, ASP.NET, development tools, “breadth developers” as a customer segment, and pretty much anything else “web” that isn’t Internet Explorer. So depending on what lens you look at the problem you come up with different answers. DevDiv decided that Silverlight was necessary for the reasons stated in #1 and #2. The Windows team no doubt objected but lost the argument.
Now along comes a new version of the HTML standard, HTML5, that is really optimized for building Rich Internet Applications. It’s clear that Internet Explorer is going to have to support the standard to some extent. The IE team decideds that rather than give the HTML5 effort lip service it is going to jump in completely and fight to be the premier HTML5-compliant browser. Google (Chrome), Mozilla (Firefox), and Apple (Safari) are already on that path. Apple is so confident of the path that they never support Flash on IOS, and the rest of the mobile world gives it lip service at best. As sites that previously required Flash, such as Google’s Youtube, are modified to work without it for the iPhone and iPad it becomes obvious that a Flash-less world is coming. So Silverlight is no longer needed as a counter to Adobe. But it isn’t just a Flash-less world, it is a world without browser plug-ins, so Adobe’s woes don’t benefit Silverlight. Silverlight has nowhere to go but down with the plug-in ship.
I suppose Microsoft could have taken a different path, made XAML support native to IE, and gone to war against HTML5. But does anyone really think that could have worked? I can’t see how it would have given the combination of IOS and other non-Microsoft OS devices out there and the rising popularity of alternate browsers like Firefox and Chrome. More likely it would have pissed off both website developers and end-users, accelerating the decline in IE marketshare and driving customers away from Windows Server et al as well.
The best technology doesn’t always win. Betamax was better than VHS in most regards, but ended up relegated to niche use (it lived on as Betacam for professional applications even as VHS totally took over the consumer market). One could argue that Silverlight and XAML are better technologies than HTML 5, but that doesn’t mean they win. Silverlight use will quickly fade from the web. XAML use will remain, and even grow, in the context of Windows devices. But in the broad spectrum of computing that is still a niche.
The bottom line is that the premise of this article is a red herring.
“Silverlight is dead, long live XAML” is a pipe dream, as Microsoft is really saying long live HTML5.
They don’t suggest that you use XAML, it’s just there because if it was removed, the scream would be primal, and they would lose a lot of business.
In the long run developers will make that call. If most (or a substantial minority) of Metro apps use XAML then it will have a long, healthy, and active life. If few metro apps use XAML then it will survive as legacy but further lose focus. It’s up to you guys.
You’ve left out XNA and Windows Phone. Where does that leave the hundreds of apps developed for Windows Phone and the very interesting things you can do to unify code bases across “three-screens” (Xbox, Phone, PC)? I am very disappointed that people expect that the console will magically become an HTML5 browser or that you need to use Unity/Unreal/etc to make a bog-standard app like Netflix.
Hopefully Microsoft will give us a clue as to the direction of XNA and game programming shortly. I really have no insights on this.
Everything is dead…given time… The question is – can your application benefit from using a particular technology given the lifetime of that technology.
As a corporate developer I am about 3-5 times more productive with SL than I am with other frameworks/ platforms.
I agree with Jude; I have also developed fairly extensively in both, and I am WAY more productive in Silverlight et.al- but thats just me. I am starting to dabble in HTML5 and it has potential, but I am not counting on it feeding the family anytime soon 🙂
Hello to everyone.
All the people that think Silverlight is dead and would like to change this situation are invited to “SilverlightIsBetter” – http://www.facebook.com/Silverlightisbetter
SilverlighIsBetter is the possibility to improve the use of this Technology on all the kind of device present in the market! I wait you all!
Power View for Excel 2013 currently relies on SL, and I think Power View is a significant development. This is an example of the fact that eventually people will want to be able to access their XAML content via a browser, so I would say the logical conclusion is that SL 6 will eventually have to come out and will be whatever it is that allows people to view their Win8 XAML content remotely on other platforms….
Rewriting away from SL to the native Win8 (or post-Win8) XAML implementation would not be that big of a deal, though if in-browser viewing is that important they’ll probably rewrite to HTML5 instead.
It’s interesting to speculate. I can imagine the scenario as being likely where eventually people will expect parity between what they see in native Office and web Office, even with advanced graphics. Or rather – people would expect to be able to access their content remotely, and the question then is whether ‘remote use’ is the same as web browsing, or if the cloud Office solution becomes platform specific. I wonder if the reason why a web version of Office exists at all is because of the rise of netbooks or low-capacity mobile device access – and if with the rise of computing power in these devices, and a rise in popularity of windows based mobile devices tied to the Office product, the whole justification for web based remote access disappears. In this scenario I would envisage HTML5 being relegated to sort of web-marketing and other universal content, while Office remains native on devices with XAML as the norm.
The first thing to keep in mind is that with the rolling death of browser plugins (e.g., you can’t get them on an iPad, most smartphones, Windows RT, etc.) and IE’s loss of dominant market share XAML as a remoting technology is dead. It just won’t be, indeed can’t be, present on the majority of devices out there. So no group inside Microsoft is going to make a bet on XAML in the browser. Period. Those that made that bet a few years back are hard at work figuring out how to change direction.
The Office Web Apps exist for one reason, the rise of Google Apps. Microsoft needed a way to counter that, particular the free versions. There are numerous scenarios where they make sense and they should have happened independent of Google (and indeed Microsoft looked at similar things before but it took Google to tip the balance in terms of benefit vs risk). Even if Microsoft produces versions of Office for every popular mobile device, there are scenarios where a user won’t have them. Cost is one reason, and Office Web Apps will continue to address the “free” market. But it could be any number of reasons. Just because I want to send you a PowerPoint presentation doesn’t mean that you need to be a PowerPoint user or be using a device with PowerPoint installed to read it. I’m not putting PowerPoint on my mother’s PC just so I can review a presentation you sent me. Or you may be a kiosk user (e.g., factory worker) without your own PC but need to read the company policy document. In the old days we would have talked about the Office Web Apps protecting the Microsoft document formats. That is by ensuring that everyone has a way to operate on the Office documents, independent of if they purchase Office, you ensure that the world sticks with those formats. Otherwise you risk an alternate format becoming the defacto standard. It would be ad for Microsoft if the Open Document Standard beat out the Open XML Standard because Microsoft couldn’t find a way to make access to Open XML documents ubiquitous. So Office Web Apps are here to stay, but that doesn’t mean they will ever equal the feature set available via other versions of Office. They will always be a subset tied to specific scenarios.
I agree that XAML in the browser is dead…but I wonder if in the future there is any need for *remote* viewing of Office content in browsers.
Native viewers and native editors (and hence non-HTML renderers…) will be sufficient if there are sufficient numbers of Windows based mobile devices. In that scenario – where’s the case for HTML based Office apps I wonder.
Hello for windows embedded, be it using compact 7 and targeting x86 or Arm platform SL technology using expression blend 3 still plays a large role in developing slick user interfaces for portable devices. The big advantage in the embedded world is that the graphics or UI are running native. Using a HTML 5 based browser in the embedded world to play video is a whole lot of baggage. SL in this regard for the likes of media audio/video is far better than html5 and life in the browser.
Hopefully MS will enhance the SL technology with a focus on apps that run at native speeds. I dont see SL going away in the embedded space anytime soon… hopefully
SL is pretty strong, shame Flash won in the browser but they got there first.