There is literally no isolation between what is being tested and how much performance goes into unrelated operations.
Example: The test for the bind operation executes the "ul > li" selector before performing the bind, thus the results are affected by this.
I could be wrong, but it seems like a benchmark specifically tailored to the benefit of RightJS and it provides no indication for overall performance of RightJS based applications.
RightJS might be wicked fast for all I know, but this test suite is not going to convince me.
Write your own specific tests if you suspect bias.
I doubt there is any real bias though, js libs have different aims. Some aim to have complete browser support at the expense of speed+size, some assume a certain level of browser, and so come in much faster.
The fastest lib though is always going to be no lib. It's far easier to optimize your own code.
The fastest lib though is always going to be no lib.
This is only true if you already know all of the performance hacks in each browser. By using a library, you can outsource the need to worry about that to a third party. Also, only about 5% of your code is ever going to underperform, so deciding to not use a library means you're wasting time on the other 95%.
I like that there's innovation in the space, but there's a couple things about this library that bother me:
- Namespacing is horrible. I've found several global objects it declares, like Browser. Not cool.
- As others have noted, it has no notes on what browsers it supports. IIRC, the thing slowing down sizzle the most is having to support older browsers. There's certainly cases where the browser is predictable, but for everyday use I'll stick with jQ.
[Edit: Supports / targeted for IE8, FF3.5, Opera 10, and Chrome out of the box. I went straight to rightjs.org, and missed the note. Thanks Igor!]
- Extends the prototypes of basic objects, like String, Array, even Object.
I agree with you completely. I looked through the API and jQuery is much cleaner in that sense. However, I think it's great that someone is squeezing extra performance out of JS.
Also, from the linked article:
"First, all the old browser patches and hacks were moved in a separated dynamically loadable module. The core by itself now focuses on the modern browsers support, meaningly FF >=3.5, IE >=8 Opera >10=, Safari 3,4, Google Chrome, while the old browsers support module handles IE6,7, Konqueror and old versions of Opera and FF."
They do seem to support older browsers: just as loadable modules. I am not opposed to the idea that the library runs different code on different browsers to get the job done if I get the same result and a performance gain out. On the other hand it's not code that I would want to debug.
How is my above comment defending it? :/ I actually extremely rarely use any js libs. I'd rather just do it myself. And no I'm nothing to do with the project.
I know; I just feel that as RightJS hasnt made this claim it's unfair to make it for them :) reading the blog they wanted to focus on other great features/additions/improvements.
(the main problem is it reads like bait: which is why all the negative/reactionary comments are appearing :))
jQuery 1.3.2 is not the most recent stable version.
jQuery alphas and betas are quite stable. The 1.4 alpha passes all current tests in all browsers.
That's a big selling point for jQuery. I'd much rather see talking points about the robustness of the development and QA process of various projects.
Also, the quick turnover for the "fastest" JavaScript library makes speed a fairly useless metric for comparing JavaScript libraries. Even if I was so concerned with speed I'd much rather see a comparison of the versions I'd likely put into production if I started a greenfield project today.
http://github.com/MadRabbit/taskspeed/blob/master/tests/jq-t...
There is literally no isolation between what is being tested and how much performance goes into unrelated operations.
Example: The test for the bind operation executes the "ul > li" selector before performing the bind, thus the results are affected by this.
I could be wrong, but it seems like a benchmark specifically tailored to the benefit of RightJS and it provides no indication for overall performance of RightJS based applications.
RightJS might be wicked fast for all I know, but this test suite is not going to convince me.