New guidance: No more Silverlight for the web?

Microsoft sparked quite a controversy when Bob Muglia stated in an ZDnet interview that their â€śStrategy had changedâ€ť regarding Silverlightâ€™s position, and HTML5 was the future way to go. In this post, I look at the whole debacleâ€™s effect on future technology recommendations.

Of course, everything posted here is my opinion and has nothing to do with Microsoftâ€™s truth.

Itâ€™s really XAML vs. HTML, and XAML lives beyond the web

Weâ€™ve seen for years that WPF and Silverlight are on a collision course. The two platforms are already reasonably close feature-wise, and the approach seems to be continuing. While full-blown WPF apps will certainly have features beyond Silverlight and Silverlight will have platform qualities unlike the libraryish WPF, these are all really rather insignificant factors. There will be one XAML platform, with one developer competence broadly sufficient for both.

How is this relevant? It is, because XAML has a far broader impact than HTML5. Even with Rayâ€™s Post-PC vision, the full-blown PC is here for at least another ten years. If you want to build a rich UI on one of those still most dominant forms of electronic devices in the world, you will use the XAML stack.

Whether or not the XAML stack will reach devices beyond the desktop PC is a good question. Microsoft Surface is an example of potential direction of expansion, yet Microsoft isnâ€™t exactly poised to conquer the OS market for all slim touch-based household devices. But they have now demonstrated the viability of Silverlight on the Windows Phone 7, so I wouldnâ€™t count them out yet.

HTML 5 was always going to win on the web

Silverlight was an effort to speed up the creation of richer internet application at a time when browser capabilities were not sufficient for application development (certainly because of IE, to an extent). Mind you, it was successful at that: It brought onboard a whole slew of developers previously new to the RIA scene.

An even battle with HTML 5 was never particularly realistic. The W3C process and browser evolution is slow, and Silverlight filled a gap. But just like with CSS, once the spec is actually implementable, the W3C-driven standard is in a position to grab the market, largely because its creation was so heavily driven by vendor consensus.

Given the annoyance towards Flash that had lasted for years, how likely was it ever for another plugin, especially by Microsoft, to replace it?

It is extremely important that Redmondians embrace the HTML5 world. It keeps Microsoft-driven web development relevant â€“ because no, Microsoft wonâ€™t control the next generation of device platforms, and yes, we as Microsoft technology developers need to be able to address the wider audience. Thereâ€™s no way Microsoft would get Silverlight onto all those devices!

The XAML stack still has a role

But even with all the drive HTML 5 has, it doesnâ€™t render everything else obsolete. In fact, the XAML stack has certain great advantages on its side:

The developer toolset for WPF/Silverlight is far more mature than for HTML5. Although HTML5 tooling is advancing in leaps, it still consists more of separate libraries compared to the relatively unified developer experience Microsoft provides.

The data connectivity between Silverlight and the server is far stronger than it is between HTML5 and a server. Although protocols like OData are becoming more common and JSON serialization is now a part of every respectable programming Framework, a data framework of RIA Servicesâ€™ caliber and LINQâ€™s syntax is a luxury HTML5 developers donâ€™t have.

Silverlight still has features that beat the HTML5 equivalents. In particular, support for touch, offline mode and various media replay features far exceed what HTML5 has to offer at this time.

When to pick which?

My recommendations:

For business apps with need for added richness and web deployment, use Silverlight.

For rich â€śdesktopâ€ť apps designed for maximum experience on a certain device, of course including Windows Phone 7, use Silverlight.

For broad reach consumer apps, default to HTML5.

If very high-fidelity media replay or similar features are required, sprinkle islands of Flash or Silverlight into the mix.

If your app would benefit more from the strong points of the XAML stack as listed above, consider using Silverlight.

Gauge the competence of your existing developers. While a Windows Forms business app developer is not ready to just jump into a Silverlight project, the knowledge gap for jumping into an HTML5 endeavor is even wider.

With HTML5, developer productivity increases considerably during the next few years. With Silverlight, developer experience is already considerably more mature.

Remember: Although HTML5 is likely to outlive Silverlight, it doesnâ€™t mean Silverlight will die before your application is naturally obsolete. Do balance the short- and long-term benefits for your specific scenario.

3 Responses

Tiny addition: the Bing Maps 3D control that was announced to be dropped, was ActiveX-control. Surely, we are not going to miss that? Similar functionality is going to be added to the Bing Maps Ajax and Silverlight controls.

A few opinions to add:
– Silverlight on mobile 7 and silverlight on the web have a number of differences including widgets and API itself. In my opinion the differences are substantial enough that I would actually call developing silverlight for windows mobile and web two different things. This may be a bit of a stretch, but I think calling silverlight for mobile 'silverlight' is almost more of a marketing thing; maybe to capture part of the previous silverlight community and transform it into the windows mobile community. To further point out the differences, the WM7 devices given out at PDC don't even render silverlight web apps in its browser!
– I actually wouldn't be surprised if we see a much further divergence between silverlight on 'Windows Mobile v-next' and silverlight for the web. Just giving Silverlight and XNA as a dev platform on the phone seems to limit the programmability of the phone. Even today looking at the documentation for Windows Mobile 7 there are several places where they say something like "This API works just like silverlight's API except…" and then they list 3-4 changes.
– I would take your statement about XAML living beyond the web a bit further. XAML is more than just being about presentation. To me, its about describing things. For example, Windows Workflow and WPF use the same XAML stack despite WF XAML describes processes rather than presentation (there's actually a neat code sample that mixes WPF and WF XAML to show that they are the same stack). I would guess that if there is a .net executing device in the future that would benefit from some complex object being declared pre-execution, it will likely understand XAML.

Pasi: Yes, of course. The key segment from the CNet article is IMO this: "Saying the same thing can now be done with Ajax, the technology Silverlight was utilized to replace just less than a year ago, does not say much for its future as part of the company's online services strategy."

While I agree the decision was a sensible one and broadens the reach of Bird's Eye imagery, from the Silverlight perspective it certain does sound bad!

Michael: Lots of good comments, again.

1. The fact that WP7 devices don't run Silverlight on the browser doesn't really surprise me. And yeah, certainly there are differences in developing for a reasonably UI-constrained device such as WP7 and the fairly open browser canvas. But the mental model of Silverlight remains, at least in my opinion, fairly same between the contexts.

2. I'm not sure about that. Although there are areas where divergence is likely (WP7-Silverlight taking specific advantage of the phone's constrained hardware specification), the improvement in raw CPU/GPU power is likely to compensate in terms of hardware capability. Also, some of the differences in the framework look as if caused by simply lack of time on behalf of the WP7 team.

3. True. I was using the "XAML stack" as a reference to XAML-based UI design, but you're right.