Jsconf 2011-us
•
4 likes•1,386 views
The making of Yahoo!'s universal JavaScript player, by Dan Beam.
![How to be a Player (on the Internet) ,[object Object],JSConf US 2011 Dan Beam [email_address]](https://image.slidesharecdn.com/jsconf-2011-us-110506210327-phpapp02/85/jsconf-2011us-1-320.jpg)
![What ’ s Y! Media Player? ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
Similar to Jsconf 2011-us
Similar to Jsconf 2011-us (20)
More from Yahoo Developer Network
More from Yahoo Developer Network (20)
Recently uploaded
Recently uploaded (20)
Jsconf 2011-us
- 4. DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS API / Customization
- 8. Our Goals
- 13. Adapter Pattern
- 14. Adapter Pattern BaseEngine VideoEngine YahooVideo YouTube QuickTime Flv Rhapsody Flash HTML <audio> HTML <video> AudioEngine
- 20. Performance
- 23. Async laziness (D ’ awwwwww!)
- 25. SSJS via YQL
- 27. To the Future!!!
Editor's Notes
- ‘ Sup guise. My name is Dan, and as you can by the liberal use of purple on my slides, I work for Yahoo!, haha. I ’ ll be giving a short presentation called “ How to be a player ... on the internet - the making of Yahoo! ’ s universal JS media player. ” So, let ’ s go.
- First of all, what is Yahoo! Media Player? By a show of hands, has anybody heard of our player (or used it)? Cool. Because this is JSConf, I added a gist of how installation of the player should go...
- Let ’ s do a quick demo now for those unfamiliar with our product, to see what it does for you. > Click link > Scroll down to third play button> Click in-page play button for Ben E. King: Stand by me> Seek to middle> Open 17. Atlas Sound> Find on page This is cool, but what if you want more customized experience? Don ’ t think we ’ ve forgotten about...
- Developers! Our goal is to make our player hackable and as friendly to the developer community as possible.
- The API we expose is an abstraction and common set of functionality we find useful for you to use the player in more advanced ways. We open up control of the playlist, player controls, view settings, engine ... pretty much everything, so feel free to change it ’ s behavior as much as you want. You can also just set a global environment variable that we listen to in order to change various aspects about your player (for instance, if it should automatically start playing or not). Let ’ s show a real quick demo I made to show some custom behavior. > Click link > Explain what we ’ re about to do (search YouTube, using our player to play links in page) This is an example of loading videos from YouTube based on a search parameter (so you ’ re doing it dynamically after the page is loaded -- so you ’ re not using the default parsing mechanism built in the player by default). > Play first entry for keyboard cat (original, preferably with sound, maybe seek?) > Do one more search (spiderman?) with the playlist open to show how we ’ re populating on every search
- We also promote skinning of our player ’ s visual appearance (and a quite a few people do). We attempt to make things easily skinnable with either the replacement of our button sprite with a custom one or the easy use of CSS to do more advanced things (the new version of the player is highly CSS-ified, using CSS gradients, RGBA and hacks, and various ways of making skins easier to change for developers and designers). We also have plans to make a theme chooser in the future, so stay tuned for this.
- Now let ’ s talk a little bit about our goals for this player in general, and what it strives to be.
- Firstly, we want our player to basically be the easiest way to add audio and video to your site. With only 1 script tag we handle pretty much everything for you in an unobtrusive, efficient way. We host the files for you for free on a globally distributed CDN so you can sure it ’ s be fast and reliable. Another goal of ours is to change webpages into playlists, giving your user a richer and more delighting experience (which in turn makes you more money, :D).
- You ’ ve probably heard of the terms localization, internationalization, well we also believe in universalization -- being able to use our player on any page with browser or device using type of media or service. Whether you ’ re a web ninja or not, our player should work seamlessly for you. Any browser, includes IE6 quirksmode and mobile. We try any available browser plugin in a large fallback chain (we ’ ll soon be looking for codec support and possibly a transcoding service as well).
- So, let ’ s talk about how we go about supporting 60 combinations of browser, OS, and document mode. About Opera - technically, we don ’ t offer *as much* browser support (by Yahoo! ’ s Graded Browser Suport guidelines). However, though we ’ re not officially mandated to support it we attempt to do our best of the goodness of our hearts. <3 Opera
- This a rich web application with tons of logic, so we chose to use a pseudo-classical inheritance model and a clear MVC separation. A lot of this is basically engine normalization and taming crazy browser quirks to accomplish the effects we want.
- The engines we support don ’ t work exactly the same (some of them suck). Each engine names their events differently, fire these events at different times (if at all), and have quirks that we ’ ve come to know and love (or hate). This adapter pattern allows us to abstract all nitty gritty details.
- This pattern allows each level of inheritance to abstract the functionality that other classes will need while putting for a standard interface. For instance, each component starts by inheriting from a base engine which basically allows them to publish and subscribe to events with some slight dependency injection in the middle. Then, each media engine inherits from an abstract engine class which requires features like play, pause, stop, or seek (if it ’ s supported). As we get more and more and more specific we allow a divergence from the ultra-generic to slightly more specific (i.e. video probably needs to be showing to be useful while playing, so the video engine overrides the base engine ’ s logic just a little bit here). This pattern works awesomely to allow us to drop in engines relatively quickly as well as tame bugs at any specific level (whether it be for 1 engine or all of them).
- So another cool aspect of our player is that we have a fallback chain of supported plugins and media players that ’ s designed to give you the best experience possible using a number of environmental clues (operating system, browser, possibly bandwidth or device in the future).
- A good example of us taking care of the logic for you are movie trailers. If we currently have “ automatic trailer finding ” built into our player to find a trailer for a movie you ’ ve linked to in a page (for now only with Yahoo! Movie Links, but we ’ ll support additional things in the future). So, if you simply reference a Yahoo! Movie page we ’ ll find the best trailer for the movie by querying Yahoo! Movies ’ API via YQL as well as searching YouTube ’ s gdata API (and using either respective player to play your movie).
- But enough about us, on to you! One of the things I think is really cool about our player is that we go to great lengths to not conflict with your page ’ s scripts, styles, or performance. Let me take you through a couple of examples of how we avoid making your page anything but awesomer, :).
- So, firstly, we namespace all our CSS with a common classname prefix (currently .ymp-, will likely change in next version). This helps avoid style collision, but we don ’ t stop there - to avoid both CSS and JS collision we don ’ t use IDs (in the new player) as they ’ re always global and we don ’ t want to limit ourselves to having to create dynamic IDs on the fly. We also like to reuse as much as possible from trusted codebases like YUI (for us, the YUI Slider widget), so we grab the corresponding CSS and namespace it with ant at build time using <fitlerchains> (glorified search and replace for our needs) as well as YUI ’ s CSS prefix mechanism (very cool). We also employ a contextual CSS reset. This is similar to those resets you ’ ve seen by Eric Meyer, YUI, or HTML5 doctor but only on a small portion of the page (to not mess up your styles and ensure ours are the same cross browser). We also do more than just normalize across all browsers. For the nodes inside our player we apply styles to override the use of globals styles like using only tag selectors (i.e. blink on anchor hover!).
- We are also a little bit paranoid about protecting your JavaScript (after all, we make a living on it, too, :P). We don ’ t want to slow down your page, so we only bring the things we need with us (we seriously have to justify every byte and are crazy about reuse). During typical usage of just 1 <script> tag in your markup, we only embed a small script that decides whether or not to load additional assets and show a minimized version of the player. Dynamically adding a <script> tag also works for those needing to get to DOMReady/load as fast as possible. If the full player is embedded, these assets are cached forever making you pay no price on any site after (even blog to blog, Yahoo! property to Yahoo! property). We don ’ t modify JavaScript natives (like Array, Object, Date, etc.) like some libraries do, we shouldn ’ t conflict with any library (that we know of, not even YUI2 or YUI3 on the same page) and we only introduce 1 global (if it ’ s not already there) - YAHOO.MediaPlayer.
- AHHHHHIGH!
- We minimize how many HTTP connections are required to get our assets to your page. One of the many optimizations we ’ ve done is building our minified CSS into a simple string in JavaScript. When the player is evaluated it creates a stylesheet dynamically and put the minified style string into that stylesheet. We do this from an ant target using YUICompressor and a template at build time. We also use CSS sprites (everybody should know about this) extensively, generally using only 1 or 2 images for all of the UI. We ’ re investigating using data URIs (for those browsers than can handle them) to put both background images and engines inline in our script to minimize these connections even more (though we have to make sure this actually doesn ’ t hurt if some things can be parallelized).
- We query the whole document only once for the top level containers, then make relative DOM queries after that into each subtree. We cache a reference to the internal DOM queries so that we never need to get an element more than once during initialization. Event delegation is useful for things with many or an unknown number of items that need to be handled (i.e. play buttons, playlist items). It also catches or prevents the default for events that we might not want to flow up to the document (i.e. we don ’ t want to send your reader to the top of the page with a play button with href= ” # ” )
- Lazy kitty is lazy.
- Like I mentioned before, we load the player asynchronously in the background after you site is done loading. This helps your page render quickly as it ’ s not waiting to parse our JavaScript. But we do more lazy stuff as well. We defer embedding / downloading video engines until you actually play a video link, as well as lazily retrieve all metadata and fallback availability until you play each item.
- We also use an awesome technology called YQL (Yahoo! Query Language) to do some server-side processing for us and send us back exactly what we need.
- For instance, if we want to normalize empty fields, do some aggregation or manipulation of data, and filter out unnecessary data, we do it with Rhino in a JavaScript <execute> block. This allows us to use almost any data source and transmit only the bare minimum in JSON back to the client (as well as lets us cache this for any TTL we want). Living inside a solely client-side widget doesn ’ t give you much security, so we also utilize YQL ’ s access control to be able to differentiate operations and hide sensitive information. YQL conveniently gives you execute, read, and write keys which can be passed to your calls to differentiate users and security levels.
- So now on to our future plans.
- As you can see from our awesome visual, the next version of our UI will be much sexier. It should be faster, safer for your page, and more modernizd (incorporating the last couple years of front-end advancements). Let ’ s see a quick mock.
- We also have plans to add more engines, media, and device support. HTML5 <audio>/<video> is pretty clearly useful for our purposes, so we hope to be incorporating this soon (and hope the implementations solidify soon as well). This will hopefully give us engines for additional codecs that have native support for free. Another item high on our radar is mobile / tablet support (there aren ’ t too many players for iOS). We hope to support additional audio and video publishers (the landscape of this industry is quite different from when the initial version of this player came out). We are also going to add a social aspect to be connect others with media you especially liked or create relationships or relevance over the content of media you ’ re playing. And there ’ s much much more, so stay tuned.