js importing problem
sidney
I am a brand new in Javascript. These days, I met a problem and can not
solve it. I hope somebody here can give me a hand. Any advice are
appreciated.
-----------------------------------------------------------------------------------------
HTML
Part:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html dir="ltr" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>DOM Example</title>
<script type="text/JavaScript" src="exampleFindElements.js">
</script>
</head>
<body>
<h1>Heading</h1>
<p>Paragraph</p>
<h2>Subheading</h2>
<ul id="eventsList">
<li>List 1</li>
<li>List 2</li>
<li><a href="http://www.google.com">Linked List Item</a></li>
<li>List 4</li>
</ul>
<p>Paragraph</p>
<p>Paragraph</p>
</body>
</html>
------------------------------------------------------------------------------------------
JS
Part:
function findElements()
{
var listElements = document.getElementsByTagName('li');
var paragraphs = document.getElementsByTagName('p');
var msg = 'This document contains ' + listElements.length + ' list items\n';
msg += 'and ' + paragraphs.length + ' paragraphs.';
alert(msg);
}
window.onload = findElements;
-------------------------------------------------------------------------------------------
I
am sure that the filename is correct, and two files are in the same
directory.But the problem is when I open the html file, no popup window
with the message appear, but the content of the html display normally.
So I guess maybe the javascript file fail to be imported into the html.
How can I solve it?
--
I am finding
The Natural Philosopher
window.onload = findElements();
Tim Down
[snip]
> I
>
> am sure that the filename is correct, and two files are in the same
> directory.But the problem is when I open the html file, no popup window
> with the message appear, but the content of the html display normally.
> So I guess maybe the javascript file fail to be imported into the html.
> How can I solve it?
Works perfectly for me in Firefox 3 and IE 7. Is the file name of
exampleFindElements.js capitalised that way on the file system?
Tim
sidney
<t...@invalid.invalid> said:
still not work, I tried. Thanks
--
I am finding
sidney
Hi Tim,
my environment is Mac OS X 10.4.11, editor is Coda, and tested by
Safari, Firefox for mac and coda embed browser.
--
I am finding
Matthias Reuter
> sidney wrote:
>> window.onload = findElements;
>>
> Im no expert, but shouldn't that be
>
> window.onload = findElements();
No, definitely not. window.onload should be a reference to a function.
findElements returns undefined, so in your approach window.onload is
undefined.
I noticed, the OP wrote type="text/JavaScript". I would try that in
lowercase, i.e. type="text/javascript".
Matt
Tim Down
> >> I
>
> >> am sure that the filename is correct, and two files are in the same
> >> directory.But the problem is when I open the html file, no popup window
> >> with the message appear, but the content of the html display normally.
> >> So I guess maybe the javascript file fail to be imported into the html.
> >> How can I solve it?
>
> > Works perfectly for me in Firefox 3 and IE 7. Is the file name of
> > exampleFindElements.js capitalised that way on the file system?
>
> > Tim
>
> Hi Tim,
>
> my environment is Mac OS X 10.4.11, editor is Coda, and tested by
> Safari, Firefox for mac and coda embed browser.
>
> --
> I am finding
You need to test whether exampleFindElements.js is being included at
all (try replacing all the JavaScript code in exampleFindElements.js
with a simple alert). If not, the simplest explanation would be
different capitalisation in the file name on the file system to that
in the file name in the <script> tag.
Tim
Thomas 'PointedEars' Lahn
> [...]
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
> <html dir="ltr" lang="en">
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
That's not Valid, so there may be other mistakes: <http://validator.w3.org/>
(These
> <title>DOM Example</title>
DOM Example of what? <http://www.w3.org/QA/Tips/good-titles>
> <script type="text/JavaScript" src="exampleFindElements.js">
Although the `type' attribute of the SCRIPT element is specified as
case-insensitive (CI), your UA might have difficulties with
"text/JavaScript"; try "text/javascript" instead, exactly as registered at IANA.
<http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.1>
<http://www.iana.org/assignments/media-types/text/> (never mind the
`obsolete', it was a mistake).
> [...]
> function findElements()
> {
> var listElements = document.getElementsByTagName('li');
> var paragraphs = document.getElementsByTagName('p');
> var msg = 'This document contains ' + listElements.length + ' list items\n';
> msg += 'and ' + paragraphs.length + ' paragraphs.';
Avoid concatenation with `+='.
> alert(msg);
Should be
window.alert(msg);
> }
> window.onload = findElements;
Forget about the proprietary window.onload, use
<body onload="findElements()">
instead.
[fixed word wrap]
> [...]
> I am sure that the filename is correct, and two files are in the same
> directory. But the problem is when I open the html file, no popup window
> with the message appear, but the content of the html display normally.
> So I guess maybe the javascript file fail to be imported into the html.
Stop guessing, start testing: <http://getfirebug.com/>
Safari (which you should have told about in the first place) has a Developer
Console and there's Firebug Lite, too.
<http://developer.apple.com/internet/safari/faq.html>
> How can I solve it?
Provided that the script resource is loaded, and that not using
`window.onload' and using window.alert() and debugging does not help, you
might not be able to solve this with alert(). That the alert message is not
shown may as well be the effect of a built-in popup blocker; alert()
messages are supposed to be displayed on user interaction (if that), not
when a document was loaded.
You might be more successful with W3C DOM Level 2 methods that create and
add an element with the corresponding content, either document.write() (you
need to do that within the `body' element, after the other elements), or
probably more reliable in terms of counting:
function findElements()
{
var listElements = document.getElementsByTagName('li');
var paragraphs = document.getElementsByTagName('p');
var msg = 'This document contains '
+ listElements.length + ' list items\n<br>'
+ 'and ' + paragraphs.length + ' paragraphs.';
var span = document.createElement("span");
span.appendChild(document.createTextNode(msg));
var div = document.createElement("div");
div.appendChild(span);
document.body.appendChild(div);
}
You should add some feature tests if this is going to be cross-browser, of
course.
PointedEars
sidney
Thank everybody have replied this post. What amazing is the popup
window appeared normally in my Safari just now, but still NOT work
under the embed browser of Coda. So I think the code above really work
(I read it from a book), and all the advice is really appreciated
--
I am finding
sidney
Hi Matt,
I tried your method changing JavaScript into lowercase, but the result
is the same.
Thank you for your advice.
--
I am finding
Jorge
wrote:
> (...)
> Safari (which you should have told about in the first place) has a Developer
> Console and there's Firebug Lite, too.
Safari has a full blown debugger built-in :
http://webkit.org/blog/197/web-inspector-redesign/
--
Jorge.
sidney
<!DOCTYPE
function
I
am
sorry everyone, I just made a mistake, after my dinner, I forgot I had
copied all the code in .js file into the html body, so in safari, it
work. but after I removed them, the situation comes back.
I have tried to use a simple alert and put all the other code in it to
test weather the .js file has been imported into the html , and the
answer is the poor NO. any other way to import the .js file into html?
--
I am finding
Thomas 'PointedEars' Lahn
> Thank everybody have replied this post. What amazing is the popup
> window appeared normally in my Safari just now, but still NOT work
> under the embed browser of Coda.
There is nothing amazing about it, alert() is a host method. If the host
environment does not provide the method, or if it employs means to suppress
its outcome, then there is no alert message.
However, that would contradict this statement on <http://www.panic.com/coda/>:
"You’re writing code; you want to see what it looks like. Thanks to Apple’s
WebKit, we’ll show your site exactly as it looks like in Safari, even as you
type."
Perhaps it boils down to the 239th Rule of Acquisition: "Never be afraid to
mislabel a product."
> So I think the code above really work
I have already told you that this is a bad idea.
> (I read it from a book),
Mark my words: That it is from a book means that it is not supposed to work.
There are just too many bad books out there.
> and all the advice is really appreciated
You don't appear to have read it all yet.
Learn to quote. <http://jibbering.com/faq/#posting>
PointedEars
rf
Or try looking at the firebug net tab to see if there is a 404 status code
involved.
sidney
<Point...@web.de> said:
yes, Mr. PointedEars, I must apologize for missing your reply. I am
checking my code according your advice, and Thank you very much, really!
--
I am finding
Tad J McClellan
> sidney wrote:
>> msg += 'and ' + paragraphs.length + ' paragraphs.';
>
> Avoid concatenation with `+='.
Why is that?
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
Jeremy J Starcher
> Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>> sidney wrote:
>
>>> msg += 'and ' + paragraphs.length + ' paragraphs.';
>>
>> Avoid concatenation with `+='.
>
>
> Why is that?
Efficiency reasons.
var msg = "Hello";
msg += " ";
msg += "there";
is computationally expensive because string objects are created and
destroyed with each step. From the way I read the specs, this isn't any
better.
var msg = "Hello" +
" " +
"there";
However, this tends to be the fastest in most user agents (particularly
if the resultant string is quite large).
var msgs = []
msgs.push("Hello");
msgs.push(" ");
msgs.push("there");
msg = msgs.join("");
Jorge
> (...)
> However, this tends to be the fastest in most user agents (particularly
> if the resultant string is quite large).
>
> var msgs = []
> msgs.push("Hello");
> msgs.push(" ");
> msgs.push("there");
> msg = msgs.join("");
AFAIK, this crap applies only to the crappiest of browsers: *IE*.
--
Jorge.
Jorge
http://jorgechamorro.com/cljs/053/
function add () {
var text= "", n= txt.length;
while (n--) {
text+= txt[n];
}
}
function join () {
var text= txt.join('');
}
Results:
MSIE 6.0 on Windows NT
add 58 (17.24ms)
join 1553 ( 0.64ms) <- 26x times faster !
Safari 3.2.2 on Windows NT
add 856 (1.17ms)
join 2768 (0.36ms) <- 3.25x times faster
Chrome 1.0.154.53 on Windows NT
add 5111 (0.20ms)
join 3016 (0.33ms) <- slower
Opera 9.64 on Windows NT
add 585 (1.71ms)
join 410 (2.44ms) <- slower
Firefox 3.0.7 on Windows NT
add 573 (1.75ms)
join 754 (1.33ms) <- 1.3x times faster
--
Jorge.
Jeremy J Starcher
My tests are showing very similar results.
(Truth be told, most of the time I will go ahead and concatenate strings
because I find the code easier to read and in most cases, the difference
doesn't matter that much. However, when I know that I'll be dealing with
more than about a dozen values, I'll use the push/join.)
JSLitmus eh? First time I've run across that particular gem. I think I
have a new hobby.
Thomas 'PointedEars' Lahn
> JSLitmus eh? First time I've run across that particular gem.
And that is good so, because it is junk. I'm sure David will gladly explain
why.
> I think I have a new hobby.
Writing a speed test that doesn't contain such blunders as browser sniffing
and augmenting prototype objects?
PointedEars
Gregor Kofler
Browser "freshly" restarted:
Firebug enabled:
add 1121 (0.89ms)
join 685 (1.46ms)
Firebug disabled:
add 997 (1ms)
join 1004 (1ms)
3rd or 4th re-run:
Firebug enabled:
add 587 (1.7ms)
join 932 (1.07ms)
Firebug disabled:
add 566 (1.77ms)
join 684 (1.46ms)
Analyze this...
Those benchmarks are pretty, but the results - particularly in FF vary so
wildly - that they are rather useless.
Gregor
kangax
Looking at JSLint source [1], I don't see `navigator.userAgent` being
used for anything except diagnostic output. From the cursory overview,
there seems to be no object inference either. I also don't see prototype
objects augmentation (if you meant prototypes of built-in native
objects, of course, and not user defined once).
Explain?
Of course, there's some strange overcomplication like -
| var title = document.getElementsByTagName('title');
| title = (title && title.length) ? title[0].innerHTML : null;
which, to my knowledge, can be replaced with just -
var title = document.title || null;
- or object "type" being, for some reason, determined from an often
unrelated object's string representation -
| if (!/function[^\(]*\(([^,\)]*)/.test(f.toString())) {
| throw new Error('"' + name +
| '" test: Test is not a valid Function object');
| }
but those don't seem like too much of a "blunder".
Are there any major mistakes in the script that I'm not seeing?
[1] http://www.broofa.com/Tools/JSLitmus/JSLitmus.js
--
kangax
Jeremy J Starcher
Are you sure that you and I are looking at the same code?
The browser sniffing is only used for screen reporting. A nicety, hardly
a sin.
I don't see augmenting prototype objects.
The only augmentation I see appears to be of the jsl itself.
Jorge
>
> Analyze this...
>
> Those benchmarks are pretty, but the results - particularly in FF vary so
> wildly - that they are rather useless.
Yes, I have seen that before:
1.- Enabling Firebug affects execution speed.
2.- it also slows down when garbage collection cycles kick in.
...but both happen (are observable) regardless of the method used for
timing: IOW, I don't think that it's JSLitmus' fault.
--
Jorge.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Jeremy J Starcher wrote:
>>> JSLitmus eh? First time I've run across that particular gem.
>> And that is good so, because it is junk. I'm sure David will gladly explain
>> why.
>>
>>> I think I have a new hobby.
>> Writing a speed test that doesn't contain such blunders as browser sniffing
>> and augmenting prototype objects?
>
> Looking at JSLint source [1],
JSLitmus, not JSLint (I presume the latter to be of better quality, but I
might be wrong). And what matters here is not the original source but what
Jorge made of it. You only need to use the URI-reference that is the `src'
attribute value.
> I don't see `navigator.userAgent` being used for anything except diagnostic
> output.
There is no good reason to use it at all.
> From the cursory overview, there seems to be no object inference either.
And what do you make of this?
// Detect OS
var oses = ['Windows','iPhone OS','(Intel |PPC )?Mac OS X','Linux'].join('|');
var pOS = new RegExp('((' + oses + ') [^ \);]*)').test(ua) ? RegExp.$1 : null;
if (!pOS) pOS = new RegExp('((' + oses + ')[^ \);]*)').test(ua) ?
RegExp.$1 : null;
// Detect browser
var pName = /(Chrome|MSIE|Safari|Opera|Firefox)/.test(ua) ? RegExp.$1 : null;
> I also don't see prototype objects augmentation (if you meant prototypes
> of built-in native objects, of course, and not user defined once).
// IE workaround - monkey patch Array.indexOf() if it's not defined
if (!Array.prototype.indexOf) {
Array.prototype.indexOf = function(o) {
for (var i = 0; i < this.length; i++) if (this[i] === o) return i;
return -1;
}
}
That precludes Array objects from being subject to a realistic benchmark.
> Explain?
Polite people say please.
> Are there any major mistakes in the script that I'm not seeing?
Yes.
PointedEars
Thomas 'PointedEars' Lahn
> On Wed, 15 Apr 2009 22:53:02 +0200, Thomas 'PointedEars' Lahn wrote:
>> Jeremy J Starcher wrote:
>>> JSLitmus eh? First time I've run across that particular gem.
>> And that is good so, because it is junk. I'm sure David will gladly
>> explain why.
>>
>>> I think I have a new hobby.
>> Writing a speed test that doesn't contain such blunders as browser
>> sniffing and augmenting prototype objects?
>
> Are you sure that you and I are looking at the same code?
My Magic 8 Ball says: Don't count on it.
> The browser sniffing is only used for screen reporting. A nicety, hardly
> a sin.
An unnecessity, at best.
> I don't see augmenting prototype objects.
Look closer.
> The only augmentation I see appears to be of the jsl itself.
The *what*?
PointedEars
Jeremy J Starcher
> kangax wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Jeremy J Starcher wrote:
>>>> JSLitmus eh? First time I've run across that particular gem.
>>> And that is good so, because it is junk. I'm sure David will gladly
>>> explain why.
>>>
>>>> I think I have a new hobby.
>>> Writing a speed test that doesn't contain such blunders as browser
>>> sniffing and augmenting prototype objects?
>>
>> Looking at JSLint source [1],
>
> JSLitmus, not JSLint (I presume the latter to be of better quality, but
> I might be wrong). And what matters here is not the original source but
> what Jorge made of it. You only need to use the URI-reference that is
> the `src' attribute value.
Since the discussion was on JSLitmus, doesn't the original source matter
more?
kangax and I are referring to the code from:
< http://www.broofa.com/Tools/JSLitmus/demo_test.html >
>> I don't see `navigator.userAgent` being used for anything except
>> diagnostic output.
>
> There is no good reason to use it at all.
>
>> From the cursory overview, there seems to be no object inference
>> either.
>
> And what do you make of this?
>
> // Detect OS
> var oses = ['Windows','iPhone OS','(Intel |PPC )?Mac OS
> X','Linux'].join('|'); var pOS = new RegExp('((' + oses + ') [^
> \);]*)').test(ua) ? RegExp.$1 : null; if (!pOS) pOS = new RegExp('(('
> + oses + ')[^ \);]*)').test(ua) ?
> RegExp.$1 : null;
>
> // Detect browser
> var pName = /(Chrome|MSIE|Safari|Opera|Firefox)/.test(ua) ? RegExp.$1
> : null;
Used for *display* *purposes* *only.*
>> I also don't see prototype objects augmentation (if you meant
>> prototypes of built-in native objects, of course, and not user defined
>> once).
>
> // IE workaround - monkey patch Array.indexOf() if it's not defined if
> (!Array.prototype.indexOf) {
> Array.prototype.indexOf = function(o) {
> for (var i = 0; i < this.length; i++) if (this[i] === o) return i;
> return -1;
> }
> }
And this code comes from .... Oh yes. A modified version of the JSLitmus
test. Not useful for discussing JSLitmus itself.
var jsl = {
[ code snipped ]
/**
* Array#indexOf isn't supported in IE, so we use this as a cross-
browser solution
*/
indexOf: function(arr, o) {
if (arr.indexOf) return arr.indexOf(o);
for (var i = 0; i < this.length; i++) if (arr[i] === o) return i;
return -1;
}
[ More code snipped ]
}
No modification of Array object.
> That precludes Array objects from being subject to a realistic
> benchmark.
Again, not valid against the original source.
Dr J R Stockton
net>, Wed, 15 Apr 2009 07:05:23, Tad J McClellan <ta...@seesig.invalid>
posted:
>Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>> sidney wrote:
>
>>> msg += 'and ' + paragraphs.length + ' paragraphs.';
>>
>> Avoid concatenation with `+='.
>
>
>Why is that?
Ignore him. For a new JavaScripter, machine efficiency is of minor
importance; what matters is that you, and maybe others, can read your
code easily.
The chief purpose of composing strings is to have then displayed and
read. Only for strings of many lines is it possible for the "joining"
part of composing to take time significant in comparison with the time
taken to display them; and on any recent machine (clock speed over about
2 MHz), it is reading which will take by far the longest time.
However,
var msg = "this " + "that " +
"tother"
is easier to type.
Code should be indented by about two spaces per unclosed "{" to show
intended structure, if it is intended to be read by people (including
yourself, later). A considerate commercial site will strip that, and
most other comment, from the publicly-distributed version.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Thomas 'PointedEars' Lahn
> On Thu, 16 Apr 2009 00:11:49 +0200, Thomas 'PointedEars' Lahn wrote:
>> kangax wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Jeremy J Starcher wrote:
>>>>> JSLitmus eh? First time I've run across that particular gem.
>>>> And that is good so, because it is junk. I'm sure David will gladly
>>>> explain why.
>>>>
>>>>> I think I have a new hobby.
>>>> Writing a speed test that doesn't contain such blunders as browser
>>>> sniffing and augmenting prototype objects?
>>> Looking at JSLint source [1],
>> JSLitmus, not JSLint (I presume the latter to be of better quality, but
>> I might be wrong). And what matters here is not the original source but
>> what Jorge made of it. You only need to use the URI-reference that is
>> the `src' attribute value.
>
> Since the discussion was on JSLitmus, doesn't the original source matter
> more?
The discussion was about the reliability of Jorge's benchmarks. It is you
original who is trying to make it a discussion about the benchmarking script.
> kangax and I are referring to the code from:
> < http://www.broofa.com/Tools/JSLitmus/demo_test.html >
Well, I'm not.
>>> I don't see `navigator.userAgent` being used for anything except
>>> diagnostic output.
>> There is no good reason to use it at all.
>>
>>> From the cursory overview, there seems to be no object inference
>>> either.
>> And what do you make of this?
>>
>> // Detect OS
>> var oses = ['Windows','iPhone OS','(Intel |PPC )?Mac OS
>> X','Linux'].join('|'); var pOS = new RegExp('((' + oses + ') [^
>> \);]*)').test(ua) ? RegExp.$1 : null; if (!pOS) pOS = new RegExp('(('
>> + oses + ')[^ \);]*)').test(ua) ?
>> RegExp.$1 : null;
>>
>> // Detect browser
>> var pName = /(Chrome|MSIE|Safari|Opera|Firefox)/.test(ua) ? RegExp.$1
>> : null;
>
> Used for *display* *purposes* *only.*
Nevertheless of questionable quality and usefulness.
>>> I also don't see prototype objects augmentation (if you meant
>>> prototypes of built-in native objects, of course, and not user defined
>>> once).
>> // IE workaround - monkey patch Array.indexOf() if it's not defined if
>> (!Array.prototype.indexOf) {
>> Array.prototype.indexOf = function(o) {
>> for (var i = 0; i < this.length; i++) if (this[i] === o) return i;
>> return -1;
>> }
>> }
>
> And this code comes from .... Oh yes. A modified version of the JSLitmus
> test.
Or an older version. In any case, Jorge is to blame for using it an
presenting it as a telltale benchmark.
> Not useful for discussing JSLitmus itself.
See above.
> var jsl = {
>
> [ code snipped ]
>
> /**
> * Array#indexOf isn't supported in IE, so we use this as a cross-
> browser solution
> */
> indexOf: function(arr, o) {
> if (arr.indexOf) return arr.indexOf(o);
> for (var i = 0; i < this.length; i++) if (arr[i] === o) return i;
> return -1;
> }
>
> [ More code snipped ]
> }
>
> No modification of Array object.
(It would have been the "Array.prototype object".) And that is good so.
>> That precludes Array objects from being subject to a realistic
>> benchmark.
>
> Again, not valid against the original source.
Again, irrelevant to my case.
PointedEars
Thomas 'PointedEars' Lahn
> The discussion was about the reliability of Jorge's benchmarks. It is you
> original who is trying to make it a discussion about the benchmarking script.
That "original" must have gotten in there by accidental copy-paste.
No offense meant.
PointedEars
Jorge
wrote:
>
> The discussion was about the reliability of Jorge's benchmarks. It is you
> original who is trying to make it a discussion about the benchmarking script.
JFTR both versions yield the same results:
The one with an older, modified JSLitmus:
http://jorgechamorro.com/cljs/053/
And the "The PointedEars is an idiot" version, with the latest version
of JSLitmus (untouched):
http://jorgechamorro.com/cljs/054/
PointedEars: could you get back to study the closures now please ?
--
Jorge.
kangax
> kangax wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Writing a speed test that doesn't contain such blunders as browser sniffing
>>> and augmenting prototype objects?
>> Looking at JSLint source [1],
>
> JSLitmus, not JSLint (I presume the latter to be of better quality, but I
That was a typo on my part :)
> might be wrong). And what matters here is not the original source but what
> Jorge made of it. You only need to use the URI-reference that is the `src'
> attribute value.
Ok. It seemed like you were talking about JSLitmus.js script itself.
>
>> I don't see `navigator.userAgent` being used for anything except diagnostic
>> output.
>
> There is no good reason to use it at all.
But it's not being *used* (as in affecting any execution logic/outcome).
It's being merely *displayed* to the user.
>
>> From the cursory overview, there seems to be no object inference either.
>
> And what do you make of this?
>
> // Detect OS
> var oses = ['Windows','iPhone OS','(Intel |PPC )?Mac OS X','Linux'].join('|');
> var pOS = new RegExp('((' + oses + ') [^ \);]*)').test(ua) ? RegExp.$1 : null;
> if (!pOS) pOS = new RegExp('((' + oses + ')[^ \);]*)').test(ua) ?
> RegExp.$1 : null;
>
> // Detect browser
> var pName = /(Chrome|MSIE|Safari|Opera|Firefox)/.test(ua) ? RegExp.$1 : null;
>
`pName` is only displayed to the user, AFAICS, just like the value of
`navigator.userAgent` (among others `navigator` properties) is displayed
on one of your pages - http://pointedears.de/scripts/test/whatami/.
I really don't see what's wrong with it.
>> I also don't see prototype objects augmentation (if you meant prototypes
>> of built-in native objects, of course, and not user defined once).
>
> // IE workaround - monkey patch Array.indexOf() if it's not defined
> if (!Array.prototype.indexOf) {
> Array.prototype.indexOf = function(o) {
> for (var i = 0; i < this.length; i++) if (this[i] === o) return i;
> return -1;
> }
> }
>
The file I linked to has something else (formatted to fit the width) -
| /**
| * Array#indexOf isn't supported in IE,
| * so we use this as a cross-browser solution
| */
| indexOf: function(arr, o) {
| if (arr.indexOf) return arr.indexOf(o);
| for (var i = 0; i < this.length; i++)
| if (arr[i] === o) return i;
| return -1;
| }
`indexOf` is a property of a user-defined object in this case.
[...]
--
kangax
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> kangax wrote:
>>> Thomas 'PointedEars' Lahn wrote:
> [...]
>>>> Writing a speed test that doesn't contain such blunders as browser sniffing
>>>> and augmenting prototype objects?
>>> Looking at JSLint source [1],
>> JSLitmus, not JSLint (I presume the latter to be of better quality, but I
>
> That was a typo on my part :)
>
>> might be wrong). And what matters here is not the original source but what
>> Jorge made of it. You only need to use the URI-reference that is the `src'
>> attribute value.
>
> Ok. It seemed like you were talking about JSLitmus.js script itself.
I was referring to the JSLitmus.js referred in the HTML source of Jorge's
"benchmark". Why should I be referring to something else if the quality of
the "benchmark" is in question?
>>> I don't see `navigator.userAgent` being used for anything except diagnostic
>>> output.
>> There is no good reason to use it at all.
>
> But it's not being *used* (as in affecting any execution logic/outcome).
> It's being merely *displayed* to the user.
Maybe so.
>> [...]
> `pName` is only displayed to the user, AFAICS, just like the value of
> `navigator.userAgent` (among others `navigator` properties) is displayed
> on one of your pages - http://pointedears.de/scripts/test/whatami/.
>
> I really don't see what's wrong with it.
A simple navigator.userAgent can do it much better.
> The file I linked to has something else (formatted to fit the width) -
> [...]
Of course.
PointedEars
Jorge
wrote:
>
> I was referring to the JSLitmus.js referred in the HTML source of Jorge's
> "benchmark". Why should I be referring to something else if the quality of
> the "benchmark" is in question?
>
JFTR, in the cljs message:
http://groups.google.com/group/comp.lang.javascript/msg/fc4da5be3a9f305a
On Apr 15, 10:53 pm, Thomas 'PointedEars' Lahn wrote:
> Jeremy J Starcher wrote:
> > JSLitmus eh? First time I've run across that particular gem.
>
> And that is good so, because it is junk. I'm sure David will gladly explain
> why.
--
Jorge.
Tad J McClellan
>
>> Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>>> sidney wrote:
>>
>>>> msg += 'and ' + paragraphs.length + ' paragraphs.';
>>>
>>> Avoid concatenation with `+='.
>>
>>
>> Why is that?
>
> Efficiency reasons.
I optimize to reduce whatever is most expensive.
Cycles are cheap.
Memory is cheap.
Programmers are expensive (though we may think we're not expensive
enough when payday rolls around).
Therefore, I optimize for maintenance first, and would write:
> var msg = "Hello";
> msg += " ";
> msg += "there";
because it is immediately apparent what the code is doing.
> var msg = "Hello" +
> " " +
> "there";
I would write that as:
var msg = "Hello"
+ " "
+ "there";
> However, this tends to be the fastest in most user agents (particularly
> if the resultant string is quite large).
>
> var msgs = []
> msgs.push("Hello");
> msgs.push(" ");
> msgs.push("there");
> msg = msgs.join("");
"Premature optimization is the root of all evil"
I write for efficient maintenance.
Only if it then proves too slow would I think about writing for
execution speed.
Lasse Reichstein Nielsen
> On Wed, 15 Apr 2009 07:05:23 -0500, Tad J McClellan wrote:
>
>> Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>>> Avoid concatenation with `+='.
>>
>>
>> Why is that?
>
> Efficiency reasons.
>
> var msg = "Hello";
> msg += " ";
> msg += "there";
>
> is computationally expensive because string objects are created and
> destroyed with each step.
That depends entirely on the implementation.
Most implementations (i.e., probably anything but IE, and I don't know
about IE 8) have efficient (constant time) string concatenation.
It's only if you start using the string that the string is flattened.
> From the way I read the specs, this isn't any better.
>
> var msg = "Hello" +
> " " +
> "there";
The spec doesn't say anything about the representation of strings, nor
their performance characteristics. It is probably the same as the former,
though.
> However, this tends to be the fastest in most user agents (particularly
> if the resultant string is quite large).
>
> var msgs = []
> msgs.push("Hello");
> msgs.push(" ");
> msgs.push("there");
> msg = msgs.join("");
This is a classical trick to avoid expensive (quadratic time
complexity) string concatentation. These days it's only really needed
in IE (but that does mean that it's needed!), and I wouldn't use it
unless the addition was in a loop and with a potentially large result.
For something with a result of eleven characters, it's probably more
expensive that just doing the additions.
It's actually what non-IE browsers do, behind the scene, anyway.
For something like this tiny example, the programmatic complexity
increase far outweighs the computational complexity improvement. (Or,
in other words: Don't optimize unless it's necessary. Don't think it's
necessary unless you have measured it.)
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'