A year or so a go I wrote a post called Adobe AIR: 10 reasons to love it, 10 reasons to hate it. Here’s the same kind of list for Microsoft’s Silverlight, based on the forthcoming Silverlight 2.0 rather than the current version. The items are not in any kind of order; they also reflect my interest in application development rather than design. It is not a definitive list, so there are many more points you could make – by all means comment – and it will be interesting to have another look a year from now when the real thing has been out for a while.
This Silverlight developer chart is available in full on Brad Abrams’ blog here, or in Joe Stegman’s Deep Zoom version here.
The pros…
1. The Silverlight plug-in means developers can target a single, consistent runtime for browser-based applications, rather than dealing with the complexity of multiple browsers in different versions. You also get video and multimedia effects that are hard or impossible with pure HTML and JavaScript; though Adobe’s Flash has the same advantages.
2. Execute .NET code without deploying the .NET runtime. Of course, the Silverlight plug-in does include a cut-down .NET runtime, but instead of dealing with a large download and the complexities of the Windows installer, the user has a small download of about 4MB, all handled within the browser. In my experience so far, installation is smooth and easy.
3. Performance is promising. Silverlight comes out well in this prime number calculator, thanks no doubt to JIT compilation to native code, though it may not compare so well for rendering graphics.
4. Support for Mono (Moonlight) means there will be an official open source implementation of Silverlight, mitigating the proprietary aspect.
5. Silverlight interprets XAML directly, whereas Adobe’s XML GUI language, MXML, gets converted to SWF at compile time. In fact, XAML pages are included as resources in the compiled .XAP binary used for deploying Silverlight applications. A .XAP file is just a ZIP with a different extension. This also means that search engines can potentially index text within a Silverlight application, just as they can with Flash.
6. Third-party component vendors are already well on with Silverlight add-ons. For example, Infragistics, ComponentOne and DevExpress.
7. Take your .NET code cross-platform. With Macs popping up everywhere, the ability to migrate VB or C# code to a cross-platform, browser-based Silverlight client will be increasingly useful. Clearly this only applies to existing .NET developers: I guess this is the main market for Silverlight, but it is a large one. The same applies to the next point:
8. Uses Visual Studio. Microsoft’s IDE is a mature and well-liked development environment; and since it is also the tool for ASP.NET, you can use it for server-side code as well as for the Silverlight client. For those who don’t get on with Visual Studio, the Silverlight SDK also supports command-line compilation.
9. Choose your language. Support for multiple languages has been part of .NET since its beginning, and having the .NET runtime in Silverlight 2.0 means you can code your client-side logic in C#, Visual Basic, or thanks to the DLR (Dynamic Language Runtime) Iron Ruby or Iron Python.
10. Isolated storage gives Silverlight applications local file access, but only in a protected location specific to the application, providing a relatively secure way to get this benefit.
The cons…
1. If Apple won’t even allow Flash on the iPhone, what chance is there for Silverlight?
2. Silverlight is late to the game. Flash is mature, well trusted and ubiquitous; Silverlight only comes out of beta in the Autumn (we hope) in the version we care about – the one that includes the .NET runtime – and will still lack support on mobile devices, even Windows Mobile, though this is promised at some unspecified later date.
3. The design tools are Expression Blend and Expression Design – but who uses them? The design world uses Adobe PhotoShop.
4. While having solution compatibility between Expression Blend and Visual Studio sounds good, it’s actually a hassle having to use two separate tools, especially when there are niggling incompatibilities, as in the current beta.
5. No support for the popular H.264 video codec. Instead hi-def video for Silverlight must be in VC-1, which is less common.
6. It’s another effort to promote proprietary technology rather than open standards.
7. Yes Linux will be supported via Moonlight, but when? It seems likely that the Linux implementation will always lag behind the Windows and Mac releases.
8. Silverlight supports SOAP web services, or REST provided you don’t use PUT or DELETE, but doesn’t have an optimized binary protocol like Adobe’s AMF (ActionScript Message Format), which likely means slower performance in some scenarios.
9. Silverlight is a browser-only solution, whereas Flash can be deployed for the desktop using AIR (Adobe Integrated Runtime). Having said that, yes I have seen this.
10. You have to develop on Windows. This is particularly a problem for the Expression design tools, since designers have a disproportionately high number of Macs.
Silverlight will run offline, hosted by MOE…
It was demoed back at Web 2.0 in the Live Mesh keynote. At the time it was said that enabling offline running would take just 25 lines of code. I guess we’ll see the tooling at PDC.
Thanks Simon. I agree that Mesh + Silverlight is a really interesting combination. I presume the demo you saw was still browser-based though?
Tim
I suspect in a windowless browser control – but that’s as near browserless as not!
3. Performance is promising.
Yes it is.
Have you seen this site?
http://deepzoom.soulclients.com/VE/
Re: Simon is right to ponder on offline functionality I think, I met with MS recently on Silverlight and apart from a brief nod to some offline caching, the focus seems to be very much on the online experience.
AdrianB
A few of corrections in response to this article (which is also on The Register). Some of negative “cons” statements are contradicted earlier in the article under “pros”, so they might be a bit redundant, but worth being clear on some of the points I think. 🙂
Regarding the lack of support for anything like Action Message Format:
Adobe’s Action Message Format is essentially a binary version of SOAP, only it’s proprietary. You can do the same thing in Sliverlight, for example using SOAP and gzip content encoding (which works just fine, is entirely standards based and more flexible than AMF) and leaving the HTTP connection open. You can equally write your own proprietary binary data format to use in Sliverlight if you want to.
Regarding needing to use the Expression tools, or even Windows:
You don’t actually need to use the Expression tools, and you don’t need to use Windows to develop Silverlight applications. It’s worth remembering that Silverlight isn’t just aimed at “designers”, but also at “developers” (note the quotation marks…) and while the Expression tools are likely to be of significant interest to those who are designers there is nothing to stop developers on Linux or Mac (or Windows) from developing Silverlight using another IDE – there are Mono/C# plugins for Eclipse, X-Code, Text Mate and other editors.
My point being that depending on what sort of application you are writing (or even, just how you want to write it) you might not even want to use the Expression tools at all. I would agree that not having the Expression tools available on Mac could hurt adoption among designers, although I get the impression from those I know who are exclusively designers it’s not nearly as mac-centric a profession as it once was (in fact these days almost all developers I know use Mac but none of the designers I know do!).
On “Silverlight is a browser-only solution”:
While technically an accurate statement, couldn’t be more off the mark in context. With C#/.NET you can reduce code duplication by sharing the same code in your web application, a server application and a desktop application – encouraging you to write classes once then wrap calls to them appropriately (which C# largely makes very easy).
The design also means that if you do roll out a .NET/Mono desktop application you can write a powerful and fully native desktop application, rather than having to compromise in terms of functionality. That said, I do think it would be prudent to provide the option to roll out Silverlight desktop applications easily for those who are just looking for something simple that is essentially a Director replacement.
Regarding VC-1 rather than H.264 support:
I gather that’s because it’s less CPU intensive to decode VC-1 than H.264 and hence more suitable for deployment (still, it does seem silly to me not ALSO have support H.264 out of the box).