jQuery vs. My Library
in [JavaScript]
|
From: Scott Sauyet on 24 Jan 2010 17:44 On Jan 23, 9:35 pm, Andrew Poulos <ap_p...(a)hotmail.com> wrote: >> 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
From: RobG on 24 Jan 2010 18:38 On Jan 25, 8:44 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > On Jan 23, 9:35 pm, Andrew Poulos <ap_p...(a)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
From: Scott Sauyet on 24 Jan 2010 21:50 On Jan 24, 6:38 pm, RobG <rg...(a)iinet.net.au> wrote: > On Jan 25, 8:44 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > > > On Jan 23, 9:35 pm, Andrew Poulos <ap_p...(a)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
From: Garrett Smith on 24 Jan 2010 21:56 Scott Sauyet wrote: > On Jan 23, 9:35 pm, Andrew Poulos <ap_p...(a)hotmail.com> wrote: >>> 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 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/
From: Scott Sauyet on 24 Jan 2010 22:06
On Jan 24, 9:56 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > 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 |