You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by li...@inuus.com on 2010/06/22 01:23:58 UTC
Re: Support JS loader script in JsServlet; tweaks to JsUriManager et
al. (issue1687043)
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
Re: Support JS loader script in JsServlet; tweaks to JsUriManager
et al. (issue1687043)
Posted by Kam Kasravi <kk...@yahoo-inc.com>.
Hi John
I would look at two implementations of 'require'.
RequireJS and Nodules both have support for client and server side dependency management.
http://requirejs.org/
http://github.com/kriszyp/nodules
There are others, most can be found on github by searching for commonjs or javascript modules.
Kris Zyp may be worth pinging about opensocial requirements for a module loader and what types of
existing implementations best meet the requirements. I could post to the relevant discussion groups if
there is a condensed set of requirements for loading js and/or other types of resources required by a gadget.
Now is the time to influence the ecmascript body and commonjs committers.
thanks
kam
On Jun 21, 2010, at 7:27 PM, John Hjelmstad wrote:
> 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 <kk...@yahoo-inc.com> 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, <li...@inuus.com> 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
>>>>
>>
>>
Re: Support JS loader script in JsServlet; tweaks to JsUriManager et
al. (issue1687043)
Posted by John Hjelmstad <fa...@google.com>.
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 <kk...@yahoo-inc.com> 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, <li...@inuus.com> 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
> >>
>
>
Re: Support JS loader script in JsServlet; tweaks to JsUriManager
et al. (issue1687043)
Posted by Kam Kasravi <kk...@yahoo-inc.com>.
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, <li...@inuus.com> 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
>>
Re: Support JS loader script in JsServlet; tweaks to JsUriManager et
al. (issue1687043)
Posted by John Hjelmstad <jo...@gmail.com>.
D'oh. Just re-read your comment, and realized I responded to something
different. Consider my response simply excess documentation ;)
Injecting into <head> rather than document.write might indeed be a
possibility.. the API already supports the callback param so ordering could
be maintained as well. I like it. Will implement.
Thanks!
John
On Mon, Jun 21, 2010 at 5:10 PM, John Hjelmstad <fa...@google.com> 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=...]<http://www.shindigserver.com/gadgets/js/lib1:lib2:lib3.js&jsload=1%5B&refresh=...%5D>
> "></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, <li...@inuus.com> 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
>>
>
>
Re: Support JS loader script in JsServlet; tweaks to JsUriManager et
al. (issue1687043)
Posted by John Hjelmstad <fa...@google.com>.
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, <li...@inuus.com> 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
>