8 Comments

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.

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.

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.

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.