JXtension - JQuery's Little Brother

[bardonw]

I recently created JXtension, a JavaScript library that is smaller than jQuery but provides many of the same features. These features include all of the following:

• New Array object functions
• New Function object functions
• New String object functions
• A $(...) CSS-like selector
• A New Color object

I am working on including cookie handling, AJAX, and wildcard search capabilities. I currently have most of the extra object functions documented. Unfortunately, I will not have the CSS-like selector documented until after December 19 (because of my workload at school). All JXDocs (JXtension Documentation pages) and JXtension information can be found at http://jxtension.gotochriswest.com/. The complete (or full) version of JXtension can be found at http://jxtension.gotochriswest.com/J...atest(Full).js. My question for you is, what would you like to see in a JavaScript library?

[rnd me]

I like the features you have created, but i think getting anyone to use a general-purpose javascript library is a tough sell at this point.

Since a lot of your functionality is fairly common, or already avail on native JS, i would take your color part and port it to a dedicated color library.

Specialized libraries like those for color will likely have a greater appeal to more people.


one thing i hate about it (sorry) is it's re-use of standard prototype method names.
if i write a generic function (arguments unknown), and i duck-type the argument:

if(arg.map){ newRay=arg.map(logger);}

, you can see how messed-up passing a function would be ( after loading your library). To me, that's an instant deal-breaker, no appeal.

IMHO, one should NEVER replace an existing prototype method with a custom one, unless it does the EXACT same thing as the original, and one should never duplicate a non-competing property to a competing type. For example, adding mozilla's [].map to IE is fine, but making a new [].map that accepts 5 extra arguments is not acceptable.

you have to assume that people will run other libs alongside yours, so play nice with others!
same goes for globals: using "$" is going to sour a lot of grapes given the popularity of jQuery...

there is a utube/yahoo video of Resig giving a library-authoring presentation floating around, watch it.

[bardonw]

Originally Posted by rnd me

I like the features you have created, but i think getting anyone to use a general-purpose javascript library is a tough sell at this point.

Since a lot of your functionality is fairly common, or already avail on native JS, i would take your color part and port it to a dedicated color library.

Specialized libraries like those for color will likely have a greater appeal to more people.


one thing i hate about it (sorry) is it's re-use of standard prototype method names.
if i write a generic function (arguments unknown), and i duck-type the argument:

if(arg.map){ newRay=arg.map(logger);}

, you can see how messed-up passing a function would be ( after loading your library). To me, that's an instant deal-breaker, no appeal.

IMHO, one should NEVER replace an existing prototype method with a custom one, unless it does the EXACT same thing as the original, and one should never duplicate a non-competing property to a competing type. For example, adding mozilla's [].map to IE is fine, but making a new [].map that accepts 5 extra arguments is not acceptable.

you have to assume that people will run other libs alongside yours, so play nice with others!
same goes for globals: using "$" is going to sour a lot of grapes given the popularity of jQuery...

there is a utube/yahoo video of Resig giving a library-authoring presentation floating around, watch it.

Thanks for the reply. I understand your concern but I am pretty sure that my library extensions (using object.prototype) offer the same functionality that was available prior to using JXtension. In other words, using the toString, indexOf, replace, and other such functions the way they are intended with regular JavaScript will produce the same results with JXtension. You will notice that the JXDocs indicate that all of the new arguments within these functions are optional. On the other hand, I will have to check to see if other browsers provide the map function for the Function object. If you have any other concerns, please reply.

[bardonw]

Funny, I now see that there is already a map function for arrays provided by Firefox but my library doesn't overwrite this function (nor does it even use it). Perhaps the next version of my library will simply use the built-in map functionality if it is provided. If you find any problems with the documentation or code, please tell me.

[rnd me]

Originally Posted by bardonw

You will notice that the JXDocs indicate that all of the new arguments within these functions are optional. On the other hand, I will have to check to see if other browsers provide the map function for the Function object. If you have any other concerns, please reply.

i'm saying that Function.map is a problem to me, though I'd be fine with Function.each(), or Function.map2()...

Also, even if your new method's arguments are optional, they are present. this means that your methods could grab, for example, the 3rd argument of a [].map'd function, whereas the native method would discard it. Given the spec's instance that most of Array's and String's native methods be generic, this implies your code is not 100% compatible with native methods, and why i mentioned it as a problem.

I didn't notice anything on Object.prototype, but if you are using it, that's another major no-go for a lot of coders. True, it's arguably their fault they don't know how to iterate an array, but at the same time, libraries should strive for interoperability with the lowest of denominators...

also, try to limit the lib to just one global variable. you're pretty close to 1 already; good job not polluting the entire namespace!

Don't get me wrong, and i apologize for being a bummer; 90% of your code is solid, but the "last mile" problems might keep folks from adopting it, and that's a bummer in itself...

[bardonw]

Originally Posted by rnd me

i'm saying that Function.map is a problem to me, though I'd be fine with Function.each(), or Function.map2()...

Also, even if your new method's arguments are optional, they are present. this means that your methods could grab, for example, the 3rd argument of a [].map'd function, whereas the native method would discard it. Given the spec's instance that most of Array's and String's native methods be generic, this implies your code is not 100% compatible with native methods, and why i mentioned it as a problem.

I didn't notice anything on Object.prototype, but if you are using it, that's another major no-go for a lot of coders. True, it's arguably their fault they don't know how to iterate an array, but at the same time, libraries should strive for interoperability with the lowest of denominators...

also, try to limit the lib to just one global variable. you're pretty close to 1 already; good job not polluting the entire namespace!

Don't get me wrong, and i apologize for being a bummer; 90% of your code is solid, but the "last mile" problems might keep folks from adopting it, and that's a bummer in itself...

Thank you for carifying about the ambiguous map function, but I can not find a browser which provides one for the Function object. Can you tell me ASAP which browser type and version you are using so that I can try to come up with a solution for this problem.

I have to agree with you about using my modified prototype functions with extra parameters. If a newbie uses extra parameters by accident for functions that are native to JavaScript, he or she may receive unwanted results.

You are right about there being no Object.prototype functions. I did not add any because IE doesn't work as expected when creating functions for this object. What I mean't to say in one of my previous posts was object.prototype.

I do realize that there can be some disadvantages to using a JavaScript library, but I figured that I would still give people a chance to use it anyway. I originally made it for a school project (a transcript viewer) but now I am finding it useful for all of my web pages and HTAs.

In response to using this with another JavaScript library, I would advise using the StdLib version. The StdLib version doesn't overwrite the "$" selector function presented in jQuery and other popular JavaScript libraries. On the other hand, using the StdLib will still give the user the ability to use the additional Array, Function, Color and String methods available in JXtension.

The last thing is, I don't play on adding any more variable names. Once again, I agree with you 100% that JavaScript libraries should not reserve too many variable names for themselves. This is why I have tried to limit it to the following:

1. JXtension
2. $
3. Color
4. parseArray
5. xor
6. $_GET

I may change parseArray, xor and $_GET so that they are members of the JXtension object in the future. The problem with doing this is any code that I or others may write using JXtension v1.0 will not be compatible with higher versions. Do you have any suggestions rnd me?

Thanks,
Chris West

[rnd me]

Originally Posted by bardonw

I may change parseArray, xor and $_GET so that they are members of the JXtension object in the future. The problem with doing this is any code that I or others may write using JXtension v1.0 will not be compatible with higher versions. Do you have any suggestions rnd me?
Thanks,
Chris West

yes, a few.
firstly, nobody wants to type "JXtension", make it "jx" or something (fewer buttons the better)

suggestions:

1. create a backwards-compatible trigger mode which appends window.x with each prop of jx.

2. wrap "with(jx){" (...) "};" around code authored for the old lib

3. write a textarea-based conversion kit for your old library's programmers that replaces the old string names with new property paths.

4. use a local-scope wrapper to dupe jx.x into vars:

(function(){
 var parseArray=jx.parseArray, Color=jx.Color;
}());

5. forget about backwards compat and move forward with a perfect design and implementation.

Just to clarify, no browser offers Function.map, but adding it will foil duck-typers like myself...

[barkermn01]

No Offence but Boo,

There is Already YUI, JQuery, Prototype, Moo-tools and lots more out there and there is not allot of point only idiots or lazy people use them,

Coz they are JavaScript coded which means any thing they do you can do in javascript so you learn how to that way your not using a library and downloading more then required to the users browser

[bardonw]

Originally Posted by barkermn01

No Offence but Boo,

There is Already YUI, JQuery, Prototype, Moo-tools and lots more out there and there is not allot of point only idiots or lazy people use them,

Coz they are JavaScript coded which means any thing they do you can do in javascript so you learn how to that way your not using a library and downloading more then required to the users browser

I agree that there is no need for a JavaScript library in some cases if you are well versed in JavaScript. On the other hand, there are a number times when libraries can be very useful, even for the advanced users such as yourself. I will be using JXtension for now on when developing new web content because I would like to easily obtain references to HTML objects based on certain criteria. This way, I will be able to style my pages in ways that are not available by using CSS (unless you decide to reference each element by class, tag name, or id).

Another thing that you need to remember is that not all web programmers are well versed in JavaScript. Therefore, these people would also like to use JavaScript libraries such as jQuery. Even if they do not choose to use JXtension, I want people to know that there are other options which provide similar functionality and have a smaller footprint.

[barkermn01]

Originally Posted by bardonw

I agree that there is no need for a JavaScript library in some cases if you are well versed in JavaScript. On the other hand, there are a number times when libraries can be very useful, even for the advanced users such as yourself. I will be using JXtension for now on when developing new web content because I would like to easily obtain references to HTML objects based on certain criteria. This way, I will be able to style my pages in ways that are not available by using CSS (unless you decide to reference each element by class, tag name, or id).

Another thing that you need to remember is that not all web programmers are well versed in JavaScript. Therefore, these people would also like to use JavaScript libraries such as jQuery. Even if they do not choose to use JXtension, I want people to know that there are other options which provide similar functionality and have a smaller footprint.

I know this but it becomes a problem i work for a company where the staff know Jquery but not JavaScript this then creates problems,

If some thing cant be done in JQuery then i have program a JQuery Addon to do it for them,

Also the Selector is easy to do
get the string split on space if first char is "." or "#" do you finders E.G if its #

document.getElementById(*String with out #*)

And Class is a bit harder but none the less quite easy

[oesxyl]

Originally Posted by barkermn01

I know this but it becomes a problem i work for a company where the staff know Jquery but not JavaScript this then creates problems,

If some thing cant be done in JQuery then i have program a JQuery Addon to do it for them,

they pay people who know jquery but don't know javascript? tell me more about this, but post please in the geek and humor forum,
forget about geek,

best regards

[rnd me]

Originally Posted by oesxyl

they pay people who know jquery but don't know javascript?

yeah, under the guise of "designers" and "administrators"...

bardonw: keep up the good fight. Perhaps nobody will ever use JXtension, but they might use the next one you make, or the one after that; you never know what will takeoff...