YUI Libraries

P

Peter Michaux

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/

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
 
M

My Pet Programmer

Randy Webb said:
My Pet Programmer said the following on 12/23/2007 7:33 PM:

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!
 
M

My Pet Programmer

Peter Michaux said:
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

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!
 
M

My Pet Programmer

Randy Webb said:
My Pet Programmer said the following on 12/23/2007 8:34 PM:

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.
Funny you should say, same project uses Matt's calendar popup for all
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!
 
P

Peter Michaux

My Pet Programmer said the following on 12/23/2007 7:33 PM:



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
 
P

Peter Michaux

Randy Webb said:




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
 
P

Peter Michaux

On Dec 23, 5:36 pm, My Pet Programmer <[email protected]>
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
 
M

My Pet Programmer

Peter Michaux said:
On Dec 23, 5:36 pm, My Pet Programmer <[email protected]>
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?

[snip]
Ooh, thank you. Clicky-click I go.
~A!
 
P

Peter Michaux

wrote:
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
 
M

My Pet Programmer

Peter Michaux said:
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!
 
P

Peter Michaux

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
 
S

slebetman

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. 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.
 
S

slebetman

slebetman said the following on 1/1/2008 4:31 AM:





100Kb uncompressed, 24kb minified, neither of which is very readable.
Never thought I would see a 3200 line script to load dependent files though.


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.


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.

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.
 
M

MB

Randy said:
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.


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
 
M

me

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

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top