TaskSpeed results for My Library
in [JavaScript]
|
From: David Mark on 27 Jan 2010 12:09 TaskSpeed is another quasi-standard test that has never seen anything like My Library. :) It was written by one of the Dojo guys. Yeah, I know. :( http://www.cinsoft.net/mylib-testspeed.html It just flat-out murders the rest (even Dojo) And yes, the test functions are _very_ concise (even too concise). And no, they aren't even close to optimized. They even use the (optional) OO interface. So there's really nothing left to argue as My Library is somehow (much) faster _and_ more concise. Not to mention compatible with virtually any agent, past, present or future. ;) So, what is it that caused whole armies of developers to write slow, incompatible, brittle, browser sniffing BS for ten years? Would be too slow and/or bloated if they didn't take the "pragmatic" (read idiotic) approach? No doubt that everyone who listened to such babbling got saddled with a lifetime installment plan of bad software (now just upgrade to jQuery 1.6543 and everything just works again!) and shelves lined with books describing just how awesome all of that bad code really is. Now we have proof that it isn't. ;) Nobody ever needed any of it. In fact, they'd have been much better off without it. Any company serious about Ajax development could have developed something like My Library years ago and saved all of the time of dealing with constant (and virtually mandatory) jQuery upgrades, incompatibilies, inefficiency, etc. Not to mention all of the time arguing if it was "better" than Prototype (or whatever). How stupid (and/or ignorant) would you have to be to waste time and money training to use one of these ever-changing monstrosities? Think how many people need to be laid off now because all they know is jQuery and Mootools. ;) As for companies that were not serious about browser scripting, they should have left it alone. The users would never have missed a thing (many would have preferred their sites without all of the Ajax-y "goodness"). And where is this ExtCore thing? Nobody seems to have written a set of tests for it. I may have to do it myself as I've seen the code and am sure it will be slow and incompatible. Ext is another software subscription service, except this one costs money AIUI. There will be a full review of Ext (and a warning to steer clear of course) on cinsoft.net soon Hard to believe people would buy into the idea of paying a company to constantly fall flat on its face. I guess they've convinced whatever customers they have left at this point that they really are working on Mission Impossible (should just be a few more years!). The various free libraries and frameworks have been feeding the same line for years. They are all working on some perfect solution to an impossible problem and must continue working on it every day forever. Please bear with them and continually download their code to "keep up" with the browsers. Thing is, my scripts never fell behind, so I never knew what they were going on about. :) By the time the collective library authors learn ES and browser scripting, there won't be any market for their wares. If that sounds like an absurd situation, it is; but history has certainly seen periods defined by absurdity and failure. Come to think of it, these things fit right into the first decade of this century. ;) Oh, and I heard from Ajaxian (for those that care). They've decided that since I said their site stinks (it does), they are not going to report any news about My Library ever (picturing a child stamping their feet). What a bunch of useless dip-shits. I bet they hang out with JS library authors. :)
From: jdalton on 27 Jan 2010 12:34 Hi David, I noticed a few problems with your tests. 1) You are comparing against older versions of some of the frameworks which don't use querySelectorAll. 2) Your tests don't follow the standards of taskspeed. (You are setting innerHTML properties instead of using the framework API where available) 3) Your QSA adapter is too simple. QSA is buggy across almost all browsers and you aren't addressing any of those issues. Your framework fails in multiple modules, multiple browsers, and multiple versions of browsers. Your CSS selector engine is incomplete, slow (compared to current engines) and fails to pass some basic unit tests of other frameworks. What I find interesting is without complete/comprehensive tests you claim superiority, but on a quick review one would find that your code fails to pass the standards by which you judge other developers/ frameworks.
From: David Mark on 27 Jan 2010 13:28 On Jan 27, 12:34 pm, jdalton <john.david.dal...(a)gmail.com> wrote: > Hi David, > > I noticed a few problems with your tests. Oh good. > > 1) You are comparing against older versions of some of the frameworks > which don't use querySelectorAll. And comparing without it as well. See previous discussions. I am all for testing the "slow lanes" as they are more significant IMO. > 2) Your tests don't follow the standards of taskspeed. What standard is that? > (You are > setting innerHTML properties instead of using the framework API where > available) I just put them up yesterday (and have been changing them to be more OO to demonstrate how well those interfaces work). Here are the exact tests that are up there now;- "make" : function(){ var createAndAppend = API.createAndAppendElementWithAttributes; var body = API.getBodyElement(); for (var i = 0; i < 250; i++) { createAndAppend('ul', {'class':'fromcode', id:'setid' + i}, body, document).innerHTML = '<li>one</li><li>two</li><li>three</li>'; } return $('ul.fromcode').length; }, "indexof" : function(){ var target = API.getEBI('setid150'), index = 0; Q('ul').forEach(function() { index = this.indexOf(target); }); return index; }, "bind" : function(){ return Q('ul > li').on('click', function(){}).length(); }, "attr" : function(){ return Q('ul').map(function(el) { return el.id }).length; }, "bindattr" : function(){ var subscriber = function() {}; return Q('ul > li').on('mouseover', subscriber).setAttribute('rel', 'touched').off('mouseover', subscriber).length(); }, "table": function(){ var myTable = E(), myCell = E(), body = API.getBodyElement(); for (var i = 0; i < 40; i++) { myTable.loadHtml('<table class="madetable"><tbody><tr><td>first</ td></tr></tbody></table>').appendTo(body); myCell.loadNew('td').insertBefore(myTable.descendants('td')[0]); } return $('tr td').length; }, "addanchor" : function(){ return Q('.fromcode > li').forEach(function(li){ li.innerHTML = '<a href="http://example.com">link</a>'; }).length(); }, "append" : function(){ var div, createAndAppend = API.createAndAppendElementWithAttributes, doc = global.document, body = doc.body; for (var i = 500; i--;) { createAndAppend('div', { 'rel':'foo2' }, body, doc); } return $("div[rel^=foo2]").length; }, "addclass-odd" : function(){ return Q('div').addClass('added').filter(function(el, i) { return (i % 2); }).addClass('odd').length(); }, "style": function(){ return Q('.added').setStyles({ backgroundColor:'#ededed', color: '#fff' }).length(); }, "removeclass": function(){ return Q('.added').removeClass('added').length(); }, "sethtml": function(){ return Q('div').forEach(function(el) { el.innerHTML = "<p>new content</p>"; }).load('div').length(); }, "insertbefore" : function(){ var myEl = E(); return Q('.fromcode a').forEach(function(a) { myEl.loadNew('p').setText('A Link').insertBefore(a); }).length(); }, "insertafter" : function(){ var myEl = E(); return Q('.fromcode a').forEach(function(a) { myEl.loadNew('p').setText('A Link').insertAfter(a); }).length(); }, "destroy": function(){ return Q('.fromcode').remove().length(); }, "finale": function(){ API.emptyNode(API.getBodyElement()); return $('body *').length; } I started to redo the last few that actually do touch the innerHTML property. Like this:- "make" : function(){ var myEl = E(), body = API.getBodyElement(); for (var i = 0; i < 250; i++) { myEl.loadNew('ul', {'class':'fromcode', id:'setid' + i}).setHtml ('<li>one</li><li>two</li><li>three</li>').appendTo(body); } return $('ul.fromcode').length; }, ....which is slightly slower. But nothing can bridge the exponential gap between My Library and the rest. ;) There's only two other tests that use any DOM property (e.g. innerHTML). Both are near identical:- "sethtml": function(){ return Q('div').forEach(function(el) { el.innerHTML = "<p>new content</p>"; }).load('div').length(); }, "addanchor" : function(){ return Q('.fromcode > li').forEach(function(li){ li.innerHTML = '<a href="http://example.com">link</a>'; }).length(); }, Solution is obvious:- "sethtml": function(){ return Q('div').setHtml('<p>new content</p>').load('div').length(); }, Six of one, half a dozen of the other. Might slow it down a hair, but then changing to use DOM appends might speed it back up. Who knows? It won't make the others any faster, that's for sure. And yes, several of them use "cheating" like innerHTML as well:- "make" : function(){ var ul; for ( var i = 0; i < 250; i++ ) { ul = document.createElement('ul'); YAHOO.util.Dom.addClass(ul, 'fromcode'); YAHOO.util.Dom.setAttribute(ul, 'id', 'setid'+i); document.body.appendChild(ul); ul.innerHTML = '<li>one</li><li>two</li><li>three</li>'; } return YAHOO.util.Selector.query('ul.fromcode').length; }, :) > 3) Your QSA adapter is too simple. QSA is buggy across almost all > browsers and you aren't addressing any of those issues. Well, it is only a day old. How much do you want to bet I can make it bypass buggy selectors without resorting to browser sniffing and without needlessly slowing down the "fast lane?" Who else is better qualified to do that? And who told those other nimrods to dump QSA into their core? It's a mistake. > > Your framework fails in multiple modules, multiple browsers, and > multiple versions of browsers. Care to elaborate on any of that? Sounds like the opposite of what the documented testing has uncovered. And yes, automated unit testing will follow. The difference is that I won't be surprised by wrong results and I won't allow such results to shape my design. > Your CSS selector engine is incomplete, slow (compared to current > engines) and fails to pass some basic unit tests of other frameworks. I never said it covered every selector. It is hardly slow (as the tests have shown). I am sure it fails to pass unit tests involving selectors it doesn't support. Read the instructions before testing. It's faster than virtually everything on virtually everything. And so what? I never told you to use a CSS selector query engine. It's just stupid. > What I find interesting is without complete/comprehensive tests you > claim superiority, but on a quick review one would find that your code > fails to pass the standards by which you judge other developers/ > frameworks. No, you just have no idea what you are talking about. For instance, there's a big difference between eschewing a few selector types (which are documented) and completely failing to understand how - for example - IE works (while releasing script after script claiming to solve it for good!) ;) If it's been ten years and you still read documents (or measure elements) wrong in IE, you aren't qualified to solve cross- browser problems for the rest of us. The whole point is that you do not need an army of code monkeys rewriting the same script, year after year, adding more bloat and complexity, requiring re-testing, deprecating "old" browsers, etc. It's been a complete waste of time as it lead up to a bunch of slow, buggy "standard" renditions that are virtually unusable on the Web.
From: David Mark on 27 Jan 2010 13:48 On Jan 27, 12:34 pm, jdalton <john.david.dal...(a)gmail.com> wrote: > Hi David, > Hi, "jdalton". I thought I recognized that moniker. Prototype hawker, huh? That library should never have been written. It manages to be the slowest (at virtually anything) while also throwing bizarre exceptions in anything but the latest browsers (and some of the latest too). And it isn't for real. It's just a collection of browser observations made by people with no idea what they were observing. It won't (doesn't) hold up. That's why a million monkeys keep churning out new Prototypes. Stop and look at the design (from a neophyte in 2005) and realize it will never be competent. Now, can you you accuse My Library of that? ;)
From: jdalton on 27 Jan 2010 14:32
Hi David, Taskspeed is standardized by Peter Higgins, he ensures that no one lib is taking shortcuts or misrepresenting their framework. If you really want your Taskspeed tests considered lagit, fork his, add it, and send him a pull request. If you take issue with one or more of the tests you can correct it and send him a pull request. Please correct me if I am wrong on this. When I or others find flaws in your work it's not a knock against you or your framework in fact you did it, whatever the flaw is, by design. On the other hand when you find faults in others code/frameworks/ libraries they are labeled incompetent. As for unit tests (massive fails): (failing Prototype tests) http://dl.dropbox.com/u/513327/mylib/test/prototype.html (failing jQuery tests, commented out the jq custom selector tests) http://dl.dropbox.com/u/513327/mylib/test/jquery1.html http://dl.dropbox.com/u/513327/mylib/test/jquery2.html (wont even run the tests some bug in mylib) (failing Dojo, Yahoo, Closure, and other tests) http://dl.dropbox.com/u/513327/mylib/test/slick.html (simple Slickspeed that works with your limited set of selectors showing it as one of the slowest) http://dl.dropbox.com/u/513327/mylib/slickspeed/index.html > Well, it is only a day old. You are promoting it as if its the best thing around (on twitter, your google group, and clj) > How much do you want to bet I can make it bypass buggy selectors ... Then you will join the rest who have without sniffing. I don't doubt your ability. Random thought, have you tried submitting bug reports against the frameworks you flame ? > I never said it covered every selector. Others cover more selectors/bugs which can add to complexity and drain overall performance. > I never told you to use a CSS selector query engine. > It's just stupid. You are the one showing Slickspeed results and promoting your framework as faster/better. > Prototype hawker, huh? I haven't contributed or endorsed Prototype for some time now. |