I’m happy to announce that we’ve open sourced the Meebo Bar embed code! It is the result of more than two years of iteration and careful consideration for the best way to embed a third party webapp on your website. I’ll get into the technical details below, but first let’s take a quick trip down memory lane and see how the embed code got to where it is today :)
The first commit to the Meebo Bar codebase was made by Paul S. on the 4th of June, 2008. Historic weather reports say that it was a beautiful Wednesday in Mountain View CA, with the sun shining and temperatures in the low 70s. Eleven days later, on June 25th, Martin H. made his first commit to the Meebo Bar – he would go on to be the key engineer for the first 7 versions of the bar. As the Meebo Bar gained traction, more and more of our developers started working on the bar codebase.
Today, roughly two and a half years later, the Meebo Bar sits on thousands of websites and reaches roughly a third of the US population every month. There are many reasons for the bar’s success (the greatest reason is the Meebo team, which you can be a part of too!), but today I want to highlight the embed code.
The solution that addressed all of these issues was to create an iframe and then load all of the Meebo code into it. It sounds simple, but there are evil edge cases and arcane tricks that you need to discover in order to make a truly non-blocking third party webapp embed code. We are happy to share our discoveries, and hope you will find it useful!
The major shortcoming of this first approach was that the hosting site had to put up a custom html file on their servers. Not only was it a technical and error-prone hassle that would slow down launching the bar on new sites, but some sites did not have the capability to put up a custom html file. Obviously, something had to be done!
With a working solution in hand the solution can often seem obvious. However, I have a genuine appreciation for the two and a half years of discovery that lead us to the current version of the embed code. I’ll let you read the commented source of the embed code by yourself below, and simply leave off with a list of features of the embed code that I find particularly awesome:
Line 46: Create the Meebo function, which is the page’s asynchronous API for Meebo functionality. It can be used right away, even before the Meebo Bar code has finished loading. When the Meebo bar code has finished loading, it grabs all the argument objects already pushed onto the Meebo._ array and executes those API calls – after that the code reassigns Meebo._.push to a function that immediately executes the API call. It works brilliantly!
Line 69: We want to know how the embed code behaves in the real world, so we track the time it takes to execute the embed code and then load the Meebo bar code. This way we can ensure that the bar doesn’t slow down as we add new features and keep innovating.
Line 83: Every byte counts! Since the embed code will be included inline on every webpage of your site, we do everything we can to make it tiny. By creating named variables for all the common DOM operations, the closure compiler can compress them all into single-letter variables.
Line 159: This function creates the HTML that will be injected into the iframe. The generated HTML does two things: 1) creates an onload function for the contentWindow of the iframe, and 2) inside of the onload function, creates a script tag that points to a meebo server and appends that script tag to the head of the contentWindow of the iframe.
Line 188: A webpage’s onload event will fire only after the onload of all its children iframes fire. When we’ve injected the HTML that will load the Meebo Bar JS into the iframe, we call document.close on the iframe contentWindow – this is what causes the iframe’s onload event to fire. Now, with the iframe’s onload event fired, we’re free to load the Meebo Bar JS into the iframe without blocking the onload event or holding up the loading of assets of the parent page.