is yahoo ... good javascript ?

[optimistx]

http://developer.yahoo.com/yui/index.html

Is this rubbish, evil, bad, wrong, not to recommend, "go away"-folks,
"knitting suits them better"-people etc

or

something that a new javascript wannabe programmer should set as an example
of good principles?

 

[Jim Ley]

http://developer.yahoo.com/yui/index.html

Is this rubbish, evil, bad, wrong, not to recommend, "go away"-folks,
"knitting suits them better"-people etc

or

something that a new javascript wannabe programmer should set as an example
of good principles?

Somewhere in the middle - the principles are fine but they are only
one of many fine ways of going, you may or may not like the style.

Jim.

 

[Douglas Crockford]

http://developer.yahoo.com/yui/index.html

Is this rubbish, evil, bad, wrong, not to recommend, "go away"-folks,
"knitting suits them better"-people etc

or

something that a new javascript wannabe programmer should set as an example
of good principles?

It is good stuff.

 

[Jim Ley]

It is good stuff.

hmm... it might be relevant to mention the fact you're an employee
of yahoo.

Jim.

 

[petermichaux]

CONS:
1. Excessive use of the YAHOO.* namespace is over-kill and annoying, IMO

I'm glad they use this for everything. If they want to be really robust
and make it difficult for people to screw up isn't this essential?

3. It looks like it's leaning towards a huge monolothic library approach,
rather than targetted solutions for specific situations

But not like Dojo with it's complex package manager etc. I like how
Yahoo! has broken up the library. For example, if I am going to use the
Yahoo! event library, it is likely I will use most of the code that is
in that library. I won't be asking people using my site to download a
big library and only be using 10% of the code in the site.

I would add as a con that...

The drag drop constructor (and many others) only takes an id string and
I cannot send the constructor an actual DOM element. This means I have
to add all sorts of dummy id's to elements so I can tell the drag drop
library how to find them. Kludge. I hope they will fix this so the
constructor can take an id string or a DOM element.

I'm considering using the Event code in a project, but so far I've use other
(IMO, better) alternatives for many of their other utilities.

I'm using the Event code and it seems good so far. Seems quite flexible
without too much code to use it.

Peter

 

[Matt Kruse]

Somewhere in the middle - the principles are fine but they are only
one of many fine ways of going, you may or may not like the style.

I agree.

PROS:
1. A lot of their code is pretty solid
2. The Event stuff seems pretty good and greatly simplifes a topic that can
be very confusing to many developers
3. Very well documented. They clearly have money to burn
4. It's free and re-distributable.
5. It will most likely continue to be supported and extended in the future

CONS:
1. Excessive use of the YAHOO.* namespace is over-kill and annoying, IMO
2. try/catch is used when not really necessary, causing ungraceful
compilation errors for older script engines
3. It looks like it's leaning towards a huge monolothic library approach,
rather than targetted solutions for specific situations
4. Some of their code, such as their DOM.getXY() is not very robust and even
resorts to browser-sniffing

I'm considering using the Event code in a project, but so far I've use other
(IMO, better) alternatives for many of their other utilities.

 

[petermichaux]

Yahoo! UI

3. Very well documented. They clearly have money to burn

I think the idea is to centralize all utility javascript development
for Yahoo and document it well to *save* money.

Peter

 

[Matt Kruse]

Would you please elaborate on this? What sort of problems would
try/catch cause, and on what engines?

try/catch was introduced in Javascript 1.4, IIRC. So Netscape 4.x, for
example, will choke on it. And it's not like it will just cause an error
when/if it hits the statement - it will cause a compilation error right from
the start. Netscape 4.x is ancient and mostly ignored these days, but I
don't know about current mobile devices and which versions of javascript
they support and whether that would be a problem.

And what method would you use to determine when to use and when not
to use?

I've never had the need to use try/catch in javascript, except for
IE-specific blocks of code for instantiating ActiveX objects.

 

[Matt Kruse]

I'm glad they use this for everything. If they want to be really
robust and make it difficult for people to screw up isn't this
essential?

Which is such a long namespace required?

Instead of YAHOO.util.DOM.getXY() they could have just used DOM.getXY()

Introducing packages into javascript similar to Java is over-kill.

The drag drop constructor (and many others) only takes an id string
and I cannot send the constructor an actual DOM element.

Indeed, they should accept an object or string, and resolve the string to an
object as necessary.

 

[petermichaux]

Instead of YAHOO.util.DOM.getXY() they could have just used DOM.getXY()

Imagine they did as you suggest, you already have an object called DOM
in your site and you want to incrementally start using the Yahoo! UI
library. That would hurt. Very unlikely that people have a "YAHOO"
object in their existing sites. Somewhat likely that people have a
"DOM" object. Perhaps Yahoo! didn't need the "util" part. This might
indicate how big they expect the library to grow.

Peter

 

[Matt Kruse]

I think the idea is to centralize all utility javascript development
for Yahoo and document it well to *save* money.

Of course, but my point was that most javascript developers who create
packages in their spare time don't have the resources to document their code
so fully and provide so many examples. So the documentation output from
yahoo's project is excellent because they have money to fund the effort.