4 ms·
RightJS vs jQuery Mano A Mano (clean test comparison)
- etherealG 17y agoSorry 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.
- MadRabbit 17y agoProbably, but don't blame me, I just test how jQuery actually builds elements, because people do build elements this way from time to time. But don't count it if you don't like the idea, it's just one test among many others and not the slowest one. So it won't change a lot.
- catch23 17y agoWell the reason jQuery rose to popularity had nothing to do with its speed. jQuery is a bit of a pseudo-dsl for dealing with dom manipulation. Sure it's a ton faster if you just did it with pure dom, but I think if you considered the development time required as part of your benchmark, you might see jQuery come out on top.
- MadRabbit 17y agothe benchmark is just a proof o point, nothing else. and certainly I know why jQuery is popular. But as for the second part, I don't see any difference in coding efforts between jQuery and RightJS, if you really read the tests on github, you will see the size of code is about the same, RightJS is even compacter in many places.
- veemjeem 17y agocode size is rarely a good indication of productivity in a framework. There's lots of frameworks that allows the developer to have a smaller code size but few actually make it more fun for the developer to work in. I'd say jQuery is popular simply due to their Sizzle library which is now in many other frameworks. It may be slow, but it sure is fun to work with. I'd also like to note that it's quite nice that jQuery does not mess with classes directly, or with prototype. Although it certainly is cool to add additional methods there, javascript doesn't have a great way to namespace stuff added to global classes and makes it a pain when you mix & match other JS libraries into your project.
- MadRabbit 17y agoYou're saying right things about jQuery, but you seem like don't know a thing about RightJS, because it has its own nice features and most people who actually tried it for real, said that it is more comfortable and fun to work with than jQuery. As for the safe mode, first of all it's not such a big problem as people usually think and actually provides more help than issues, and secondly RightJS will end up with a safe mode plugin sooner or later.
- veemjeem 17y agoI do think you should consider adding a safe mode sooner rather than later. It's actually a bigger problem than you might think. My mentor generally won't care too much if I use a 3rd party js library as long as it doesn't interfere with other company libraries (which do put functions on Array.prototype/Object.prototype). I'm guessing that other people working at large companies may not be able to use your library for this reason.
- MadRabbit 17y agoI know about the problem. RightJS is extra careful with native classes extensions, it adds only standard methods and doesn't extend the Object.prototype at all. In many cases it's just adds missing methods in old browsers and that's it. And we always keep the original functionality intact. We're trying to balance between the Prototype extensions hell and jQuery agnosticism. Things like String#endsWith, Array#compact is kinda standard features, they are extremely handy in everyday work and most of soberminded programmers won't hack those methods if they create some plugin that other people might use. As the matter of fact most of jQuery plugins don't extend prototype too. So it is a problem, but I believe it's negotiable and there might be a non-polar solution.
- ErrantX 17y agoIt'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 17y agoIt 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
- baha_man 17y agoThat should be mano-a-mano, surely? http://en.wikipedia.org/wiki/Mano-a-mano http://en.wikipedia.org/wiki/Mano-a-mano
- deleted 17y ago[deleted]
- MadRabbit 17y agofixed. thanks for heads up!
- Slashed 17y agoCan someone explain me, how PureDom can be slower?
- MadRabbit 17y agoIt'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.
- c00p3r 17y agobtw, 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.
- IgorPartola 17y agoBrowsers 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 17y agoIgor, 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 17y agoLive 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 17y ago> 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 17y agoIt'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?
- deleted 17y ago[deleted]
- MadRabbit 17y agoOkay 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
- MadRabbit 17y agoI've updated the screenshots, adding those two new tests. It actually increased the overall gap between RightJS and jQuery 8)