var ThirdPartyDevs = ThirdPartyDevs || [];
FB.api('/me', {}, function( me ) {
  me.name === 'Alex Sexton'; // true
  me.location = 'Austin, TX';
  me.employer = 'Bazaarvoice';
  me.teams = [
    'modernizr',
    'yepnope',
    'yayquery'
  ];
  ThirdPartyDevs.push( me );
});
          

Um.. ok. It's any piece of code that you include from someone else's servers that adds functionality to your page. Kind of.

It could mean a number of things (and usually depends on perspective):

• Any JS loaded from a different domain than the host domain.
• Any JS not written by the author of the host domain.
• Both of those at the same time?
• Both of those, minus developer libraries? But only sometimes?

• FB Like / FB SDK -- ui/api
• Disqus
• ga.js
• Twitter @anywhere
• Bazaarvoice R&R !!11010
• Ads

• jQuery
• jQuery from the google cdn
• Your site main.js served from Amazon S3

Cross-domain from the perspective of a security-focused person, perhaps, though.

There are two monsters in third-party JavaScript development.

The Same Origin Policy

Other Developers

1. Cross-Domain Communication
2. Getting The Hell Out of the Way

Cross-domain communication can really mean two quite distinct problems

1. Between purely front-end contexts (frames, windows, documents)
2. Between a page and a server (usually during the life of the document)

And each of these categories of xd communication has two categories:

1. Spec'd APIs
2. Massive Hacks

The same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from another origin. -MDN

Bad news for the third parties (good for security)

All but the pathname must match.

Are these just called *slash* *slash*?

://

 "http://taylorswift.com"
"https://taylorswift.com"
          

SOP FAIL

"http://diary.taylorswift.com"
"http://taylorswift.com"
          

SOP FAIL

"http://taylorswift.com:8080"
"http://taylorswift.com"
          

SOP FAIL

"http://taylorswift.com:80"
"http://taylorswift.com"
          

SOP FAIL (WTF INORITE?!)

"http://taylorswift.co.uk"
"http://taylorswift.com"
          

SOP FAIL

"http://taylorswift.com"
"http://taylorswift.com"
          

SOP PASS

"http://tswift.com/love-letter-4-slexaxton"
"http://tswift.com/my-fav-javascript-confs"
          

SOP PASS

• The Same Origin Policy in JS dates all the way back to Netscape Navigator 2.0
• But there was a HUGE (intentional) security hole in the fact that <script> tags were not included in this policy.
• This was both a security hole in browsers, and imo, the thing that made the web successful.
• This means that you can load executable code from any domain into the exact same context as the first party code.

1. The Spec'd apis: CORS and postMessage
2. How to use a shim: I like easyXDM

1. Breaking The Cross Domain Barrier
2. Also, the Disqus guys, Ben and Anton, are putting out a book! Third Party JavaScript

// Call it
NS.jsonp(
  'http://server.com/data.dart',
  function ( data ) {
    console.log( data.MY_DATA_YAY );
  }
);
          

• You can hide iframes and set the target of forms to them
• You can use this technique to support a POST capable json transport
• Ben Vinegar expanded on this technique a bit and called it JSONPI

iFrames are awesome. - Me, just now.

// On sub.domain.com
document.domain = "domain.com";
            

• BOTH have to set document domain -- that way all tlds aren't subject.
• Must be less specific (sub.domain.com -> domain.com)
• Can only be set once
• IE6 kind of freaks out randomly :/

• You can pass messages across fragment identifiers in the 'src' of nested iframes.
• 2006 era James Burke (re: requirejs/dojo fame)
• This technique should not be your first choice, but it's a really cool hack.
• Twitter and Facebook use this hack quite a bit.

Use easyXDM

• Everything should be non-blocking.
• Meebo gains a few things by injecting an iframe on the host domain, forcing it to say that it's done loading, using it's built-ins, and then shipping information and parts back over to the dark side. (sub 10ms affect)
• Minimally asynchronous inclusion of your script.

Whatever you tell someone to put on their page, you have to support forever.

• Give them as little as possible to integrate with.
• async snippet that does the injection of extra markup, handles the initialization/customization in the initial request, and injects the correct styles.
• Caching is a double edged sword, better performance/lower cost, but updates are hard to roll out

Do a quick double hop, if your code is suited for this.

• Normally you have a control file that kicks everything off. Keep that small and light and cached for shorter amounts of time (1-7days?)
• Then use a cachebusting/version system in your files.
• Cache all these files forever. They will only rerequest on updates.

The ulimate 'get-out-of-the-way-test' is to see if you can implement your widget twice on the same page.

Crazy people may be interested in sandboxed natives. see @jdalton (and his Fusebox) for info on this.

Using a library for large 3rd party apps can be a good idea, but hard to guarantee no collisions.

• You wanna serve jQuery async from google cdn?
• Then you just call noConflict() on it?
• Death from above.

In IE8 and lower, there is not an atomic callback for script loads.

• Include jQuery along with the noconflict in the body (bad for cdns)
• Use @jaubourgs crazy onclick script trick

<script
  id="scriptId"
  for="scriptId"
  event="onclick"
  src="script.js">
</script>

          

scriptTag.event = "onclick";
scriptTag.id = scriptTag.htmlFor = generateNewId();

scriptTag.onreadystatechange = function() {
  if ( /loaded|complete/.test( scriptTag.readyState ) ) {
    try {
      scriptTag.onclick();
    } catch( e ) {}
    requestCallback();
  }
};
          

• Alex Sexton
• AlexSexton [at] gmail.com
• alexsexton.com
• @SlexAxton