Hi Kam: Thanks for the input - I agree wholeheartedly w/ you that we should support standards to the maximum extent possible. This being said, "eventually be replaced" isn't equivalent to "available today," which is quite often a requirement.
CommonJS seems closest to a compromise at the moment. I'd be happy to facilitate the use of its syntax. SM seems better but requires browser support. What are your thoughts on what we might do now to fill the need during transition? --j On Mon, Jun 21, 2010 at 7:12 PM, Kam Kasravi <[email protected]> wrote: > 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 > >> > >
