Structuring Javascript code

[Tom de Neef]

I hope you don't mind trivial questions. I only ask them after failing to
find answers in my book and on the web...

Can I split Javascript code into separate js files which reference each
other (hierarchically)? For instance, can I put core functions in a library
file and refer to them from other script files (like: $ïnclude "core.js").

TIA
Tom

 

[Peter Michaux]

I hope you don't mind trivial questions. I only ask them after failing to
find answers in my book and on the web...

Can I split Javascript code into separate js files which reference each
other (hierarchically)? For instance, can I put core functions in a library
file and refer to them from other script files (like: $ïnclude "core.js").

There are quite a few "module loader" systems out there that allow
building dependencies like this. I don't use such a system. I just
manually list them in the page like this

<script type="text/javascript src="core.js"></script>
<script type="text/javascript src="app.js"></script>

I think the module loaders encourage making many HTTP requests to the
server and that is a bad idea. It is better to have a build system
that aggregates the various JavaScript development files into
production files with the whitespace removed etc.

Peter

 

[Ipequey]

I've used the script injection technique to accomplish this in the
past. The problem with it is that if you want to test the presence of
methods using typeof(<function name>) == "function", it doesn't seem
to like working if the function is inside the injected script
file...at least not in IE.

Here is a handy function to take a src string and create a script
file. I suppose it could be improved by specifying namespaces...but
it'll do what you want it to

function jsInsert(src) {
if( document.createElement && document.childNodes ) {
var scriptElem = document.createElement('script');
scriptElem.setAttribute('src',src);
scriptElem.setAttribute('type','text/javascript');
document.getElementsByTagName('head')[0].appendChild(scriptElem);
} else {
alert('Your browser is not W3C DOM compliant.');
}
}

 

[Tom de Neef]

"Peter Michaux" <[email protected]> schreef in bericht

I hope you don't mind trivial questions. I only ask them after failing to
find answers in my book and on the web...

Can I split Javascript code into separate js files which reference each
other (hierarchically)? For instance, can I put core functions in a
library
file and refer to them from other script files (like: $ïnclude "core.js").

<script type="text/javascript src="core.js"></script>
<script type="text/javascript src="app.js"></script>

So, the HTML will bind it all together. That is fine: a function defined in
"core.js" can be referenced in "app.js" and within the HTML it will work
together.

That does not solve the problem of how to test "app.js" without the HTML, if
it calls a function declared in "core.js". Or do you never test the script
standalone? In my editor (Antechinus) standalone testing is an option.
Tom

 

[Peter Michaux]

"Peter Michaux" <[email protected]> schreef in bericht


<script type="text/javascript src="core.js"></script>
<script type="text/javascript src="app.js"></script>

So, the HTML will bind it all together. That is fine: a function defined in
"core.js" can be referenced in "app.js" and within the HTML it will work
together.

You are correct. All the scripts are evaluated in the same global
namespace.

That does not solve the problem of how to test "app.js" without the HTML, if
it calls a function declared in "core.js". Or do you never test the script
standalone? In my editor (Antechinus) standalone testing is an option.

I suppose the editor should be able to be told which scripts to "load"
when testing a particular script.

Peter

 

[David Mark]

I've used the script injection technique to accomplish this in the
past. The problem with it is that if you want to test the presence of
methods using typeof(<function name>) == "function", it doesn't seem
to like working if the function is inside the injected script
file...at least not in IE.

That is incorrect. Perhaps you are trying to test before you inject
it?

Here is a handy function to take a src string and create a script
file. I suppose it could be improved by specifying namespaces...but

What does that mean?

it'll do what you want it to

function jsInsert(src) {
        if( document.createElement && document.childNodes ) {

This is an object inference (a form of browser sniffing.) These are
always a bad idea. Detect and test the features required by your
script. You didn't use childNodes here, so you can remove that check.

Also, detecting methods of host objects by boolean type conversion is
a bad idea. See the isHostMethod function in the Code Worth
Recommending repository.

                var scriptElem = document.createElement('script');
                scriptElem.setAttribute('src',src);

You didn't test for the presence of setAttribute (and as Randy
mentioned, you don't need it for this script.)

                scriptElem.setAttribute('type','text/javascript');
                document.getElementsByTagName('head')[0].appendChild(scriptElem);

You didn't test for the presence of gEBTN or appendChild.

        } else {
                alert('Your browser is not W3C DOM compliant.');

This line illustrates your flawed reasoning. And why would you alert
such a thing? Scripts should not insult the user's chosen browser and
most users will dismiss this message as gobbledygook anyway.

[snip]

 

[Henry]

I've used the script injection technique to accomplish this in the
past. The problem with it is that if you want to test the presence of
methods using typeof(<function name>) == "function", it doesn't seem
to like working if the function is inside the injected script
file...at least not in IE.

That is incorrect.  Perhaps you are trying to test before you inject
it?

Here is a handy function to take a src string and create a script
file. I suppose it could be improved by specifying namespaces...but

What does that mean?

it'll do what you want it to

function jsInsert(src) {
        if( document.createElement && document.childNodes ) {

This is an object inference (a form of browser sniffing.)  These are
always a bad idea.  Detect and test the features required by your
script.  You didn't use childNodes here, so you can remove that check.

Also, detecting methods of host objects by boolean type conversion is
a bad idea.  See the isHostMethod function in the Code Worth
Recommending repository.

                var scriptElem = document.createElement('script');
                scriptElem.setAttribute('src',src);

You didn't test for the presence of setAttribute (and as Randy
mentioned, you don't need it for this script.)

                scriptElem.setAttribute('type','text/javascript');
                document.getElementsByTagName('head')[0]..appendChild(scriptElem);

You didn't test for the presence of gEBTN or appendChild.

        } else {
                alert('Your browser is not W3C DOM compliant.');

This line illustrates your flawed reasoning.  And why would you alert
such a thing?  Scripts should not insult the user's chosen browser and
most users will dismiss this message as gobbledygook anyway.

[snip]

 

[Richard Cornford]

David Mark wrote:

This line illustrates your flawed reasoning.

No only flawed reasoning but a general human failing; the assumption that
all other people are either like yourself or should be like yourself. In web
developers this manifests itself in the assumption that all possible users
are web developers and so more or less know about web development technology
and terminology.

It is easy to see how it happens, especially given the number of existing
examples published by people who had not thought about what they were
writing, but the bottom line is that actual users of the Internet are the
full spectrum of ordinarily people. The vast majority of whom don't know
anything about web technologies/terminology, don 't want to know anything
about it, and would find any explanation of the subject unwelcome and
tedious. And that is what should be expected from them; there are no grounds
for attributing blame.

And why would you alert such a thing?

Absolutely! Even if the user knows what a "W3C" or a "DOM" are, or even what
"compliant" means in this (somewhat technical) context, what exactly are
they expected to do about it?

Scripts should not insult the user's chosen browser and
most users will dismiss this message as gobbledygook anyway.

Dismiss it or worry about it, gobbledegook is exactly what it is.

Richard.

 

[David Mark]

David Mark wrote:




No only flawed reasoning but a general human failing; the assumption that
all other people are either like yourself or should be like yourself. In web
developers this manifests itself in the assumption that all possible users
are web developers and so more or less know about web development technology
and terminology.

Indeed. I recently ran into a site that alerted "you must enable
cookies to continue to browse this site" on every page load. (!)
Children shouldn't play with JavaScript.

It is easy to see how it happens, especially given the number of existing
examples published by people who had not thought about what they were
writing, but the bottom line is that actual users of the Internet are the
full spectrum of ordinarily people. The vast majority of whom don't know
anything about web technologies/terminology, don 't want to know anything
about it, and would find any explanation of the subject unwelcome and
tedious. And that is what should be expected from them; there are no grounds
for attributing blame.

Right. Browsing Google search results, I often see the ridiculous
"Your browser does not support JavaScript" message, indicating misuse
of the NOSCRIPT element.

Absolutely! Even if the user knows what a "W3C" or a "DOM" are, or even what
"compliant" means in this (somewhat technical) context, what exactly are
they expected to do about it?

Yes, and is there anything more annoying than an alert?

Dismiss it or worry about it, gobbledegook is exactly what it is.

Yes, that is another concern. The average user is just as likely to
think that their browser (or computer) is broken as the result of such
a message.