Determine if script is loaded

[pman]

I'm trying to add/load a javascript on the document dynamically. This part is okay, but I need to know if the script has been loaded completely or not so that from a 2nd script I can call functions that are on the first script(loading dynamically).

What I have found so far by googling about it, looks like there's no way of doing it. I thought I would ask here in case I missed it. Without modifying the first script, which will be loaded dynamically, is there any way of finding if the script has been completely loaded or not? Does DOM have any properties for this?

Let me know if you have any suggestions. I hope I explained it properly, if not, let me know and I'll try to elaborate it. Thanks

[jscheuer1]

If the first script has any functions and/or variables in it that you are depending upon, just check to see if they are what they need to be before using them.

Say the script has a function:


function reallyImporatant(){
return 'magic things';
}

Before trying to use it, you could always test:


if(typeof reallyImporatant=='function')

[pman]

Thanks so much for your reply jscheuer1. I'll try your suggestions, but I think I'm gonna have to use a for loop or a while loop when checking if it's a function. That might be another problem. From previous experience, I think this will put the browser into an infinite loop and then crash. Anyways, I'll try it out.


Say the script has a function:

Code:

function reallyImporatant(){
return 'magic things';
}

Before trying to use it, you could always test:

Code:

if(typeof reallyImporatant=='function')



Now, let's say the function reallyImportant() is calling another function in the same script like this:

Code:

function reallyImporatant(){
var val = getValue() ;
}

If the script didn't load completely but
if(typeof reallyImporatant=='function') returns true and I call the function reallyImportant(), it's probably not going to work all the time. Again, I don't know if I was able to explain the problem properly.

[Twey]

Have the script call a callback when it's loaded?

[pman]

Have the script call a callback when it's loaded?

Thanks Twey, But that would require me to modify the script. Also, how would I know when it's loaded? Correct me if I misunderstood your post.

[jscheuer1]

Scripts generally load only one way, or consistently for certain browsers according to what methods they support and how that causes the script to branch. So, all you need to do is to determine what is the last thing to get assigned that's essential to the script's use. A well written script, even if it branches will end up with certain things defined, or at least one out of three, something like that. I'm not going to second guess what that is/these are in a script I haven't seen. If all else fails, it could be determined via trial and error.

Now, I didn't mean to say that what I was offering was a complete solution. I had no way of knowing what you were going to do with that test. One use could be:


function myDependantFunc(){
if(typeof reallyImporatant=='function'){
do dependant stuff here;
}
else
setTimeout("myDependantFunc()",300);
}

You could even count the loops and give up and do something else if - say a minute, or 3 seconds, or whatever passed and what you need from the other script wasn't ready yet.

[pman]

Thanks John and Twey. I think both you have a good solution. As Twey suggested, I could write a call back function in my script and someone else could use that if they are using my script. And if I'm using someone else's script, I guess I could use John's suggestion.

I think now that web 2.0 is really spreading out and api is available from all over the place, may be we should look into dynamically loading javascript. Or else the page will take much longer to load than it should. Also, it probably doesn't make sense to load a whole bunch of javascript files at the beginning and most of it may not be used depending on what the user is doing on the page.

That's why I think loading javascripts (same applies for CSS) dynamically is the best approach and also script functionalities should be separated in different files instead of having everything in the same file, but then I got stuck at the question that I asked in this thread.

Thanks again.

[jscheuer1]

I think the up and coming solution to script loading is third party hosting of popular code libraries. That way, chances are that the user already has most of the code cached.

With today's high speed connections though, you would need to have many, many very complex and long scripts to take much of a loading hit from just them. Images and things like audio, video, and Flash are, and will continue to be the real bandwidth hogs.

Images can be optimized to speed page loading.

[Twey]

But even a single image is usually many thousand times the size of a script. I don't think I've ever seen a 100k+ Javascript file.

[jscheuer1]

But? Don't you mean 'And'?

[Twey]

It contrasts with
Images can be optimized to speed page loading.Besides, "and" and "but" are logically the same connective anyway, they just have different nuances :)

[jscheuer1]

It contrasts with


Images can be optimized to speed page loading.

Besides, "and" and "but" are logically the same connective anyway, they just have different nuances :)

So, do you mean to say:

But instead of optimizing images, you should be aware of how much larger images are than your average script???!!

[Twey]

[Images can be optimized to speed page loading, b]ut even a single image is usually many thousand times the size of a script.Even though images can be optimised, they're usually much larger than a script.

[pman]

Again, both of you are right. But that doesn't necessarily mean that there's any disadvantage in loading scripts dynamically, if they can be done properly.

True, size of scripts are generally smaller than the size of images but if you have a lot of scripts file and you load them only if you need it, it CAN make a difference, when you add all of it together. Ofcourse, this is not gonna make any difference if you have an image whose size is about 2MB or so and you are only using it for a thumbnail display. For site optimization, you have to consider everything and there's many different factors. (I'm not an expert on site optimization :D. That's just my opinion :) )

Also, even if you have an image with large size, at least the user can see the progress of it. I'm sure you all have seen a large image appearing on the screen little by little. You can tell that it's still loading by just looking at it. For scripts, users will have no clue about it, because you don't know see any visual effects.

You already mentioned that a lot of people has high speed internet connection. That might be true for the people in Europe and America. It's still not global yet. If you have a business that also has customers in other parts of the world, you may want to reconsider this.

You may also ask who would have so many AND such big scripts. Well, look at the trend on the web now. Google is already offering so many different API's. There's ajax feed, ajax search, map. The list goes on. API is also available from Yahoo, Amazon, ebay (don't know if the last two offers api in Javascript).

Lastly, it's a preference as well. I personally don't want to load a script if I know that it will only be used if the user is doing something specific. If not, then it was a waste of time loading the script. It's kinda like:

Why do I like Firefox or Opera over Internet Explorer
Why do I prefer CSS over tables for layout
Why do I like xhtml strict over other doctypes
Why do I like Windows instead of Linux


I can guarantee that there's a lot of people who will disagree with all those I mentioned above. Well, that's it for now. Didn't mean to write a huge blog in this post :D. Let me know what you think. I'm curious to know your thoughts on this. I'm sure you have more good points besides those you mentioned already.

[jscheuer1]

The relative size of scripts vs. images and other higher byte content holds true regardless of the connection rate. If page loading speed is a primary concern, you should think about limiting the number of scripts and optimizing their code's length, rather than loading them dynamically. And, more importantly about optimizing and limiting high byte content. What you save in initial load time of scripts will be (and usually more) lost at point of load for the dynamically added script (not to mention potential problems with scripts that need to load at specific points in the page's hierarchy of loading), and perhaps (likely even) this loss of time to loading will occur at at a much less opportune moment in the flow of the user's experience than if it happened while images and whatnot that are easily expected by most users to require time to load are loading.

[Twey]

Why do I like xhtml strict over other doctypesIf you intend to support IE, you may want to rethink that one (http://www.webdevout.net/articles/beware-of-xhtml) :)
Why do I like Windows instead of LinuxI'm not sure how that applies really :-\
Again, both of you are right. But that doesn't necessarily mean that there's any disadvantage in loading scripts dynamically, if they can be done properly.You're quite right. In fact, I've developed a framework for my scripts to facilitate doing exactly that. If you can do it, do. It's still less important, though, than other elements of the page.

[jscheuer1]

Again, both of you are right. But that doesn't necessarily mean that there's any disadvantage in loading scripts dynamically, if they can be done properly.

You're quite right. In fact, I've developed a framework for my scripts to facilitate doing exactly that. If you can do it, do. It's still less important, though, than other elements of the page.

Ahem, what about the loss in performance at the critical juncture (for dial-up users) where the script is first required? I imagine that if the scripts could all be loaded after page load, that might be nice, but only if they are available before needed. It's somewhat like image preloading, which is worthless at best if the image is required before it's preloading is complete.

[pman]

If you intend to support IE, you may want to rethink that one (http://www.webdevout.net/articles/beware-of-xhtml) :)

Thanks for that link Twey. It DID make me rethink ;). But not because IE doesn't support it. I used to be a hardcore IE user, until I started coding :). Sadly, I still need to spend time to get things working in IE when using CSS or JS :(.


You're quite right. In fact, I've developed a framework for my scripts to facilitate doing exactly that. If you can do it, do. It's still less important, though, than other elements of the page.

agreed 100%

[Twey]

But not because IE doesn't support it.Alas, most of us have to make our sites work on IE :( The basic message was, XHTML is an entirely separate language with its own pros and cons that just happens to look like HTML. It's not just a different DOCTYPE.