jQuery vs. My Library
David Mark
dispel some misunderstandings.
First off, there's no rationalizing or apologizing for jQuery. Twist it
around any way you like, but there's no justification for such a failure
(or series of failures to accurate). Second, it doesn't make the
slightest difference how many rubes got caught up in it over the past
few years (the operative word is "past"). Third, don't believe
_anything_ you read on that miserable Ajaxian site. One of their
editors is an "evangelist" for jQuery. :(
The main point of the post seemed to be that jQuery was "concise"
because it was somehow designed to be that way (rather than full of
random goofs). Of course, its tangled up, interdependent mess of an API
is not any more concise than the optional layer offered with My Library.
Some random samples from a test page:-
E().loadHtml('<div><strong>This is a
test</strong></div>').appendTo(document.body);
Q('div:first-child').show().setOpacity(0.5);
myEl = E('#myid');
myEl.onHelp(function() { alert('test1') }).onContextClick(function() {
alert('test2') });
html = myEl.htmlOuter();
Personally, I don't care for such "chained" gobbledygook, but there it
is. No more or less concise than jQuery (or the like), detachable,
readable (under the hood too) and easily extensible. The various
globals (e.g. E, Q, D, W) are actually constructors, which allows for
leveraging all of the wonderful OO features included in all ES
implementations (see F and I for examples). jQuery has a $ function
that returns a new jQuery object. :(
So more "concise" code and a more "elegant" API is complete bullshit.
(and that's usually the main argument).
Then there is the question of why jQuery fucks up so much on basic
operations. For instance, if you want to measure the height of an
element, it is likely because you want to adjust that height and put it
back. Do I even need to say any more about that at this point? The
"designers" of jQuery didn't make some conscious decision to fuck that
up. They just fucked it up (and gained nothing in the process). End of
story on the "it's flawed but there's a reason and it really helps"
theory. JFTR, when it comes to sizing and positioning elements, there's
nothing close to My Library, which doesn't care what box model you use
at all (you can even mix them in one document). So night and day there.
Then there is the fact that the sorts of mistakes made by the jQuery
authors (that sit uncorrected for years) indicate gross incompetence.
How do you fuck up reading/writing/removing attributes? Isn't that the
most basic low-level operation and shouldn't there be all sorts of tests
to prevent regressions? Well, it is and they don't have tests because
they don't understand what they are testing.
All the more laughable given Resig's infamous "you don't understand
test-driven development" retort to a review from two years back. He
doesn't understand... anything at all it seems. Years later, his
attribute-handling is still all fucked up and after wasting days arguing
about it, they decided not to fix it at all (nobody really understood
what was wrong). They didn't fix the height/width stuff either. If you
can't read and write documents (not to mention measure elements), you
can't create widgets on top of them (at least not good widgets) and you
sure as hell can't _query_ them with any degree of consistency.
Obviously, as I invented the feature test for broken attributes, My
Library has a much better handle on attributes. ;)
So, jQuery is just a boondoggle. It's not that they designed it to deal
with "certain cases" instead of "all cases". They just fucked up
randomly and are consistently surprised by what it does (not a good sign).
On the other hand, after spending a week testing, I am pleased to
announce that Cinsoft supports My Library in the following browsers:
All of them.
But seriously, we've tested successfully in:-
IE 5-8
FF 1-3.5
Safari 2-4
Opera 5-10
Netscape 3-9
All modes and virtually all platforms with few issues to report (and
most of those fixed immediately).
And yes, there's a growing community of people who are tired of using
lousy browser scripts and putting up with authors who can't fix
anything. They are helping to test in ancient browsers because it helps
to illuminate problems that could show up in other lesser browsers (e.g.
mobile devices). It's not so that people can use NN4.7 (though they
certainly can if they want).
As for size, AIUI, the "new" jQuery is 70K minified. Well, the full
build of My Libary, which is equivelent to jQuery plus dozens of
plug-ins is (and always has been) 139K minified. Yes, it is the same
size with "support" for all of those ancient browsers (quotes indicate
there's nothing in there specific to any of them) as before those were
even attempted. So much for the "trying to do everything" bloating theory.
And take a guess which is faster. Rather, don't guess but try the the
Speed Test. The "do everything" cross-browser script that doesn't need
dozens of dubious plug-ins is much faster than the "optimized" (more
like lobotomized) script. And not just at queries either; it's much
faster at everything, which is crucial for support handheld devices, old
PC's, etc. Of course, everything out there is faster than jQuery. This
latest release claims something about a 3X increase in something. It's
likely still behind everyone else, but I see brain-washed rubes cheering
about the "breakthrough" anyway. And speaking of the rest (e.g. YUI,
Dojo, Prototype), they are relatively slow as well. They all made the
same mistake (too much over-engineered and inappropriate bullshit
bogging them down).
Must come as quite a shock to those who spent years compiling browser
sniffs, explaining all the while that to be truly cross-browser would
result in really slow, bloated code. ;)
And, of course, the whole thing is modular to a fault, whereas jQuery is
just an inorganic lump that must always be replaced wholesale.
Questions?
Helbrax
I'm not a javascript guru by any means(recent posts will probably
demonstrate that). However, I am getting a pretty good handle on the
language. I've tried all of the "big boy" libraries in the past. It
didn't take me long to abandon all of them.
I abandoned prototype.js because they were using Object.prototype.
WTF? I *think* the eventually coded around that, but I'm sure they
replaced it with something worse. Also, why use the name prototype?
Why not just name it "if" or "function"(or "!function")? :P
Dojo was slow, and usually the main page of the website would crash
the browser. Junk.
jQuery looked appealing at first, until I tried it out. After I coded
a few test cases, I looked back and had absolutely no idea what any of
the code meant. It was also twice the size as if I had done it
normally. It also didn't work in one of the browsers I tested it in
(my hand code worked fine).
After having to include/import the 13 .js file from the YUI framework
just to get a simple AJAX example working I gave up.
I would be more than happy to give My Library a try. Even if it's
only half as good as you say it is, that would be far greater than any
of the other frameworks perform(despite their claims otherwise).
What license is it under? I remember seeing a discussion about
licensing, but I must have missed the final decision.
Matt Kruse
> The various
> globals (e.g. E, Q, D, W) are actually constructors, which allows for
> leveraging all of the wonderful OO features included in all ES
> implementations (see F and I for examples).
With so many globals, I would suggest giving them full names as well
as the single-letter identifiers. E===Element, etc
Can I do
E("#mydiv .classname").hide(); // multiple elements
with your lib?
What if there are no elements found?
> All the more laughable given Resig's infamous "you don't understand
> test-driven development" retort to a review from two years back.
I would like to see your lib run against jQuery's test suite. Not all
would be expected to pass, of course, since they may look for some
different results.
If you could write some wrapper so that your lib could "plug into" the
tests, that would be cool and make people more comfortable with moving
over.
> But seriously, we've tested successfully in:-
> IE 5-8
> FF 1-3.5
> Safari 2-4
> Opera 5-10
> Netscape 3-9
> All modes and virtually all platforms with few issues to report (and
> most of those fixed immediately).
It would be interesting to see how you support functionality that
simply isn't possible in older browsers. Do you just not do it? If so,
then are they really "supported"?
> And take a guess which is faster. Rather, don't guess but try the the
> Speed Test.
Have you? Will you post the results?
Matt Kruse
David Mark
I'll take your word for that. :) I assume you are not a browser
scripting guru either.
> However, I am getting a pretty good handle on the
> language.
That's good. But understand there is an additional discipline to master
if you plan to write JS for browsers.
> I've tried all of the "big boy" libraries in the past. It
> didn't take me long to abandon all of them.
You are learning. :)
> I abandoned prototype.js because they were using Object.prototype.
Yes, fatal. Took them years to stop doing that. Imagine a million
howling code monkeys "arguing" endlessly about nothing. That's what
these projects are like.
> WTF? I *think* the eventually coded around that, but I'm sure they
> replaced it with something worse.
Probably. Last time I looked at their code (a month ago), I recoiled in
horror. It's the same functions over and over, once for each browser
they've pawed. It's pure insanity that would have been locked up in
2001. Using something like that in 2010 is unthinkable.
> Also, why use the name prototype?
Because they are stupid. ;)
> Why not just name it "if" or "function"(or "!function")? :P
How about "constructor?"
> Dojo was slow, and usually the main page of the website would crash
> the browser. Junk.
You got that straight. And the laughable thing is that they think they
are fast (their speed tests just don't take loading into account).
There's a new Dojo though (that I cleaned and sped up considerable).
They have unearthed it recently (they wouldn't look at it while I was
around for some reason). The one guy ran off to try to rewrite
everything I wrote for the loader on Github (God I hate _that_ site),
but predictably fucked it all up. First thing he did was copy Dojo's
attr, isFunction, isArray, etc. The others over there are now
applauding his "great efforts" and oh God save us. No hope IMO. :(
> jQuery looked appealing at first, until I tried it out.
:)
> After I coded
> a few test cases, I looked back and had absolutely no idea what any of
> the code meant.
Yes, readability is some sort of myth associated with that project.
Debugging is a nightmare with all of that chaining crap too. Why they
are so obsessed with the number of lines is beyond me (it all gets
minified in the end). Stupid. :(
> It was also twice the size as if I had done it
> normally.
But... Write less, do more? That's what the box said. :)
> It also didn't work in one of the browsers I tested it in
> (my hand code worked fine).
Well, that's probably one of the browsers "they don't care about"
(quoting Resig). Why don't you just upgrade?
> After having to include/import the 13 .js file from the YUI framework
> just to get a simple AJAX example working I gave up.
LOL. No shot. They are the worst sort of weasels. All of those
disingenuous graphs about browser grading and GZIP and it turns out the
underlying DOM scripts (where the rubber meets the road) are re-treads
with nails in them. What the hell are they doing over there Crockford?
Did they set out to fuck everything up and leave it that way forever
or was I seeing things?
>
> I would be more than happy to give My Library a try. Even if it's
> only half as good as you say it is, that would be far greater than any
> of the other frameworks perform(despite their claims otherwise).
And I would be more than happy to provide support for it. I estimate it
is at least half as good as I say it is and getting a little better
every day. Make no mistake, it is not perfect. It sat for years with
all sorts of glaring typos and gaps in logic. Apparently nobody was
paying attention as I found and fixed the bulk of them hours after my
return. And the higher up you go in the interfaces, the more likely you
are to encounter incongruities. Overall, it was really more slapped
together (client and server side) than designed. I'm open to changes
and the user base is low, so it's flexible.
Recently I've gotten a few new clients because of the new licensing
deal, so I spend much of my day working with (and occasionally on) the
My Library code now. One is a recovering Dojo user. I get a lot of
inquiries from nervous jQuery shops as well. There's at least one
person in each that sees through the bullshit and realizes that they can
change now or die. The Flash module seems to be particularly popular.
Not surprising as all of the other Flash scripts (especially Adobe's)
are complete shit. And that definitely includes the awful SWFObject,
which creates more problems than it solves.
>
> What license is it under? I remember seeing a discussion about
> licensing, but I must have missed the final decision.
Um, good question. MIT something or other--see the source. Basically,
as long as you don't try to steal it and pass it off as your own, you'll
be alright. ;)
S.T.
>
> Questions?
1. Is it being used *anywhere* right now where code can actually be
seen? Aside from a single lawyer's website with a somewhat uninspiring
look and compressed code, never seen it in the wild to view what the
code usage might look like. Docs look like a very lengthy list of
methods with curious naming pattern -- tough to visualize.
2. Target audience would appear to be experienced JS developers who are
concerned about legacy browsers. Fair representation? Yes, I realize
it's a thousand-fold better than anything currently out there as you're
a thousand-fold better than Resig, the YUI team, etc.... but that aside,
am I on base with the actual target audience?
David Mark
> On Jan 22, 11:34 am, David Mark <dmark.cins...@gmail.com> wrote:
>> The various
>> globals (e.g. E, Q, D, W) are actually constructors, which allows for
>> leveraging all of the wonderful OO features included in all ES
>> implementations (see F and I for examples).
>
> With so many globals, I would suggest giving them full names as well
> as the single-letter identifiers. E===Element, etc
Yeah, I've never been married to those names. Longer names (or aliases)
would be a good idea.
>
> Can I do
> E("#mydiv .classname").hide(); // multiple elements
> with your lib?
Q("#mydiv .classname").show(false);
> What if there are no elements found?
It will dutifully hide no elements.
>
>> All the more laughable given Resig's infamous "you don't understand
>> test-driven development" retort to a review from two years back.
>
> I would like to see your lib run against jQuery's test suite. Not all
> would be expected to pass, of course, since they may look for some
> different results.
I'm adding so many unit tests at the moment that I'll have everything
covered. I'll look at it when I'm done to see if I forgot anything.
Any suite that jQuery passes can hardly be comprehensive. Also, realize
that I did not bother to do every CSS selector. I may well fill in the
blanks in the future. See the Speed Test page to get an idea of what is
supported (obviously, if it is on there, it is supported).
>
> If you could write some wrapper so that your lib could "plug into" the
> tests, that would be cool and make people more comfortable with moving
> over.
Well, it plugs into the SlickSpeed (sp?) because it just looks for a $.
That's the only reason I included that (optional) identifier.
>
>> But seriously, we've tested successfully in:-
>> IE 5-8
>> FF 1-3.5
>> Safari 2-4
>> Opera 5-10
>> Netscape 3-9
>> All modes and virtually all platforms with few issues to report (and
>> most of those fixed immediately).
>
> It would be interesting to see how you support functionality that
> simply isn't possible in older browsers. Do you just not do it? If so,
> then are they really "supported"?
It's very simple. If functionality is impossible, the related features
do not exist in the API. So you start out each app with something like:-
var API;
if (API && API.areFeatures('getEBCS', 'setOpacity')) {
}
Or, if using the OO interface, it gets even simpler:-
var Q;
if (Q && Q.prototype.fadeIn) {
// For sure can query and fade!
}
If you notice, the test page demonstrates the progressive enhancement
capabilities quite well (some might say stunningly--I would).
The current practice is the "bull in a china shop" method (e.g. call
anything and expect anything to happen).
So "supported" in terms of the whole library means that features that
are possible are present and work properly and features that impossible
are not present. That's it. And no, not all of the above are not
perfect in that regard. See the discussion group for details.
>
>> And take a guess which is faster. Rather, don't guess but try the the
>> Speed Test.
>
> Have you? Will you post the results?
>
Huh? The Speed Test on my site. I've ran it in everything from IE8 to
FF1 (and most in between). My Library kills its contemporaries (the
further back you go, the larger the margin). If I add QSA support
(estimated twelve lines), it will trounce all of the latest QSA wrappers
(e.g. Sizzle) as well. And if you mean the TaskSpeed results, yes I
will certainly post them. I'll post plenty more too. Stay tuned...
Ivan Marsh
> Having just read a post about jQuery vs. My Library, I think I need to
> dispel some misunderstandings.
Having just made up a post about jQuery vs. your crappy, unknown, untested
software you will now spam the newsgroups.
--
"All right, all right, if it will make you happy, I will overthrow society."
- Philip J. Fry
David Mark
> David Mark wrote:
>
>> Having just read a post about jQuery vs. My Library, I think I need to
>> dispel some misunderstandings.
>
> Having just made up a post about jQuery vs. your crappy, unknown, untested
> software you will now spam the newsgroups.
>
What are you, stupid? Matt Kruse posted it _here_ today (or late last
night). And no, I'm not posting a link. It's too soon. :)
Helbrax
>That's good. But understand there is an additional discipline to master
if you plan to write JS for browsers.
Agreed. That's my biggest problem right now is that there are so many
inconsistencies among all the browsers, trying to learn all the
pitfalls is daunting. I feel like I'm coming in very late in the
game.
Stevo
> Having just read a post about jQuery vs. My Library, I think I need to
> dispel some misunderstandings.
>
Is it really called "My Library" ?
David Mark
> On 1/22/2010 9:34 AM, David Mark wrote:
>>
>> Questions?
>
> 1. Is it being used *anywhere* right now where code can actually be
> seen?
Oh, hello anon@anon. And of course it is. How could you miss it?!
> Aside from a single lawyer's website with a somewhat uninspiring
> look and compressed code, never seen it in the wild to view what the
> code usage might look like.
An uninspiring look? Or do you mean uninspiring looks? And it's just a
mock-up waiting for some real content (e.g. some custom graphics).
Leave it alone.
And what the hell does the look have to do with the scripting? And what
does that 15K script (uncompressed, but minified) have to do with My
Library. It's like you are watching everything intently but somehow
mixing everything up. Glad you stopped to ask questions. :)
> Docs look like a very lengthy list of
> methods with curious naming pattern -- tough to visualize.
That's the API. And what is curious about names like createElement,
createFlash, getEBI, getEBTN, setOpacity, etc.? As mentioned
repeatedly, there's an OO layer that you can take or leave. Looks a lot
like jQuery too (just makes more sense).
>
> 2. Target audience would appear to be experienced JS developers who are
> concerned about legacy browsers. Fair representation?
No. Legacy browsers is a red herring. The point of testing on as many
lesser browsers as possible is to expose cracks in the feature detection
and testing logic. That's all. You've got to figure that if the entire
build can load and run in NN4.7, as well as IE8, chances are good for
virtually anything else out there (and the future). Really good. ;)
> Yes, I realize
> it's a thousand-fold better than anything currently out there as you're
> a thousand-fold better than Resig, the YUI team, etc....
You said all of that shit, not me. But if you think Resig has anything
on me when it comes to cross-browser scripting (or programming in
general), you are sadly deluded. The YUI "team" is just another million
monkeys as YUI is open source now. Such teams have faired very poorly
in the past when it comes to browser scripting (as one would imagine).
They might fair better at something like Frisbee golf. The list of
failed projects should sound familiar to anyone developing Websites
(probably got one or more on their servers right now).
> but that aside,
> am I on base with the actual target audience?
>
No. Picked off. Audience is anyone who scripts browsers. The most
advanced developers won't need it anyway. ;)
David Mark
Don't panic. The ostensible vanguard is mired down in misconceptions
and the browsers have converged almost completely at this point. These
are the basic rules of browser scripting:-
1. Context
2. Context
3. Context
And add:-
4. Keep everything as simple as possible
Of course, despite the granularity of My Library, it is still somewhat
the antithesis of the above. It's general, general, general and overly
complex for many contexts. As are the rest of them (to a ludicrous degree).
David Mark
Yes it is.
Ivan Marsh
Stupid... no. You do realize everything you post here can be Googled and
read even months after you post it right?
Don't need to elaborate on what I've said when it's all been done for me:
"Someone is critical of a widely used library and at the same time promoting
their own library? Call me cynical, but given the inherent conflict of
interest I'd look for another opinion or 2 before taking their word as the
definitive answer."
Gregor Kofler
Garrett Smith
> On Jan 22, 11:34 am, David Mark <dmark.cins...@gmail.com> wrote:
>> The various
>> globals (e.g. E, Q, D, W) are actually constructors, which allows for
>> leveraging all of the wonderful OO features included in all ES
>> implementations (see F and I for examples).
>
> With so many globals, I would suggest giving them full names as well
> as the single-letter identifiers. E===Element, etc
>
Element.prototype.myFunc = [...]
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
David Mark
> David Mark wrote:
>
>> Ivan Marsh wrote:
>>> David Mark wrote:
>>>
>>>> Having just read a post about jQuery vs. My Library, I think I need to
>>>> dispel some misunderstandings.
>>> Having just made up a post about jQuery vs. your crappy, unknown,
>>> untested software you will now spam the newsgroups.
>> What are you, stupid? Matt Kruse posted it _here_ today (or late last
>> night). And no, I'm not posting a link. It's too soon. :)
>
> Stupid... no.
No? :)
> You do realize everything you post here can be Googled and
> read even months after you post it right?
WHAT?! OMG. But seriously, that's my point. A quick search could have
short-circuited your unfortunately inaccurate post.
>
> Don't need to elaborate on what I've said when it's all been done for me:
Do tell!
>
> "Someone is critical of a widely used library and at the same time promoting
> their own library? Call me cynical, but given the inherent conflict of
> interest I'd look for another opinion or 2 before taking their word as the
> definitive answer."
>
And who said that? Unfortunately (again), I've been saying the same
thing about the "majors" for years and My Library is now free.
Better luck next post!
Stevo
That'll lead to some fun discussions :) Like calling your band "That
Band" and calling your first album "Their First Album". You can imagine
the fun when people go into the record store :)
Scenario:
Guy 1: Did you use jQuery or My Library?
Guy 2: Oh, *you* have a library?
Guy 1: No, why do you ask?
:-)
Good luck with it. It will be amazing to have a library that people on
here actually approve of. Although, when there's a 10 message back and
forth just on what the word consise means, it'll be tough.
David Mark
> Stevo meinte:
>> David Mark wrote:
>>> Having just read a post about jQuery vs. My Library, I think I need to
>>> dispel some misunderstandings.
>>>
>>> Questions?
>>
>> Is it really called "My Library" ?
>
> The name's spot on, isn't it?
>
I like it, but I do keep having to explain it for some reason. :)
For those wondering, the answer is at the bottom of the front page
(headline: Build _Your_ Library). The whole point is that it can be
built to suit. there is a ton more flexibility coming on that front,
including filtering out the XHTML and frames support.
And I suppose it has a dual meaning in that it is truly My Library with
a few small assists (a couple of functions date to the CWR project).
Kangax has been a great help with pointing out silly mistakes and
oversights in the past. Recently others have stepped up to help with
testing, so it is becoming a (sort of) group effort.
I might allow authors to contribute modules as well. I figure I'll use
as much of Stockton's date/time/math stuff as I can wade through, but
there must be other (good) stockpiles out there looking for a home.
Could use a graphics module. Best advice is to start small as I am
going to be picky about what I put in there. ;)
David Mark
> Matt Kruse wrote:
>> On Jan 22, 11:34 am, David Mark <dmark.cins...@gmail.com> wrote:
>>> The various
>>> globals (e.g. E, Q, D, W) are actually constructors, which allows for
>>> leveraging all of the wonderful OO features included in all ES
>>> implementations (see F and I for examples).
>>
>> With so many globals, I would suggest giving them full names as well
>> as the single-letter identifiers. E===Element, etc
>>
> That would conflict with any code that uses:-
>
> Element.prototype.myFunc = [...]
Yes. It will likely end up as MyElement, MyForm, MyImage, MyDocument, etc.
var myEl = MyElement('#test');
David Mark
> David Mark wrote:
>> Stevo wrote:
>>> David Mark wrote:
>>>> Having just read a post about jQuery vs. My Library, I think I need to
>>>> dispel some misunderstandings.
>>>>
>>>> Questions?
>>> Is it really called "My Library" ?
>>
>> Yes it is.
>
> That'll lead to some fun discussions :) Like calling your band "That
> Band" and calling your first album "Their First Album". You can imagine
> the fun when people go into the record store :)
My Library is not available in stores. :)
>
> Scenario:
>
> Guy 1: Did you use jQuery or My Library?
That will be a moot question soon enough.
> Guy 2: Oh, *you* have a library?
> Guy 1: No, why do you ask?
>
> :-)
Yes. Verbally, David Mark's library will suffice (though it perverts
the meaning of the name). ;)
>
> Good luck with it.
Thanks, but I don't believe in luck.
> It will be amazing to have a library that people on
> here actually approve of.
Well, there are different levels of approval. Lets just say that nobody
here will rip it to shreds (or complain about browser compatibility).
And, of course, I'm here to answer or act on any complaints, rather than
off in some fantasy world basking in ignorance.
> Although, when there's a 10 message back and
> forth just on what the word consise means, it'll be tough.
Yes, that was an unfortunate waste of time. :(
Matt Kruse
> > Guy 1: Did you use jQuery or My Library?
> That will be a moot question soon enough.
I agree, though probably in a different way than you.
I'm curious, do you have any predictions? Goals? Time lines? What
exactly are you trying to accomplish and how will you know if you've
achieved it?
Matt Kruse
David Mark
> On Jan 22, 3:02 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>> Guy 1: Did you use jQuery or My Library?
>> That will be a moot question soon enough.
>
> I agree, though probably in a different way than you.
Probably.
>
> I'm curious, do you have any predictions?
The sun will rise tomorrow.
> Goals? Time lines?
What are those?
> What
> exactly are you trying to accomplish and how will you know if you've
> achieved it?
>
I don't know. Do you know why you do everything? The short-term
results has been a couple of new clients. I'm happy with that for the
moment. Destroying jQuery (and everything like it) would be a plus as
well. The world is really better off without such scripts. ;)
S.T.
> An uninspiring look? Or do you mean uninspiring looks? And it's just a
> mock-up waiting for some real content (e.g. some custom graphics).
> Leave it alone.
>
> And what the hell does the look have to do with the scripting? And what
> does that 15K script (uncompressed, but minified) have to do with My
> Library. It's like you are watching everything intently but somehow
> mixing everything up. Glad you stopped to ask questions. :)
My mistake. I thought the code at the bottom of the page was the
compressed library followed by some actual use of the library. Looked
similar in a glance at least. Whatever.
So it's not being used, as best I can tell. That's not an insult to a
young library necessarily, but does make it harder to evaluate and
certainly question whether the bold claims you make have been adequately
vetted.
>> Docs look like a very lengthy list of
>> methods with curious naming pattern -- tough to visualize.
>
> That's the API. And what is curious about names like createElement,
> createFlash, getEBI, getEBTN, setOpacity, etc.? As mentioned
> repeatedly, there's an OO layer that you can take or leave. Looks a lot
> like jQuery too (just makes more sense).
Uh huh... Somehow I'm not shocked you feel you've perfectly nailed the
naming aspect, seeing as how you wrote it.
>>
>> 2. Target audience would appear to be experienced JS developers who are
>> concerned about legacy browsers. Fair representation?
>
> No. Legacy browsers is a red herring. The point of testing on as many
> lesser browsers as possible is to expose cracks in the feature detection
> and testing logic. That's all. You've got to figure that if the entire
> build can load and run in NN4.7, as well as IE8, chances are good for
> virtually anything else out there (and the future). Really good. ;)
Makes some sense.
>> Yes, I realize
>> it's a thousand-fold better than anything currently out there as you're
>> a thousand-fold better than Resig, the YUI team, etc....
>
> You said all of that shit, not me. But if you think Resig has anything
> on me when it comes to cross-browser scripting (or programming in
> general), you are sadly deluded.
You may be right. I don't know and don't really care. I'm now bored with
the rest of your post.
I will say Resig is WAY ahead of you in cross-browser library
development, in the sense that he's done so with widespread adoption and
extraordinarily high user satisfaction while you have yet to do so.
So far you've written a script that apparently passes some test cases.
Your grade in the library venue would be an 'incomplete' so far. The
fact that you believe that by merely releasing a library you've a) now
achieved success and b) will surely win the developer community's heart
if they would only take a few moments to look at it is the reason this
project is presently headed towards failure (or, at least, obscurity).
Here's some free advice, which you'll no doubt ignore or more likely
rant about instead, but I'll offer it anyhow.
If you actually want your library to gain some traction:
1. Figure out your target demographic. I get that you feel it's not
merely the best, but the ONLY solution for a cross-browser DOM library
-- but honestly... it's not. Craft your demos, documentation, community,
etc towards a subset of the development community and speak to them.
Don't try to pull every would-be library user with you. I would
recommend the more experienced JS base. Other subsets will follow if you
can succeed with the first.
2. Promote the library on its merits rather than some net kook bash-fest
on other open source projects that appears to be your present approach.
3. Diplomacy. Related to the above. Get into your frenzies in random CLJ
threads all you want but when it comes to discussing your library, even
if someone bashes it, display unwavering tact. Crazy rants don't inspire
confidence in potential community members.
4. Take criticism better and scale back your ego. Related to the above.
For instance getting featured on Ajaxian was a huge opportunity to reach
a large and targeted audience. If your goal is to actually see the
library used, you getting virtually blacklisted from them was an
enormous blunder.
That's what I'd suggest. Unfortunately I seriously doubt you'll do any
of this and sadly (assuming your library has merit) I'm almost certain
your library will remain in near total obscurity as a result. Maybe I
could beat Kobe Bryant one-on-one in basketball, but I'll never get a
game for anyone to find out. Likewise your library is never going to get
a shot at taking on the "majors" out there because your non-technical
approaches to the library are painful to watch.
David Mark
> On 1/22/2010 12:21 PM, David Mark wrote:
>
>> An uninspiring look? Or do you mean uninspiring looks? And it's just a
>> mock-up waiting for some real content (e.g. some custom graphics).
>> Leave it alone.
>>
>> And what the hell does the look have to do with the scripting? And what
>> does that 15K script (uncompressed, but minified) have to do with My
>> Library. It's like you are watching everything intently but somehow
>> mixing everything up. Glad you stopped to ask questions. :)
>
> My mistake. I thought the code at the bottom of the page was the
> compressed library followed by some actual use of the library. Looked
> similar in a glance at least. Whatever.
Indeed. Doesn't really matter.
>
> So it's not being used, as best I can tell.
By lots of public sites? Not that I know of. But it is being used.
> That's not an insult to a
> young library necessarily, but does make it harder to evaluate and
> certainly question whether the bold claims you make have been adequately
> vetted.
Yes. Of course, there is no such ambiguity with jQuery. Even the
lamest of claims can be blown off as bluster.
>
>>> Docs look like a very lengthy list of
>>> methods with curious naming pattern -- tough to visualize.
>>
>> That's the API. And what is curious about names like createElement,
>> createFlash, getEBI, getEBTN, setOpacity, etc.? As mentioned
>> repeatedly, there's an OO layer that you can take or leave. Looks a lot
>> like jQuery too (just makes more sense).
>
> Uh huh... Somehow I'm not shocked you feel you've perfectly nailed the
> naming aspect, seeing as how you wrote it.
I don't think I've perfectly named anything, but it is hard to imagine
another name for createELement or setOpacity.
>
>>>
>>> 2. Target audience would appear to be experienced JS developers who are
>>> concerned about legacy browsers. Fair representation?
>>
>> No. Legacy browsers is a red herring. The point of testing on as many
>> lesser browsers as possible is to expose cracks in the feature detection
>> and testing logic. That's all. You've got to figure that if the entire
>> build can load and run in NN4.7, as well as IE8, chances are good for
>> virtually anything else out there (and the future). Really good. ;)
>
> Makes some sense.
You have to be ready for about anything these days. It seems like there
is a new browser every other day and people are starting to actually use
them on the go.
>
>>> Yes, I realize
>>> it's a thousand-fold better than anything currently out there as you're
>>> a thousand-fold better than Resig, the YUI team, etc....
>>
>> You said all of that shit, not me. But if you think Resig has anything
>> on me when it comes to cross-browser scripting (or programming in
>> general), you are sadly deluded.
>
> You may be right. I don't know and don't really care. I'm now bored with
> the rest of your post.
I am very sorry to hear that. Your entertainment is paramount, of
course. :)
>
> I will say Resig is WAY ahead of you in cross-browser library
> development, in the sense that he's done so with widespread adoption and
> extraordinarily high user satisfaction while you have yet to do so.
Um, that's cross-browser library _marketing_. And his users
satisfaction is unmeasurable, but I'll generalize and say it is in the
toilet.
>
> So far you've written a script that apparently passes some test cases.
There's a ringing endorsement.
> Your grade in the library venue would be an 'incomplete' so far.
In other words, I haven't marketing a free library. I likely never
will. Suddenly people are discovering it, so I am accommodating them.
I always said I would if there were interest. I never set out to beat
people over the head with it as I'm not in the business of selling free
libraries (I'm in the business of selling very dear consulting).
> The
> fact that you believe that by merely releasing a library you've a) now
> achieved success and b) will surely win the developer community's heart
> if they would only take a few moments to look at it is the reason this
> project is presently headed towards failure (or, at least, obscurity).
Where do you get this stuff? Did I say any of that? And I hardly think
it can be a considered a failure compared to the futility that has come
before it. Not much chance of obscurity though. That ship has sailed. ;)
>
> Here's some free advice, which you'll no doubt ignore or more likely
> rant about instead, but I'll offer it anyhow.
Oh brother. Thanks so much for the charity.
>
> If you actually want your library to gain some traction:
>
> 1. Figure out your target demographic. I get that you feel it's not
> merely the best, but the ONLY solution for a cross-browser DOM library
> -- but honestly... it's not.
No, really. At present, it is the only comprehensive JS framework out
there that eschews 1990's era browser sniffing. The others are buried
in it (and soon to be buried with it). Check it out.
> Craft your demos, documentation, community,
> etc towards a subset of the development community and speak to them.
I do need to get some volunteers to work on the documentation as I am
too busy at the moment. That's the biggest weakness.
> Don't try to pull every would-be library user with you.
I'm not. Other than those who pay for my consulting services, I
couldn't care less what anybody uses (it's their funeral).
> I would
> recommend the more experienced JS base. Other subsets will follow if you
> can succeed with the first.
It seems too much like a strategy to me. I prefer chaos. ;)
>
> 2. Promote the library on its merits rather than some net kook bash-fest
> on other open source projects that appears to be your present approach.
No, that's your idiotic interpretation of my posts criticizing your
favorite blob of browser scripting (jQuery wasn't it?)
>
> 3. Diplomacy. Related to the above. Get into your frenzies in random CLJ
> threads all you want but when it comes to discussing your library, even
> if someone bashes it, display unwavering tact. Crazy rants don't inspire
> confidence in potential community members.
Apparently you've never been to my community.
>
> 4. Take criticism better and scale back your ego. Related to the above.
What criticism? I'm usually the one dishing it out. Do you have any
examples where I reacted badly to criticism?
> For instance getting featured on Ajaxian was a huge opportunity to reach
> a large and targeted audience.
Oh, alas. And now I've muffed it forever. Get real. :)
> If your goal is to actually see the
> library used, you getting virtually blacklisted from them was an
> enormous blunder.
You are projecting some sort of power onto those two clods that they
don't have. See how they took the bait and announced they weren't
publishing the article for... spite? LOL. Any credibility they might
have had flew out the window at that point (as I knew it would). One of
their editors is a jQuery "evangelist" as well, so they really have no
credibility at all as journalists. Anyone who thinks they do is too
stupid for words (at least for mine).
>
> That's what I'd suggest. Unfortunately I seriously doubt you'll do any
> of this and sadly (assuming your library has merit) I'm almost certain
> your library will remain in near total obscurity as a result.
I thought you said it was headed towards obscurity. Here;s a thought.
It can't be obscure when everyone is talking about it. ;)
> Maybe I
> could beat Kobe Bryant one-on-one in basketball, but I'll never get a
> game for anyone to find out.
I think it's a safe assumption he'd school you.
> Likewise your library is never going to get
> a shot at taking on the "majors" out there because your non-technical
> approaches to the library are painful to watch.
Non-technical? Is Ajaxian supposed to be technical in some way? Are
the jQuery people technical people? And if it pains you, why are you
watching?
Scott Sauyet
> Matt Kruse wrote:
>>> And take a guess which is faster. Rather, don't guess but try the the
>>> Speed Test.
>
>> Have you? Will you post the results?
>
> Huh? The Speed Test on my site. I've ran it in everything from IE8 to
> FF1 (and most in between). My Library kills its contemporaries (the
> further back you go, the larger the margin).
Are you referring to this?:
http://www.cinsoft.net/mylib-testspeed.html
Because I see several problems with it. If not, could you let us know
what page we should examine?
The first problem I see is that you're comparing an up-to-date version
of My Library with a version of MooTools that came out in November,
2007, a version of Prototype from January, 2008, and a version of
JQuery from May, 2008. That is certainly enough to invalidate the
results in the fast-moving world of JS libraries.
Second of all, although slickspeed has numerous faults, it has
performed at least one useful service to the ecosystem of CSS selector
engines: it has helped to standardize the collection of selectors
libraries are expected to support. Instead of adding support for
these selectors, you simply remove 30% of the tests from the original
slickspeed. Five of those removed selectors cause errors in My
Library in recent versions of Firefox, Opera, and Webkit-based
browsers.
And third, even among those selectors tested, there are two ("*", and
"div + div") for which My Library returns different values in every
browser than do the other libraries. I haven't gone and counted, and
perhaps My Library is correct, but I'd be surprised if each of the
other libraries got it wrong, yet all got identical values.
I made two new versions based on the original slickspeed [1]. The
first one keeps intact the original selectors. It's at
http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/
I used the latest versions of Dojo, JQuery, MooTools, and Prototype
from:
http://code.google.com/apis/ajaxlibs/
and the version of My Library posted here:
http://www.cinsoft.net/mylib-min.js
My results, all on Win XP SP2 (results in milliseconds, low numbers
are better):
Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 56, Proto - 7, MyLib -
30
FF 3.5.7 : Dojo - 58, JQ - 40, Moo - 105, Proto - 58,
MyLib - 75
IE 8 : Dojo - 16, JQ - 16, Moo - 405, Proto - 282,
MyLib - 46
Opera 9.64 : Dojo - 30, JQ - 0, Moo - 94, Proto - 16, MyLib
- 0
Safari 4.0.3 : Dojo - 27, JQ - 25, Moo - 56, Proto - 30,
MyLib - 40
The second version uses the set of selectors from the My Library
page. It's at
http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/
With the same testing configuration, my results were:
Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 23, Proto - 13, MyLib
- 13
FF 3.5.7 : Dojo - 34, JQ - 21, Moo - 81, Proto - 50,
MyLib - 53
IE 8 : Dojo - 0, JQ - 0, Moo - 1063, Proto - 31,
MyLib - 0
Opera 9.64 : Dojo - 0, JQ - 0, Moo - 0, Proto - 16, MyLib -
0
Safari 4.0.3 : Dojo - 23, JQ - 15, Moo - 29, Proto - 22,
MyLib - 21
This hardly looks like a win for My Library.
-- Scott
____________________
[1] http://mootools.net/slickspeed/
David Mark
> On Jan 22, 2:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> Matt Kruse wrote:
>>>> And take a guess which is faster. Rather, don't guess but try the the
>>>> Speed Test.
>>> Have you? Will you post the results?
>> Huh? The Speed Test on my site. I've ran it in everything from IE8 to
>> FF1 (and most in between). My Library kills its contemporaries (the
>> further back you go, the larger the margin).
>
> Are you referring to this?:
>
> http://www.cinsoft.net/mylib-testspeed.html
Yes.
>
> Because I see several problems with it. If not, could you let us know
> what page we should examine?
>
> The first problem I see is that you're comparing an up-to-date version
> of My Library with a version of MooTools that came out in November,
> 2007, a version of Prototype from January, 2008, and a version of
> JQuery from May, 2008.
My Library is from the Fall of 2007 (the query stuff is untouched and
most is a matter of public record). The others are whatever was on the
test page when I copied it. It's not my original work (as noted).
> That is certainly enough to invalidate the
> results in the fast-moving world of JS libraries.
No, it isn't. It may change your interpretation of the results though.
Anything today is going to be a QSA wrapper, so such testing is largely
superfluous. I'll get to that.
>
> Second of all, although slickspeed has numerous faults, it has
> performed at least one useful service to the ecosystem of CSS selector
> engines: it has helped to standardize the collection of selectors
> libraries are expected to support.
Great. It's all a waste of time.
> Instead of adding support for
> these selectors, you simply remove 30% of the tests from the original
> slickspeed.
So what? And I don't think it is 30%. More like ten of about fifty.
I've mentioned this numerous times and it says it right at the top of
the page. I don't feel it is useful to add all of those selectors, but
estimate it would take me an hour or two to do so. If the users really
care, I'll add them. I wrote the whole engine in a weekend. ;)
> Five of those removed selectors cause errors in My
> Library in recent versions of Firefox, Opera, and Webkit-based
> browsers.
They do not cause errors unless you do not follow the instructions. ;)
You aren't allowed to use selectors that aren't supported and the speed
test page is the indicator (as I've mentioned).
>
> And third, even among those selectors tested, there are two ("*", and
> "div + div") for which My Library returns different values in every
> browser than do the other libraries.
That's not true. As noted, in IE, that test page has two extra elements
added by the Audio module. I should use a build without that module, of
course. I just ran it in Chrome (and have run it in virtually every
browser I have). For "*":-
4 ms | 251 found 8 ms | 251 found 2 ms | 251 found 3 ms | 251 found
All 251. That's what I have seen for years in all but IE.
As for the other one:-
2 ms | 242 found 6 ms | 242 found 4 ms | 242 found 3 ms | 242 found
All the same and I've run this on almost everything. So what are you
saying?
> I haven't gone and counted, and
> perhaps My Library is correct, but I'd be surprised if each of the
> other libraries got it wrong, yet all got identical values.
See above.
>
> I made two new versions based on the original slickspeed [1]. The
> first one keeps intact the original selectors. It's at
>
> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/
>
> I used the latest versions of Dojo, JQuery, MooTools, and Prototype
> from:
Okay, good. You are testing the very latest ones.
>
> http://code.google.com/apis/ajaxlibs/
>
> and the version of My Library posted here:
>
> http://www.cinsoft.net/mylib-min.js
Okay.
>
>
> My results, all on Win XP SP2 (results in milliseconds, low numbers
> are better):
Waste of time. They are all using QSA now, which is incompatible with
their "slow lane" branches. It's stupid. But I can add QSA too. It's
just silly to compare apples and oranges at the moment.
>
> Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 56, Proto - 7, MyLib -
> 30
> FF 3.5.7 : Dojo - 58, JQ - 40, Moo - 105, Proto - 58,
> MyLib - 75
> IE 8 : Dojo - 16, JQ - 16, Moo - 405, Proto - 282,
> MyLib - 46
> Opera 9.64 : Dojo - 30, JQ - 0, Moo - 94, Proto - 16, MyLib
> - 0
> Safari 4.0.3 : Dojo - 27, JQ - 25, Moo - 56, Proto - 30,
> MyLib - 40
>
What do these totals even mean if you used selectors unsupported by My
Library?
>
> The second version uses the set of selectors from the My Library
> page. It's at
>
> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/
>
> With the same testing configuration, my results were:
>
> Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 23, Proto - 13, MyLib
> - 13
> FF 3.5.7 : Dojo - 34, JQ - 21, Moo - 81, Proto - 50,
> MyLib - 53
> IE 8 : Dojo - 0, JQ - 0, Moo - 1063, Proto - 31,
> MyLib - 0
> Opera 9.64 : Dojo - 0, JQ - 0, Moo - 0, Proto - 16, MyLib -
> 0
> Safari 4.0.3 : Dojo - 23, JQ - 15, Moo - 29, Proto - 22,
> MyLib - 21
>
>
> This hardly looks like a win for My Library.
>
QSA. You might try IE in compatibility mode to get a level playing
field. But realize that the methods are built into the browsers, so
testing becomes a measure of just the wrappers (where mine will
certainly win again).
Also, you need to run these tests on slower machines. That's where the
results matter anyway. ;) For example, on FF1 on an old XP box, mine
came in thousands ahead of the nearest "competitor". Nobody cares about
a few milliseconds difference on fast machines. It's the phones and
other lesser browsers where speed kills.
I'll run a few tests here on an old machine and post the results...
David Mark
LOL. Here's a result from a relatively slow machine running FF1:-
999 1561 1107 842 358
The result is far more significant than the above (half of which are
completely irrelevant) combined.
David Mark
Running it the latest Chrome, I did notice the two discrepancies.
Clearly this new test page has exposed some bugs. It can't be the same
content as the last one. I bet I'll fix them and they won't come back.
;) I'm not shocked that there are bugs in there. I've never claimed
to have tested the CSS selector queries with any sort of seriousness
(I've stated the exact opposite numerous times here).
Thing is, various people (who know who they are) should have been doing
what you are doing two years ago. That's how this project was supposed
to go. But never mind, no time like the present. I wouldn't bother
testing _unsupported_ selectors though. ;)
90 53 209 87 174
Not bad considering the others are using QSA (except perhaps Mootools,
which is still slower two years later). You have to test the fallback
branches to get an indication of how fast the query implementations are.
In fact, that's why my test page is actually better. It's the older,
slower, QSA-less browsers (and other agents) that will expose efficiency
problems. The new ones using QSA will all act about the same. As mine
is competitive even without QSA, it would seem to be the winner. ;)
RobG
[...]
> Don't need to elaborate on what I've said when it's all been done for me:
>
> "Someone is critical of a widely used library and at the same time promoting
> their own library? Call me cynical, but given the inherent conflict of
> interest I'd look for another opinion or 2 before taking their word as the
> definitive answer."
What is the point of an anonymous quote?
Initial responses to David's criticisms of various libraries were
along the lines of "you can't criticise it if you haven't written a
library". So he released his own.
Now the response is "you're only criticising it to promote your own".
Whatever.
Regarding the quote itself, should anyone adopt a library for a non-
trivial purpose without thoroughly reviewing it against their
requirements and and seeking expert opinions from various sources? And
if that is a recommended strategy for selecting a library, then how is
advising someone to do it a substantial criticism of MyLibrary?
--
Rob
David Mark
They vary wildly from one load to the next:-
144 174 282 82 164
Clearly the results from Chrome are insignificant (as were most of
yours). Look for _major_ differences in the slower machines. That's
what tells the tale.
David Mark
IE8:
109 15 7330 282 218
See what happens? :) You lost Mootools. The other differences are
insignificant.
In compatibility mode:-
344 454 4001 6860 328
Wow. Prototype and Mootools (latest versions) are unusable in IE8
compatibility mode. My Library is the clear winner, but not
significantly faster than the other two. This is an older machine, but
hardly a clunker.
The slower the machine, the older the browsers, the wider the margin.
Running such tests on blazing fast machines is a waste of time as the
differences aren't significant enough to be palpable.
john
> LOL. Here's a result from a relatively slow machine running FF1:-
>
> 999 1561 1107 842 358
>
> The result is far more significant than the above (half of which are
> completely irrelevant) combined.
here are some more results.
<http://www.cinsoft.net/mylib-testspeed.html>
---
54 122 112 38 # Opera 9.64 +
70 121 117 47 # Firefox 3.0.12 +
1 1964 184 2352 # iCab 3.0.5 + *
543 290 191 299 # Internet Explorer 6 -
547 278 187 274 # Internet Explorer 7 -
360 167 135 144 # Internet Explorer 8 -
53 51 1383 1362 # OmniWeb 5.1 + **
940 661 591 611 # Netscape Navigator 6.2.3 -
1147 1451 1303 1377 # iPhone 3.1.2 (7D11)
---
<http://www2.webkit.org/perf/slickspeed/>
---
14529 11520 5827 646 # Firefox 3.6 +
6059 6666 3916 225 # Safari 4.0.4 +
5806 8766 4825 647 # Opera 10.5 pre-alpha -
559 8201 4841 274 # Google Chrome 3.0.195.38 -
:( # Internet Explorer 8 - ***
---
clearly it is unfair to compare results which use a branch for
QuerySelectorAll capable browsers and a different branch for "old" browsers.
---
+ tested on a relatively fast Mac Pro under "typical" (for me anyway)
system load
- tested in a VMWare virtual machine running XP SP3 with just the tested
browser running.
* My Library miscounts `div:last-child` while MooTools miscounts
`div[class!=madeup]`. Prototype errors on everything and jQuery
miscounts everything.
** MooTools and Prototype error on everything. OmniWeb 5.1 uses a forked
version of WebKit from around about January 2005.
*** i think Internet Explorer 8 may have a buggy/incomplete QSA
implementation as it was unable to complete the tests. so i have to
wonder what would happen if something like jQuery were to take the QSA
branch on IE8. errors or a "the script on this page is running too slow"
message i guess. does anyone know if they skip IE8s buggy/incomplete QSA
implementation?
john
> Scott Sauyet wrote:
>> are better):
>
> Waste of time. They are all using QSA now, which is incompatible with
> their "slow lane" branches. It's stupid. But I can add QSA too. It's
> just silly to compare apples and oranges at the moment.
my results confirm the futility of comparing results gathered from QSA
and from the "slow lane" branch. i'd like to see you add QSA to My
Library (and if possible make it aware of the possible quirks in the IE8
implementation of QSA).
David Mark
> On 22 Jan 5:01 PM, David Mark wrote:
>> LOL. Here's a result from a relatively slow machine running FF1:-
>>
>> 999 1561 1107 842 358
>>
>> The result is far more significant than the above (half of which are
>> completely irrelevant) combined.
>
> here are some more results.
>
> <http://www.cinsoft.net/mylib-testspeed.html>
> ---
> 54 122 112 38 # Opera 9.64 +
Cool.
> 70 121 117 47 # Firefox 3.0.12 +
Cool.
> 1 1964 184 2352 # iCab 3.0.5 + *
Ah, two of the others bombed out.
> 543 290 191 299 # Internet Explorer 6 -
That's a horse race. Your VM is much faster than my real (slow) Wintel
boxes.
> 547 278 187 274 # Internet Explorer 7 -
Definitely much faster than my test machines.
> 360 167 135 144 # Internet Explorer 8 -
Here we see the effect of taking the standard getAttribute branch. ;)
And it's actually a horse race with jQuery (which is using QSA).
> 53 51 1383 1362 # OmniWeb 5.1 + **
First two bombed out of course.
> 940 661 591 611 # Netscape Navigator 6.2.3 -
> 1147 1451 1303 1377 # iPhone 3.1.2 (7D11)
Woohoo! We support phones too! And ours actually has a shot at working
on them (due to the feature testing). Normal tasks (e.g. creating
elements) should be light years ahead in terms of speed on slow moving
mobile devices as well.
> ---
>
> <http://www2.webkit.org/perf/slickspeed/>
> ---
> 14529 11520 5827 646 # Firefox 3.6 +
I haven't seen that browser yet. Downloaded it, but haven't installed.
> 6059 6666 3916 225 # Safari 4.0.4 +
That's what I'm talking about. But this second set of tests is tainted
by the unsupported (by My Library) selectors. Personally, I don't
consider four or five scripts agreeing on one page to be a standard
though. I say we shouldn't try to handle every one of them as most apps
don't need them all. :)
> 5806 8766 4825 647 # Opera 10.5 pre-alpha -
> 559 8201 4841 274 # Google Chrome 3.0.195.38 -
> :( # Internet Explorer 8 - ***
> ---
>
> clearly it is unfair to compare results which use a branch for
> QuerySelectorAll capable browsers and a different branch for "old"
> browsers.
Right. I should add the QSA support at some point, but I don't want to
rush into it as I don't see how it will make any palpable difference on
fast machines and I already own all of the old ones (and other lesser
browsers), which don't have QSA anyway. So it can only buy
incompatibility at the moment (something the others picked up in droves).
>
> ---
> + tested on a relatively fast Mac Pro under "typical" (for me anyway)
> system load
>
> - tested in a VMWare virtual machine running XP SP3 with just the tested
> browser running.
>
> * My Library miscounts `div:last-child` while MooTools miscounts
> `div[class!=madeup]`. Prototype errors on everything and jQuery
> miscounts everything.
>
> ** MooTools and Prototype error on everything. OmniWeb 5.1 uses a forked
> version of WebKit from around about January 2005.
>
> *** i think Internet Explorer 8 may have a buggy/incomplete QSA
> implementation as it was unable to complete the tests. so i have to
> wonder what would happen if something like jQuery were to take the QSA
> branch on IE8. errors or a "the script on this page is running too slow"
> message i guess. does anyone know if they skip IE8s buggy/incomplete QSA
> implementation?
I know they don't skip it entirely. More likely they skip it for a
handful of cases where they've observed inconsistencies. Granted,
that's a completely insane approach, but then history always repeats
itself. ;)
There's just no way any of these things should have dove into QSA. But
then these five deluded groups of programmers think they are in some
sort of significant arms race. They think people are too stupid to
realize they are all on QSA now (except in older or lesser browsers
where they are using something incompatible with QSA). These things are
definitely going to die out soon (and I don't necessarily mean because
of My Library).
David Mark
Will do if it turns out to be viable in IE8 (and it will definitely be
optional). I'm going to fix the current branches first though
(combinator problems it appears).
Scott Sauyet
> Scott Sauyet wrote:
>> My results, all on Win XP SP2 (results in milliseconds, low numbers
>> are better):
>
> Waste of time. They are all using QSA now, which is incompatible with
> their "slow lane" branches. It's stupid. But I can add QSA too. It's
> just silly to compare apples and oranges at the moment.
Face it. I called your bluff.
You started this off with the following:
| And take a guess which is faster. Rather, don't guess but try the
| the Speed Test. The "do everything" cross-browser script that
| doesn't need dozens of dubious plug-ins is much faster than the
| "optimized" (more like lobotomized) script.
I went and looked at your speed test, which pairs old versions of the
other libraries with your latest and greatest. When I compare yours
with the recent versions of these scripts, your claims were not
substantiated. Or -- excuse me, maybe I misunderstood -- did you
perhaps mean to imply that My Library is the lobotomized script?
Trying to bury this in post after post of results that don't reinforce
your claims only serves to obfuscate.the issue. If there is something
wrong with these two slickspeed tests, please let us know:
http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/
http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/
Otherwise, go ahead and add your QSA code. Feel free to crow
(briefly, please) about your speed when you've done so and are again
at least in the running for the fastest library.
I'd tell you that it's fine to downplay the meaning of these tests,
but you are the one bringing them up as support for the advantages of
your library.
Bluff called.
-- Scott
john
> john wrote:
>> <http://www2.webkit.org/perf/slickspeed/>
>> [QSA beating the pants off of javascript selector implementations]
>
> That's what I'm talking about. But this second set of tests is tainted
> by the unsupported (by My Library) selectors.
the second set of tests didn't test My Library at all it's:
Prototype 1.6.0.2 / jQuery 1.2.3 / ext 2.0 / QSA
sorry for the confusion.
the point was just to show that QSA is generally an order of magnitude
faster than the fastest javascript implementation; thus results which
don't take that into consideration are useless.
> I say we shouldn't try to handle every one of them as most apps
> don't need them all. :)
agreed; but inevitably some one is going to put up a page such as:
<http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/> and
say "This hardly looks like a win for My Library." while not
understanding what has been tested; and inevitably someone with even
less understanding will see the results and decide jQuery must be the
"best".
that being said i still agree some of those selectors are useless
regardless of the speed at which they run. John Resig apparently said
the same: <http://ejohn.org/blog/selectors-that-people-actually-use/>
although that post seems to contradict itself in a couple of places.
David Mark
> On Jan 22, 5:56 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> Scott Sauyet wrote:
>>> My results, all on Win XP SP2 (results in milliseconds, low numbers
>>> are better):
>> Waste of time. They are all using QSA now, which is incompatible with
>> their "slow lane" branches. It's stupid. But I can add QSA too. It's
>> just silly to compare apples and oranges at the moment.
>
> Face it. I called your bluff.
And you fell right on your face (again). You only tested a fast machine
and you weren't testing the right thing at all. The QSA branches will
always be about the same (and My Library's QSA-less implementation is
almost as fast as they are). How do you like that?
>
> You started this off with the following:
Oh here we go with the time-wasting. :)
>
> | And take a guess which is faster. Rather, don't guess but try the
> | the Speed Test. The "do everything" cross-browser script that
> | doesn't need dozens of dubious plug-ins is much faster than the
> | "optimized" (more like lobotomized) script.
>
> I went and looked at your speed test, which pairs old versions of the
> other libraries with your latest and greatest.
Which only makes sense as it's an old test and My Library's query module
was written two years ago. ;) Also, it makes no sense to compare QSA
to DOM traversal. Think.
> When I compare yours
> with the recent versions of these scripts, your claims were not
> substantiated.
Sure they were. Keep reading all the way to the end of the thread.
Mine is way the hell faster where it matters (and competitive enough
where it doesn't, even without QSA). Your tests proved me 100% correct.
> Or -- excuse me, maybe I misunderstood -- did you
> perhaps mean to imply that My Library is the lobotomized script?
Obviously not. But you might want to consider one the way you are going
here. ;) Did you hear nothing Richard told you about speed tests?
>
> Trying to bury this in post after post of results that don't reinforce
> your claims only serves to obfuscate.the issue.
But the results (which were not all posted by me) _do_ reinforce it in
spades. It wasn't even a horse race (as predicted).
> If there is something
> wrong with these two slickspeed tests, please let us know:
>
> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/
That one is irrelevant as it includes unsupported selectors. I'm
telling you and you are alone. There's no "us". LOL.
> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/
Yeah, that's the one I used. Were the results unclear? Executive
summary: a massacre. I even posted a link to this thread from my forum.
You should stop making a fool of yourself.
>
> Otherwise, go ahead and add your QSA code.
Do you understand that testing QSA like this is pretty much worthless?
> Feel free to crow
> (briefly, please) about your speed when you've done so and are again
> at least in the running for the fastest library.
Ah, you don't get it. For one, QSA is not compatible with all of the
old bullshit, so they all fucked up by rushing into it. For two, QSA is
built into the browsers. There's no point in running repetitive
comparisons on that. For three, on older and lesser browsers (where
speed variations actually matter), the others are orders of magnitude
slower. Nobody will notice the minor variations in the QSA wrappers on
blazing fast machines. Everybody will notice massive slowdowns on older
PC's, phones, etc. Face it, you didn't understand what you were testing
or why (sound familiar?)
>
> I'd tell you that it's fine to downplay the meaning of these tests,
Who's downplaying them? I clearly won by a landslide. Thanks so much! :)
> but you are the one bringing them up as support for the advantages of
> your library.
And you are the one bringing them up now. Thanks again!
>
> Bluff called.
>
You lose. :)
David Mark
> On 22 Jan 7:06 PM, David Mark wrote:
>> john wrote:
>>> <http://www2.webkit.org/perf/slickspeed/>
>>> [QSA beating the pants off of javascript selector implementations]
>>
>> That's what I'm talking about. But this second set of tests is tainted
>> by the unsupported (by My Library) selectors.
>
> the second set of tests didn't test My Library at all it's:
> Prototype 1.6.0.2 / jQuery 1.2.3 / ext 2.0 / QSA
I get it.
>
> sorry for the confusion.
BP.
>
> the point was just to show that QSA is generally an order of magnitude
> faster than the fastest javascript implementation; thus results which
> don't take that into consideration are useless.
Exactly. That's what I told the "bluff-caller" who started this
conversation and still doesn't realize he lost. ;)
>
>> I say we shouldn't try to handle every one of them as most apps
>> don't need them all. :)
>
> agreed; but inevitably some one is going to put up a page such as:
> <http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/> and
> say "This hardly looks like a win for My Library." while not
> understanding what has been tested; and inevitably someone with even
> less understanding will see the results and decide jQuery must be the
> "best".
Oh I know. It's the old Matt Kruse strategy. That's why he put up
tests for selectors that aren't even supported (and it's documented that
they aren't supported). He's trying to make it look like it is broken.
That's also why he only tested (or posted tests from) one fast machine.
He's been told recently that's a losing strategy for speed tests, but
he's not really trying to win (just to come up with results that will
make him look clever). Whatever. :)
I think I refuted his "call" well enough, but I will definitely add QSA
when I get a chance. Still a bunch of nearly identical results on
really fast machines won't really tell the tale. ;)
>
> that being said i still agree some of those selectors are useless
> regardless of the speed at which they run.
No question. What I have in there should be enough for anyone. Granted,
there is a problem with two of them. That bit wasn't BS and I am
grateful for that feedback. As I've mentioned several times over the
years, I don't like CSS selector queries and didn't spend much time on
my implementation (I always figured those who did like them would test
them and help to improve them, but that never happened).
> John Resig apparently said
> the same: <http://ejohn.org/blog/selectors-that-people-actually-use/>
Yes, he eventually punted (smartly in this case).
> although that post seems to contradict itself in a couple of places.
LOL. That's him all over. ;)
RobG
[...]
>
> Trying to bury this in post after post of results that don't reinforce
> your claims only serves to obfuscate.the issue. If there is something
> wrong with these two slickspeed tests, please let us know:
>
> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/
> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/
I ran the tests on iPhone - they seem to work OK, but for some reason
the results are set a huge distance down the page so it takes several
minutes to scroll to them. Can you fix that please? The result tables
appear briefly just after the text, but then are shifted so it appears
to be something to do with the default CSS being altered by script.
--
Rob
john
>> john wrote:
>> sorry for the confusion.
>
> BP.
what does "BP" stand for?
boiling point? badly played? ballpark? best practice? blood pressure?
British Petroleum?
Scott Sauyet
> Scott Sauyet wrote:
>> On Jan 22, 5:56 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> Face it. I called your bluff.
>
> And you fell right on your face (again). You only tested a fast machine
> and you weren't testing the right thing at all. The QSA branches will
> always be about the same (and My Library's QSA-less implementation is
> almost as fast as they are). How do you like that?
You heard it here first, folks! The latest version of David Mark's My
Library runs faster on old machine running browsers nobody uses
against those selectors he deigns to support than do two year old
versions of the more widely-used libraries, at least when he tweaks
the test framework every most one else uses intact! And this is how
he proves that his library is better. I'm finding less and less of a
reason to even try My Library.
Try as hard as you might to deny this, that is what your posts are
claiming.
-- Scott
Scott Sauyet
This is not something I can comfortably fix. The slickspeed tests are
maintained by the MooTools team. The original test is here:
http://mootools.net/slickspeed/
And it has a Subversion repository here:
http://slickspeed.googlecode.com/svn/trunk/
This is easily posted on any PHP-enabled server. It offers a config
file to supply the libraries you want to compare and a text file to
hold your selectors. But if I try to alter even the output format, I
think people used to these slick-speed tests would start to doubt
them. Obviously if you want to do that yourself, it would not be hard
to do, but I'm not sure how others would take your tests.
-- Scott
Scott Sauyet
> Scott Sauyet wrote:
>> Or -- excuse me, maybe I misunderstood -- did you
>> perhaps mean to imply that My Library is the lobotomized script?
>
> Obviously not. But you might want to consider one the way you are going
> here. ;) Did you hear nothing Richard told you about speed tests?
Yes, Richard is right that performance testing on the most powerful
machines is not the right way to do micro-benchmarking. But for
comparisons of libraries, the point is to test their relative speeds
in whatever environments you care about. Perhaps for you, testing
Firefox 1 on an eight-year old machine is relevant. I don't find it
so, myself.
-- Scott
Scott Sauyet
err, "the test framework most everyone else uses intact." :-)
-- Scott
Andrew Poulos
> David Mark wrote:
>
>> Ivan Marsh wrote:
>>> David Mark wrote:
>>>
>>>> Having just read a post about jQuery vs. My Library, I think I need to
>>>> dispel some misunderstandings.
>>
>>>
>>> Having just made up a post about jQuery vs. your crappy, unknown,
>>> untested software you will now spam the newsgroups.
>>
>> What are you, stupid? Matt Kruse posted it _here_ today (or late last
>> night). And no, I'm not posting a link. It's too soon. :)
>
> Stupid... no. You do realize everything you post here can be Googled and
> read even months after you post it right?
>
> Don't need to elaborate on what I've said when it's all been done for me:
>
> "Someone is critical of a widely used library and at the same time promoting
> their own library? Call me cynical, but given the inherent conflict of
> interest I'd look for another opinion or 2 before taking their word as the
> definitive answer."
I won't call you cynical but tell me why won't you refute "facts" have
been presented, or support your claims, rather that post a comment about
a personality? For example, can you point out how "My Library" is
crappy, that is have you found flaws in the scripting within "My Library"?
The valid criticism of so-called "widely used libraries" began long
before any so-called "promotion" of "My Library". I consider that
comment to be disingenuous.
Andrew Poulos
joedev
Thanks for having this discussion :)
Dave,
think you could implement the tests for taskspeed as well?
http://yuilibrary.com/~msweeney/yui-tests/taskspeed/#
could be a good starting point.
Thank,
Joe
David Mark
> Hi,
> Thanks for having this discussion :)
>
> Dave,
> could be a good starting point.
Already on that. Er, at least for something called TaskSpeed. I
thought it was Dojo's thing (Peter Higgins?) Whatever. It will be up
shortly. Results indicate that "pure DOM" is not much faster than My
Library (for reasons that should be obvious). ;)
David Mark
>
> > Scott Sauyet wrote:
> >> On Jan 22, 5:56 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >> Face it. I called your bluff.
>
> > And you fell right on your face (again). You only tested a fast machine
> > and you weren't testing the right thing at all. The QSA branches will
> > always be about the same (and My Library's QSA-less implementation is
> > almost as fast as they are). How do you like that?
>
> You heard it here first, folks! The latest version of David Mark's My
> Library runs faster on old machine running browsers nobody uses
> against those selectors he deigns to support than do two year old
> versions of the more widely-used libraries, at least when he tweaks
> the test framework every most one else uses intact!
No. Get your facts straight. I tested _your_ page which uses the
_latest_ versions of the other libraries. And there's no tweaking.
Unsupported selectors were commented out. That's it. So what are you
saying? That the results on the one fast PC you tested (which were
all very close) trump the massive lead I have in the older PC's,
phones, lesser browsers without QSA, etc.? Which results are more
important to the end-users? ;)
> And this is how
> he proves that his library is better.
Don't be an idiot. SlickSpeed (and the query module itself) is far
less important than compatibility and the speed of the rest of it.
I've never advocated using queries for anything and I still don't.
What does that tell you? ;)
> I'm finding less and less of a
> reason to even try My Library.
You are simply a disingenuous dip-shit.
>
> Try as hard as you might to deny this, that is what your posts are
> claiming.
>
Nope. See above.
David Mark
> On Jan 22, 9:36 pm, RobG <rg...@iinet.net.au> wrote:
>
> > On Jan 23, 11:35 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
> >> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/
> >> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/
>
> > I ran the tests on iPhone - they seem to work OK, but for some reason
> > the results are set a huge distance down the page so it takes several
> > minutes to scroll to them. Can you fix that please? The result tables
> > appear briefly just after the text, but then are shifted so it appears
> > to be something to do with the default CSS being altered by script.
>
> This is not something I can comfortably fix. The slickspeed tests are
> maintained by the MooTools team. The original test is here:
>
> http://mootools.net/slickspeed/
So what? Fix the one you copied to your server.
David Mark
>
> > Scott Sauyet wrote:
> >> Or -- excuse me, maybe I misunderstood -- did you
> >> perhaps mean to imply that My Library is the lobotomized script?
>
> > Obviously not. But you might want to consider one the way you are going
> > here. ;) Did you hear nothing Richard told you about speed tests?
>
> Yes, Richard is right that performance testing on the most powerful
> machines is not the right way to do micro-benchmarking.
And isn't that exactly what you did? See the problem?
> But for
> comparisons of libraries, the point is to test their relative speeds
> in whatever environments you care about.
Uh, no. Let me try to put this kindly. You are an idiot.
They are all about the same in the one fast PC you tested. That's
even with mine _not_ using QSA. So those results don't matter at all
as they won't affect the users.
On the slower PC's and in browsers without QSA, it wasn't even a horse
race. That predicts what mobile devices and other lesser
environements will do.
So it doesn't really matter what _you_ care about, does it? And if
you are so stupid as to think testing QSA wrappers means anything,
then I can't help you. Hint: they'll all be about the same, so the
results don't matter. You have to test what these same libraries will
do everywhere else (e.g. without QSA). That's where the issues
lie. ;)
> Perhaps for you, testing
> Firefox 1 on an eight-year old machine is relevant.]
You still don't get it. I tested it in the latest Chrome on that same
machine (and in IE8 in both modes). I posted those results too, but
perhaps you are cherry-picking your arguments. Another person posted
a whole slew of tests on newer machines (and at least one phone). You
didn't find those results relevant either? You just want to cling to
the idea that in a newer machine with QSA, there is an imperceptible
advantage to the libraries that foolishly rushed to insert QSA. Do
you not understand why they rushed into something stupid for no
palpable benefit at all? Apparently not as that would undermine your
"argument" completely.
> I don't find it
> so, myself.
See above, genius.
David Mark
Don't bother proofing this drivel. I already sank all of your
battleships. Didn't take thirty seconds. Think before you post next
time. ;)
David Mark
Oh, and I fixed those combinator issues last night. I uploaded a new
mylib-min.js just for you. Let me know if you have any more issues
with it. :)
Scott Sauyet
> here are some more results.
>
> <http://www.cinsoft.net/mylib-testspeed.html>
As pointed out, these tests were against two-year old versions of the
other libraries.
-- Scott
David Mark
As pointed out, my results were against _your_ test page, which
included the "lastest and greatest" libraries, which basically added
QSA on top of their old bullshit (without much benefit at all).
Amazing that mine can be competitive (more than fast enough), even
without QSA. Seems like a good reason not to foul things up with QSA,
don't you think?
The above link is a better test as it lets you know differences where
they will matter (e.g. when the latest libraries "thunk" back to DOM
traversal in browsers without built-in queries). Get it?
And I'll add columns for the newer library versions when I get a
chance. We already know the results though. About the same where it
doesn't matter (fast PC's with QSA) and My Library by about a hundred
lengths in anything less than that (which will include phones and
other lesser agents), where it does matter. Now I know you get it, so
don't hold your breath waiting for any major revelations on the Speed
Test page. :)
David Mark
> On 22 Jan 8:09 PM, David Mark wrote:
>>> john wrote:
>>> sorry for the confusion.
>>
>> BP.
>
> what does "BP" stand for?
Typo. NP. :)
Scott Sauyet
> Scott Sauyet wrote:
>> You started this off with the following:
>
> Oh here we go with the time-wasting. :)
Yes, I'm starting to agree that reading your twisting pseudo-logic is
a waste of time.
When I called your bluff, you tried to change the argument. Do you
really think many people care how your code runs on ancient browsers
in FF1? When's the last time you say that browser in your logs?
If you want to say that the difference in performance is mostly a non-
issue, I will certainly agree with you. But you are the one who made
a point of bragging about it, and then pointed your latest library
against much older versions of the competition.
I don't have very old machines laying around to test with. There are
four computers in my house; all are slower than the work machine I
tested with yesterday, but none are dog-slow; they are all between one
and five years old. I've tested three of them, with whatever browsers
I still had on them (the majors, all at recent releases on my machine,
FF, IE8, and OP on my kids's, FF & IE6 on my wife's.) Perhaps we
don't represent average users, but I cover ever browser that has
appeared in the logs of three sites I checked. Although the numbers
were in most cases higher than I posted earlier, the only changes in
relative speeds was that MooTools and Prototype swapped places on my
son's Vista machine in both Safari and FF.
> Also, it makes no sense to compare QSA to DOM traversal. Think.
I have been thinking. I wish you would join me in this endeavor.
You say it makes no sense to compare these. The only way I can make
sense of that is if you're saying that your techniques are so much
better than the previous techniques of the other libraries, and that
users should spend their time contemplating the beauty of your code
instead of using the best tool for the job. Is that what you mean?
If not, why does it not make sense to compare the libraries as they
are built? Instead, you seem to be saying, "Well, you haven't hobbled
yourself to come down to my level; that's obviously not fair!"
> Mine is way the hell faster where it matters (and competitive enough
> where it doesn't, even without QSA). Your tests proved me 100% correct.
So your changing your initial argument from saying that yours is
faster, then? Not it's simply "way the hell faster where it
matters."? Which clearly does not include powerful machines with
recent browsers.
>> Or -- excuse me, maybe I misunderstood -- did you
>> perhaps mean to imply that My Library is the lobotomized script?
>
> Obviously not. But you might want to consider one the way you are going
> here.
No, sorry, there's only room for one lobotomized participant per
discussion, and you've already filled that spot.
>> If there is something
>> wrong with these two slickspeed tests, please let us know:
>
>> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/
>
> That one is irrelevant as it includes unsupported selectors.
So, you think your lack of support is a *good* thing?
>> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/
>
> Yeah, that's the one I used. Were the results unclear? Executive
> summary: a massacre. I even posted a link to this thread from my forum.
> You should stop making a fool of yourself.
Why, though, when you provide such a great role model for how to do
it?
>> I'd tell you that it's fine to downplay the meaning of these tests,
>
> Who's downplaying them? I clearly won by a landslide. Thanks so much! :)
I think you really believe this. Pathetic!
-- Scott
David Mark
> On Jan 22, 8:59 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Scott Sauyet wrote:
> >> You started this off with the following:
>
> > Oh here we go with the time-wasting. :)
>
> Yes, I'm starting to agree that reading your twisting pseudo-logic is
> a waste of time.
No. You are the lone twisted voice of illogic here. What is it you
don't understand?
1. QSA === no benefit, several drawbacks
2. No QSA === good tests where it matters
That's it. ;)
>
> When I called your bluff, you tried to change the argument.
As we have been over (and over), you lost the farm on that bluff. :)
> Do you
> really think many people care how your code runs on ancient browsers
> in FF1?
There you go again. I tested lots of modern browsers too. Did you
forget or are you just an incorrigible, confusing little sod?
> When's the last time you say that browser in your logs?
You just don't get it at all, do you? That was one browser tested.
One. It thrashes them in FF1-3 and is more than competitive (fast
enough) in the QSA-enabled FF3.5. Then there's IE7, IE8, Chrome, etc.
>
> If you want to say that the difference in performance is mostly a non-
> issue, I will certainly agree with you.
It's a huge issue in older (or slower) environments.
> But you are the one who made
> a point of bragging about it, and then pointed your latest library
> against much older versions of the competition.
No. That test page has been up there since the end of 2007. ;) And,
as we've seen, it makes more sense to use that than testing QSA
wrappers (where the differences are insignificant).
>
> I don't have very old machines laying around to test with.
Then run browsers that do _not_ have QSA. Then you can get some
significant results. ;)
> There are
> four computers in my house; all are slower than the work machine I
> tested with yesterday, but none are dog-slow; they are all between one
> and five years old.
Great.
> I've tested three of them, with whatever browsers
> I still had on them (the majors, all at recent releases on my machine,
> FF, IE8, and OP on my kids's, FF & IE6 on my wife's.)
And...?
> Perhaps we
> don't represent average users, but I cover ever browser that has
> appeared in the logs of three sites I checked.
You are still thinking about this in simplistic terms. The point of
testing older browsers is to eliminate QSA from the equation. For
one, you can put IE8 in compatibility mode to accomplish this.
> Although the numbers
> were in most cases higher than I posted earlier, the only changes in
> relative speeds was that MooTools and Prototype swapped places on my
> son's Vista machine in both Safari and FF.
So what?
>
> > Also, it makes no sense to compare QSA to DOM traversal. Think.
>
> I have been thinking. I wish you would join me in this endeavor.
You are the one that is not making sense. AFAICT, I don't _need_ to
add QSA at all at this point. It's more than fast enough without it.
>
> You say it makes no sense to compare these. The only way I can make
> sense of that is if you're saying that your techniques are so much
> better than the previous techniques of the other libraries, and that
> users should spend their time contemplating the beauty of your code
> instead of using the best tool for the job.
You missed by a mile. There's little difference in the fast PC/QSA
results, so they don't really matter. There's a _huge_ difference in
the non-QSA results, which will apply to older PC's with older
browsers, mobile devices, etc. This where speed matters. Now do you
get it?
> Is that what you mean?
No, but it is clear that my slap-dash selector engine from two years
ago is far superior to the "slow lanes" featured in the various
"major" libraries. For those end-users stuck in the slow lane, that's
a positive boon.
> If not, why does it not make sense to compare the libraries as they
> are built?
We've been over this. We _are_ comparing them as they were built
(when testing the latest libraries). One set of results is
significant, one is not.
> Instead, you seem to be saying, "Well, you haven't hobbled
> yourself to come down to my level; that's obviously not fair!"
No, that's not what I'm saying at all. If I add a QSA wrapper on top
of what I have, the insignificant results will converge a bit more.
Who cares? Then there are the significant results, which will never
change.
>
> > Mine is way the hell faster where it matters (and competitive enough
> > where it doesn't, even without QSA). Your tests proved me 100% correct.
>
> So your changing your initial argument from saying that yours is
> faster, then?
It is _much_ faster where it _matters_.
> Not it's simply "way the hell faster where it
> matters."? Which clearly does not include powerful machines with
> recent browsers.
In those, they are all about the same as they are using the browser's
built-in queries. At that point, the results are insignificant
(though it is telling that mine is competitive at that level, even
without QSA).
>
> >> Or -- excuse me, maybe I misunderstood -- did you
> >> perhaps mean to imply that My Library is the lobotomized script?
>
> > Obviously not. But you might want to consider one the way you are going
> > here.
>
> No, sorry, there's only room for one lobotomized participant per
> discussion, and you've already filled that spot.
Twit.
>
> >> If there is something
> >> wrong with these two slickspeed tests, please let us know:
>
> >> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/
>
> > That one is irrelevant as it includes unsupported selectors.
>
> So, you think your lack of support is a *good* thing?
>
> >> http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/
>
> > Yeah, that's the one I used. Were the results unclear? Executive
> > summary: a massacre. I even posted a link to this thread from my forum.
> > You should stop making a fool of yourself.
>
> Why, though, when you provide such a great role model for how to do
> it?
Again.
>
> >> I'd tell you that it's fine to downplay the meaning of these tests,
>
> > Who's downplaying them? I clearly won by a landslide. Thanks so much! :)
>
> I think you really believe this. Pathetic!
Anyone here that doesn't believe it (other than this loser?)
Esa
>
> That'll lead to some fun discussions :) Like calling your band "That
> Band"
Andrew Poulos
> On Jan 22, 8:59 pm, David Mark<dmark.cins...@gmail.com> wrote:
>> Scott Sauyet wrote:
>
>>> You started this off with the following:
>>
>> Oh here we go with the time-wasting. :)
>
> Yes, I'm starting to agree that reading your twisting pseudo-logic is
> a waste of time.
>
> When I called your bluff, you tried to change the argument. Do you
> really think many people care how your code runs on ancient browsers
> in FF1? When's the last time you say that browser in your logs?
IE 6 is 10 years old and my corporate clients still use it, and won't
upgrade any time soon, so ancient browsers are important.
> If you want to say that the difference in performance is mostly a non-
> issue, I will certainly agree with you. But you are the one who made
> a point of bragging about it, and then pointed your latest library
> against much older versions of the competition.
I have colleagues who work for large development houses that *do* use
the "common" js libraries on a day-to-day basis. I learnt very early on
to not ask how their latest js project was going because of the violent
denunciation of whatever bug they had just discovered and were trying to
workaround. (I've been too "afraid" to ask why they don't drop using a
library).
ap
Thomas 'PointedEars' Lahn
> Garrett Smith wrote:
>> Matt Kruse wrote:
>>> With so many globals, I would suggest giving them full names as well
>>> as the single-letter identifiers. E===Element, etc
>>>
>> That would conflict with any code that uses:-
>>
>> Element.prototype.myFunc = [...]
>
> Yes. It will likely end up as MyElement, MyForm, MyImage, MyDocument,
> etc.
>
> var myEl = MyElement('#test');
Or better myLib.getElement(...), as (structurally) suggested before?
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
joedev
wrote:
> David Mark wrote:
> > Garrett Smith wrote:
> >> Matt Kruse wrote:
> >>> With so many globals, I would suggest giving them full names as well
> >>> as the single-letter identifiers. E===Element, etc
>
> >> That would conflict with any code that uses:-
>
> >> Element.prototype.myFunc = [...]
>
> > Yes. It will likely end up as MyElement, MyForm, MyImage, MyDocument,
> > etc.
>
> > var myEl = MyElement('#test');
>
> Or better myLib.getElement(...), as (structurally) suggested before?
>
--Support http://wikileaks.org/
Scott Sauyet
> On 24/01/2010 4:17 AM, Scott Sauyet wrote:
>> When I called your bluff, you tried to change the argument. Do you
>> really think many people care how your code runs on ancient browsers
>> in FF1? When's the last time you say that browser in your logs?
>
> IE 6 is 10 years old and my corporate clients still use it, and won't
> upgrade any time soon, so ancient browsers are important.
Oh yes, I always test with IE6. I did forget to post those results,
because I didn't have it on the machine I used yesterday.
934 1105 1771 3825 1113.
Obviously MooTools falls down a bit and Prototype even more. The rest
were comparable.
>> If you want to say that the difference in performance is mostly a non-
>> issue, I will certainly agree with you. But you are the one who made
>> a point of bragging about it, and then pointed your latest library
>> against much older versions of the competition.
>
> I have colleagues who work for large development houses that *do* use
> the "common" js libraries on a day-to-day basis. I learnt very early on
> to not ask how their latest js project was going because of the violent
> denunciation of whatever bug they had just discovered and were trying to
> workaround. (I've been too "afraid" to ask why they don't drop using a
> library).
I think it's worth testing older libraries in various environments.
What I objected to is the self-aggrandizing manner in which David
Marks promoted the spped of his library, upgrading his library in the
tests to the latest version, but leaving the other libraries with two-
year old versions. You know he didn't expect anyone to notice.
When I post some results he responds by saying that I'm testing the
wrong thing. Either the browsers are too recent or the computer is
too fast. It's nonsense, of course.
-- Scott
-- Scott
Andrew Poulos
> On Jan 23, 4:12 pm, Andrew Poulos<ap_p...@hotmail.com> wrote:
>> On 24/01/2010 4:17 AM, Scott Sauyet wrote:
>>> When I called your bluff, you tried to change the argument. Do you
>>> really think many people care how your code runs on ancient browsers
>>> in FF1? When's the last time you say that browser in your logs?
>>
>> IE 6 is 10 years old and my corporate clients still use it, and won't
>> upgrade any time soon, so ancient browsers are important.
>
> Oh yes, I always test with IE6. I did forget to post those results,
> because I didn't have it on the machine I used yesterday.
>
> 934 1105 1771 3825 1113.
>
> Obviously MooTools falls down a bit and Prototype even more. The rest
> were comparable.
By "falls down a bit" do you mean unsuited to the task?
>>> If you want to say that the difference in performance is mostly a non-
>>> issue, I will certainly agree with you. But you are the one who made
>>> a point of bragging about it, and then pointed your latest library
>>> against much older versions of the competition.
>>
>> I have colleagues who work for large development houses that *do* use
>> the "common" js libraries on a day-to-day basis. I learnt very early on
>> to not ask how their latest js project was going because of the violent
>> denunciation of whatever bug they had just discovered and were trying to
>> workaround. (I've been too "afraid" to ask why they don't drop using a
>> library).
>
> I think it's worth testing older libraries in various environments.
> What I objected to is the self-aggrandizing manner in which David
"self-aggrandizing"? Why do you care about any perceived personality
flaw in someone you most likely will never meet/know? Can't you just
objectively comment on the quality of the work?
> Marks promoted the speed of his library, upgrading his library in the
> tests to the latest version, but leaving the other libraries with two-
> year old versions. You know he didn't expect anyone to notice.
I didn't get the feeling that he didn't expect anyone to notice. Quite
the contrary, that everything was openly laid out before us.
At any rate, haven't the other libraries been around for a "long" time?
So shouldn't even a two year old version be an accurate representation
of the quality of the coding involved?
> When I post some results he responds by saying that I'm testing the
> wrong thing. Either the browsers are too recent or the computer is
> too fast. It's nonsense, of course.
Perhaps you *are* testing the wrong thing. Sorry if I missed it but I
didn't notice your defence of your claim.
To repeat, the people that I know that use the "common" js libraries are
unhappy with all of them.
Andrew Poulos
Faisal Vali
> 4. Take criticism better and scale back your ego. Related to the above.
> For instance getting featured on Ajaxian was a huge opportunity to reach
> a large and targeted audience. If your goal is to actually see the
> library used, you getting virtually blacklisted from them was an
> enormous blunder.
>
While few would dispute that David Mark's discourse should be more
civil, Ajaxian blacklisting his work because of the nature of his
discourse rather than the quality of his work raises far more
disturbing issues about Ajaxian's integrity (to us consumers) than it
could possibly raise about David Mark's attitude. The brunt of the
criticism should be directed towards Ajaxian here. I for one was
looking forward to that article.
Faisal Vali
Radiation Oncology
Loyola
ace
> In fact, that's why my test page is actually better. It's the older,
> slower, QSA-less browsers (and other agents) that will expose efficiency
> problems. The new ones using QSA will all act about the same. As mine
> is competitive even without QSA, it would seem to be the winner. ;)
In other words, the time has run over you.
Feel free to take a shovel and bury yourself somewhere in a backyard.
Scott Sauyet
>> 934 1105 1771 3825 1113.
>
>> Obviously MooTools falls down a bit and Prototype even more. The rest
>> were comparable.
>
> By "falls down a bit" do you mean unsuited to the task?
Possibly. It depends of course on the task. But it takes almost 4
seconds to run 40 queries on a 114KB HTML page. Three of the
libraries only take around 1 second for the same task. So whether
it's good enough for your task is up to you, but you should notice
that the other libraries are significantly faster here.
>> I think it's worth testing older libraries in various environments.
>> What I objected to is the self-aggrandizing manner in which David
>
> "self-aggrandizing"? Why do you care about any perceived personality
> flaw in someone you most likely will never meet/know? Can't you just
> objectively comment on the quality of the work?
I don't give a damn about his personality. But both the style and the
content of his posts get to be noxious. In the few months I've been
reading he makes fairly outrageous claims for his own skill and
regularly castigate the other libraries, claiming that anything the
other libraries get right, they steal from him.
When I go to test the claims he has made, and post my results, I'm met
with insults.
>> Marks promoted the speed of his library, upgrading his library in the
>> tests to the latest version, but leaving the other libraries with two-
>> year old versions. You know he didn't expect anyone to notice.
>
> I didn't get the feeling that he didn't expect anyone to notice. Quite
> the contrary, that everything was openly laid out before us.
But when challenged on the speed advantages he announced, he didn't
post a link to the speed test, nor did he post his results. He merely
makes these very strong, but non-specific claims.
> At any rate, haven't the other libraries been around for a "long" time?
> So shouldn't even a two year old version be an accurate representation
> of the quality of the coding involved?
But it's not the quality of the coding that's under challenge here.
There should definitely be investigations here into that quality, but
what I was presenting was hard numbers that challenged his assertions
about the speed of his library compared to the competitors. Anyone
using such numbers as a factor in deciding which library to use would
expect the comparison to be among reasonably recent, if not the
latest, versions.
>> When I post some results he responds by saying that I'm testing the
>> wrong thing. Either the browsers are too recent or the computer is
>> too fast. It's nonsense, of course.
>
> Perhaps you *are* testing the wrong thing. Sorry if I missed it but I
> didn't notice your defence of your claim.
I'm not sure at this point "testing the wrong thing" has any
significant meaning. I posted the results of my tests of his library
in recent versions of the major browsers on a developer's Window's
machine. In what way could that be the wrong thing to test?
Additional tests on older machines, or other browsers are equally
legitimate. But people looking to use one library or another should
know how they perform in the environments in which they expect the
libraries to run. Perhaps in some locked-down corporate environment,
only IE 6-8 matters. If their application is to run only on iPhones,
presumably testing on those devices is what the user will care about.
For instance, I certainly don't give a damn personally about how any
of the libraries perform in FF1. Maybe David has a good use case for
that. But to try to claim that my tests are useless because they were
performed on a relatively modern machine is ridiculous and self-
serving.
> To repeat, the people that I know that use the "common" js libraries are
> unhappy with all of them.
I think it's great that David is bringing another library into the
fray. Certainly the survivors of the last rounds of the competition
have a great number of flaws, and the competition should help improve
all of them. But if he starts by making over-exaggerated claims about
his library, he is doing everyone (himself included!) a great
disservice.
-- Scott
Scott Sauyet
You're right. It would be nice to see some serious analysis of My
Library, especially outside this small community. And I do think that
Ajaxian was rather small-minded. But it is not that surprising a
reaction. How do you think O'Reilly would react to someone whose
content was being considered as the subject of a new book were to
publicly proclaim, "I think the entire O'Reilly catalog is a crock of
shit!"?
-- Scott
RobG
> On Jan 23, 9:35 pm, Andrew Poulos <ap_p...@hotmail.com> wrote:
> > Perhaps you *are* testing the wrong thing. Sorry if I missed it but I
> > didn't notice your defence of your claim.
>
> I'm not sure at this point "testing the wrong thing" has any
> significant meaning.
Testing is pointless if you don't have any criteria to establish what
the testing means. Speed is usually the last criterion to be
considered, more important ones are:
1. What specific types of sites or application is it best at
developing?
2. Does it provide sufficient functionality to make development easier
or faster?
3. Will it help maintenance?
4. Is the library itself maintained and what is the strategy for
backward compatibility?
5. How tolerant is the library of browsers with missing or incorrectly
implemented features?
6. What existing browsers does the library work in without error?
7. Is the download size acceptable?
8. How good is the documentation?
Each of the above topics likely has several subtopics that look at
architecture and implementation.
> I posted the results of my tests of his library
> in recent versions of the major browsers on a developer's Window's
> machine. In what way could that be the wrong thing to test?
The users of such libraries are visitors to web sites. Testing
performance on a developers machine on a LAN (or with client and
server on the same box) is completely the wrong environment.
> Additional tests on older machines, or other browsers are equally
> legitimate.
You mean essential.
> But people looking to use one library or another should
> know how they perform in the environments in which they expect the
> libraries to run.
Precisely, which is why results from a developer's machine mean very
little.
[...]
> For instance, I certainly don't give a damn personally about how any
> of the libraries perform in FF1. Maybe David has a good use case for
> that.
He has a *reason* and he mentioned it.
> But to try to claim that my tests are useless because they were
> performed on a relatively modern machine is ridiculous and self-
> serving.
The slickspeed tests are designed for one purpose only: to test the
speed of CSS selectors. If the "major libraries" fork into browser-
native QSA branches and don't use their CSS selector engines, then
what is being tested? The tests themselves don't even use a suitable
document, they use a document essentially picked at random.
If the tests were to have any real meaning, the test document should
be specifically designed to test several scenarios for each selector,
such as a group of elements close together, some widely separated in a
shallow DOM and others in a deep and complex DOM. It may be that a
particular library comes up trumps in one type of DOM but not in
another. There should also be edge cases of extremely complex
selectors that may never occur in reality, but test the abiltiy of the
engine to correctly interpret the selector and get the right elements.
Speed may be a very low priority in such cases.
A good starting point might be the ACID 2 or 3 test page.
> > To repeat, the people that I know that use the "common" js libraries are
> > unhappy with all of them.
>
> I think it's great that David is bringing another library into the
> fray. Certainly the survivors of the last rounds of the competition
> have a great number of flaws, and the competition should help improve
> all of them. But if he starts by making over-exaggerated claims about
> his library, he is doing everyone (himself included!) a great
> disservice.
No one's perfect. But subjective criteria like "is the architect a
nice guy" don't rate too highly in my selection criteria. I've worked
with a number of self-opinionated arseholes who were, never-the-less,
very good at their job. I much preferred working with them to the Mr.
Nice Guys who were barely competent but great to talk to over a
beer. :-)
--
Rob
Faisal Vali
> On Jan 24, 11:19 am, Faisal Vali <fais...@gmail.com> wrote:
>
> > On Jan 22, 3:47 pm, "S.T." <a...@anon.com> wrote:
>
> > While few would dispute that David Mark's discourse should be more
> > civil, Ajaxian blacklisting his work because of the nature of his
> > discourse rather than the quality of his work raises far more
> > disturbing issues about Ajaxian's integrity (to us consumers) than it
> > could possibly raise about David Mark's attitude. The brunt of the
> > criticism should be directed towards Ajaxian here. I for one was
> > looking forward to that article.
>
> You're right. It would be nice to see some serious analysis of My
> Library, especially outside this small community. And I do think that
> Ajaxian was rather small-minded. But it is not that surprising a
> reaction.
Agreed.
> How do you think O'Reilly would react to someone whose
> content was being considered as the subject of a new book were to
> publicly proclaim, "I think the entire O'Reilly catalog is a crock of
> shit!"?
Well I would want to respond similarly too (although I hope I
wouldn't ;) - but that would not speak favorably to my professional
integrity (since I would clearly be prioritizing my self-interest over
the interest of those I serve). I would like to think that I would
try and engage the criticizer (lubricant in hand ;) to learn more
about the reason for their dissatisfaction - but that is far easier
said than done.
Eitherway, Ajaxian can obviously do whatever they want; but, as
consumers of Ajaxian's articles, we should be furious about them
putting their own ego over our interests. I understand why we're not
enraged, but I'm not sure that either their or our pettiness really
serves our larger interests.
Has anyone contacted Ajaxian about this?
Andrew Poulos
> On Jan 24, 4:52 pm, Scott Sauyet<scott.sau...@gmail.com> wrote:
>> On Jan 24, 11:19 am, Faisal Vali<fais...@gmail.com> wrote:
>>
>>> On Jan 22, 3:47 pm, "S.T."<a...@anon.com> wrote:
>>
>>> While few would dispute that David Mark's discourse should be more
>>> civil, Ajaxian blacklisting his work because of the nature of his
>>> discourse rather than the quality of his work raises far more
>>> disturbing issues about Ajaxian's integrity (to us consumers) than it
>>> could possibly raise about David Mark's attitude. The brunt of the
>>> criticism should be directed towards Ajaxian here. I for one was
>>> looking forward to that article.
>>
>> You're right. It would be nice to see some serious analysis of My
>> Library, especially outside this small community. And I do think that
>> Ajaxian was rather small-minded. But it is not that surprising a
>> reaction.
>
> Agreed.
>
>> How do you think O'Reilly would react to someone whose
>> content was being considered as the subject of a new book were to
>> shit!"?
>
> Well I would want to respond similarly too (although I hope I
> integrity (since I would clearly be prioritising my self-interest over
> the interest of those I serve). I would like to think that I would
> about the reason for their dissatisfaction - but that is far easier
> said than done.
>
> consumers of Ajaxian's articles, we should be furious about them
> putting their own ego over our interests. I understand why we're not
> enraged, but I'm not sure that either their or our pettiness really
> serves our larger interests.
>
> Has anyone contacted Ajaxian about this?
I think you are working under the misconception that Ajaxian has our
interests at heart.
Andrew Poulos
Scott Sauyet
> On Jan 25, 8:44 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
>
> > On Jan 23, 9:35 pm, Andrew Poulos <ap_p...@hotmail.com> wrote:
> [...]
>>> Perhaps you *are* testing the wrong thing. Sorry if I missed it but I
>>> didn't notice your defence of your claim.
>
>> I'm not sure at this point "testing the wrong thing" has any
>> significant meaning.
>
> Testing is pointless if you don't have any criteria to establish what
> the testing means. Speed is usually the last criterion to be
> considered, more important ones are:
Right, which makes it strange for David to claim that I was testing
the wrong things. How in the world could he *know* what tests are
meaningful for me?
>> I posted the results of my tests of his library
>> in recent versions of the major browsers on a developer's Window's
>> machine. In what way could that be the wrong thing to test?
>
> The users of such libraries are visitors to web sites. Testing
> performance on a developers machine on a LAN (or with client and
> server on the same box) is completely the wrong environment.
Actually, I'm not doing much front-end development right now. But
there's a good chance I'll be doing so soon, for the corporate
intranet at my job. The project will have 50 - 100 users, most on IE8
or FF3.5, but some probably on Chrome. I will try to ensure that it
will work in Opera and Safari as well. I will probably be able to
assume that the users will have Windows XP or Windows 7, and my
machine is the type the company is using to replace old ones. I can't
assume they will be as powerful as mine, but I also don't need to
worry about 500MHz, single-core processors.
>> Additional tests on older machines, or other browsers are equally
>> legitimate.
>
> You mean essential.
Yes, but there are limits to what's worth testing for any particular
user. I'm certainly not expecting this to even look reasonable in
IE3.
>> But people looking to use one library or another should
>> know how they perform in the environments in which they expect the
>> libraries to run.
>
> Precisely, which is why results from a developer's machine mean very
> little.
Unless... :-)
For me ancient processors and FF1 means very little.
> [ ... ]
> The slickspeed tests are designed for one purpose only: to test the
> speed of CSS selectors. If the "major libraries" fork into browser-
> native QSA branches and don't use their CSS selector engines, then
> what is being tested? The tests themselves don't even use a suitable
> document, they use a document essentially picked at random.
>
> If the tests were to have any real meaning, the test document should
> be specifically designed to test several scenarios for each selector,
> such as a group of elements close together, some widely separated in a
> shallow DOM and others in a deep and complex DOM. It may be that a
> particular library comes up trumps in one type of DOM but not in
> another. There should also be edge cases of extremely complex
> selectors that may never occur in reality, but test the abiltiy of the
> engine to correctly interpret the selector and get the right elements.
> Speed may be a very low priority in such cases.
There's a lot to be said for that. But there's also a lot to be said
for a process that weighs the speeds of the selectors depending upon
the likely common usage of each. A test that weighs these equally has
some clear-cut issues:
span.highlight
#myDiv ul div.group ul li:nth-child(7n + 3)
>> I think it's great that David is bringing another library into the
>> fray. Certainly the survivors of the last rounds of the competition
>> have a great number of flaws, and the competition should help improve
>> all of them. But if he starts by making over-exaggerated claims about
>> his library, he is doing everyone (himself included!) a great
>> disservice.
>
> No one's perfect. But subjective criteria like "is the architect a
> nice guy" don't rate too highly in my selection criteria. I've worked
> with a number of self-opinionated arseholes who were, never-the-less,
> very good at their job. I much preferred working with them to the Mr.
> Nice Guys who were barely competent but great to talk to over a
> beer. :-)
Oh, I'd always prefer to work with someone competent but less
likable. However, I would hesitate to commit to using his library in
any production environment until there are people helping support it
that seem willing to admit to their faults and honestly interested in
helping users through their problems. If it's a one-man show, then I
want that one man to be someone whose responses to requests for help,
to suggestions, and to critiques are helpful rather than abusive.
-- Scott
Garrett Smith
Defining "code quality" is a topic that is likely to result in flames.
I did create one unofficial document here:-
http://jibbering.com/faq/notes/review/code-guidelines.html
There was much heated debate regarding the "don't modify objects you
don't own." That document may need to be taken down, actually.
The motivation for the document was bad code reviews. I wanted to
facilitate better code reviews.
Code quality matters. Bugs should be fixed before being pushed to
production, or even given to QA.
Code design and architecture matters, too. Javascript is extremely
flexible and powerful language. It is easy to create tangled messes in
javascript.
>
> I think it's great that David is bringing another library into the
> fray.
David is not alone, he is just the most obstreperous. That's probably
too kind a term to use.
I too am building a library/framework. Features: IoC to create
factories, AOP event system, dom abstraction layer, and some widgets. IT
is all organized into modules. Ther is no query selector because the
cost of using that just isn't worth it at this point. Native QSA might
be a good option in 5 years when support is more widespread, but not for
the time being.
There is a ton of work that needs to be done on it. It is not easy find
good javascript developers who have time to donate on this stuff, so I'm
doing it all myself. Slowly.
If you would like to donate your time provide criticism or feedback to
the the code, I would certainly appreciate that very much. I won't call
you a buffoon for doing that, but I reserve my right challenge the
criticism if I feel it is wrong.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
Scott Sauyet
> Scott Sauyet wrote:
>> I think it's great that David is bringing another library into the
>> fray.
>
> David is not alone, he is just the most obstreperous. That's probably
> too kind a term to use.
But it's much more polite than most that come to my mind!
> I too am building a library/framework. Features: IoC to create
> factories, AOP event system, dom abstraction layer, and some widgets. IT
> is all organized into modules. Ther is no query selector because the
> cost of using that just isn't worth it at this point. Native QSA might
> be a good option in 5 years when support is more widespread, but not for
> the time being.
Yes, I did know about that. No slight intended. I do intend to check
it out. But I also have not seen you present any outrageous claims
for it.
> There is a ton of work that needs to be done on it. It is not easy find
> good javascript developers who have time to donate on this stuff, so I'm
> doing it all myself. Slowly.
>
> If you would like to donate your time provide criticism or feedback to
> the the code, I would certainly appreciate that very much. I won't call
> you a buffoon for doing that, but I reserve my right challenge the
> criticism if I feel it is wrong.
I would like to do so. My time for the next few days is pretty
limited, but I will take a look at it later in the week. And feel
free to call me a buffoon if I act like one! :-)
-- Scott
Matt Kruse
> nice guy" don't rate too highly in my selection criteria.
I think it is important (although perhaps not MOST important) because
it gives a good idea of what kind of adoption the library will have,
whether it will become widely used, what the support/user community
will be like, how the library will respond to criticism, whether it
will take suggestions, etc. And that stuff matters. So I think it's
important to weigh that in with other criteria.
And this is, I think, critical for this library because currently it
has virtually no acceptance, few examples, poor documentation, a bad
web site, no support community, and a bad name. Having an architect
who behaves like a child is just another reason why the library will
be ignored, IMO.
Personally, I don't see "My Library" gaining any acceptance or having
much impact on the scripting library space. But I suspect that
something may rise out of it (perhaps by someone other than DM,
perhaps several people here) and be something influential. That's my
prediction. Regardless of personalities, I think it is important for
anyone who is interested in js and scripting libraries to be informed
about this discussion and to be watching where this goes.
Matt Kruse
Andrew Poulos
> On Jan 24, 6:38 pm, RobG<rg...@iinet.net.au> wrote:
>> No one's perfect. But subjective criteria like "is the architect a
>> nice guy" don't rate too highly in my selection criteria.
>
> I think it is important (although perhaps not MOST important) because
Did you also check the personalities of Bill Gates, Steve Jobs and Linus
Torvald before deciding on an OS?
> it gives a good idea of what kind of adoption the library will have,
> whether it will become widely used, what the support/user community
> will be like, how the library will respond to criticism, whether it
> will take suggestions, etc. And that stuff matters. So I think it's
> important to weigh that in with other criteria.
>
> And this is, I think, critical for this library because currently it
> has virtually no acceptance, few examples, poor documentation, a bad
> web site, no support community, and a bad name. Having an architect
> who behaves like a child is just another reason why the library will
> be ignored, IMO.
>
> Personally, I don't see "My Library" gaining any acceptance or having
> much impact on the scripting library space. But I suspect that
> something may rise out of it (perhaps by someone other than DM,
> perhaps several people here) and be something influential. That's my
> prediction. Regardless of personalities, I think it is important for
> anyone who is interested in js and scripting libraries to be informed
> about this discussion and to be watching where this goes.
I've asked for people to post a defence of the *factual* criticisms that
David Mark has made of various js libraries. So far the postings have
been along the lines of:
- I don't like him
- He's not a nice person
and now
- His library won't get used
Andrew Poulos
Scott Sauyet
> On 25/01/2010 2:43 PM, Matt Kruse wrote:
>
>> On Jan 24, 6:38 pm, RobG<rg...@iinet.net.au> wrote:
>>> No one's perfect. But subjective criteria like "is the architect a
>>> nice guy" don't rate too highly in my selection criteria.
>
>> I think it is important (although perhaps not MOST important) because
>
> Did you also check the personalities of Bill Gates, Steve Jobs and Linus
> Torvald before deciding on an OS?
I rather doubt he did. But I'll bet he knew something about the
support offered by Microsoft, Apple, and the Linux community.
>> it gives a good idea of what kind of adoption the library will have,
>> whether it will become widely used, what the support/user community
>> will be like, how the library will respond to criticism, whether it
>> will take suggestions, etc. And that stuff matters. So I think it's
>> important to weigh that in with other criteria.
> [ ... ]
>> Personally, I don't see "My Library" gaining any acceptance or having
>> much impact on the scripting library space. But I suspect that
>> something may rise out of it (perhaps by someone other than DM,
>> perhaps several people here) and be something influential. That's my
>> prediction. Regardless of personalities, I think it is important for
>> anyone who is interested in js and scripting libraries to be informed
>> about this discussion and to be watching where this goes.
>
> I've asked for people to post a defence of the *factual* criticisms that
> David Mark has made of various js libraries. So far the postings have
> been along the lines of:
> - I don't like him
> - He's not a nice person
> and now
> - His library won't get used
Excuse me, but you seem to have stepped into the wrong discussion
here. I haven't seen anyone trying to defend any other library here,
only discussing My Library and David Mark's promotion of it.
And even the critique of his abrasiveness has been tempered, as Matt
did here, as one consideration among many.
-- Scott
Matt Kruse
> Did you also check the personalities of Bill Gates, Steve Jobs and Linus
> Torvald before deciding on an OS?
That's a bad analogy. If I had an interest in analyzing and predicting
the success of different OS options back at the time those were being
created, then looking at the personality of the people in charge would
certainly have been important. In retrospect, their personalities have
been a very important factor in the overall success.
Often in history, the success of one product or technology over
another has had little to do with the technical and factual qualities
of each, but rather the marketing and branding and people behind them.
There are countless examples.
If a person is going to invest heavily into one technology in terms of
time, money, training, development, support, etc then it's important
to figure out if the technology is going to be widely accepted for
years to come, or obsolete in 6 months. If you were convinced of the
technical superiority of HD-DVD over Blu-Ray, and invested heavily
into that technology because of the technical issues alone, you would
have found yourself in a lot of trouble as the market went the other
way. It is often a better choice to go with the market leader rather
than a technically superior solution that has no support.
> I've asked for people to post a defence of the *factual* criticisms that
> David Mark has made of various js libraries.
Those discussions have been going for years. Most of the time, his
factual criticisms are valid. Sometimes not. Sometimes they are valid
but miss the bigger picture. Opinions differ. But that isn't the point
of this thread or my post.
> So far the postings have
> been along the lines of:
> - I don't like him
> - He's not a nice person
> and now
> - His library won't get used
David is throwing himself out there in a very rude and abrasive
manner, as usual. That's fine. That's who he wants to be. He is
offering up his library as the best library ever and trashing everyone
else. So he is opening himself up to criticism and opinions, and I
think that's what this thread is about.
In discussing whether his library will gain acceptance or make any
real challenge to the "major" libraries, I think his personality and
how he "markets" his product are indeed very important. That's
independent of the quality of the code, but it's still a discussion
that many people here might be interested in. If nothing else, it's
way more interesting than discussing yet again how stupid he thinks
John Resig is.
Matt Kruse
S.T.
> Eitherway, Ajaxian can obviously do whatever they want; but, as
> consumers of Ajaxian's articles, we should be furious about them
> putting their own ego over our interests. I understand why we're not
> enraged, but I'm not sure that either their or our pettiness really
> serves our larger interests.
It seems to me Ajaxian was going to him a favor by doing a write-up,
borderline prematurely, based largely on his criticisms of other
libraries he apparently sends them that perhaps they agreed with to a
degree. Then he made an ass of himself and they yanked the offer.
What is so compelling to-date that Ajaxian should feel compelled to
feature it at this time? It's a gigantic script with no demos, no
documentation (I don't count "appendToHTML() - appends to HTML" as
docs), virtually no community, it's not being used anywhere to even
substitute as a demo and it's entire publicity so far is purely the
result of the author being a troll/net kook.
So far the entirety of 'My Library' is a huge script, a contrived slick
speed test and an author running around making bold claims. I don't
think one can fault Ajaxian for taking a pass. If it pans out to
something actually relevant (that's a big 'if') and Ajaxian ignores
it... then it might be fair to criticize their editorial policies.
Andrew Poulos
So if he'd played nice, would Ajaxian have passed?
Andrew Poulos
D.Campagna
>
> Face it. I called your bluff.
>
> You started this off with the following:
>
> | And take a guess which is faster. Rather, don't guess but try the
> | the Speed Test. The "do everything" cross-browser script that
> | doesn't need dozens of dubious plug-ins is much faster than the
> | "optimized" (more like lobotomized) script.
>
> I went and looked at your speed test, which pairs old versions of the
> other libraries with your latest and greatest. When I compare yours
> with the recent versions of these scripts, your claims were not
> substantiated. Or -- excuse me, maybe I misunderstood -- did you
> perhaps mean to imply that My Library is the lobotomized script?
>
> Trying to bury this in post after post of results that don't reinforce
> your claims only serves to obfuscate.the issue. If there is something
> wrong with these two slickspeed tests, please let us know:
Scott,
thanks for the time you invested in this review.
We all know the way DM tries to promote himself and his work and how he
is used to argue with the unfortunates who try to exchange opinions with
him.
So, no need to waste your time discussing with a person that in fact
probably has never had a genuine exchange of opinions in his life,
conceiving discussions as an exercice of one-way communication and total
distortion of what others say.
I knew the man is somewhat obfuscated by his attitude and his
presumption, but this stupid thing to compare old versions of the major
libraries is so ridicolous I was really laughing while reading.
The entire thing is so pathetic and ridicolous that should never have
been even discussed in a serious technical forum. Strange enough, nobody
here ever noticed such biased tests were in place, even if Mr. Mark
often bragged about the speed of his library et. al.
Sometimes I have the feeling that a lot of people here are very tolerant
to Mr. Mark.
I come back to my habit to lurk this NG; I suppose many other do the
same. I oly wanted to make it clear, I appreciate this thread...
>
> Bluff called.
>
> -- Scott
He'll never become rich with poker, I think :-)
Dan
David Mark
> On 1/24/2010 4:09 PM, Faisal Vali wrote:
>
> > Eitherway, Ajaxian can obviously do whatever they want; but, as
> > consumers of Ajaxian's articles, we should be furious about them
> > putting their own ego over our interests. I understand why we're not
> > enraged, but I'm not sure that either their or our pettiness really
> > serves our larger interests.
>
> It seems to me Ajaxian was going to him a favor by doing a write-up,
> borderline prematurely, based largely on his criticisms of other
> libraries he apparently sends them that perhaps they agreed with to a
> degree.
Are you just making this up? I never sent them anything.
> Then he made an ass of himself and they yanked the offer.
They never made any "offer". They are just a blog that some people
mistake for a news site. In any event, journalists don't offer, they
report.
>
> What is so compelling to-date that Ajaxian should feel compelled to
> feature it at this time?
Are you kidding? It's definitely a game-changer (in every way
conceivable).
> It's a gigantic script with no demos, no
A gigantic script?! It's modular to a fault, with an online builder.
What library are you looking at? You want demos? Try the test page.
I think some people actually miss that.
> documentation (I don't count "appendToHTML() - appends to HTML" as
> docs)
What the hell is appendToHTML? And what does the typical jQuery doc
describe for attr and other low-level functions? About a sentence
(and often inaccurate).
> , virtually no community, it's not being used anywhere to even
> substitute as a demo and it's entire publicity so far is purely the
> result of the author being a troll/net kook.
A troll? What sort of idiotic reasoning led you to that conclusion?
And anyone using jQuery or the like is the kook. ;)
>
> So far the entirety of 'My Library' is a huge script,
That's twice you have called it a "huge script". What are you trying
to say? Where jQuery is monolithic and interdependant, My Library is
modular and interchangeable. So you have no dig with "huge script".
> a contrived slick
> speed test
Contrived? How so?
> and an author running around making bold claims.
Running around? I've been right here for years. And the "claims" are
backed up in spades. Look at the results of the compatibility testing
(see the forum) or either of the two speed tests:-
http://www.cinsoft.net/mylib-testspeed.html
...and _I_ support it, stupid. What do you think about that?
> I don't
> think one can fault Ajaxian for taking a pass.
Taking a pass? Get real.
> If it pans out to
> something actually relevant (that's a big 'if') and Ajaxian ignores
> it... then it might be fair to criticize their editorial policies.
What an imbecile. So I suppose jQuery is "relevant" somehow? Qooxdoo
1.0, the maturation of a framework? That's important? LOL. Diaries
of mad browser sniffers are of no interest to the average business.
Trust me. ;)
David Mark
wrote:
> Scott Sauyet ha scritto:
>
>
>
>
>
> > Face it. I called your bluff.
>
> > You started this off with the following:
>
> > | And take a guess which is faster. Rather, don't guess but try the
> > | the Speed Test. The "do everything" cross-browser script that
> > | doesn't need dozens of dubious plug-ins is much faster than the
> > | "optimized" (more like lobotomized) script.
>
> > I went and looked at your speed test, which pairs old versions of the
> > other libraries with your latest and greatest. When I compare yours
> > with the recent versions of these scripts, your claims were not
> > substantiated. Or -- excuse me, maybe I misunderstood -- did you
> > perhaps mean to imply that My Library is the lobotomized script?
>
> > Trying to bury this in post after post of results that don't reinforce
> > your claims only serves to obfuscate.the issue. If there is something
> > wrong with these two slickspeed tests, please let us know:
>
> Scott,
> thanks for the time you invested in this review.
Review?
> We all know the way DM tries to promote himself and his work and how he
> is used to argue with the unfortunates who try to exchange opinions with
> him.
What does that mean? Seriously.
>
> So, no need to waste your time discussing with a person that in fact
> probably has never had a genuine exchange of opinions in his life,
> conceiving discussions as an exercice of one-way communication and total
> distortion of what others say.
No, more like you are rambling on about nothing. :(
>
> I knew the man is somewhat obfuscated by his attitude and his
> presumption, but this stupid thing to compare old versions of the major
> libraries is so ridicolous I was really laughing while reading.
Then how bad are your reading skills? Go back and re-read it or get
somebody to read it to you. :)
> The entire thing is so pathetic and ridicolous that should never have
> been even discussed in a serious technical forum.
What is pathetic and ridiculous? The two-year-old speed test page
with the two-year-old libraries? It's now been updated with newer
versions. But, as discussed, those tests are nowhere near as
illuminating (despite the fact that My Library beats them handily
too).
> Strange enough, nobody
> here ever noticed such biased tests were in place, even if Mr. Mark
> often bragged about the speed of his library et. al.
Are you insane? That selector test page has sat in the same spot,
unchanged for two years and I never even mentioned it. When I talk
about speed, I am talking about things other than queries.
> Sometimes I have the feeling that a lot of people here are very tolerant
> to Mr. Mark.
What does that mean?
>
> I come back to my habit to lurk this NG; I suppose many other do the
> same. I oly wanted to make it clear, I appreciate this thread...
Too bad you got nothing out of it. :(
>
>
>
> > Bluff called.
>
> > -- Scott
>
> He'll never become rich with poker, I think :-)
>
No, he won't. ;)
David Mark
> On Jan 24, 6:38 pm, RobG <rg...@iinet.net.au> wrote:
>
> > No one's perfect. But subjective criteria like "is the architect a
> > nice guy" don't rate too highly in my selection criteria.
>
> I think it is important (although perhaps not MOST important) because
> it gives a good idea of what kind of adoption the library will have,
Don't be your usual (idiotic) self. Adoption? As in downloading?
What sort of laughable point are you trying to make here? How many
people who use your scripts actually know you?
> whether it will become widely used,
You are blithering again.
> what the support/user community
> will be like, how the library will respond to criticism, whether it
> will take suggestions, etc.
Uh, just visit the forum. ;)
> And that stuff matters. So I think it's
> important to weigh that in with other criteria.
Weigh away. :)
>
> And this is, I think, critical for this library because currently it
> has virtually no acceptance, few examples, poor documentation, a bad
> web site, no support community, and a bad name.
It has plenty of acceptance for something that was first promoted a
month ago. How many users did jQuery have the first month? :)
There are _tons_ of examples. Perhaps not as organized as you or I
would like, but there they are. Start with the test page, which has a
really nifty console that makes it easy to see what is going on with
the examples. There's nothing else like it.
Fair to poor documentation at this point. As if the others are any
different. Quality counts more than quantity. The others' docs are
frequently wrong. ;)
A bad Website? Why because it has no graphics? Don't be stupid. The
builder/test page is an absolute revelation for those who bother to
try it out. I recently found that it worked on NN4.7 BTW. But then
it all works in the latest IE8 modes as well. The rest of them just
"work" in one wave of browsers (usually the latest). What does that
tell you?
> Having an architect
> who behaves like a child is just another reason why the library will
> be ignored, IMO.
I don't act like a child. You just can't take criticism at all. You
made the mistake of advocating jQuery for years and now you look like
an ass because of it (always did to me). That's hardly my fault.
>
> Personally, I don't see "My Library" gaining any acceptance or having
> much impact on the scripting library space.
Personally, your predictions have never been worth much. Lets see,
faster, smaller, more efficient, runs on anything, future-proof, free,
supported by _me_. You think people will still put a penny on John
Resig (or YUI or Dojo) when I am done? Hint: I'm just getting started
on the promotion and you can imagine what is coming. ;)
> But I suspect that
> something may rise out of it (perhaps by someone other than DM,
> perhaps several people here) and be something influential.
Whatever that means.
> That's my
> prediction. Regardless of personalities, I think it is important for
> anyone who is interested in js and scripting libraries to be informed
> about this discussion and to be watching where this goes.
>
Obviously. That's what makes it so laughable that Ajaxian is getting
scooped by the likes of Matt Kruse and S.T. :)
Hans-Georg Michna
>Questions?
Yes. I can't find any documentation on what exactly the
functions do. Is that still in the works?
Hans-Georg
D.Campagna
>> Scott,
>> thanks for the time you invested in this review.
>
> Review?
>
Test? Comment? Whatever. English is not my first language.
>> We all know the way DM tries to promote himself and his work and how he
>> is used to argue with the unfortunates who try to exchange opinions with
>> him.
>
> What does that mean? Seriously.
>
Minimize or ignore criticism aimed at you; insult people, distort facts
and words. You caused the runaway of many decent persons from this
newsgroup, too. And you are banned from some other newsgroups. And you
in the past have faked your name to support yourself and your library.
And so on. Seriously.
>
>> The entire thing is so pathetic and ridicolous that should never have
>> been even discussed in a serious technical forum.
>
> What is pathetic and ridiculous? The two-year-old speed test page
> with the two-year-old libraries? It's now been updated with newer
From now on, maybe it's not still ridicolous. But it was!
>
>> Strange enough, nobody
>> here ever noticed such biased tests were in place, even if Mr. Mark
>> often bragged about the speed of his library et. al.
>
> Are you insane? That selector test page has sat in the same spot,
> unchanged for two years and I never even mentioned it. When I talk
> about speed, I am talking about things other than queries.
And if you are addressing people to your homepage and there they will
find that bullshit, this is what you have done, no more and no less.
>> Sometimes I have the feeling that a lot of people here are very tolerant
>> to Mr. Mark.
>
> What does that mean?
It seems you have some supporters, after all. Not proud of it?
>
>> I come back to my habit to lurk this NG; I suppose many other do the
>> same. I oly wanted to make it clear, I appreciate this thread...
>
> Too bad you got nothing out of it. :(
To be fair: I began to understand something about javascript when I
first stumped into this newsgroup.
And you too teached me something, among your rants. The same way one
learns how to properly use a hammer after having beaten his finger, I
would add. :-)
Oh and I tried your library months ago, and apparently I found
immediately a small insignificant bug in the graphical effects test
page. Insignificant, but...
Regards,
Dan
Andrew Poulos
> David Mark ha scritto:
>>> Sometimes I have the feeling that a lot of people here are very tolerant
>>> to Mr. Mark.
>>
>> What does that mean?
>
> It seems you have some supporters, after all. Not proud of it?
I think you misunderstand. Being able to see the worth in what someone
is saying does not mean that a judgement has been made on the worth of
the person themselves.
Though postings (such as yours) whose purpose appear to cause injury, do
tend to say something about the poster.
Andrew Poulos
Faisal Vali
As does the above statement, and therefore I guess this one too.
Perhaps we all need to reign our sanctimony in a little ;)
Andrew Poulos
I ask that posters not attack personalities because that reflects badly
on the posters themselves but you find that so offensive that you need
to call me a hypocrite?
Andrew Poulos
D.Campagna
> I think you misunderstand. Being able to see the worth in what someone
> is saying does not mean that a judgement has been made on the worth of
> the person themselves.
I don't think someone here is denying the huge work and the huge
knowledge necessary to put toghether such a library, nor the competence
of DM. And I don't judge the person, because it is completely possible
that DM is the kindest person in the world, and has created a fictional
personality here just to "shake the water". Do you know him personally?
>
> Though postings (such as yours) whose purpose appear to cause injury, do
> tend to say something about the poster.
>
Not really a tough post, nor even comparable with the angry posts of DM.
Maybe he's causing some reaction. You too seem to react. It's normal.
I can and i do judge actions, not persons, via internet. Fair enough?
> Andrew Poulos
Dan
Faisal Vali
No. I applaud your sentiment that we should avoid ad hominem
"arguments". I was simply commenting on the veiled personal attack
within the remark that "postings (such as yours) ... do tend to say
something about the poster". Now, if you meant that as a positive
remark about the poster, I apologize.
wmc
> While few would dispute that David Mark's discourse should be more
> civil, Ajaxian blacklisting his work because of the nature of his
> discourse rather than the quality of his work raises far more
> disturbing issues about Ajaxian's integrity (to us consumers) than it
> could possibly raise about David Mark's attitude. The brunt of the
> criticism should be directed towards Ajaxian here. I for one was
> looking forward to that article.
You are 100% correct. There is nothing more relevant that the Ajaxian
could discuss.
What is more relevant than a fundamental criticism of all the major JS
libraries and the counter-claim of a superior design?
The fact that DM has (to put it mildly) an abrasive on-line persona,
which even extends to criticism of *them*, should be taken by them as a
challenge. If his claims are so baseless and irrelevant, why don't they
sharpen their knives and assemble a 'dream team' to rebut his claims?
They would probably say they don't want to give him any more publicity,
but if they can't demolish what he's saying technically, then he, and
the issues he raises, deserve to be widely aired.
As somebody with no dog in this fight, I, too, would love to read their
article on this and the followups... I plan to contact them and tell
them so.
--williamc
Garrett Smith
> Faisal Vali wrote:
>> While few would dispute that David Mark's discourse should be more
>> civil, Ajaxian blacklisting his work because of the nature of his
>> discourse rather than the quality of his work raises far more
>> disturbing issues about Ajaxian's integrity (to us consumers) than it
>> could possibly raise about David Mark's attitude. The brunt of the
>> criticism should be directed towards Ajaxian here. I for one was
>> looking forward to that article.
>
>
> You are 100% correct. There is nothing more relevant that the Ajaxian
> could discuss.
>
> What is more relevant than a fundamental criticism of all the major JS
> libraries and the counter-claim of a superior design?
>
counter claim of superiority?
How about a drama-free discussion of what defines good and bad design?
There are many factors to consider in javascript library design. These
factors include, but are not limited to: The program, time constraints,
budget. Library design decisions can also be influenced by hype.
Peter Michaux
> And yes, there's a growing community of people who are tired of using
> lousy browser scripts and putting up with authors who can't fix
> anything.
Such a community is really "growing"? I just see more and more jQuery
everywhere I look.
> They are helping to test in ancient browsers because it helps
> to illuminate problems that could show up in other lesser browsers (e.g.
> mobile devices). It's not so that people can use NN4.7 (though they
> certainly can if they want).
I wish more people understood this point. I've found bugs thanks to
testing in "weird" browsers.
> And, of course, the whole [My Library] is modular to a fault
What is the fault?
Peter
Peter Michaux
> Helbrax wrote:
> > Also, why use the name prototype?
>
> Because they are stupid. ;)
>
> > Why not just name it "if" or "function"(or "!function")? :P
>
> How about "constructor?"
"My Library" is overloaded and ambiguous also. "I was using my library
today." vs "I was using My Library today." is a bit too subtle. Also
Googling "My Library" will likely be a bit of trouble.
Peter
David Mark
> On Jan 22, 11:25 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Helbrax wrote:
> > > Also, why use the name prototype?
>
> > Because they are stupid. ;)
>
> > > Why not just name it "if" or "function"(or "!function")? :P
>
> > How about "constructor?"
>
> "My Library" is overloaded and ambiguous also.
It's the name of the Web app that generates custom libraries. I think
it is appropriate for that. After you build it, it is _your_ library.
"I was using my library
> today." vs "I was using My Library today." is a bit too subtle. Also
> Googling "My Library" will likely be a bit of trouble.
>
"My Library javascript" and even "browser scripting library" result in
the top pick in every search engine I've tested, but the point is
taken.
David Mark
> On Jan 22, 9:34 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > And yes, there's a growing community of people who are tired of using
> > lousy browser scripts and putting up with authors who can't fix
> > anything.
>
> Such a community is really "growing"? I just see more and more jQuery
> everywhere I look.
>
> > They are helping to test in ancient browsers because it helps
> > to illuminate problems that could show up in other lesser browsers (e.g.
> > mobile devices). It's not so that people can use NN4.7 (though they
> > certainly can if they want).
>
> I wish more people understood this point. I've found bugs thanks to
> testing in "weird" browsers.
They are great for that. :) It's not that I care that Opera 6 has no
documentElement property. I want the library to degrade gracefully in
any environment.
>
> > And, of course, the whole [My Library] is modular to a fault
>
> What is the fault?
>
Ah, figure of speech. Perhaps not appropriate here. I used that a
ways back to describe Dojo's
automatic downloading and concatenation of dozens of files on every
refresh (through sync XHR no less), with no option to leverage the
files individually (so why are they separate?) I don't think I ever
got a suitable answer on that one (among many other questions).
There are faults to the partial builds though. The use of typeof to
detect functions that may not be part of the build is clearly error-
prone (and I have been slowly weeding those out and replacing them
with API.* tests). The server side script is fairly primitive as well
as it could easily take care of these issues on its end.
David Mark
wrote:
> David Mark ha scritto:
>
> >> Scott,
> >> thanks for the time you invested in this review.
>
> > Review?
>
> Test? Comment? Whatever. English is not my first language.
Yes, that was uncalled for. My apologies as I knew what you meant.
>
> >> We all know the way DM tries to promote himself and his work and how he
> >> is used to argue with the unfortunates who try to exchange opinions with
> >> him.
>
> > What does that mean? Seriously.
>
> Minimize or ignore criticism aimed at you;
Ludicrous. Do you have examples or are you just making things up?
> insult people, distort facts and words.
Examples?
> You caused the runaway of many decent persons from this
> newsgroup, too.
Oh dear. If grown adults cannot control their own PC's and eyes and
choose to flee a newsgroup rather than skip articles by authors they
don't like, I can hardly be named the culprit. If this were a
moderated group, these same "adults" would be crying to the moderator
to install a global filter for them. For God's sake, filter your own
mail.
> And you are banned from some other newsgroups. > And you
> in the past have faked your name to support yourself and your library.
> And so on. Seriously.
>
>
>
> >> The entire thing is so pathetic and ridicolous that should never have
> >> been even discussed in a serious technical forum.
>
> > What is pathetic and ridiculous? The two-year-old speed test page
> > with the two-year-old libraries? It's now been updated with newer
>
> From now on, maybe it's not still ridicolous. But it was!
No, it wasn't.
>
>
>
> >> Strange enough, nobody
> >> here ever noticed such biased tests were in place, even if Mr. Mark
> >> often bragged about the speed of his library et. al.
>
> > Are you insane? That selector test page has sat in the same spot,
> > unchanged for two years and I never even mentioned it. When I talk
> > about speed, I am talking about things other than queries.
>
> And if you are addressing people to your homepage and there they will
> find that bullshit, this is what you have done, no more and no less.
It was never bullshit. It was a test of pre-QSA libraries, rather
than apples vs. oranges. The whole jump to QSA is a ridiculous
blunder anyway. Like browser sniffing, it allows the authors to
delude themselves at the expense of their users.
>
> >> Sometimes I have the feeling that a lot of people here are very tolerant
> >> to Mr. Mark.
>
> > What does that mean?
>
> It seems you have some supporters, after all. Not proud of it?
The only "supporters" I really care about are those who send me money,
which have been steadily growing in number since I started promoting
the library as something other than a curiosity. :)
Having trouble with a rusting Prototype or jQuery site? Do drop me a
line. ;)
>
>
>
> >> I come back to my habit to lurk this NG; I suppose many other do the
> >> same. I oly wanted to make it clear, I appreciate this thread...
>
> > Too bad you got nothing out of it. :(
>
> To be fair: I began to understand something about javascript when I
> first stumped into this newsgroup.
> And you too teached me something, among your rants. The same way one
> learns how to properly use a hammer after having beaten his finger, I
> would add. :-)
>
> Oh and I tried your library months ago, and apparently I found
> immediately a small insignificant bug in the graphical effects test
> page. Insignificant, but...
Well, I am all ears, but it has likely already been addressed as
testing all of the old browsers
turned up some holes in the feature testing. There was a silly
oversight in the enhanced changeImage function as well, which has been
fixed in the posted downloads, but I haven't re-built the dynamic
(builder) version yet.
And again, my pitch has never been that it is 9000+ error-free,
perfectly executed and thoroughly tested lines of JS. Not even close
at this point. My point is that it is light years ahead of the
others. The design is far more ambitious as well (to allow calling
apps to gracefully degrade, rather than run head-first into brick
walls). And the others have that nagging browser sniffing that has to
be updated constantly to keep up with just a handful of major browsers
(in their default configurations). It's night and day in that respect.
David Mark
> Faisal Vali wrote:
> > While few would dispute that David Mark's discourse should be more
> > civil, Ajaxian blacklisting his work because of the nature of his
> > discourse rather than the quality of his work raises far more
> > disturbing issues about Ajaxian's integrity (to us consumers) than it
> > could possibly raise about David Mark's attitude. The brunt of the
> > criticism should be directed towards Ajaxian here. I for one was
> > looking forward to that article.
Thanks for the support! I agree that Ajaxian has squandered whatever
integrity it may have had (be fair, none). And their issue is that I
called their site a "crock of shit". I really think that is fair
comment.
>
> You are 100% correct. There is nothing more relevant that the Ajaxian
> could discuss.
I second that.
>
> What is more relevant than a fundamental criticism of all the major JS
> libraries and the counter-claim of a superior design?
Exactly. Web developers and the people they work for don't need to
squander their time on endless Beta tests of dubious browser scripts.
It's madness and has been going on for far too long. Most of these
things are still UA sniffing, which guarantees they have no legs.
They fall apart in anything more than a couple of years old as well.
That's just not cross-browser scripting.
>
> The fact that DM has (to put it mildly) an abrasive on-line persona,
Only to those who ask for it. ;)
> which even extends to criticism of *them*, should be taken by them as a
> challenge.
Well, for example, Resig hides his head in the sane, refusing to even
read this group. Now that's a loser. And I don't think it is
abrasive to call a spade a spade. He had numerous chances to make his
case and flopped every time.
> If his claims are so baseless and irrelevant, why don't they
> sharpen their knives and assemble a 'dream team' to rebut his claims?
Who would be on this team? I can think of a few people here that
could easily poke holes in My Library (and I welcome that), but notice
that the library mavens prefer to get their science from blogs and
Ajaxian. Think of the authors of the "majors". Do you ever see them
in here, even to ask a question? ISTM that they live in their own
parallel universes where basic rules of logic do not apply (e.g. the
prevalence of the typeof xyz == 'array' gaffe, browser sniffing,
etc.) They call it the "real world", but I don't think that's an
appropriate name for their personal cocoons. ;)
>
> They would probably say they don't want to give him any more publicity,
They might say all sorts of illogical things. They are great for
that.
> but if they can't demolish what he's saying technically, then he, and
> the issues he raises, deserve to be widely aired.
Well, there's no "if" there. They can't. Their positions are
indefensible. It would be like saying that lead-based paint was
really a good idea and all of this talk of abatement is just jealousy
talking. :)
>
> As somebody with no dog in this fight, I, too, would love to read their
> article on this and the followups... I plan to contact them and tell
> them so.
>
From what I've heard, they are getting a lot of that. They've sort of
painted themselves into a corner though. Will be interesting to see
how long it takes them to back off their silly position. Let me know
as I don't read that rag at all. ;)