Silverlight - Pros & Cons

Download Silverlight - Pros & Cons

Post on 23-Nov-2015

31 views

Category:

Documents

0 download

Embed Size (px)

DESCRIPTION

Continue developing with Silverlight or not.

TRANSCRIPT

<p>Microsoft tehnology:Silverlight is much more than a browser technologyOverviewSilverlight is technology that allows you to create rich web-looking applications on the desktop, complex video components for the web , and to reuse the same skills to build native mobile applications for Windows Phone 7. But they should stop comparing Silverlight to HTML5, they are complementary technologies, not competing technologies.Silverlight enables applications that deliver the kinds of rich experiences users want. We group these into three broad categories: premium media experiences, consumer apps and games, and business/enterprise apps.Use Silverlight for: To build desktop applications To build Windows Phone 7 native applications And to build islands of interactivity of web applications, where the current simpler and more standard technologies are not enough, like in media applications. </p> <p>Article: When Should You Use Silverlight?Theres been a lot of talk recently about Silverlight in particular comparisons to HTML (JavaScript/CSS). Unfortunately a lot of these comparisons come down a catfight over whether one is better than the other. The truth, of course, is that both have their place and the challenge is in fact deciding when to use one technology set over another.Simone believes Silverlight is limited to desktop, Windows Phone 7 and niche extensions to traditional web applications. Despite his (IMHO false) assertion that HTML/JS/CSS can do almost as much as Silverlight (deserves a separate post to address this wildly inflated claim come on Simone!) I actually agree with his definition however, I would further comment that the desktop is not the same as it was when we all wrote VB apps and installed them on our users (Windows only) desktops, one MSI at a time! The new desktop now covers, mobiles, televisions, Windows &amp; Mac desktops, Xbox and are growing markets that Silverlight is in a great position to make an impact in.So I decided to write down the scenarios that I believe might compel you to choose Silverlight. Not in any particular order, You need the power of the desktop but delivery of the web historically the rise in popularity of HTML based applications was driven by the easy in which applications could be updated and distributed. Simply update a few files on your web server and auto-magically your clients had the latest version. Silverlight gives you this same power and in addition your users can control whether/when they upgrade. Technologies like MEF and Prism also allow you to modularize your applications to allow for selective downloads/upgrades depending on a users permissions. In fact, Id argue that Silverlight out-of browser with elevated privileges is where it becomes a completely different beast to HTML applications. If also raises the question of when does Silverlight become WPF or perhaps more importantly when do we stop seeing them as different technologies and start talking about XAML applications that can target either the desktop or browser, share a common set of assemblies, but depending on the target can reference specialised enhancement assemblies. Youre building a graphics intensive application kind of a no-brainer really. Sure you can use the newly supported canvas tag and some fancy JavaScript libraries but its a drop in the ocean to whats possible in XAML and C#. Your application needs to operate outside the sandbox of the browser there are some restrictions you simply cant get round in the browser, primarily for security reasons. You cant access information on a users computer, you cant write to a users disk (other than cookies and HTML5 offline storage), you cant access devices connected to your users machine by running Silverlight out-of-browser and/or with elevated trust a lot of these restrictions are lifted. You need to interact with the device your application is running on in addition to the comments above there are an increasing number of scenarios where your application needs to communicate with local devices. As mobiles, televisions and other devices become more important for business and consumers the applications that run on them need to be more and more advanced. You want to be able to integrate cameras, webcams, scanners, printers into your applications and the browsers sandbox wont allow this. Your application needs to stay alive there are lots of examples of applications that need to keep running but are still connected to the internet email clients, twitter, face-book and IM clients, monitoring applications (for say networks, stock prices...). These applications typically need to stay alive at all times and notify you when things change like display a toast notification or give some audio feedback. While you can achieve some of these features in HTML I dont know many people that would prefer to use a browser twitter client over a web based one its just not the same. Your application needs to take heavy use of state - HTML5 has add local storage which (if youre a .NET coder) is similar to Session State management in ASP.NET but instead controlled by the browser. But this is a long way from the statefulness (not a word but lets make it mainstream!) most of use have forgotten after years of web development. Remember when the applications we built didnt have to make a server request to load a new view? Or being able to Imagine being able to browse to a different page without making a server request. Imaging being able to store state in memory You need your application to look exactly the same on all platforms because each browser interprets your HTML in order to render it to the screen it is not possible to guarantee your pages will render the same. Sure theyll be close but if you application relies on pixel perfect rendering Silverlight is a better choice. Your application needs to work offline HTML5 has made some cool advances here but it does seem a bit simplistic you basically get to nominate pages that should be available offline and these will be cached and served locally. In Silverlight OOB applications the only thing you are typically doing over the wire is communicating with services to process data everything else is done locally anyway with no requirement to be online. You can continue (or switch) to storing data in Isolated Storage or in disk in user folders, pages can be navigated to and rendered as normal. Like an offline HTML application you simply need to proxy your service requests to handle being offline and I know Id rather be doing this logic in C# not JavaScript. Your application needs to consume/create media again a no brainer even with HTML5s video tag there is so much more available in Silverlight you get smooth streaming, multicasting, editing, video brushes and unlimited rendering options for your player. Your application needs to support multi-touch in Silverlight you can detect multi-touch interactions from your users in HTML it cant. Youre building a game sure you could (if you really wanted to) build Pong in JavaScript but if you want to create anything serious then Silverlight is a good alternative for a .NET coder that doesnt want to learn Flash/Action Script. Your application needs to be highly performant (again not a word but should be one) Ill admit I havent done any tests myself but others have and it seems that in general Silverlight is faster than JavaScript for graphics and processing. Its also true that your users will find a Silverlight application to navigate around since it doesnt need to perform server page request this can make a huge different to both real and perceived performance of your application. Ive deliberately stayed away from questions over whether solutions are easier in Silverlight/C# versus HTML/JavaScript/CSS at the end of the day it comes down to your teams experience and knowledge of each technology set. But I personally love the fact that in Silverlight I get to code entirely in C# both on the Silverlight client and in services on the server. I also love not having to worry about page requests, session management, browser compatibility (as long as Silverlight is supported Im good to go), page weight (ViewState anyone in Silverlight I just dont care!), unit testing JavaScript (possible but yet another framework to use and support in Silverlight you can use one testing framework for client and server and stick with it), page lifecycle (especially in ASP.NET not so bad in ASP MVC), session timeouts, state</p>