Why Silverlight.js in 1.0?
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:
- be backwards-compatible with Silverilght 1.0
- rely on static HTML only
- offer the right installer for the right client (Mac vs. Windows vs. other)
- provide actionable feedback to users who will not be able to use Silverlight
- 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.