

RightJS vs jQuery Mano A Mano (clean test comparison) - MadRabbit
http://st-on-it.blogspot.com/2009/12/rightjs-vs-jquery-mano-o-mano.html

======
etherealG
Sorry to say, but at least one of your tests still suffers from a non apples
to apples problem. Specifically the "make" tests. The jquery make test does
parsing of strings into dom elements and various appends. The rightjs make
test is just a wrapper for DOM creation. That's not even close to the same
thing.

~~~
ErrantX
It's arguable that a) if they do the same and thing and b) it is the
_accepted_ way to do that thing in each framework than it is surely a fair
test?

:)

~~~
MadRabbit
It is arguable. For this reason I left the thing in one single test.

So that you have a choice. If you disagree, then you don't count this line, if
you do agree then you count it.

Either way RightJS comes faster

------
IgorPartola
Browsers were desgined from the beginning to parse HTML fast. JavaScript was
added later and optimized much later. Doing e.innerHTML = "some markup" will
be faster than making function calls to do createElement, etc. because these
calls have to go between JS and the underlying C(++) environments and back.
And knowing that I might optimize my code accordingly where it might make a
difference. In other words if I am adding 500 elements to a document I am
going to do it by making the browser parse HTML, which will not involve the JS
lib at all. Doing this kind of a test is useless since it will never happen in
the wild. Instead let's test selector speeds etc. We could also test event
handler assignment but here too i would use jQuery's live() and then binding
takes almost no time for any number of elements.

~~~
MadRabbit
Igor, as I said below, testing elements building is only one test and you can
ignore it if disagree.

> Instead let's test selector speeds etc.

Actually this is what's pointless, both of the frameworks do it by using
native features of the modern browsers and results will about the same for any
framework.

> i would use jQuery's live() and then binding takes almost no time for any
> number of elements.

Are you sure about that?

~~~
IgorPartola
Live binds one event handler to a parent element and then simply watches for
any events of that type to bubble up. bind adds 500 handlers to 500 elements.
live is faster in theory. Will write a test to show in practice.

Yes simple selectors are pointless. How about '.Class
.child:visible:not(.test):eq(1)'?

~~~
MadRabbit
> Live binds one event handler to a parent element and then simply watches for
> any events

It's kinda different story and rather a hack than a standard approach. And
it's not always a cace, because it will handle the callbacks slower than a
direct bind and therefore not always appropriate.

In any case it's not what the test is intended to do. We test standard
operations, that's all. Testing live with bind is like comparing apples with
oranges.

> How about '.Class .child:visible:not(.test):eq(1)'?

Do you mean non-standard css-selectors? There is nothing to test, rightjs
simply doesn't support them

With rightjs you always can do it like that

$$('.class').filter('visible');

~~~
IgorPartola
While event delegation doesn't work 100% of the time (e.g. when another piece
of code that uses capture instead of bubbling such as google maps API), I
wouldn't consider it a hack. Of course event handling will be slower but we
can test how much slower :).

You can do that with jQuery as well and that's an ineresting performance
comparison in itself. E.g. $('.class:visible:not(:eq(1))') vs
$('.class').filter(':visible').not(':eq(1)'). I suspect it heavily depends on
the size of the DOM tree and the number of elements.

~~~
MadRabbit
At the beginning you're kinda was against the "make" test, because there is no
such thing in jQuery, and now you practically offer the same thing, to test
something that does exist in jQuery but doesn't in RighJS.

You should choose already what do you stand for.

But anyway, if you want to test it go ahead, you know where the code is. I
suppose jQuery handles virtual selectors via JavaScript and therefore there
will be no serious difference in performance. I even suspect that a single
additional function in the filter method in RightJS will still work faster
than several internal selectors in jQuery.

------
baha_man
That should be mano-a-mano, surely?

<http://en.wikipedia.org/wiki/Mano-a-mano>

~~~
MadRabbit
fixed. thanks for heads up!

------
IgorPartola
It's interesting that your test shows that insert after is slower on jQuery
1.4 than on 1.3 since the release notes for 1.4a says "append, prepend, etc.
have been heavily optimized." How about adding append and prepend to the test
suite?

~~~
MadRabbit
Okay I've added it to the test.

Insert element bottom 48 131 169

Insert element on top 48 134 167

Don't know about the release notes, my test says 1.4 is slower than 1.3.2

------
Slashed
Can someone explain me, how PureDom can be slower?

~~~
MadRabbit
It's not slower, PureDom is faster in most of the tests, there are just couple
of tests insert/before/after that seems have slower implementation, don't
really now why.

It's not RightJS only, Dojo and YUI win in those tests too.

Generally speaking PureDom is still faster than RightJS. It has to be.

~~~
Slashed
Thanks! P.S. For some reason I can't up-vote.

~~~
MadRabbit
no problem

------
c00p3r
btw, very good self-promotion. I admire your effort, self-esteem and courage!
There are lots of programmers who were afraid to attract such attention to
their products.

