YUI Libraries
My Pet Programmer
from Yahoo? I've just noticed them, used one or two for a couple things,
but I haven't dug too deep.
http://developer.yahoo.com/yui/
~A!
Peter Michaux
wrote:
I think that of the big popular libraries (Dojo, Prototype, jQuery)
the YUI library is the best because I think they've done more things
right than the others. I don't think they have done it all right.
YUI relies on browser sniffing (with navigator.userAgent like all the
big libraries seem to do) which is not necessary except perhaps in
some really rare odd bizarre situation which should probably be
avoided. Sniffing leads to less predictable behavior in untested
browsers. Feature detection is preferred method for dealing with
browser differences and feature detection is many years old now. I
don't think a library can be considered state of the art if it is
using browser sniffing. Yahoo! seems satisfied if the code only works
with only a very small set of new browsers (http://developer.yahoo.com/
yui/articles/gbs/). These browsers do make up the majority of traffic
on the web and Yahoo! is depending on this code but perhaps due to
their size they can afford to sacrifice some visitors. A small company
with a sales site that is barely scraping by may not be able to
sacrifice even one visitor. If your target audience is using cell
phone browsers or some other unusual os/browser combination not in the
graded browser support chart, then perhaps the YUI code wouldn't work
well for your visitors.
YUI has widgets but I have never been able to use a prepackaged widget
in my work. I always need custom widgets and when I wrote a tabbed
pane it was 1/10th the size, had smaller dependency files and did
exactly what I needed including functionality not in the YUI widget. I
don't think the benefit of a general purpose library is in the widgets
but rather in the base libraries like events and ajax.
Even though YUI libraries are broken up into several files, I think
the granularity of the files is too large. There are parts of the
event library and ajax libraries that I've never used but clients
would still need to download them.
The YUI code contains many workarounds for many browser bugs and it
was very educational for me to ready the YUI code.
The YUI team has produced some technical videos about JavaScript that
are well worth watching.
I've had contact with some of the YUI team through the YUI forum over
the last couple years and they are always helpful and friendly.
Peter
Randy Webb
Find any post in the archives with the word prototype.js in it and
substitute the phrase YUI and you can get a pretty good indication of
what people in this group are going to think about it.
Does YUI still eval script blocks retrieved via XHR?
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
My Pet Programmer
> My Pet Programmer said the following on 12/23/2007 7:33 PM:
>> Just a question in general, how do you guys feel about the YUI
>> libraries from Yahoo? I've just noticed them, used one or two for a
>> couple things, but I haven't dug too deep.
>>
>> http://developer.yahoo.com/yui/
>
> Find any post in the archives with the word prototype.js in it and
> substitute the phrase YUI and you can get a pretty good indication of
> what people in this group are going to think about it.
>
> Does YUI still eval script blocks retrieved via XHR?
>
See, that's what I was afraid of. I noticed in a single implementation
that the code ran slower and it was a bear to use. I was hoping to find
a calendar widget in there that would do what I needed, but there were
so many includes, millions of style elements, and a bloat I just
couldn't accept.
I do like the DOM library a bit, with the getAncestorsByTagName()
function, but that would be pretty simple to code up anyway.
Thanks for the feedback, much obliged.
~A!
My Pet Programmer
Thanks, Peter, I appreciate the response. I don't like the browser
detection, everything I've read has always said feature detect is good,
navigator is bad.
Their JSON lib is interesting in the way it extends the String prototype
out a bit, I'm just worried about compatibility across the board, the
software my company writes is for the Hotel and Car Rental industries,
and has to port all over the world under just about any circumstance.
~A!
Randy Webb
> Randy Webb said:
>> My Pet Programmer said the following on 12/23/2007 7:33 PM:
>>> Just a question in general, how do you guys feel about the YUI
>>> libraries from Yahoo? I've just noticed them, used one or two for a
>>> couple things, but I haven't dug too deep.
>>>
>>> http://developer.yahoo.com/yui/
>>
>> Find any post in the archives with the word prototype.js in it and
>> substitute the phrase YUI and you can get a pretty good indication of
>> what people in this group are going to think about it.
>>
>> Does YUI still eval script blocks retrieved via XHR?
>>
>
> See, that's what I was afraid of. I noticed in a single implementation
> that the code ran slower and it was a bear to use. I was hoping to find
> a calendar widget in there that would do what I needed, but there were
> so many includes, millions of style elements, and a bloat I just
> couldn't accept.
Have you looked at Matt's calendar widget? And, what are you needing it
to do?
<URL: http://www.mattkruse.com/javascript/calendarpopup/>
That is the old version. The main library site:
<URL: http://www.javascripttoolbox.com/lib/calendar/>
says the new one isn't available yet.
Randy Webb
<snip>
> Thanks, Peter, I appreciate the response. I don't like the browser
> detection, everything I've read has always said feature detect is good,
> navigator is bad.
The first two things I check in a library? A search for the word eval
and the word navigator. It is - usually - a pretty good indicator of
whether you need to look any further, depending on what they use it for.
My Pet Programmer
> My Pet Programmer said the following on 12/23/2007 8:34 PM:
>> Randy Webb said:
>>> My Pet Programmer said the following on 12/23/2007 7:33 PM:
>>>> Just a question in general, how do you guys feel about the YUI
>>>> libraries from Yahoo? I've just noticed them, used one or two for a
>>>> couple things, but I haven't dug too deep.
>>>>
>>>> http://developer.yahoo.com/yui/
>>>
>>> Find any post in the archives with the word prototype.js in it and
>>> substitute the phrase YUI and you can get a pretty good indication of
>>> what people in this group are going to think about it.
>>>
>>> Does YUI still eval script blocks retrieved via XHR?
>>>
>>
>> See, that's what I was afraid of. I noticed in a single implementation
>> that the code ran slower and it was a bear to use. I was hoping to
>> find a calendar widget in there that would do what I needed, but there
>> were so many includes, millions of style elements, and a bloat I just
>> couldn't accept.
>
> Have you looked at Matt's calendar widget? And, what are you needing it
> to do?
>
> <URL: http://www.mattkruse.com/javascript/calendarpopup/>
>
> That is the old version. The main library site:
> <URL: http://www.javascripttoolbox.com/lib/calendar/>
> says the new one isn't available yet.
>
the date fields. :)
I ended up coding it myself, it needed week, month, and yearly display
with the ability to add events to the days and color code them. Then I
needed hooks back into the calling page for click, mouseover, and
mouseout on the days themselves. That part of it I don't think I did in
a very clean way, it calls functions on the calling page as callbacks,
but the names have to be the same each time.
Like:
var cal = new Calendar(CALENDAR.MONTH_VIEW, eventData);
function calClick(e, dateStr) {
// do something with the date and the event that fired it
}
When what I really wanted to do was more like:
cal.setClickCallback(functionname);
Which, now that I think about it, I can do. Damn, you're a genius.
~A!
Peter Michaux
> My Pet Programmer said the following on 12/23/2007 7:33 PM:
>
> > Just a question in general, how do you guys feel about the YUI libraries
> > from Yahoo? I've just noticed them, used one or two for a couple things,
> > but I haven't dug too deep.
>
> >http://developer.yahoo.com/yui/
>
> Find any post in the archives with the word prototype.js in it and
> substitute the phrase YUI and you can get a pretty good indication of
> what people in this group are going to think about it.
>
> Does YUI still eval script blocks retrieved via XHR?
I don't ever remember that being part of YUI's connection.js library
and "eval" is not present in the file now. That is part of
Prototype.js as part of the whole rjs concept in Rails. Which can be
good for some applications. I don't see that dynamic script insertion
into the DOM is hands down better than using eval. I imagine using
eval is faster as it doesn't modify the DOM and the insertion
technique has an implicit eval anyway. The only thing to really worry
about using eval for this is how global variables are retrieved and
set. This isn't a common necessity. eval is supported in more user
agents (and certainly those without DOM's (although that makes me
sound a bit like Thomas.))
eval and the similar Function constructor are both required for some
sophisticated JavaScript tasks/techinques. eval is required (unless
you want some very slow big substitute that does exactly the same
thing) for converting JSON strings into objects and arrays. The
Function constructor is used when compiling CSS selector strings to
fast DOM getter functions. The alternative to compiling is much
slower. This was discussed here recently. Of course eval and the
Function constructor should only be used where appropriate just like
everything in programming in general. I don't think a positive search
for either in a library's code should automatically judge the library
poor quality.
Peter
Peter Michaux
wrote:
> Randy Webb said:
>
> > My Pet Programmer said the following on 12/23/2007 7:33 PM:
> >> Just a question in general, how do you guys feel about the YUI
> >> libraries from Yahoo? I've just noticed them, used one or two for a
> >> couple things, but I haven't dug too deep.
>
> >>http://developer.yahoo.com/yui/
>
> > Find any post in the archives with the word prototype.js in it and
> > substitute the phrase YUI and you can get a pretty good indication of
> > what people in this group are going to think about it.
>
> > Does YUI still eval script blocks retrieved via XHR?
>
> See, that's what I was afraid of. I noticed in a single implementation
> that the code ran slower and it was a bear to use. I was hoping to find
> a calendar widget in there that would do what I needed, but there were
> so many includes, millions of style elements, and a bloat I just
> couldn't accept.
>
> I do like the DOM library
Of their base libraries, that was the was the one I thought should be
broken up to many files. I can imagine needing just one function in
the file and it is a big file.
[snip]
Peter
Peter Michaux
wrote:
[snip]
> Their JSON lib is interesting in the way it extends the String prototype
> out a bit,
That is not a good idea, in my opinion. I didn't know the YUI team
ever did that and in fact I thought they held the "don't modify what
you don't own" ideal at a premium. After all they namespace like
crazy.
> I'm just worried about compatibility across the board, the
> software my company writes is for the Hotel and Car Rental industries,
> and has to port all over the world under just about any circumstance.
I started with one of Crockford's earlier JSON libraries that doesn't
extend any built in objects. This needs updating to be consistent with
the logic of his current library.
http://forkjavascript.org/json/docs
http://dev.forkjavascript.org/trac/browser/trunk/public/javascripts/fork/json.js
Peter
My Pet Programmer
> On Dec 23, 5:36 pm, My Pet Programmer <anth...@mypetprogrammer.com>
> wrote:
>
> [snip]
>
>> Their JSON lib is interesting in the way it extends the String prototype
>> out a bit,
>
> That is not a good idea, in my opinion. I didn't know the YUI team
> ever did that and in fact I thought they held the "don't modify what
> you don't own" ideal at a premium. After all they namespace like
> crazy.
>
knowing what the basic types do in my own apps?
[snip]
> http://forkjavascript.org/json/docs
> http://dev.forkjavascript.org/trac/browser/trunk/public/javascripts/fork/json.js
>
Ooh, thank you. Clicky-click I go.
~A!
Peter Michaux
wrote:
> Peter Michaux said:> On Dec 23, 5:36 pm, My Pet Programmer <anth...@mypetprogrammer.com>
> > wrote:
>
> > [snip]
>
> >> Their JSON lib is interesting in the way it extends the String prototype
> >> out a bit,
>
> > That is not a good idea, in my opinion. I didn't know the YUI team
> > ever did that and in fact I thought they held the "don't modify what
> > you don't own" ideal at a premium. After all they namespace like
> > crazy.
>
> What is it that's irksome about it, beyond the obvious matter of not
> knowing what the basic types do in my own apps?
Augmenting built in prototypes or objects you don't own is playing
with fire.
If your code needs to be robust and you want it to be more likely to
work without modification in weird situations (e.g. mashups or in
legacy pages) then you want to limit your use and dependency on
identifiers in places where others may be playing (e.g. global
identifiers and built-in objects.)
Another problem is if you create at String.prototype.toJSON and then a
standardized version comes along you have to move yours out of the
way. That is maintenance you could have avoided. What can make the
situation worse is if yours doesn't function the same way as the new
standardized version does. Then you can't just add yours if the
standard one doesn't exist.
The only argument I know of in favor of modifying built in objects is
because it makes the programmer feel all warm and fuzzy when they look
at the code. That isn't a good enough reason for me. I've never seen
much difference between writing "toJSON(obj)" and "obj.toJSON()" but
many people are really hung up about it and need to see the second one
in their code.
Peter
My Pet Programmer
> The only argument I know of in favor of modifying built in objects is
> because it makes the programmer feel all warm and fuzzy when they look
> at the code. That isn't a good enough reason for me. I've never seen
> much difference between writing "toJSON(obj)" and "obj.toJSON()" but
> many people are really hung up about it and need to see the second one
> in their code.
>
> Peter
Thanks for the explanation. I won't mess with the prototypes then. I
thought it was nifty you could do it, but I didn't really see the point,
I've always been an oo guy, and I think I prefer having my functions act
in a same manner. If I really need them encapsulated, I'll drop them in
an object.
Thanks again.
~A!
Randy Webb
> On Dec 23, 5:23 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> My Pet Programmer said the following on 12/23/2007 7:33 PM:
>>
>>> Just a question in general, how do you guys feel about the YUI libraries
>>> from Yahoo? I've just noticed them, used one or two for a couple things,
>>> but I haven't dug too deep.
>>> http://developer.yahoo.com/yui/
>> Find any post in the archives with the word prototype.js in it and
>> substitute the phrase YUI and you can get a pretty good indication of
>> what people in this group are going to think about it.
>>
>> Does YUI still eval script blocks retrieved via XHR?
>
> I don't ever remember that being part of YUI's connection.js library
> and "eval" is not present in the file now.
My bad then. I thought it might have been YUI but if it wasn't, then I
was mistaken. After finding a thread I was hunting, it was jQuery that
used eval on it that I was thinking about. But, if YUI doesn't eval
script blocks, then how does it deal with script blocks from an XHR
request? Or, does it?
> That is part of Prototype.js as part of the whole rjs concept in Rails.
> Which can be good for some applications.
Using eval on script blocks or Rails can be "good for some
applications"? I wouldn't think that anything with Prototype in it is
good for anything.
> I don't see that dynamic script insertion into the DOM is hands
> down better than using eval.
Is the last time, that I remember, that eval versus dynamic script
insertion was discussed.
I have yet to see an advantage to using eval over dynamic insertion. The
one place I might worry about it would be in IE4 and that falls way
outside the boundaries of "common and modern" browsers.
> I imagine using eval is faster as it doesn't modify the DOM and the
> insertion technique has an implicit eval anyway.
The only windows based browser where they are even close is in IE. FF2,
FF1.5, Opera9 and Safari3, the eval call took almost twice as long as
dynamic script insertion. I used a very simple test case and I think I
actually know why the results are what they are. I am, by no means, an
expert on how eval calls are done inside a browser. From what I have
read, and my own thoughts, it seems that eval is opening and using a
second script engine whereas dynamic insertion is using the currently
running engine. That could be true, it could be patently false though.
It might explain the time differences where that is the time to load the
second JS engine.
IE7 was consistently giving me ~2600 milliseconds for both calls.
FF2.0 eval was ~1900, dynamic insertion was ~750ms.
Opera 9 eval was ~600, dynamic insertion was ~350ms.
Safari3 eval ~300, dynamic insertion was ~150ms.
The test code is at the bottom of this post.
To be fair, I changed the stringToInsert to be a string form of the
latest incarnation of loadHTMLFragment and the results were:
IE7 eval was ~1000ms, dynamic insertion was ~6000ms.
Opera9 eval was ~1200ms, dynamic insertion was ~450ms.
FF2.0 eval was ~2900ms, dynamic insertion was ~1100ms.
Safari3 eval was ~2500ms, dynamic insertion was ~150ms!! (That one
shocked me).
The times are ~ from me running the tests 4 times and just watching
results and coming up with an average time. I didn't care to write a
loop to run them, track times, and then average them.
> The only thing to really worry about using eval for this is how
> global variables are retrieved and set. This isn't a common necessity.
As long as functions fall into the "global variables" category. And, I
do see it as a "common necessity" because a lot of AJAX sites are merely
retrieving existing documents, inserting them via innerHMTL, and wanting
the script blocks executed.
> eval is supported in more user agents (and certainly those without DOM's
> (although that makes me sound a bit like Thomas.))
Makes you sound a lot like Thomas. It goes back to your discussion with
him about where you draw the line for support. As it is now, I know of
only a few places where dynamic script insertion isn't viable and those
few browsers fall into the "old and not worth supporting category".
> eval and the similar Function constructor are both required for some
> sophisticated JavaScript tasks/techinques. eval is required (unless
> you want some very slow big substitute that does exactly the same
> thing) for converting JSON strings into objects and arrays.
I don't think we are talking about the same thing. I am considering the
scenario where some bonehead decides he wants an "AJAX site" and simply
retrieves entire documents, inserts them via innerHTML into a container,
and then posts here wondering why the scripts aren't executed. And that
is asked a lot here.
One of the major drawbacks to a complete eval solution is if a script
element is inserted that has a src property, eval can't handle that
situation.
> The Function constructor is used when compiling CSS selector strings to
> fast DOM getter functions. The alternative to compiling is much
> slower. This was discussed here recently. Of course eval and the
> Function constructor should only be used where appropriate just like
> everything in programming in general. I don't think a positive search
> for either in a library's code should automatically judge the library
> poor quality.
That wasn't what I was implying. I search for those two words, see how
and why they are used, then make my judgment. But, then again, I only
look at them when they get asked about here, I don't use them.
Test code:
function testIt(){
var stringToInsert = "document.getElementById('myDiv').innerHTML=" +
"'new Text';"
var beginEval = new Date().getTime();
for (i=0;i<10000;i++){eval(stringToInsert)}
var endEval = new Date().getTime();
var begin2 = new Date().getTime();
for (i=0;i<10000;i++){
var newScript = document.createElement('script');
newScript.type = "text/javascript";
newScript.src = stringToInsert;
}
var end2 = new Date().getTime();
dynamicTotalTime = end2 - begin2;
evalTotalTime = endEval - beginEval;
document.getElementById('results').innerHTML =
'eval took ' + evalTotalTime + ' milliseconds.' +
'<br>Dynamic Insertion took ' +
dynamicTotalTime + ' milliseconds.'
}
window.onload = testIt;
<div id="myDiv"></div>
<div id="results"></div>
Peter Michaux
<snip>
> I don't think we are talking about the same thing. I am considering the
> scenario where some bonehead decides he wants an "AJAX site" and simply
> retrieves entire documents, inserts them via innerHTML into a container,
> and then posts here wondering why the scripts aren't executed. And that
> is asked a lot here.
>
If someone is trying to just "add AJAX" to a site then what happens
when he retrives a page that has document.write in it? I imagine you
draw the line there and that your solution doesn´t support that
situation, true?
Will you be writing up an article about your style of handling all of
this stuff? It seems you've been thinking about dynamic script
insertion and your style of XHR-free Ajax and experimenting for a long
time. I'd sure like to read a distillation of how all the bits work
together as a system, it's pros and cons, etc.
Peter
slebetman
Incedentally, since we are talking about YUI, have a look at how YUI
does it. Look at the get utility and YUIloader. Both use dynamic
script insertion instead of eval. Of course, YUI only supports
loading .js and .css files and not .html so it isn't exactly "bonehead-
proof". But that's a good thing IMHO.
Randy Webb
> On Jan 1, 4:09 am, Peter Michaux <petermich...@gmail.com> wrote:
>> On Dec 24, 6:20 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>>
>> <snip>
>>
>>> I don't think we are talking about the same thing. I am considering the
>>> scenario where some bonehead decides he wants an "AJAX site" and simply
>>> retrieves entire documents, inserts them via innerHTML into a container,
>>> and then posts here wondering why the scripts aren't executed. And that
>>> is asked a lot here.
>> If someone is trying to just "add AJAX" to a site then what happens
>> when he retrives a page that has document.write in it? I imagine you
>> draw the line there and that your solution doesn´t support that
>> situation, true?
>>
>> Will you be writing up an article about your style of handling all of
>> this stuff? It seems you've been thinking about dynamic script
>> insertion and your style of XHR-free Ajax and experimenting for a long
>> time. I'd sure like to read a distillation of how all the bits work
>> together as a system, it's pros and cons, etc.
>
> Incedentally, since we are talking about YUI, have a look at how YUI
> does it. Look at the get utility and YUIloader.
100Kb uncompressed, 24kb minified, neither of which is very readable.
Never thought I would see a 3200 line script to load dependent files though.
> Both use dynamic script insertion instead of eval.
From what I read, it isn't doing what we are talking about. A search
for createElement returns one place, at line 1017 (in the
yuiloader-beta.js file). Then, it depends on UA detection and uses
setAttribute.
> Of course, YUI only supports loading .js and .css files and not .html so
> it isn't exactly "bonehead- proof". But that's a good thing IMHO.
What YUILoader appears to be for is loading dependent files and nothing
more. If externalFile1.js needs externalFile2.js and externalFile3.js in
order to operate properly then YUILoader loads those two files. But, it
appears to only work with YUI Code.
I don't care to make a test case, but, if anybody is using it then you
can possibly tell me how it deals with a case where it retrieves a
document (complete or snippet) via AJAX that has script blocks in it.
How does it go about executing those script blocks? Or does it?
Randy Webb
> On Dec 24, 6:20 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>
> <snip>
>
>> I don't think we are talking about the same thing. I am considering the
>> scenario where some bonehead decides he wants an "AJAX site" and simply
>> retrieves entire documents, inserts them via innerHTML into a container,
>> and then posts here wondering why the scripts aren't executed. And that
>> is asked a lot here.
>>
>
> If someone is trying to just "add AJAX" to a site then what happens
> when he retrives a page that has document.write in it?
Then, hopefully, they figure out what a dumb idea it was and learn how
to make a true AJAX site that uses the benefits of AJAX.
> I imagine you draw the line there and that your solution doesn´t
> support that situation, true?
Very true. And I don't believe that any script based solution for that
problem will ever exist. The problems with it are beyond being a good
humanitarian. You could try to find document.write calls and replace it
with a function call of your own. The function would have to put a place
holder where it was and then try to insert whatever was being written
into that holder. Even then, it is fraught with problems.
document.write('This document last modified on ' + document.lastModified);
Nasty, nasty scenario for something that simple.
> Will you be writing up an article about your style of handling all of
> this stuff? It seems you've been thinking about dynamic script
> insertion and your style of XHR-free Ajax and experimenting for a long
> time. I'd sure like to read a distillation of how all the bits work
> together as a system, it's pros and cons, etc.
I have wanted to do one for over a year now. When I sit down to start
writing it I usually get sidetracked by something else and when I go
back to it, I forgot where I was. And, I am not a very good technical
writer for the masses so it would have to be edited/reviewed by some
other people for me as well. The entire concept has to be covered from
the ground up though. You can't simply add the concept, you have to
redesign the entire site around the concept. And that is true whether
you use AJAX or Dynamic Script elements.
slebetman
Yes YUILoader is meant for YUI code although it can be made to load
external scripts. The get utility is the more generic utility to load
scripts and css via XHR (on top or which YUILoader was built).
>
> I don't care to make a test case, but, if anybody is using it then you
> can possibly tell me how it deals with a case where it retrieves a
> document (complete or snippet) via AJAX that has script blocks in it.
> How does it go about executing those script blocks? Or does it?
>
As I mentioned in my earlier post, it doesn't. And it doesn't even try
to. The get utility (and YUILoader built on top of it) only loads
javascript or css files, not xml/html/xhtml documents.
MB
> I have yet to see an advantage to using eval over dynamic insertion. The
> one place I might worry about it would be in IE4 and that falls way
> outside the boundaries of "common and modern" browsers.
>
>> I imagine using eval is faster as it doesn't modify the DOM and the
>> insertion technique has an implicit eval anyway.
>
> The only windows based browser where they are even close is in IE. FF2,
> FF1.5, Opera9 and Safari3, the eval call took almost twice as long as
> dynamic script insertion. I used a very simple test case and I think I
> actually know why the results are what they are. I am, by no means, an
> expert on how eval calls are done inside a browser. From what I have
> read, and my own thoughts, it seems that eval is opening and using a
> second script engine whereas dynamic insertion is using the currently
> running engine. That could be true, it could be patently false though.
> It might explain the time differences where that is the time to load the
> second JS engine.
>
> IE7 was consistently giving me ~2600 milliseconds for both calls.
> FF2.0 eval was ~1900, dynamic insertion was ~750ms.
> Opera 9 eval was ~600, dynamic insertion was ~350ms.
> Safari3 eval ~300, dynamic insertion was ~150ms.
>
> The test code is at the bottom of this post.
This test is not right. What are you really measuring?
The test is broken and the logic is flawed.
Broken because of this bug: In the DOM test, you take a string
containing javascript code and use that as src of a javascript tag. That
will never work. If you had appended the script element to the head, you
would have seen a javascript error as a result.
Flawed because with eval you take a pice of javascript code, insert it
into the document, run it and measure the total time of all this,
including execution. So far all good. But the DOM test just makes a
"dummy" element with a faulty src and then do nothing more with it. You
don't run any code. You don't insert the element into the document. You
just measure the time it takes to create a faulty script element. That's
it. So of course that will be fast.
A suggestion for a better test:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Eval vs DOM test</title>
<script type="text/javascript">
function testIt(){
var stringToInsertEval = "document.getElementById('divEval')"+
".innerHTML='new Text '+i;";
var stringToInsertDOM = "document.getElementById('divDOM')"+
".innerHTML='new Text '+i;";
var beginEval = new Date().getTime();
for (i=0;i<10000;i++){eval(stringToInsertEval)}
var endEval = new Date().getTime();
var beginDOM = new Date().getTime();
var head = document.getElementsByTagName('head')[0];
for (i=0;i<10000;i++){
var newScript = document.createElement('script');
newScript.type = "text/javascript";
newScript.text = stringToInsertDOM;
head.appendChild(newScript);
}
var endDOM = new Date().getTime();
dynamicTotalTime = endDOM - beginDOM;
evalTotalTime = endEval - beginEval;
document.getElementById('results').innerHTML = 'eval took ' +
evalTotalTime + ' milliseconds.<br>Dynamic Insertion took ' +
dynamicTotalTime + ' milliseconds.';
};
window.onload = testIt;
</script>
</head>
<body>
Eval: <span id="divEval"></span><br>
DOM: <span id="divDOM"></span><br>
<div id="results"></div>
</body>
</html>
This test (as well as your own test?) asumes that the javascript that we
want to insert has already been fetched and is contained in a variable.
We could also make another test where the eval test includes fetching
the javascript to be included via Ajax and where the DOM test fetches
the javascript the traditional way by setting the src attribute of a
script tag. But I think that's not really what this test was all about.
Now, when you run this test, you will see totally different numbers, in
favour of eval().
My results where:
IE7 eval was ~3469ms, dynamic insertion was 15797ms.
Opera9 was ~812ms, dynamic insertion was ~2563ms.
FF2.0 eval was ~2922ms, dynamic insertion was ~4547ms.
Safari3 eval was ~422ms, dynamic insertion was ~703ms.
MB
Randy Webb
> Randy Webb wrote:
>> I have yet to see an advantage to using eval over dynamic insertion.
>> The one place I might worry about it would be in IE4 and that falls
>> way outside the boundaries of "common and modern" browsers.
>>
>>> I imagine using eval is faster as it doesn't modify the DOM and the
>>> insertion technique has an implicit eval anyway.
>>
>> The only windows based browser where they are even close is in IE.
>> FF2, FF1.5, Opera9 and Safari3, the eval call took almost twice as
>> long as dynamic script insertion. I used a very simple test case and I
>> think I actually know why the results are what they are. I am, by no
>> means, an expert on how eval calls are done inside a browser. From
>> what I have read, and my own thoughts, it seems that eval is opening
>> and using a second script engine whereas dynamic insertion is using
>> the currently running engine. That could be true, it could be patently
>> false though. It might explain the time differences where that is the
>> time to load the second JS engine.
>>
>> IE7 was consistently giving me ~2600 milliseconds for both calls.
>> FF2.0 eval was ~1900, dynamic insertion was ~750ms.
>> Opera 9 eval was ~600, dynamic insertion was ~350ms.
>> Safari3 eval ~300, dynamic insertion was ~150ms.
>>
>> The test code is at the bottom of this post.
>
> This test is not right.
Indeed.
m...@brianhurtt.com
>
> IE7 eval was ~3469ms, dynamic insertion was 15797ms.
> Opera9 was ~812ms, dynamic insertion was ~2563ms.
> FF2.0 eval was ~2922ms, dynamic insertion was ~4547ms.
> Safari3 eval was ~422ms, dynamic insertion was ~703ms.
>
> MB
Interesting- I just tested on Firefox 3.0b2 on Mac and results were in
favor of code insertion:
eval was ~3134 milliseconds.
Dynamic Insertion was ~2161 milliseconds.
I also found that removing the appended script element immediately
reduced IE7's time from ~7364ms to ~3777ms. A decent difference. For
reference, eval took ~1872ms on my PC.