jquery vs dojo vs yui etc

[Thomas 'PointedEars' Lahn]

Duh. But the discussion is about general-purpose libraries, whose main
purpose is to smooth over cross-browser issues and add functionality
for web scripting.

You have destroyed the context. Duh!


PointedEars

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn :

This has (as for me) nothing to do with personal smears. [...]
John Resig's delusions of grandeur [...]

I rest my case.

You have no case; you are disregarding the available evidence.


PointedEars

 

[Tim Streater]

Perhaps you just haven't been exposed to all the cross-browser issues
yet?

This is certainly true.

There are tons of quirks, bugs, non-standard behaviors, etc that
you must deal with if you write cross-browser scripts for the web,

but I'm not.

where just about any browser may be used.


Aren't most of us here? I've been using javascript since the day it
was released to the public. It still frustrates me sometimes. The
browser implementations, at least. Not so much the language itself.

Well, I guess I came to it rather later. I was out of programming and
working on wide area networks for most of the 90s.

Hmmm, I'm not sure what this statement really means.

As I said, it was very brief. Just came away with the feeling that
having avoided perl why would I want to use JScript?

 

[Tim Streater]

As I said, it was very brief. Just came away with the feeling that
having avoided perl why would I want to use JScript?

Ah sorry - I probably meant JQuery.

 

[Garrett Smith]

On Jun 18, 7:37 am, Thomas 'PointedEars' Lahn<[email protected]>
wrote:
[...]

I still believe that the way to combat jQuery and to help fix all the
junk that it has spewed on the web is to create a library with a
compatible subset of the jQuery API, and implement it correctly. Then
people can switch over to it easily and comfortably, and get the
benefit of more robust code.

You missed my outline post?

Please see:
MessageID: [email protected]

I'm going to wager you've not even started on following your own advice.
If you had, you probably would have realized that the design of jQuery
has fundamental problems (please see my earlier message).

Why do you think jQuery has had so many issues with upgrades?

Before reimplementing jQuery correctly, you'll first need to define what
"correctly" means.

Documentation for the selectors are a good starting point.

Let us know how far you get with that.

Garrett

 

[Thomas 'PointedEars' Lahn]

Please see:
MessageID: [email protected]

Please use `URIs as specified in RFC 4438 to refer to postings, here

<
so that the posting being referred to can be viewed easily with the majority
of newsreaders.


TIA

PointedEars

 

[Thomas 'PointedEars' Lahn]

Please see:
MessageID: [email protected]

Please use `URIs as specified in RFC 5538¹ to refer to postings, here

<
so that the posting being referred to can be viewed easily with the majority
of newsreaders.


TIA

PointedEars
___________
¹ <http://tools.ietf.org/html/rfc5538>

 

[John G Harris]

It is not what reinventing the wheel means in the context which should
be clear from the quotation as given. People don't need to sit on a
wheel for now on, but: people don't need to find another equiradial
shape just because the wheel is already taken.

According to your definition the inventors of JQuery were reinventing
the wheel, so JQuery should be thrown away.

John

 

[Matt Kruse]

You missed my outline post?
Please see:
MessageID: [email protected]

I don't see the relevance.

I'm going to wager you've not even started on following your own advice.

I looked into it at one point. That's what http://MyJQuery.com (which
I own) was going to be. The problem was time and desire on my part.

If you had, you probably would have realized that the design of jQuery
has fundamental problems (please see my earlier message).

Obviously. That's why you would change the design. The API would be
changed to not allow so much overloading. Just keep the stuff that is
most common/useful. You would have a reduced set of jQuery
functionality, but it would be robust. It would be sane.

Why do you think jQuery has had so many issues with upgrades?

Primarily, because the jQuery team doesn't care much about backwards-
compatibility.

Before reimplementing jQuery correctly, you'll first need to define what
"correctly" means.

To some degree, yes. But you could begin and define as you go.

Documentation for the selectors are a good starting point.

Sure, that would be fine. If I were to re-write jQuery, I would keep
Sizzle as-is, even with bugs, and just document the things that won't
work correctly. They are fairly minor, IMO.

Let us know how far you get with that.

I have no intention of doing so. And thus, the problem. The people
with the skill needed to make a great product rarely have the time or
desire to do so. The less experienced have time, patience, and a lack
of things to work on, and a desire for significance and "fame", and
therefore starting writing the next monolithic library, and it becomes
popular because they have the time to support, market, and evangelize
it. *shrugs*

Matt Kruse

 

[S.T.]

Umm, that's not at all what the mantra has been in here for years.
Over and over and over it has been said by many that general-purpose
javascript libraries are a bad idea.

My point has always been that general-purpose js libraries are a
_must_, and if the people with the skill to write them correctly don't
do so, then someone else will. And other people have. jQuery has lots
of problems. The coding of it and its design and the way the authors
attack problems are all quite poor. But it fills a need.

Exactly.

The fact that most CLJ regulars (the vocal ones, at least) can't
comprehend why there's such demand for libraries is the same reason
their critiques of libraries are technically accurate yet largely
ignored. They can't see in context, nor anything less rigid than a
true/false view.

Even when someone like DM comes along and writes "His Library", he's
missing the point. He may get the technical aspects more correct, but
he lacks the vision and social grace required to make the library
actually useful to most developers. It's like he's created a better
mousetrap, but completely drops the ball on manufacturing, marketing,
and distribution. Whereas something like jQuery suffers from poor
quality, but gets the other stuff right.

DM's script may be solid but the project as a whole is a train wreck. It
wasn't a project developed to solve a problem, rather was a script
written in an attempt to mock other libraries. It was DOA before it saw
daylight.

Turn on any infomercial and see how ridiculous the product is, yet see
how many people buy it and how rich the creators are. It doesn't
matter how great of a product you create if you can't get it out to
the masses! And if the masses are creating terrible web sites full of
broken script, and this is the problem that DM is trying to address,
then he's doing it wrong. Even though it seems to drive DM crazy, the
truth is that John Resig is a much better salesman, and his product is
beating the pants of DM's "higher quality" product.

I still believe that the way to combat jQuery and to help fix all the
junk that it has spewed on the web is to create a library with a
compatible subset of the jQuery API, and implement it correctly. Then
people can switch over to it easily and comfortably, and get the
benefit of more robust code.

You are in a small subset of developers that use jQuery by choice, yet
are also highly critical of it. In fact you might be the only person
I've read that shares those characteristics. Not that there's anything
wrong with that, just a somewhat unique view.

The bulk of jQuery users seem perfectly content with it and the pace of
fixes. Even those who recognize there are some shortcomings (like me)
find the outstanding issues borderline trivial. To "combat jQuery" you'd
need to write a better alternative and convince the user base it's
better. The former is likely far easier than the latter.

I don't think there's a need to 'combat' jQuery and the other libraries.
They will fade away on their own eventually. The major browsers are
*finally* headed in the right direction with standardization. As the
average user's browser improves jQuery's merits will diminish, as will
its usage. When jQuery stops solving a problem, people will stop using
it. A few years, I'd guess.


Off topic, but looks as though jQuery's looking to ease cross-mobile
browser issues next. Mobile remains of little interest to me but should
be interesting to watch their approach.

http://www.flickr.com/photos/jeresig/sets/72157624180070911/

 

[Scott Sauyet]

[in response to Matt Kruse]
You are in a small subset of developers that use jQuery by choice, yet
are also highly critical of it. In fact you might be the only person
I've read that shares those characteristics. Not that there's anything
wrong with that, just a somewhat unique view.

You can put me in that category as well. I find that JQuery often
simplifies my development, but I recognize many flaws in it and would
love to see something more solid come along to take it's place. But
those need to be libraries that I would feel comfortable handing off
to a client to continue with, which leaves out, for instance, My
Library.

At the moment, JQuery seems the best of a fairly bad bunch. But I
really don't want to skip a library altogether. Yes, I trust my own
skills enough to believe I could do everything that's done in those
libraries, but I really don't want to spend the time. And I don't
think it's *that* bad.

-- Scott

 

[Garrett Smith]

I don't see the relevance.

It seems like you believe that there are technical problems that ccan be
fixed and do not agree that the problems with jQuery come from the
initial API design. That's what my other post was getting at.

[...]

Primarily, because the jQuery team doesn't care much about backwards-
compatibility.

OK. I believe that complexity and loosely defined methods were reasons.

To some degree, yes. But you could begin and define as you go.

Sure, if you realized previously unforeseen problems and complexity in
the process.

Sure, that would be fine. If I were to re-write jQuery, I would keep
Sizzle as-is, even with bugs, and just document the things that won't
work correctly. They are fairly minor, IMO.

How much have you looked into it?

I have no intention of doing so. And thus, the problem. The people
with the skill needed to make a great product rarely have the time or
desire to do so. The less experienced have time, patience, and a lack
of things to work on, and a desire for significance and "fame", and
therefore starting writing the next monolithic library, and it becomes
popular because they have the time to support, market, and evangelize
it. *shrugs*

Well, time yes, but desire, too. What good is a large user base?

Garrett

 

[S.T.]

There's only a demand because people take on javascript projects that
are beyond their skill level.

This is always what I suspected a portion of the animosity was based on.
A fear that opening up DOM manipulation and AJAX to the masses cheapens
a particular skill set.

DM's library has had little objective criticism and to call it DOA when
its usage is clearly growing shows how much you know about it.

Huh? What indicators show its "clearly growing"? Aside from David's 14
posts, mostly replying to himself, the "support group" shows five posts
from two authors so far this month. Not exactly a booming community.

I've never actually *seen* 'My Library' in use on a live site. Have you?
Tough to gauge growth rates when the benchmarks hold steady at zero.

Until something suggests otherwise I'll stand by my conclusion the
project is dead, and always was dead, as the result of largely
non-technical factors.

Why don't you just admit that you have stopped trying to discredit DM as
a person and are now trying to discredit his library both of which you
apparently know little about.

I know David Mark's online persona is that of an asshat. That's about
all I know about DM. Maybe he's a stand-up rational guy in the real
world. I have no idea.

If you think there's something more involved here, like I'm in the midst
of a several-year mission to discredit a javascript library and it's
author, running to various online forums constantly posting the same
arguments over and over and over... well, those sorts of actions would
border on lunacy.

I might pop in an occasional CLJ thread and voice my opinion, but that's
it. Nothing more elaborate going on. You can relax.

 

[Tim Streater]

This is always what I suspected a portion of the animosity was based on.
A fear that opening up DOM manipulation and AJAX to the masses cheapens
a particular skill set.

Anyone who has enough brain cells to understand DOM manipulation and
AJAX is going to understand JavaScript.

 

[Matt Kruse]

It seems like you believe that there are technical problems that ccan be
fixed and do not agree that the problems with jQuery come from the
initial API design. That's what my other post was getting at.

There are multiple problems of different types, including:

1. Algorthm: Some problems are simply solved in the wrong manner,
giving incorrect or inconsistent results

2. API: Overloaded functions should be split into multiple functions,
or in many cases just trashed. Complicated API should be simplified.

3. Design: Some of the goals of the core lib are too lofty and cannot
be adequately accomplished, and should be trashed.

4. Syntax: The source is unnecessarily obfuscated and could be much
more readable.

How much have you looked into it?

Quite a bit. Nearly as much as DM, I suppose.

What good is a large user base?

A large user base is helpful because it brings out many situations and
conditions that could not be predicted or found by a small development
group. Even the best, most experienced js developers can't keep track
of all the browser quirks and bugs out there. If the goal of a js
library is to work well in many environments and situations, it's
great to be exposed to thousands of different contexts that you may
have never thought of. It will make the code more robust.

I know that in many things I've built, I thought it worked fine until
a small portion of users complained about something. Then I learned of
a whole new way of thinking, or a whole new context, and I could
further generalize my code.

Matt Kruse

 

[RobG]

This is always what I suspected a portion of the animosity was based on.
A fear that opening up DOM manipulation and AJAX to the masses cheapens
a particular skill set.

Perhaps you are reflecting your own fears, as far as I know that has
never been used as justification for criticism of various libraries in
this group.

More to the point is that the publishers of various libraries say that
they remove the various quirks of cross-browser scripting, yet only
appear to do so for a small number of current browsers. Anyone with an
"unsupported" browser may be left unable to access on-line resources
for no reason other than the site developer's choice of development
tools.

A fundamental principle of the WWW is that it provides universal
access to information regardless of user agent or platform. Developing
sites that only work in a small number of browsers is the antithesis
of that ideal.

It is also very difficult to get library authors to improve their
products - how long did it take jQuery to ditch browser sniffing? How
many of the current crop continue to do it? Even the supposed champion
of web devices, Apple, uses browser sniffing on their MobileMe site to
*prevent* access by their own web-enabled products such as iPhone and
iPodTouch. I expect it's because the site is based on a couple of
script libraries (like spoutcore and prototype.js) and is so bloated
that it is unusable on a typical web-enabled phone or similar device.

There are companies like Sencha with their massive ext.js framework
who are pushing a library for touch devices that is over 200KB
minified. It is full of useless functions like:

isPrimitive : function(v) {
return Ext.isString(v) || Ext.isNumber(v) || Ext.isBoolean(v);
},

...

isNumber : function(v) {
return Object.prototype.toString.apply(v) === '[object
Number]' && isFinite(v);
},

isString : function(v) {
return Object.prototype.toString.apply(v) === '[object
String]';
},

so passing a String or Number object to isPrimitive() returns true.
Why are such functions considered necessary at all? In what
circumstance will isNumber or isString be better than using typeof?
Why coerce a primitive to an Object to find out if it's a primitive?
Why two function calls when none is necessary? What do the inclusion
of such functions, and their use within the library, tell you about
the architecture and mindset of the authors? These functions are pure
ECMAScript, anyone with a basic understanding of the language should
be able to see their silliness.

Javascript libraries and frameworks are promoted as making web
development easier. A consequence of their adoption is bloated, slow
and limited sites that work only for those with the latest and
greatest devices and software and high-speed access to the web. The
developers who use them trumpet the fact that they can knock up a site
in no time at all, forgetting that for a good number of their
prospective visitors the site so produced is dysfunctional. When
alerted to that, they respond that they don't care about 0.1% of
traffic (or some other fictional number), it's not important in "the
real world". They also ignore the fact that if a visitor finds a site
dysfunctional, they are unlikely to report it and will simply go
elsewhere. The lack of complaints is often held up as evidence that no
one is having difficulty, a further demonstration of the cluelessness
of the author.

The alternative to large, bloated libraries and obese frameworks like
Cappuccino and Qooxdoo are small, concise libraries built to provide
sufficient functionality and no more. That is the line that has been
promoted here for many years, it has never been seriously challenged.
The only opposing argument has been that not everyone has the skill to
develop or collect such a library. But somehow such people *are*
sufficiently skilled to select a library or framework instead.

Go figure.

 

[Garrett Smith]

Perhaps you are reflecting your own fears, as far as I know that has
never been used as justification for criticism of various libraries in
this group.

More to the point is that the publishers of various libraries say that
they remove the various quirks of cross-browser scripting, yet only
appear to do so for a small number of current browsers. Anyone with an
"unsupported" browser may be left unable to access on-line resources
for no reason other than the site developer's choice of development
tools.

A fundamental principle of the WWW is that it provides universal
access to information regardless of user agent or platform. Developing
sites that only work in a small number of browsers is the antithesis
of that ideal.

"Anyone who slaps a 'this page is best viewed with Browser X' label on a
Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network."
-- Tim Berners-Lee in Technology Review, July 1996

It is also very difficult to get library authors to improve their
products - how long did it take jQuery to ditch browser sniffing? How

The initial design was based around browser detection. Later on, it was
retrofitted with feature tests.

Apple, Yahoo, and Google still use browser detection. The IEBlog
mentioned how the content GMail sends to clients varies:

many of the current crop continue to do it? Even the supposed champion
of web devices, Apple, uses browser sniffing on their MobileMe site to
*prevent* access by their own web-enabled products such as iPhone and
iPodTouch. I expect it's because the site is based on a couple of
script libraries (like spoutcore and prototype.js) and is so bloated
that it is unusable on a typical web-enabled phone or similar device.

Massive waste of effort.

All the energy that went into developing those frameworks, yet the
functionality Apple needs is not all that complicated.

There are companies like Sencha with their massive ext.js framework
who are pushing a library for touch devices that is over 200KB
minified. It is full of useless functions like:

isPrimitive : function(v) {
return Ext.isString(v) || Ext.isNumber(v) || Ext.isBoolean(v);
},

...

isNumber : function(v) {
return Object.prototype.toString.apply(v) === '[object
Number]'&& isFinite(v);
},

That returns true for both number objects and primitive numbers.

isString : function(v) {
return Object.prototype.toString.apply(v) === '[object
String]';
},

Returnds true for String objects and string values.

Typical typechecking antipattern stuff.

Of course with Ext, they don't use closures much. If they did, they
could save a private variable as:

var _toString = Object.prototype.toString;
return{
isNumber : function(v) {
_toString.call(v) == "[object Number]";
}
};

so passing a String or Number object to isPrimitive() returns true.

What about null and undefined? They're not primitives to Ext-js
developers or what?

Why are such functions considered necessary at all? In what

Wher type checking functions are used, it is usually indicative of bad
design. Most often, they are used for fake overloading strategies.

circumstance will isNumber or isString be better than using typeof?

Probably the circumstance where the developers get tired of repeating
typeof checks and

Why coerce a primitive to an Object to find out if it's a primitive?

Obviosly coercing an object to a primitive does not tell you if it is a
primitive, and if you don't know what it is, then this function won't
tell you.

Pretty useless and futile, isn't it?

[...]

Javascript libraries and frameworks are promoted as making web
development easier. A consequence of their adoption is bloated, slow
and limited sites that work only for those with the latest and
greatest devices and software and high-speed access to the web. The
developers who use them trumpet the fact that they can knock up a site
in no time at all, forgetting that for a good number of their
prospective visitors the site so produced is dysfunctional. When
alerted to that, they respond that they don't care about 0.1% of
traffic (or some other fictional number), it's not important in "the
real world". They also ignore the fact that if a visitor finds a site
dysfunctional, they are unlikely to report it and will simply go
elsewhere. The lack of complaints is often held up as evidence that no
one is having difficulty, a further demonstration of the cluelessness
of the author.

Right, all the classic arguments. I always get a kick out of the line
"hardly any of our customers use that browser." It would seem obvious
that a user would not return to a site if it didn't work.

That's also what I like about IE9 coming out. I just wish it didn't have
compatibility mode. I really want to see all those badly written sites
break. The easiest way for the companies to learn the consequences of
hiring such "developers" is for the projets to fail. Then they'll start
figuring on different strategies and hire people who know how to develop
cross-browser sites.

The other consequence to javascript libraries is at the other end of the
stick. Self-promotion, hidden in the guise of generosity, often
harmfully imparts bad practices and even lies to a very large number of
unqualified web developers who don't read specs. These guys won't know
when a blog is full of it or if a library he's been told was great
actually isn't.

When these so-called experts censor their blog comments and hide any
correction, they help promote themselves fraudulently. They do this to
fool all of the dummies who won't ever read usenet into believing in
them. In the process, they hurt the web by promoting misconceptions
instead of the truth that it needs. In the worst case, they react
personally, as has happened to me a few times. They may even slander the
correct person's character. It's really easy to do that, too, because we
all know someone who will do anything to try and "win" a fight and call
names, etc. It's a likely and believable characteristic so switching "he
corrected me" to "he insulted me" comes off as believable, especially
from one of those so-called experts.

Library teams tend to involve a lot more marketing than just blogs. They
hire paid designers. Cappucino did. The APE knockoff did, too. jQuery
has even PR team! PR, for code. So much effort goes into marketing and
the result is that it fools all the fools, just as can be expected.

As a user, I've found that reporting UI bugs to a site doesn't go over
well. In many cases, the company will deny the bug and in some cases
they either blame me or take offense. Ironically, such reactions are
about the worst they could possibly do for themselves. The best thing
would be to try and understand what it is that the user was expecting
and where that expectation was not met. Next would be to look into why.
Own your mistakes and get more respect.

It's easy to complain to each other and much more difficult to reach out
to the rest of the web by writing and publishing such things.

There should be no reason for JS Conferences to be full of BS. There
should be no GWT or Google Closure library. There should never ever have
been a Dojo and Ajaxian promoting jQuery is one of the worst things that
they have done for my industry.

Part of why I wrote the code guidelines and code reviews documents is
that people need to see good code reviews on these things.

http://jibbering.com/faq/notes/code-guidelines/
http://jibbering.com/faq/notes/review/

The alternative to large, bloated libraries and obese frameworks like
Cappuccino and Qooxdoo are small, concise libraries built to provide
sufficient functionality and no more. That is the line that has been
promoted here for many years, it has never been seriously challenged.
The only opposing argument has been that not everyone has the skill to
develop or collect such a library. But somehow such people *are*
sufficiently skilled to select a library or framework instead.

Another argument that has been given is that there isn't enough time to
develop a reusable code base.

A good set of reusable abstractions (a library) saves time.

The popular libraries today have such crazy designs that they provide
counter evidence to that argument. Then again, most wouldn't know any
better anyway.

Garrett

 

[Garrett Smith]

Garrett Smith :


That is all nice and good, but should I wait till everybody has caught
up with Google Chrome before I publish things like these?

http://baagoe.com/en/RandomMusings/hash/avalanche.xhtml

No, that's a test page.

There were plenty of sites that failed on Opera 10 beta user agent
string because it had "10" in it and seeing that, determined that the
site cannot work.

Unsupported browser pages were popular in the late 90s. Recently Robert
Sayre made blog post that used some of those old, nostalgic icons.

<http://blog.mozilla.com/rob-sayre/2010/06/04/check-out-these-html5-demos/>

This was in response to the recent example of the Apple "HTML 5" demos,
which turned out to be using browser detection to determine "unsupported
browsers".

It is not a matter of using proprietary extensions - I don't do that
as a rule, although that page is not valid XHTML, since it contains SVG.

It is simply that to the best of my knowledge, no other javascript engine
is fast enough for the task. On my platform (Ubuntu), Firefox nearly
chokes, Opera isn't much better, and I expect IE won't perform well on
Windows, either (I can't test, not being a Microsoft customer). Safari
might be all right, if I understand its workings rightly.

It was fast on Firefox 3.6.3. I'm scared to try IE but I'll try Opera...

No freeze, completed in a few secs. I'm using Windows 7 on a 3yr old
decent laptop.

Garrett

 

[Matěj Cepl]

Dne 22.6.2010 10:49, Johannes Baagoe napsal(a):

Weird. On mine, both Opera 10.01 and Firefox 3.6.3 take a few seconds
not to complete, but simply to display the first snapshot - that is
1 % of completion. Chromium 5.0.375.70 completes in about 20 seconds.

RHEL 6beta, chromium-6.0.417.0-1.20100526svn48276.el6.x86_64
and firefox-3.6.4-7.el6.x86_64 ... firefox is slower (like 2 or 3 times
slower, not worse) but finishes in all dignity.

Matěj

 

[Garrett Smith]

There are multiple problems of different types, including:

1. Algorthm: Some problems are simply solved in the wrong manner,
giving incorrect or inconsistent results

Well yeah, starting with queries are broken. That's like the core of it.
Fixing the query engine requires defining what it should do in the first
place, which brings up the subject of attributes.

2. API: Overloaded functions should be split into multiple functions,
or in many cases just trashed. Complicated API should be simplified.

3. Design: Some of the goals of the core lib are too lofty and cannot
be adequately accomplished, and should be trashed.

I've read where you previously wrote that the issues could be fixed and
improved while still maintaining the same API. That's what they've gone
after, it seems.

4. Syntax: The source is unnecessarily obfuscated and could be much
more readable.

I agree with all of that.

Quite a bit. Nearly as much as DM, I suppose.

Keeping Sizzle as-is sounds like a really bad idea to me.

A large user base is helpful because it brings out many situations and
conditions that could not be predicted or found by a small development
group. Even the best, most experienced js developers can't keep track
of all the browser quirks and bugs out there. If the goal of a js
library is to work well in many environments and situations, it's
great to be exposed to thousands of different contexts that you may
have never thought of. It will make the code more robust.

That sounds right. More people using it in different contexts will find
bugs.

Then again, why's jQuery like it is? jQuery has thousands of users. Look
at the query selector for five seconds. Well, you did, so OK, 10 seconds.

I know that in many things I've built, I thought it worked fine until
a small portion of users complained about something. Then I learned of
a whole new way of thinking, or a whole new context, and I could
further generalize my code.

I see your point. Code reviews help. Using the abstraction more helps.

I can see the motivation to improve on jQuery, I mean, if you can help a
company avoid some of the problems they're having, that's great, right?

As attractive as that might sound at this point, there are design
decisions that should have been avoided from the start. The design of
the query engine, for starters. Some of the fundamental problems, in
particular, the selector engine, cannot very well be fixed.

I see that YUI has copied some of these problems and has added to that
its own problems, sometimes blowing up, other times returning every
element in the document. What sort of low-level abstraction is that?
Does it solve cross browser issues or does it cause them?

Javascript library authors tend to publish things as solutions to "other
peoples'" problems, as sort of "crowd pleasers," rather than creating
abstractions that solve real problems. There is a certain fundamental
joy in publishing something that everybody likes and that's great, but
it can result in a public API and if it's got problems, you're stuck
with them.

Garrett