From: David Mark on 9 Feb 2010 01:26
On Feb 4, 4:04 pm, Andrew Poulos <ap_p...(a)hotmail.com> wrote:
> On 5/02/2010 3:45 AM, Andrea Giammarchi wrote:
> >> Cheers,
> >> -- Scott
> > and which library outperform PureDOM? Aren't we talking about that
> > post with my massive comment inside removed/filtered?
> Under TaskSpeed, on Vista SP 2 with Safari 4.04 "My Library" was faster
> than PureDom - 168 versus 246.
Should be noted that multiple tests must be run and the results
averaged to get a fair representation. I see a lot of posts that
appear to be one-off runs, which may or may not be good indications.
No question that My Library is faster than the "pure" tests in Webkit
though (by a long stretch), even with the unnecessary overhead of the
From: David Mark on 9 Feb 2010 01:40
On Feb 4, 8:33 pm, RobG <rg...(a)iinet.net.au> wrote:
> One of the main claims about libraries is that they smooth over
> browser quirks. It might be interesting to develop a suite of
> "QuirksSpeed" tests of known differences between browsers to determine
> how well each library manages to overcome them. The overall speed is
> likely not that important, quirks accommodated and correctly dealt
> with likely are.
I agree 100%. That is where most of them fail miserably (e.g. jQuery
"punts" on IE quirks mode, none of them handle attributes properly,
etc.) And sniffing the UA string must result in a disqualification.
I'm working on something like that, but I can't find too many that
eschew the UA string. They give up much too easily in the name of
"getting things done" (which translates to "not getting anything done"
From: jdalton on 9 Feb 2010 14:16
> Other libraries unit tests are inconsequential at this stage.
They still cover bugs and browser issues that your library fails to
> Don't be stupid.
> I've submitted lots of bug reports to the other
> libraries. They are hesitant to change anything as
> they don't seem to understand anything they have done
Reporting bugs is good. They (Dojo) will fix them on their timeline
not yours. Twitter spamming them won't help.
> That's not a bug. There's no crutch for the IE
Again, the tests show you have bugs in lots of areas.
> No, I don't have the problem at all. The QSA add-on is not needed as
> the library is certainly fast enough without it.
Other's Up-to-date CSS engines beat yours, in speed and compatibility,
with or without QSA.
> I don't want you to report bugs to me, nor have I asked you to. I
> don't need your help. Is that clear enough?
> (particularly TaskSpeed,
> where my optimized-for-conciseness tests beat the "baseline" PureDom
If your tests are beating PureDom you A) have done your tests
incorrectly or B) there is a problem with PureDom.
> Have you read _anything_ I've written?
Unfortunately I have. Your writings are mostly long multi-post/page
rants where you reply to yourself or aliases. Repeat the same tired
arguments over and over again, sprinkle in some name calling/insults,
and you have a classic David Mark post.
> And failing?
Yes, your library has bugs in many browsers and versions of browsers.
So many, in fact, visitors to your g-group, who seem to be relatively
new to JS, point them out over and over again.
> They've long since been updated. And what business is it of yours?
> I still contend the old speed tests are far more telling than comparing
> QSA results. ;)
> Not really. 90% of the SlickSpeed tests take 0ms in the environments
You should try a modified form of SlickSpeed that test max executions
per ms, instead of 3 or so calls per test. This gives a more accurate
indication of performance. You will find that your library is actually
one of the slowest. Example: http://davidmissedthemark.com/slickspeed/
> No reluctance at all. I don't need to worry about unit tests written
> by others at the time.
Again, you are missing several basic bug fixes/browser issues because
you refuse to look at others tests.
From: David Mark on 9 Feb 2010 14:49
On Feb 9, 2:16 pm, jdalton <john.david.dal...(a)gmail.com> wrote:
> Hi David,
> > Other libraries unit tests are inconsequential at this stage.
> They still cover bugs and browser issues that your library fails to
You have a very child-like view of this. If I decide (as I did) to
_not_ allow bizarre markup (e.g. names and ID's that are the same for
different elements), that is my design choice. I want the developer
to know they are screwing up in that case. Other libraries took a
different tack. That's why it makes little sense to test my design
against their unit tests. Certainly you can't take the results at
face value. What is reported as an "error" may well be intended by
the designer. Get it?
> > Don't be stupid.
> > I've submitted lots of bug reports to the other
> > libraries. They are hesitant to change anything as
> > they don't seem to understand anything they have done
> Reporting bugs is good. They (Dojo) will fix them on their timeline
> not yours. Twitter spamming them won't help.
You aren't following (and are clearly out of that loop). They tried
to fix them and could never get past the understanding stage. I asked
them to define what attr does and they said "it does what it does in
FF". There's no hope with that sort of thinking. The _owners_ of
Dojo are who asked me to step in and pound these points home, so mind
your own business. ;)
> > That's not a bug. There's no crutch for the IE
> Again, the tests show you have bugs in lots of areas.
See above. What you see as a bug may not be a bug at all. I will
tell you when I have a chance to look at whatever it is you are
looking at. I'm quite familiar with, for example, Dojo's unit tests
and some of them sniff the UA string, so don't look at them as magical
indicators. They are just code and in many cases may not be suitable
for my design, which varies wildly from theirs.
> > No, I don't have the problem at all. The QSA add-on is not needed as
> > the library is certainly fast enough without it.
> Other's Up-to-date CSS engines beat yours, in speed and compatibility,
> with or without QSA.
That's a completely worthless statement. And you know it is patently
untrue if you know the first thing about the DOM (and have read any of
their DOM-level code). They can't even get _IE_ right after ten years
of relative quiet on that front. And IE8 is out of the question
(that's when things predictably went from bad to impossible).
> > I don't want you to report bugs to me, nor have I asked you to. I
> > don't need your help. Is that clear enough?
> > (particularly TaskSpeed,
> > where my optimized-for-conciseness tests beat the "baseline" PureDom
> > handily).
> If your tests are beating PureDom you A) have done your tests
> incorrectly or B) there is a problem with PureDom.
B. PureDom is just a script and it is clearly not optimal. Not only
that, but the various test functions for each library are apples and
oranges. So don't look at those tests as magic either.
> > Have you read _anything_ I've written?
> Unfortunately I have. Your writings are mostly long multi-post/page
> rants where you reply to yourself or aliases.
That's complete fiction. I've got almost 4000 posts here and maybe
two come from a (well-advertised) alias, due to Google's idiotic
posting limits. Please try to pay attention.
> Repeat the same tired
> arguments over and over again, sprinkle in some name calling/insults,
The same tired scripts are out there fumbling and bumbling, year after
year. Perhaps we should all just ignore their seemingly endless
failings? I, for one, am tired of sites that fall apart for no
reason, other than the developers wanted to be "hip" and use a
"cool" (read: dubious) JS library.
> and you have a classic David Mark post.
You talk about nothing but David Mark, with a few generalizations
about CSS selector engines thrown in. That's worthless noise by any
standard in a technical discussion group.
> > And failing?
> Yes, your library has bugs in many browsers and versions of browsers.
Another worthless generalization. All things relative, it's far more
solid than anything out there. It's not even comparable to the
"majors" as they all use the same stupid design that short-circuits
the ability to do progressive enhancement.
> So many, in fact, visitors to your g-group, who seem to be relatively
> new to JS, point them out over and over again.
You really are a disingenuous idiot. Are you referring to the users
who are testing ancient browsers (per my request?) No kidding they
found some gaps in the degradation paths and I fixed them all
virtually instantaneously. Compare that to the "majors" that still
can't get the latest version of IE anywhere near straight and take
forever to move on anything, preferring to argue and whine that they
are being embarassed by all of the "complaints".
> > They've long since been updated. And what business is it of yours?
> > I still contend the old speed tests are far more telling than comparing
> > QSA results. ;)
> > Not really. 90% of the SlickSpeed tests take 0ms in the environments
> You should try a modified form of SlickSpeed that test max executions
> per ms,
I should try a modified version of SlickSpeed? Why?
> instead of 3 or so calls per test. This gives a more accurate
> indication of performance.
In what sense?
> You will find that your library is actually
> one of the slowest. > > Example:http://davidmissedthemark.com/slickspeed/
According to whatever nonsensical theory you have come up with about
CSS selector engines (which are a stupid idea to begin with).
I haven't tried your link. Is that a joke, or did you really create a
tribute page? You've clearly got too much time on your hands (and a
fixation on me for some reason). Good luck with it!
> > No reluctance at all. I don't need to worry about unit tests written
> > by others at the time.
> Again, you are missing several basic bug fixes/browser issues because
> you refuse to look at others tests.
Again, see above.
From: David Mark on 9 Feb 2010 15:20
On Feb 9, 2:16 pm, jdalton <john.david.dal...(a)gmail.com> wrote:
> You should try a modified form of SlickSpeed that test max executions
> per ms, instead of 3 or so calls per test. This gives a more accurate
> indication of performance. You will find that your library is actually
> one of the slowest. Example:http://davidmissedthemark.com/slickspeed/
As I expected, you have no idea what you are talking about.
From your twitter account:-
"mylib-domready.js will fail if inline script/html comment has text `</
body>` or if the output buffer is flushed"
Nonsense. If you knew anything, you would know that the test for "</
body>" is superfluous. It doesn't do anything and will be removed
whenever I feel like it. And I've advised anyone who has asked (here)
not to use that add-on as I don't believe it is a good idea (in any
"mylib.js returns wrong for`Array.prototype.x=(a=).x=1;
isOwnProperty(a,'x')` and `isOwnProperty(a,'nonexistant')"
That's been answered too (somebody brought it up in my forum). It's
not _wrong_ as the function is not designed to deal with such ill-
advised prototype augumentations. About the worst thing you could say
is my documentation isn't specific enough about such things (as I've
admitted many times here).
"mylib.js API.every, API.filter, API.map, API.push, & API.some don't
follow spec causing cross-browser inconsistencies"
API.push doesn't use the native Array.prototype.push, so throw that
one out. And, yeah, I really should document (the previously
mentioned) cases where the deviations occur with the others (I am well
aware of them). Or maybe I will go ahead and put the extra code in to
handle cases that are basically academic (e.g. undefined values are
skipped due to my purposeful avoidance of the - in - operator).
"A is for Awkward. mylib.js API.setAttribute erases element event
observers when name/type attributes are set in IE."
As mentioned, and discussed here dating back two years, changing the
type and/or name is a novelty (came up on discussing INPUT elements
and the IE bug related to DOM collections). And it's laughable that
you would bring up attributes in IE. The others are completely off
the map when it comes to those. Have a look at what jQuery, YUI,
Dojo, etc. do. Now those are issues that will actually come up (and
for a lot more than two attributes). ;)
And I contend that it does not erase "observers" that were set with My
Library. I am quite sure I will remove that novelty altogether when I
have a chance, which will make this a moot point.
"mylib.js API.getElementSizeStyle may resize elements to 0,0 for
browsers that don't compute style of hidden elements"
Complete and utter nonsense. It's the only solution out there that
deals with variations in box models (e.g. IE quirks mode) and it
certainly does not resize elements to 0,0 as you suggest. Also, I am
sure you meant elements with display style of "none", not "hidden"
elements. Get your terms straight. ;)
"mylib.js attempts to support IE4 (~13yrs old) but fails to support
Safari 2 (~5yrs old) in API.getDocumentWindow"
I've never "attempted" to support IE4, or mentioned virtually anything
about it (other than I can't get it to run in XP). Where do you get
And if getDocumentWindow is unfeasible in the current environment
(whatever it may be), it is "pruned" from the API, along with anything
that relies on it. The others just present the same static API and
allow the calling app to blunder into an exception. Get it?
"mylib.js API.addScript called in the HEAD elem throw an `Operation
Aborted` error in IE6 when a page has a BASE"
You really like the novelties, huh? That's also a purely academic
exercise (and based on Randy Webb's tireless work on the subject). If
IE6 throws an exception when a BASE element is present, it is a bug in
IE6 that should be documented (by both MS and myself). Thanks!
Hey, you've got a friend! But just look at him. :(
"mylib.js css selector engine, getEBCS(), fails a massive amount of
Prototype unit tests"
We've been over that. Using another script's tests agsinst my design
is ludicrous. Taking the results of such a tests at face value is
completely disingenuous. I will evaluate the results when I have
time. Thanks for your concern (but not your ill-gotten conclusions).
"mylib.js API.getComputedStyle converts pt & em units to px but fails
to do so for inch & cm units in IE"
Another novelty! That whole hack is just begging to be removed.
Realize I wrote most of this stuff over two years ago (and, as
mentioned repeatedly, I was laboring under some misconceptions at the
"mylib.js getEBCS() fails tons of jQuery tests on one & bombs the
There you go again. See above.
"mylib.js API.getEBCS fails ~650 Dojo, YUI, Google Closure & Slick
Parse error. :)
Nice try, but beetle-browed babbling from an obviously ignorant nitwit
isn't helping anything. Thanks for the one or two (possibly)
legitimate bugs you have reported so far. :)