Hacker News new | past | comments | ask | show | jobs | submit login
LightningJS: safe, fast, and asynchronous third-party Javascript (olark.com)
151 points by bcx on Oct 25, 2011 | hide | past | favorite | 10 comments



From 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.


I agree. LightningJS was originally written for third-party Javascript providers to improve their own embed code, though I think it would be awesome if end-users could easily take matters into their own hands. Maybe something for future development...


I 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.


Did 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.


The funny thing is that this shows that Google Analytics's async loader can actually slows down window.onload in some cases.


For 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?


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: