Globals, prototypes and mismatched library versions can cause lots of compatibility headaches for third-party code.
With LightningJS, all of that third-party code lives in its own separate window context. If the code needs to do DOM manipulation, it still has access to the original document via window.parent.
Fast: Avoids blocking window.onload and document.ready
Slowdowns in embedded third-party code should never impact the original document. Traditional embed techniques can block window.onload if the server responds slowly, even when the embed itself is asynchronous.
With LightningJS, third-party server response time has zero impact on the original document. It should even be safe to embed the code at the top of the body of the document for an added speed boost :)
Asynchronous: Defers API calls with a simple interface
When customers are using your third-party API, asynchronicity can make usage a bit more complicated. Some libraries require manual creation of a callstack (e.g. Google Analytics var _gaq=; _gaq.push(...)), and others try to hook into script.onload events.
With LightningJS, the third-party namespace is immediately available as a callable function. All calls return objects that adhere to the CommonJS Promise API. Just a few modifications to the existing API will enable these deferred calls.