Joe Levi:
a cross-discipline, multi-dimensional problem solver who thinks outside the box – but within reality™

Day 1, Building Rich Web Experiences using Silverlight and Javascript for Developers (DEV11)

Why Silverlight™?

  • Silverlight lets you put video on the web (WMV 7 -9, as well as high-definition up to 720p, W00T!)
  • Silverlight lets you put audio on the web (WMA 7-9, as well as MP3)
  • Silverlight is cross-platform and cross-browser; the Silverlight plug-in is RIDICULOUSLY small (especially when compared to Flash)
  • Visual Studio support
  • Expression Studio support

More notes on this topic to be transcribed later.


You may also like...

13 Responses

  1. John Dowdell says:

    ” Silverlight plug-in is RIDICULOUSLY small (especially when compared to Flash)”

    Silverlight 1.0 beta Mac: 5.3M
    Silverlight 1.1 alpha Mac: 10.3M
    Silverlight 1.0 beta Win: 1.4M
    Silverlight 1.1 alpha Win: 4.3M

    Adobe Flash Player 9 Win (ActiveX): 1.2M
    Adobe Flash Player 9 Win (plugin): 1.2M
    Adobe Flash Player 9 Mac (binary): 4.2M
    Adobe Flash Player 9 Mac (PPC): 1.8M
    Adobe Flash Player 9 Linux: 2.5M


  2. Joe says:


    Thank you for the reply!

    Although I haven’t had time to confirm your numbers I don’t have any reason to doubt them.

    Perhaps rather than “ridiculously small” I should have said how “ridiculously fast” the total “sniff to download to install to viewing content” was, which was literally less than 10 seconds (of course that was over a broadband connection, but even still).

    Frankly, I was amazed, utterly amazed.

    Hey, while I’ve got you here, when are you guy going to release a version of the Flash player that will stream content when loaded through the standard <object type=””> tag (without a nested embed tag)?

    Thanks again for the comment!

  3. John Dowdell says:

    SWF file format naturally streams. Video content is progressive-download unless there’s a streaming video server.

    “OBJECT/EMBED” has a tortured history… Netscape introduced EMBED 1995, Microsoft duplicated extension support with OBJECT a year later, and got the W3C to bless their tag (with different syntax) a few years after that. Browsermakers have had the dickens of a time figuring how to reconcile the W3C spec with the world’s existing content. Practically, I’d recommend continued use of nested OBJECT/EMBED until the various deployed browsers show that they don’t balk with a W3C-style OBJECT. (The Adobe Flash Player itself doesn’t know or care about the invoking HTML.)


  4. Joe Levi says:

    Ah yes… the tortured history of OBJECT/EMBED.

    Although before November 2002 I would have agreed with you on the whole OBJECT/EMBED use… but Alistapart ( says otherwise…

    “Drew McLellan is the author of Dreamweaver MX Web Development and a member of The Web Standards Project’s Dreamweaver Task Force, who work with Macromedia to improve standards compliance in its market-leading web authoring products.”

    Do you have info to the contrary? Please say you do!


  5. John Dowdell says:

    ? Not sure what you’re asking, but a search on our names will reveal tons. Add “geoff stearns” in there for more.

    (I think Drew was seeking to decrease use of EMBED tag, but he didn’t actually test how current browsers behaved with that tag.)

  6. Joe says:

    In response to my obviously detail-lacking previous comment (sorry about that), the ALA Satay method of loading a flash object without using the EMBED tag involves stripping the classid from the object tag, instead relying upon the type property. This, at least at the time of ALA’s writing (a long time ago), caused the SWF to load, but it wouldn’t stream in. Maybe this has changed (read: fixed) in a more recent Flash player, but I just don’t have the time to test this right now (we’re being kept VERY busy at MIX07).

    Looks like we’ve got some homework! Sweet! John, you rock!

    Since you’ve got an ear at Adobe/Macromedia (at least more than I do), I’d like to see a new release of Flash Player that is instantiated via an external .js library which will automatically sniff for the presence of the player, and if not present will present the user with a default (but developer customizable should s/he so desire) “click to install” button that will download the installer (which we hope the user will then run), then refresh the page such that the plug-in is automatically rendered.

    This is what Silverlight does (pretty much), and a LOT less obtrusive than what Adobe is doing now with the pluginspage value.

    Additionally, the developer would be able to reference that script to pass back to a function in the external .js the path to, height, width, wmode, etc. to a dynamic loader function that would then write the control into the page thus avoiding the whole “automatic” clause in the EOLAS ‘906 Patent (or is it ‘609 Patent?) and activate the control via the script.


    PS: Are you at MIX07? I’d love to meet you if you are! +1 (801) 797-1376 (leave a voice mail and I’ll call you back).

  7. John Dowdell says:

    Sorry, no, I went to MIX last year, but chose not to this year.

    Are you seeking external JavaScript libraries to do plugin/version-detection and route accordingly? If so, there have been many over the years, and recent versions bypass the IE “click to activate” change… here are two popular resources:


  8. Matthew Fabb says:

    The Flash player also has something called “Express Install”, which allows the user to upgrade their Flash player without leaving the website, which I think is what you partly looking for. Here’s a link for more info:

    Also JavaScript libraries such as the SWFObject, include an option to use the Flash Express Install.

    Also one of the JavaScript libraries that extends SWFObject, is SWFObject which gives developers an easy way to allow deep linking in Flash along with better search engine indexing. Here’s the link:

  9. Jon B says:

    It seems to me the people who rave about silverlight were never that knowledgeable in the use, or capabilities, of flash. From what I’ve read so far silverlight does have some cool features (presented in such a way that they appear unique to silverlight) but many of them are features flash pioneered.

    To be honest I work with flash but often find application development a bit of a pain – I’m hoping silverlight will make that easier – but I’m not about to shout about it being the ultimate plugin for RIA just yet – Flash has a proven history of good apps (and a lot of crap too lol) and also an amazing developer community including adobe employees.

  10. Jon B says:

    Ooh, as an interesting note I took a look at and it’s not streaming video – it’s progressive download

  11. Joe says:

    Jon B,

    I completely agree. Silverlight is a “Flash Alternative” (excluding Linux at present) rather than a “Flash Killer,” for now, anyway.

    Why do I say “for now”? You’re correct about Flash, it does the majority of stuff that Silverlight proposes to do, and that’s saying a lot. So in that respect, Silverlight is an “evolutionary” technology, learning from others in the marketplace, making easier, making more powerful, adding more features, etc. Simple product differentiation.

    That said, Silverlight is also “revolutionary,” especially in its ease of use, IDE integration (which will really come of age with Silverlight 1.1 and being able to address the SL objects via managed code — 1.0 is only programmably accessible via .XAML and javascript at present), and being able to stream 720p, full-screen over an internet connection, inside a “cross-platform, cross-browser” window.

    Also revolutionary is the manner in which Microsoft is using to invoke the plug-in (with plug-in detection and oh-so-slick download/install of the plug-in if not present). A few people (John Dowdell and Matthew Fabb) have pointed out similar capabilities with the “Flash plug-in install/upgrade experience”, and while that’s cool (and stuff that I didn’t know about before — thanks guys!), the fact is that Microsoft is doing this for the developer, by default. Adobe needs to do that to make their plug-in install/upgrade even more translucent to the end user. Failing to do so isn’t going to “kill” Flash, but it sure has the potential to erode the share of sites that use Flash versus Silverlight.

    Also revolutionary is the .XAML format, and although that’s not specifically a Silverlight feature, it exposes the capacity of an open, extensible project format that was demonstrated across development tools (Visual Studio “Orcas”, Expression, Media Encoder, etc.). I can’t wait to see how Adobe responds to this by extending their applications to utilize the same (or even an extended) .XAML format. It could be argued that Microsoft didn’t include native (nor import/export) Adobe Photoship, GoLive, Illustrator support in their suite of tools, so why should Adobe add support for “Microsoft” formats? In my opinion, with Adobe’s ubiquity in the design arena, they’re “all that” and could really set the bar and further strengthen their market position by allowing current designers to stay in the suite that they’re comfortable with, yet allow us designers to be able to use the designer’s files in their native format, rather than slicing and dicing and “rebuilding” their design in Visual Studio with ASP.NET, CSS, and XHTML.

    My last point, Flash, again in my opinion, seems to be a “media player” by ancestry, and scripting and actions and all that other “interactivity” were sort of slapping in there and muddied up the waters. The last few builds of the designer have improved on this DRAMATICALLY, but it still feels like anything but just playing the timeline contiguously was an “inconvenience” to the development team. That’s just my bias, of course, but I’m sure it’s an opinion that’s shared by at least a few out there.

    Bottom-line: Adobe has just been passed, and if they don’t catch up quick they run the risk of being lapped.

    I sincerly hope that the execs at Adobe quit flinging-mud and start saying “yeah, competetion is good — they’ve done some cool stuff — just wait till you see what we’ve got coming!” (Bruce Chizen, are you listening?)

    Thanks for the comment Jon!

  12. Scott Barnes says:

    Silverlight is still in beta, and the runtime players itself will probably get smaller depending on how the 1.1 moves forward.

    Overall, we have a compelling solution here for 1.0 and whilst it’s still somewhat beta, the difference between what I was initially shown in Feb07 to now is leaps and bounds ahead of what it once was (I’m amazed at the level of progress the SL Teams make daily). The Silverlight teams are commited to doing better and getting the pieces as small as they possibly can going forward.

    I’d also like to point out that the end result (ie applications themselve) are extremly small in payload. From memory the Top Banana application was approx 30k in size (excluding videos of course).

    I’d worry less about “Flash Killer” theories and keep an openmind on where it’s going, what it can do now and more to the point how the rest of the Microsoft stack can play a role for developers going forward. (Silverlight with for example).

    Experience First technology rox 🙂

    Scott Barnes
    Developer Evangelist

  13. Joe says:

    Scott, well said. From the developer’s standpoint, Silverlight (particularly 1.1alpha) is so much easier to code to (what with .XAML and managed code and all).

    I am really excited about playing with it on some of the sites that I maintain! 🙂

Leave a Reply