YUI Libraries

[My Pet Programmer]

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/

~A!

[Peter Michaux]

On Dec 23, 4:33 pm, My Pet Programmer <[e-mail]>
wrote:

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

[Randy Webb]

My Pet Programmer said the following on 12/23/2007 8:36 PM:

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

--
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]

Peter Michaux said:

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

http://forkjavascript.org/json/docs
http://dev.forkjavascript.org/trac/b...s/fork/json.js

Ooh, thank you. Clicky-click I go.
~A!

[Peter Michaux]

On Dec 23, 9:02 pm, My Pet Programmer <[e-mail]>
wrote:

Peter Michaux said:On Dec 23, 5:36 pm, My Pet Programmer <[e-mail]>

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]

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!

[Randy Webb]

MB said the following on 1/8/2008 6:02 AM:

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.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

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