Many Silverlight developers have noticed a rather fundamental change between the Silverlight installation/instantiation models in Silverlight 1.0 and Silverlight 2.0. Silverlight 1.0 relied on a javascript helper file, Silverlight.js, to provide the installation experience for the control. Silverlight 2 projects and samples, however, have moved away from the Javascript model and towards a more familiar <object> tag model. This raises a few questions: Why Silverlight.js in 1.0? Why <object> in 2.0? And, most importantly, which model is right for me?
Many Silverlight 1.0 developers remember working with a helper file called Silverlight.js. At it's core, this file contained a function called Silverlight.createObject. When a page called on this function Silverlight.js determined if Silverlight was installed and, if so, would put a Silverlight control into a pre-defined <DIV>. This model provides many advantages to the developer. First and foremost, Silverlight 1.0 was a new product with a new <object> tag that was not well understood by most developers. By providing a helper function with named parameters we were able to help folks get accustomed to the Silverlight development model without having to build <object> tags by hand. Second was the installation experience. Silverlight.js provided a consistent cross-browser installation experience which did not depend on browser-specific installation technologies. Third was the selection of an installation binary. Silverlight 1.0 was offered for Windows, Intel Mac, and PPC Mac. By using Silverlight.js a developer could ignore the fact that they needed to choose an installer URL and could trust the js file to do the right thing when a user clicked the installation button. Finally, there was the utility functionality provided by Silverlight.js. Sites which wanted to provide specific experiences based on the installed version of Silverlight could do so through pre-defined javascript. Using javascript also helped Web sites remove the"Click To Activate" requirement in IE.
Despite the benefits of Silverlight.js, using the helper file requires active involvement on behalf of the Web site administrator. As the Web ecosystem changes over time Microsoft will have to continue updating the Silverlight.js file. When we do, web admins who want to take advantage of new functionality will need to download the latest version of the file, stage it, test their Web site, and deploy to production.
In Silverlight 1.0 we wanted to provide a lighter-weight approach for Silverlight installation and instantiation which would give developers many of the benefits of Silverlight.js without requiring the maintenance costs of Silverlight.js. Specifically, we wanted a model which met the following criteria:
After several proposals and lots of testing we found that the <object> tag method, combined with several cool sever and control technologies, provided us with the ability to meet the requirements above in the most scalable fashion. I will get into the details of how this works in a future post, but here's a summary of what you get by using the <object> method:
As you would expect, both models still exist because there are scenarios which are met by one and not the other.
Use <object> tag if you want to add Silverlight to your site and not mess with related HTML or javascript again. Your users will be able to install, upgrade, and view Silverlight content without enabling javascript. Microsoft will provide your sites users with installers and error-resolution web content based on server-side detection. Your Web site will automatically work with new Silverlight platforms as they come online. Changes in browsers are unlikely to impact the functionality of your site because you are using simple HTML concepts and not script.
Use Silverlight.js if you are actively maintaining your Silverlight content and want to have fine control over your users' experiences. You want to use script to provide specific javascript-driven experiences when Silverlight is not installed, when the installation button is clicked, when installation finishes, etc. You also want to be sure that users never see the "Click To Activate" experience in IE. Finally, you want to be able to refresh your web page when installation is finished. Since script is more likely to be affected by changes in the browser, be sure to check back often for changes/fixes in the released Silverlight.js file.
Use a combination of models if you want the simplicity of <object> with the added benefit of automatic page refresh on install. Simply include a <script type="text/javascript" src="[myPath]\Silverlight.js"></script> pointing to your copy of the Silverlight 2 Beta 2 SDK's Silverlight.js file to get this experience.