A JS loader that has the capability to load other javascript and their transitive closures shouldn't reinvent the wheel, or use a loader that is only specific to opensocial or a vendor's extension of opensocial, but rather use commonjs's require or ECMAScript's 'Simple Modules' which includes the concept of a dynamic loader. 'Require' can load js and dependencies on both the server and client side. 'Require' has significant buy-in from the community on both server and client side js engines. The best argument to forgo other types of loaders is they will eventually be replaced by those mentioned above. 'Simple Modules' will likely be adopted within the javascript language formally and become part of JS 'Harmony'.
thanks kam On Jun 21, 2010, at 5:10 PM, John Hjelmstad wrote: > Actually, this is for use of JS outside the context of a direct gadget load. > The canonical example are containers using gadgets.rpc, though this > technique will likely be used by other containers and container-like pages > on an ongoing basis. > > It's somewhat akin to the Google AJAX APIs, eg: > http://www.google.com/uds/?file=ads&v=1&packages=searchiframe; a "JS loader" > for Shindig-supplied JS if you will. > > With it, statically or dynamically a page can do: > <script src=" > http://www.shindigserver.com/gadgets/js/lib1:lib2:lib3.js&jsload=1[&refresh=...] > "></script> > > ...and will get a tiny piece of JS that in turn loads a much larger cached > JS. > > The extension of this will allow dynamically-generated pages to > incrementally add JS support. > > Use case where gadget container loads gadget X, which requires > container-side JS A, B, and C. It does: <script src=" > http://www.shindigserver.com/gadgets/js/A:B:C.js&?jsload=1";> > > Later, gadget Y is installed, which (per metadata service) requires features > B and E, where E depends on A. A wrapper script (also in a later follow-up) > adds: > <script src=" > http://www.shindigserver.com/gadgets/js/B:E.js?jsload=1&alreadyhas=A:B:C";> > > With this, JsServlet just omits A:B:C's JS from the output and spits out the > rest. > > So goes the idea anyway. This is the first step, and IMO reasonably useful > on its own. > > --j > > On Mon, Jun 21, 2010 at 4:23 PM, <[email protected]> wrote: > >> interesting.. I wonder if it would be better to inject the script node >> into the head instead of using document.write? This would then result >> in async/deferred js loading which may help page load performance. >> >> >> http://codereview.appspot.com/1687043/show >>
