Is it safe to substitute html <script src="xxx.js"> 'includes' with $.getScript(...)?

Question

(I am still very new to Javascript and JQuery) I am trying to keep my code clean by creating one js file per html file. I also have a couple of common js file containing code used by page-specific js files.

I was searching for solutions to import/include other js files in a given js file and I came accross this one. It refers to $.getScript().

Instead of using multiple <script src="xxx.js"></script> as imports/includes in my html pages, could I move them to my js files and use $.getScript(...) instead? I mean, is it safe? Is it a good practice?

EDIT

Is it safe regarding cyclic references?

EDIT II

To make it more clear, let's imagine I have a1.js, a2.js and a3.js.

For a1.js:

$.getScript("a2.js");
$.getScript("a3.js");
...

For a2.js:

$.getScript("a3.js");
...

For a3.js:

$.getScript("a2.js");
...

There is a potential infinite loop between a2.js and a3.js. Should I handle it with something like this in each js file:

var vari;

if (typeof vari === 'undefined') {
    vari = 1;
}

Answer 1

Regarding good Practice that answer is as always... it depends.

Your Page Style

Contra:

• If you for example use a script to substitute some page fonts, the effect will be that the font change will be even more visible for the user.
• If your script changes the height of some elements, this will be very noticeable.

PRO:

• If you load a Script to handle a specific form, that the user first has to edit, there is no problem at all
• If you load a Script that starts animation that can be substituted with a single loading animation you can do this.
• If your page is a application with many views and models, you can use getScript like getJson, in this case your page speed will greatly improve.

Your Coding Style

• Not every Page and Script is structured to be used this way. JQuery's $(document).ready() fires every registered handler once, even after the event occurred. This does not necessarily mean every handler works this way, certainly not the DOM2 Events.

• If you have anywhere inline Scripts it will no longer work.

• You can no longer guarantee a certain order your initialization code will have, so you can run in problems have to add more checks, that e.g. a expectedly visible container is still visible.

Whats the reward?

On high performance pages, you gain some thats clear. But script tags at the end of the page can do the same thing with half the work (mainly: remove inline scripts). In my opinion getScript is something like a last reward, you should not overuse it, because the potential to not only scare other developers but also your customers away is clearly there. I would only use it in the environment of a web application, because here are the real benefits

UPDATE response to your comment

Using getScript on your page should look like this:

//since you need it there will be some kind of wrapper
var initClosure = function() {...}

if(typeof optionalNamespace == 'undefined') {
    $.getScript('/foo.js', initClosure);
} else {
    initClosure();
}

All depending code is in initClosure, and you check a namespace, or variable name (even something like window['blub'] or simply blub will work). You will need this, since the on getScript depending function, wich typically sets default values or appends something to the dom should only be called once.

Nevertheless I don't really see the point in cyclic references, because this would mean:

load script 1 -> wait -> loaded ->load script 2 -> wait ->loaded -> [...] ->load script 1

This situation should be avoided for at least 2 reasons

• The browser can not predict this. If there are several script tags, your browser will take care of parallel downloads, so the overall speed (simplified & rough) is the time the biggest file will need to load. In my Example it will take the sum of the script loads.
• Initialization of your scripts will be handled twice, so any state will get lost.