On-Demand Javascript?

[Rey Bango-2]

I was reading this article on Ajaxian:

http://ajaxian.com/archives/prototype-extension-dynamic-script-pattern-support

which discusses Dynamic Script Pattern or On-Demand Javascript. I think
this is a VERY cool feature. Does Jquery support something like this?

What are the pros and cons of something like this?

Rey...

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Dan Atkinson]

Lazy loading is indeed a great feature to have in any framework and I'd be interested in any information on this.

Rey Bango-2 wrote:

I was reading this article on Ajaxian:

http://ajaxian.com/archives/prototype-extension-dynamic-script-pattern-support

which discusses Dynamic Script Pattern or On-Demand Javascript. I think
this is a VERY cool feature. Does Jquery support something like this?

What are the pros and cons of something like this?

Rey...

_______________________________________________
jQuery mailing list
[e-mail]
http://jquery.com/discuss/

[Christof Donat]

Hi,

> which discusses Dynamic Script Pattern or On-Demand Javascript. I think
> this is a VERY cool feature. Does Jquery support something like this?

I wouldn't put it into jQuery itsself, because then you would need to load
jQuery before you can use the dynamic Script loading. I have developed
something like this which you can se at http://jspax.cdonat.de . I am using
it to load jQuery, jQuery Plugins and some other of my code.

> What are the pros and cons of something like this?

Pros:
- don't need to load everything at startup of your page - faster startup
- don't need to load all the code you don't need on the page:
$('#myElement').click(function() {
        $using('jquery.fx',function() {
                $(this).slideUp('slow');
        });
});
The fx-Plugin is loaded after the first click on the Element and as soon as it
is available the slideUp is executed.
- you can easier modularize your code
- the dynamic script loader can handle dependencies:
$using('com.example.test',function() {...});
Now com/example/test.js could contain
$using('com.example.test2',function() {
        ...;
        $package('com.example.test',{});
});
the dependency is automatically resolved.

Cons:
- you can not be shure that your code was loaded and executed as usual while
the page was loading - document.write() e.g. may behave differently.
- either you need to do synchronous loading like JSON does or you need to work
with callbacks as I do. Synchronous loading blocks the browser, callbacks are
not understood by everyone.
- to load all the scripts your page needs multiple HTTP-Requests are necessary
which increases the overhead.

I hope that helps.

Christof

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Rey Bango-2]

Awesome Christoff. Thanks for the help!

Rey

Christof Donat wrote:

> Hi,
>
>
>>which discusses Dynamic Script Pattern or On-Demand Javascript. I think
>>this is a VERY cool feature. Does Jquery support something like this?
>
>
> I wouldn't put it into jQuery itsself, because then you would need to load
> jQuery before you can use the dynamic Script loading. I have developed
> something like this which you can se at http://jspax.cdonat.de . I am using
> it to load jQuery, jQuery Plugins and some other of my code.
>
>
>>What are the pros and cons of something like this?
>
>
> Pros:
> - don't need to load everything at startup of your page - faster startup
> - don't need to load all the code you don't need on the page:
> $('#myElement').click(function() {
> $using('jquery.fx',function() {
> $(this).slideUp('slow');
> });
> });
> The fx-Plugin is loaded after the first click on the Element and as soon as it
> is available the slideUp is executed.
> - you can easier modularize your code
> - the dynamic script loader can handle dependencies:
> $using('com.example.test',function() {...});
> Now com/example/test.js could contain
> $using('com.example.test2',function() {
> ...;
> $package('com.example.test',{});
> });
> the dependency is automatically resolved.
>
> Cons:
> - you can not be shure that your code was loaded and executed as usual while
> the page was loading - document.write() e.g. may behave differently.
> - either you need to do synchronous loading like JSON does or you need to work
> with callbacks as I do. Synchronous loading blocks the browser, callbacks are
> not understood by everyone.
> - to load all the scripts your page needs multiple HTTP-Requests are necessary
> which increases the overhead.
>
> I hope that helps.
>
> Christof
>
> _______________________________________________
> jQuery mailing list
> discuss@...
> http://jquery.com/discuss/
>

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Dan Atkinson]

Christof,

While I agree with your cons in theory, a couple of them can be discounted.

Christof Donat wrote:

- either you need to do synchronous loading like JSON does or you need to work
with callbacks as I do. Synchronous loading blocks the browser, callbacks are
not understood by everyone.

You mention that not everyone understands callbacks (maybe I read it wrongly). Well, it would also be true that not everyone understands JavaScript, and an even smaller number understand jQuery (however easy it may be, the missus just doesn't see the magic that I do).

Christof Donat wrote:

- to load all the scripts your page needs multiple HTTP-Requests are necessary
which increases the overhead.

While multiple HTTP-Requests do increase overall overhead, that is based on the assumption that the total sum of code loaded is the same as a normal page load (ie, the user loads all or nearly all the modules through their page interaction). I'll actually give this a bye though, because I'm not fully au fait with the performance statistics of multiple on-request HTTP requests, versus single all-in-one HTTP Requests.

It'd be great if there was some further discussion on this though.

For anyone looking for a quick resource on lazy loading/on demand JS:
http://ajaxpatterns.org/On-Demand_Javascript

Cheers,

Dan

[Rey Bango-2]

So from the docs, this looks like its library agnostic correct (ie: not
dependent on JQuery)?

Rey...

Christof Donat wrote:

> Hi,
>
>
>>which discusses Dynamic Script Pattern or On-Demand Javascript. I think
>>this is a VERY cool feature. Does Jquery support something like this?
>
>
> I wouldn't put it into jQuery itsself, because then you would need to load
> jQuery before you can use the dynamic Script loading. I have developed
> something like this which you can se at http://jspax.cdonat.de . I am using
> it to load jQuery, jQuery Plugins and some other of my code.
>
>
>>What are the pros and cons of something like this?
>
>
> Pros:
> - don't need to load everything at startup of your page - faster startup
> - don't need to load all the code you don't need on the page:
> $('#myElement').click(function() {
> $using('jquery.fx',function() {
> $(this).slideUp('slow');
> });
> });
> The fx-Plugin is loaded after the first click on the Element and as soon as it
> is available the slideUp is executed.
> - you can easier modularize your code
> - the dynamic script loader can handle dependencies:
> $using('com.example.test',function() {...});
> Now com/example/test.js could contain
> $using('com.example.test2',function() {
> ...;
> $package('com.example.test',{});
> });
> the dependency is automatically resolved.
>
> Cons:
> - you can not be shure that your code was loaded and executed as usual while
> the page was loading - document.write() e.g. may behave differently.
> - either you need to do synchronous loading like JSON does or you need to work
> with callbacks as I do. Synchronous loading blocks the browser, callbacks are
> not understood by everyone.
> - to load all the scripts your page needs multiple HTTP-Requests are necessary
> which increases the overhead.
>
> I hope that helps.
>
> Christof
>
> _______________________________________________
> jQuery mailing list
> discuss@...
> http://jquery.com/discuss/
>

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Christof Donat]

Hi,

> So from the docs, this looks like its library agnostic correct (ie: not
> dependent on JQuery)?

Yes, that is tue. I use it to load jQuery. You need to modify the libraries
you load so that they generate the package-Object. Otherwise the
callback-Function will never be called.

Christof

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Christof Donat]

Hi,

> Christof Donat wrote:
> > - either you need to do synchronous loading like JSON does or you need to
> > work
> > with callbacks as I do. Synchronous loading blocks the browser, callbacks
> > are
> > not understood by everyone.
>
> You mention that not everyone understands callbacks (maybe I read it
> wrongly). Well, it would also be true that not everyone understands
> JavaScript, and an even smaller number understand jQuery (however easy it
> may be, the missus just doesn't see the magic that I do).

I just thought of the recurring questions why te following won't work in
jQuery:

$('#myNiceElement').load('http://www.example.com/');
$('#thisElementWillBeCreatedByLoad').css({backgroundColor:'red'});

> Christof Donat wrote:
> > - to load all the scripts your page needs multiple HTTP-Requests are
> > necessary
> > which increases the overhead.
>
> While multiple HTTP-Requests do increase overall overhead, that is based on
> the assumption that the total sum of code loaded is the same as a normal
> page load (ie, the user loads all or nearly all the modules through their
> page interaction). I'll actually give this a bye though, because I'm not
> fully au fait with the performance statistics of multiple on-request HTTP
> requests, versus single all-in-one HTTP Requests.

I totaly agree with you that this is only a problem in case you would load all
the code anyway. As I wrote I use dynamic loading myself, because in my
projects the cons are really weak. In other projects this might be an issue.

Christof

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Stephen Howard]

Christof Donat wrote:
>
> Cons:
> - either you need to do synchronous loading like JSON does or you need to work
> with callbacks as I do. Synchronous loading blocks the browser, callbacks are
> not understood by everyone.
>
>  
I believe Christof is referring here to JSAN (openjsan.org) not JSON
(data format) when he is referring to the synchronous loading


I'd like to throw in my voice in support of Christof's call for keeping
things like this out of jQuery proper.  To me 'doing different things
should look different'.  When i see raw ajax calls and such hanging off
$ that looks wrong, as I think of $ signifying that I'm selecting and
manipulating the DOM.  If I'm doing something that doesn't have to do
with DOM selection, I shouldn't see the $ in my code, because that's
what I associate it with, and anything else interrupts the visual
texture of my code.

-Stephen

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Christof Donat]

Hi,

> > Cons:
> > - either you need to do synchronous loading like JSON does or you need to
> > work with callbacks as I do. Synchronous loading blocks the browser,
> > callbacks are not understood by everyone.
>
> I believe Christof is referring here to JSAN (openjsan.org) not JSON
> (data format) when he is referring to the synchronous loading

Yes, sorry. I was typing to fast :-)

Christof

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Dan Atkinson]

Christof,

Thanks for the clarification.

Dan

Christof Donat wrote:

Hi,

> Christof Donat wrote:
> > - either you need to do synchronous loading like JSON does or you need to
> > work
> > with callbacks as I do. Synchronous loading blocks the browser, callbacks
> > are
> > not understood by everyone.
>
> You mention that not everyone understands callbacks (maybe I read it
> wrongly). Well, it would also be true that not everyone understands
> JavaScript, and an even smaller number understand jQuery (however easy it
> may be, the missus just doesn't see the magic that I do).

I just thought of the recurring questions why te following won't work in
jQuery:

$('#myNiceElement').load('http://www.example.com/');
$('#thisElementWillBeCreatedByLoad').css({backgroundColor:'red'});

> Christof Donat wrote:
> > - to load all the scripts your page needs multiple HTTP-Requests are
> > necessary
> > which increases the overhead.
>
> While multiple HTTP-Requests do increase overall overhead, that is based on
> the assumption that the total sum of code loaded is the same as a normal
> page load (ie, the user loads all or nearly all the modules through their
> page interaction). I'll actually give this a bye though, because I'm not
> fully au fait with the performance statistics of multiple on-request HTTP
> requests, versus single all-in-one HTTP Requests.

I totaly agree with you that this is only a problem in case you would load all
the code anyway. As I wrote I use dynamic loading myself, because in my
projects the cons are really weak. In other projects this might be an issue.

Christof

_______________________________________________
jQuery mailing list
[e-mail]
http://jquery.com/discuss/

[Rey Bango-2]

Christof,

Can you show how you modified the JQuery library to generate the
package-object? Code?

Rey...

Christof Donat wrote:

> Hi,
>
>
>>So from the docs, this looks like its library agnostic correct (ie: not
>>dependent on JQuery)?
>
>
> Yes, that is tue. I use it to load jQuery. You need to modify the libraries
> you load so that they generate the package-Object. Otherwise the
> callback-Function will never be called.
>
> Christof
>
> _______________________________________________
> jQuery mailing list
> discuss@...
> http://jquery.com/discuss/
>

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Dan Atkinson]

I'd be -for- having something like this inside jQuery.

For all the other non-element additions that there in jQuery, something like this would be a great feature to have.

As much as code purity is a good thing, there comes a point when you say 'well, this might just make things better...'.

Stephen Howard wrote:

Christof Donat wrote:
>
> Cons:
> - either you need to do synchronous loading like JSON does or you need to work
> with callbacks as I do. Synchronous loading blocks the browser, callbacks are
> not understood by everyone.
>
>  
I believe Christof is referring here to JSAN (openjsan.org) not JSON
(data format) when he is referring to the synchronous loading


I'd like to throw in my voice in support of Christof's call for keeping
things like this out of jQuery proper.  To me 'doing different things
should look different'.  When i see raw ajax calls and such hanging off
$ that looks wrong, as I think of $ signifying that I'm selecting and
manipulating the DOM.  If I'm doing something that doesn't have to do
with DOM selection, I shouldn't see the $ in my code, because that's
what I associate it with, and anything else interrupts the visual
texture of my code.

-Stephen

_______________________________________________
jQuery mailing list
[e-mail]
http://jquery.com/discuss/

[Franck Marcia]

2006/9/5, Dan Atkinson <dandementia@...>:
>
> I'd be -for- having something like this inside jQuery.

There's an undocumented function in the core of the current SVN
version which imo already implements it:

$.getScript(url, data, callback)

Of course, you can't use it to load jQuery.

Franck.

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Christof Donat]

Hi,

> Can you show how you modified the JQuery library to generate the
> package-object? Code?

In case of jQuery I simply appended:

$package('jquery',{});

The plugins are wrapped with:

$using('jquery',function() {
        ...
        $package('jquery.myplugin',{});
});

You can also define multiple dependencies like this:

$using(['jquery.fx','jquery.dom'],function{
        ... // here we use the two plugins.
});

For code that needs these two plugins loaded. Since they are wrapped with
$using() like I have written above this will load jQuery as well.

Christof

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Stephen Howard]

Well, as I've put it down below, this isn't really an issue of code
purity (although I'm sure that bugs me too).  What I was trying to say
was that it is an issue of readability.  At least to me, seeing $ in my
javascript code indicates DOM manipulation.  So my preference is to make
anything not pertaining to DOM manipulation not look like jQuery.  I
certainly wouldn't have any issues if John or the jQ community wanted to
write/sponsor/host solutions that didn't fall under the jQ mandate, but
what harm is there in putting them into their own namespace?  I'd argue
that it would only add clarity to the situation.  jQuery remains
coherent and quantifiable, rather than an ever expanding kitchen sink,
and we get peer libraries that the community knows will play well with
the beloved jQ.  Remember the old Unix saw about doing one thing and
doing it well (aside from Emacs, of course).  I think it ought to
pertain here as well.

-Stephen


Dan Atkinson wrote:

> I'd be -for- having something like this inside jQuery.
>
> For all the other non-element additions that there in jQuery, something like
> this would be a great feature to have.
>
> As much as code purity is a good thing, there comes a point when you say
> 'well, this might just make things better...'.
>
>
> Stephen Howard wrote:
>  
>>
>> Christof Donat wrote:
>>    
>>> Cons:
>>> - either you need to do synchronous loading like JSON does or you need to
>>> work
>>> with callbacks as I do. Synchronous loading blocks the browser, callbacks
>>> are
>>> not understood by everyone.
>>>
>>>  
>>>      
>> I believe Christof is referring here to JSAN (openjsan.org) not JSON
>> (data format) when he is referring to the synchronous loading
>>
>>
>> I'd like to throw in my voice in support of Christof's call for keeping
>> things like this out of jQuery proper.  To me 'doing different things
>> should look different'.  When i see raw ajax calls and such hanging off
>> $ that looks wrong, as I think of $ signifying that I'm selecting and
>> manipulating the DOM.  If I'm doing something that doesn't have to do
>> with DOM selection, I shouldn't see the $ in my code, because that's
>> what I associate it with, and anything else interrupts the visual
>> texture of my code.
>>
>> -Stephen
>>
>> _______________________________________________
>> jQuery mailing list
>> discuss@...
>> http://jquery.com/discuss/
>>
>>
>>    
>
>  

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Jörn Zaefferer]

Stephen Howard wrote:
> jQuery remains coherent and quantifiable, rather than an ever expanding kitchen sink,
> and we get peer libraries that the community knows will play well with
> the beloved jQ.  Remember the old Unix saw about doing one thing and
> doing it well (aside from Emacs, of course).  I think it ought to
> pertain here as well.
>  
You make a good point. Its similar to the idea of integrating a class
creating facility in jQuery that came up a few days ago. Should this be
seperated from jQuery as it has nothing to do with DOM manipulation? I'm
not so sure, because most aspects of the class creation facility are
already available in the jQuery code. This is also true for OnDemand-JS,
as all the AJAX stuff is already covered. I'd like to see jQuery
concentrate on its strength, but on the other hand, I don't like
duplicating code.

jQuery itself claims to change the way you write javascript. With
helpers like $.each, $.map and $.trim it does just this, without
touching DOM, FX or AJAX at all.

I therefore vote to integrate an On-Demand Javascript facility into jQuery.

-- Jörn

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Stephen Howard]

Well, that is one conclusion you could reach.  The other is that perhaps
jQuery needs a couple of components extracted and turned into external
libraries that it then depends on (ajax, etc).  A bit blasphemous, I
know, considering jQuery is supposed to be easy to download as a
standalone, but there's no reason the libraries + jQuery couldn't be
stitched together into a 'standalone' package for download on the jQ
server.  This would also open up the well-vetted sub-systems of the jQ
universe to other developers without requiring all of jQuery.  For
example, Christof's scriptloader could use jQ's ajax code, or could
merge with it.  The mandate of the ajax library would certainly include
the sorts of things that he and JSAN have in mind.

-Stephen

Jörn Zaefferer wrote:

> Stephen Howard wrote:
>  
>> jQuery remains coherent and quantifiable, rather than an ever expanding kitchen sink,
>> and we get peer libraries that the community knows will play well with
>> the beloved jQ.  Remember the old Unix saw about doing one thing and
>> doing it well (aside from Emacs, of course).  I think it ought to
>> pertain here as well.
>>  
>>    
> You make a good point. Its similar to the idea of integrating a class
> creating facility in jQuery that came up a few days ago. Should this be
> seperated from jQuery as it has nothing to do with DOM manipulation? I'm
> not so sure, because most aspects of the class creation facility are
> already available in the jQuery code. This is also true for OnDemand-JS,
> as all the AJAX stuff is already covered. I'd like to see jQuery
> concentrate on its strength, but on the other hand, I don't like
> duplicating code.
>
> jQuery itself claims to change the way you write javascript. With
> helpers like $.each, $.map and $.trim it does just this, without
> touching DOM, FX or AJAX at all.
>
> I therefore vote to integrate an On-Demand Javascript facility into jQuery.
>
> -- Jörn
>
> _______________________________________________
> jQuery mailing list
> discuss@...
> http://jquery.com/discuss/
>  

_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/

[Christof Donat]

Hi,

> For example, Christof's scriptloader could use jQ's ajax code, or could
> merge with it.

That is something that won't happen. I whanted it to be as small as possible.
I felt that the JSAN core had to many functions that are not necessary for
the basic functionalitiy of resolving dependencies and loading scripts
dynamically. If I had to load jQuery and the ajax-plugin before I'd be better
off to user JSAN.

As I said I use it to load jQuery and the plugins as well and sometimes I load
them delayed like e.g. in an event Handler.

Christof



_______________________________________________
jQuery mailing list
discuss@...
http://jquery.com/discuss/