LightningJS: safe, fast, and asynchronous third-party Javascript
1–10 of 11 posts
Re: LightningJS: safe, fast, and asynchronous third-party Javascript
#2The funny thing is that this shows that Google Analytics's async loader can actually slows down window.onload in some cases.
Re: LightningJS: safe, fast, and asynchronous third-party Javascript
#3For a somewhat-related blast from the past, see Crockford's ADsafe:
Re: LightningJS: safe, fast, and asynchronous third-party Javascript
#4For a somewhat-related blast from the past, see Crockford's ADsafe: http://www.adsafe.org/
That looks pretty interesting. I love the concept, I guess it just didn't really get the buy in that it needed.
Matt's loader is less focused on making javascript safe to embed from the security standpoint, and is more focused on ensuring that a 3rd part javascript file does not slow down your page.
Re: LightningJS: safe, fast, and asynchronous third-party Javascript
#5For a somewhat-related blast from the past, see Crockford's ADsafe: http://www.adsafe.org/
Haha, yea I remember that post. Good stuff. LightningJS is really more focused on being "safe" as in "no library conflicts", rather than sandboxing the code itself. In general, end users are copy/pasting embed code directly, so there wouldn't really be a guarantee that the third-party wrapped their resulting code in ADSafe :)
Definitely would be interesting to perhaps include some concepts from ADSafe into LightningJS though - maybe in the bootstrap component?
Re: LightningJS: safe, fast, and asynchronous third-party Javascript
#6Did you guys look at caja? http://code.google.com/p/google-caja/
Re: LightningJS: safe, fast, and asynchronous third-party Javascript
#7Did you guys look at caja? http://code.google.com/p/google-caja/
I did just now :) The concepts in Caja are really interesting, but probably outside the scope of LightningJS. We used the term "safe" as in "safe from library conflicts", though I can see how that might have unintentionally indicated that it provides a managed sandbox as well.
That said, some kind of Caja integration could be a pretty nice addition to LightningJS.
Re: LightningJS: safe, fast, and asynchronous third-party Javascript
#8I see you're creating an iframe and then loading the javascript script tag into the it. I assume this is how you are providing encapsulation of a unique window object per script. However, what about scripts that depend on access to the real window object?
Re: LightningJS: safe, fast, and asynchronous third-party Javascript
#9I see you're creating an iframe and then loading the javascript script tag into the it. I assume this is how you are providing encapsulation of a unique window object per script. However, what about scripts that depend on access to the real window object?
Good question. Since LightningJS writes the iframe with a "javascript:" URL, that iframe is really part of the same domain (and therefore same security context). To access the window on the original document, just use the "window.parent" object.
Re: LightningJS: safe, fast, and asynchronous third-party Javascript
#10From the comments:
"The short answer is that the third-party provider must make small modifications to take advantage of LightningJS. This is done by adding the bootstrap Javascript and ensuring that the code uses window.parent for manipulation of the original document."
That's kinda a big asterisks to add. That said, deferring JS safely is really hard. It's not a bad thing for more people to be working on.