Instantiating Silverlight: HTML vs. Script

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?

Why Silverlight.js in 1.0?

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.

Why <object> in 2.0?

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:

1. be backwards-compatible with Silverilght 1.0
2. rely on static HTML only
3. offer the right installer for the right client (Mac vs. Windows vs. other)
4. provide actionable feedback to users who will not be able to use Silverlight
5. provide an easily-customizable installation/upgrade experience

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:

• Support for users with script disabled
• Always up-to-date server-side user requirement detection:
  • do they want the Windows exe?
  • do they want the Mac dmg?
  • are they running in an unsupported mode (64-bit browser)?
  • Are they running on an unsupported platform?
• Plain HTML install/upgrade experience development

Which model is right for me?

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.

Comments

• Anonymous
  June 23, 2008
  The comment has been removed

• Anonymous
  June 24, 2008
  The Silverlight 2 installation/instantiation model promotes the use of the Silverlight &lt;object&gt;

• Anonymous
  June 24, 2008
  Busy Day in SL2B2-Land: Chris Cavanagh with Soft-Body Physics, Emil Stoychev on Asynchronous SL, Rich

• Anonymous
  September 23, 2008
  Silverlight 2 Beta 2 has been out since June 6th and the number of sites that have taken advantage of