jQuery VS jQ.Mobi VS zepto VS ten.js
JavaScript performance comparison
Info
This is an edited test from http://jsperf.com/jqm3/68 by levin, which is based on some other test.
All I did was add a test for ten.js and remove the native JavaScript tests.
Preparation code
<script src="//zeptojs.com/zepto.min.js"></script>
<script src="//cdn.jqmobi.com/jq.mobi.min.js"></script>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>
<script src="http://lordsnow.net/kvf/ten/ten.min.js"></script>
<div id="container"></div>
<script>
Benchmark.prototype.setup = function() {
var d = {};
d.id = function(el) {
return document.getElementById(el);
}
d.create = function(el) {
return document.createElement(el);
}
//Lets add the append method to all html dom nodes:
HTMLElement.prototype.append = function(el) {
this.appendChild(el);
}
var container = d.id('container');
var ul, li, i = 0;
};
Benchmark.prototype.teardown = function() {
container.innerHTML = "";
};
</script>
Preparation code output
Test runner
Warning! For accurate results, please disable Firebug before running the tests. (Why?)
Java applet disabled.
| Test | Ops/sec | |
|---|---|---|
jQ.Mobi |
|
pending… |
jQuery |
|
pending… |
ten.js |
|
pending… |
Zepto |
|
pending… |
Compare results of other browsers
Revisions
You can edit these tests or add even more tests to this page by appending /edit to the URL. Here’s a list of current revisions for this page:
- Revision 5: published
- Revision 10: published by Jesse
- Revision 11: published
- Revision 14: published
- Revision 15: published
- Revision 16: published
- Revision 17: published
- Revision 18: published by David Kaneda
- Revision 19: published by Nige White
- Revision 20: published
- Revision 22: published by Nige White
- Revision 24: published by Nige White
- Revision 25: published by fake-or-dead
- Revision 26: published by Praneet Loke
- Revision 27: published by Devin
- Revision 28: published
- Revision 30: published by Praneet Loke
- Revision 31: published by Devin
- Revision 32: published
- Revision 35: published by Devin Rhode
- Revision 37: published by Devin Rhode
- Revision 40: published by Devin Rhode
- Revision 41: published by Devin Rhode
- Revision 43: published
- Revision 44: published
- Revision 45: published
- Revision 49: published
- Revision 50: published
- Revision 51: published
- Revision 52: published by jason mcleod
- Revision 54: published
- Revision 56: published
- Revision 58: published
- Revision 60: published by Keith Chu
- Revision 61: published
- Revision 62: published
- Revision 64: published
- Revision 66: published
- Revision 67: published
- Revision 68: published by levin
- Revision 69: published
- Revision 70: published
- Revision 71: published by Jacob Gable
- Revision 75: published
- Revision 76: published
- Revision 77: published
- Revision 79: published
- Revision 84: published by bill
- Revision 85: published
- Revision 86: published
- Revision 92: published
- Revision 93: published
- Revision 94: published
- Revision 95: published by Kevin
- Revision 97: published
- Revision 102: published by Mark Bradshaw
- Revision 103: published by j79
- Revision 104: published
- Revision 105: published
- Revision 106: published
- Revision 107: published
- Revision 108: published by Marnix T'Jaeckx
- Revision 109: published
- Revision 110: published
- Revision 112: published
- Revision 113: published by Miles Elam
- Revision 114: published by dameleon
- Revision 115: published by realpeterz
- Revision 116: published
- Revision 118: published
- Revision 119: published
- Revision 120: published
- Revision 123: published
- Revision 124: published
- Revision 125: published
- Revision 127: published
- Revision 128: published
8 comments
Apples and oranges man ;)
Good start on ten.js, but all the other "constructor" calls for jQuery, Zepto and jqMobi allow you to do much more. The logic inside makes it slower. Since you aren't checking for DOM nodes, arrays, ten.js objects, it should be significantly faster then the others.
Thanks,
Yeah that's kind of the point. There's a lot of jQuery that I'm not too interested in, and would rather keep it as small as possible. However much more functionality is in development, it's only existed for 5 days.
Also - the HTML manipulation methods do check for arrays, even .html (jQuery doesn't even do that).
im talking about the general selector. There is a lot ten.js doesnt supper that the other libraries do, so a comparrison isnt really usefull. its not a drop in replacement for any of the apis.
There are a few other libraries coming out that are way faster that do not provide a similar api to jquery. not sure what the goal is since you want help writing a "css selecor engine" when browsers do most of it for you now. Sizzle is good for backwards compatibility in old browsers and the fake selectors jQuery made. Why not just let te browser do the work?
you should look into not being compatible with those libraries and just build for speed! most users do not use all the variable types for the functions/selectors with those libraries. Its easier to support your own instead of trying to match the exising libraries that already have a strong base and greater coverage. good work so far though.
Right, it's not a drop-in replacement, just a minimalist version of something familiar.
I actually didn't even know about querySelector, I figured there must be some function like that but wasn't sure. Anyway, I found that and implemented it, and it's running faster now (and smaller).
What are the other APIs you mentioned? Would be curious to check them out.
Not to be rude, but go read jQuery's documentation ( much better then Zepto or jqMobi) and look at the source code too. Then decide if its a path you want to go down. Its a good way to learn how the low level code works, but its clear you do not have a broad understanding of how the libraris work. Thats why i said apples and oranges. The tests on here are to show api compatible libraries. While Zepto and jqMobi are not 100% perfect they are very close and work great for modern browsers. Adding features like "arrays" as parameters is not really helpful to anyone who knows those libraries since you left major parts out. Thats why I recommended going another route since you are trying to compare yourself against these libraries but offer an extremely small subset of overall functionality. Its not just additonal api calls, its supporting the same parameters that the other libraries do. You are bettrr off taking the wrapped dom tests on here and going from there as trn.js doesnt offer a real useable improvement.
Apples and oranges are fine with me, but I need something to test the performance against. That's what this is for. Like I said, it has only existed for a few days, I need to get the basics working before moving on. Performance of simple functions is my primary concern at the moment. You can't expect it to have jQuery level functionality in a few days.
Beating a dead horse but its obvious you do not understand what the libraries do. Who cares yours is only days old. If you want to try to beat the big frameworks you need to be faster, smaller and match what they do. You would have been better off creating your own test case instead of editing an existing one for everyone to see.