As stated previously, TaskSpeed was not ‘ready’ to be released. I’d mentioned in the initial post regarding this suite about the use of .innerHTML in places, and either have addressed or plan to address a lot of the other above statements with the “real initial announcement” – hopefully which will include YUI, ExtJS, and @WebReflection’s “PureDom” library.

There are a _number_ of issues I want to address regarding the suite, the charts, the tests … Please hold off on bashing until I’ve had a chance to ‘justify my actions’.

Regards,
Peter Higgins

in jQuery, as example, if you use .html() rather than .append() performances are extremely different

Am I too off the base here?

Tests that just set .innerHTML on something aren’t even using the library, code like that shouldn’t be in there, those tests should use update(), html() or whatever comes with the library.

There are many ways to do the same thing in any of these languages, and which one is chosen is due to the situation and the programmer. So what are we testing the speed of? One programmer’s favorite solution, which may be based on clarity rather than speed.

Dojo’s Test:
var n = dojo.doc.createElement(‘ul’);
dojo.addClass(n, “fromcode”);
n.id = “setid” + i;
dojo.body().appendChild(n);
n.innerHTML = “(li)one(/li)(li)two(/li)(li)three(/li)”

jQuery’s Test:
$(“”)
.append(“onetwothree”)
.appendTo(“body”);

Moo’s Test:
new Element(’ul’, { id:’setid’+i, ‘class’:’fromcode’})
.adopt(
new Element(’li’, { html:’one’ }),
new Element(’li’, { html:’two’ }),
new Element(’li’, { html:’three’ })
)

See eyelidlessness, it looks to me like Dojo and jQuery are using a string insertion via innerHTML to add their li’s in this test round. I mean for apples to apples sake why would you use one library’s full Element creation method to create and inject sub nodes for a test, while skipping that additional logic processing on the same test for a different library? I have to think that skipping the steps to process the function of a library that creates an element and does its insertion and instead using innerHTML has to be a performance difference. If I am way off here just let me know…

I really have to check out the qooxdoo codez nao!

That is just one example of many where the author is using slow ass stuff instead of faster methods, maybe the guy who wrote this should try using methods that someone using each framework correctly would, use instead of writing everything to take as long as possible.

That’s exactly the point of having the library authors write the test to their API. The API provided is expected to be an abstraction that developers will use. The purpose of the benchmark is to test real-world use of those abstractions—essentially, to test the performance of the API.

Perhaps you wouldn’t use the Element() DOM builder abstraction, but many of us do because it provides a lot of utility in a generally concise API. Replacing it with innerHTML is not only not a 1:1 replacement, but also more and more problematic as you go to incorporate user data into the DOM nodes you’re creating.

There’s a very valid reason for testing the various libraries DOM APIs as such: people are using them, and it’s good to know what kind of performance we’re getting.

Nice Test!!! …and the short way:

new Element(‘table’,{ ‘class’:'madetable’ ,
‘html’:'(tr)(td)(/td)(td)first(/td)(/tr)’
}).inject(document.body);

new Element(’ul’, { id:’setid’+i, ‘class’:’fromcode’,
‘html’:’(li)one(/li)(li)two(/li)(li)three(/li)’
}).inject(document.body);

have to use () for < i guess, use your imagination.

new Element(‘ul’, { id:’setid’+i, ‘class’:'fromcode’})
.adopt(
new Element(‘li’, { html:’one’ }),
new Element(‘li’, { html:’two’ }),
new Element(‘li’, { html:’three’ })
)
.inject(document.body);

That is just one example of many where the author is using slow ass stuff instead of faster methods, maybe the guy who wrote this should try using methods that someone using each framework correctly would, use instead of writing everything to take as long as possible.

What it should look like:

new Element(‘ul’, { id:’setid’+i, ‘class’:'fromcode’,
‘html’:'onetwothree’
}).inject(document.body);

C’mon TestGyver, your better than that.