Join the DZone community and get the full member experience.Join For Free
Bugsnag monitors application stability, so you can make data-driven decisions on whether you should be building new features, or fixing bugs. Learn more.
- 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.
Exhaustive browser support is really important for LightningJS. To that end, this loading approach has been battle-tested in production by both Meebo and Olark across thousands of websites and browsers. The included tests have been verified to pass in every browser the developers could get their hands on:
- Firefox 2+ (tested in 2.0, 3.0, 3.6, 4.0, 5.0, 6.0, 7.0)
- Chrome 12+ (tested in 12, 13, 14, 15)
- Internet Explorer 6+ (tested in 6, 7, 8, 9)
- Safari 4+ (tested in 4.0, 5.0, 5.1)
- Opera 10+ (tested in 10, 11.5)
- Mobile Safari 5+ (tested in 5.0, 5.1)
Demo: http:/ / lightningjs. com/
License: MIT License
Published at DZone with permission of Hirvesh Munogee , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.