Any criticism on my JavaScript micro-library?

Question

I made this little library for personal use to make javascripting faster and easier. I would like to know if there are any inefficiencies in it (in size and performance) and possibly if there is a feature you think is missing that would be useful.

//PUT ALL CODE AT THE END OF THE PAGE!!!!!! THIS IS UBER IMPORTANT

//document shorthand
doc=document

//querySelectorAll shorthand
function $q(a){return doc.querySelectorAll(a)}

//returns specific element
function $(a,b){return $q(a)[b||0]}

//function to set properties in a chainable manner
Element.prototype.$p=function(a){for(b in a)this[b]=a[b];return this}

//creates a class that hides elements (notice the use of the function above)
$("head").appendChild(doc.createElement("style").$p({"innerHTML":".wqh{display:none}"}))

Element.prototype.$p({
"removeClass":function(a){this.classList.remove(a)},
"addClass":function(a){this.classList.add(a)},
"hide":function(){this.addClass("wqh")},
"show":function(){this.removeClass("wqh")},
//loads content of a file inside the element, example: element.load("random file.txt")
"load":function(a,b,c){c=this;b=new XMLHttpRequest;b.open("GET",a,!0);b.send();b.onreadystatechange=function(){c.innerHTML=b.responseText}}
})

Example of its uses:

$(".test").addClass("red")
$(".test",1).removeClass("big")
$(".test",2).hide()

for(a in b=$q("p"))
b[a].style.fontFamily="serif",
b[a].style.color="blue",
b[a].style.fontSize="20px";

More readable version of the $p() function:

//function to set properties in a chainable manner
Element.prototype.$p = function(proplist){
    var property;
    for(property in proplist){this[property] = proplist[property]}
    return this;
}

Answer 1

Problems with it :

• in the global namespace
• use of innerHTML
• no cross-compatibility
• messing with object prototypes
• quite useless

Answer 2

Going off a little on what others have mentioned, I have a couple of main criticisms:

1. Manually minified -- it's really difficult to get an idea of what you're really trying to do here. I understand that you don't trust minifiers, but the reason people use those instead of always just writing small code by hand is so that they (and other developers) can make sense of the code when they're working on it, and yet still provide an optimized version for production.
2. The use of doc as your shorthand -- general concerns about global variables aside, that's just a bad name for a library shortcut variable. What if someone using your library needs a variable named doc, to represent something the user uploads (for example)? Sure they can sort it all out using correct scoping rules, but it'd be too easy for them to forget about it, maybe put their own variable in the global namespace, and then either their code breaks or your library breaks. If you create a namespace for your library, then you can isolate doc from the user's code, and you'll be fine.
3. Modifying existing object prototypes -- really, I could go either way on this. I've used the Prototype library, which did a lot of that, and it was really nice. I'm also aware that it can really confuse developers, and it can even cause problems. It's generally frowned upon by most "best practices" lists I've seen, so while I wouldn't avoid it completely, I'd recommend using it gently when it makes more sense than creating a wrapper. That's probably one of the bigger selling points jQuery offers -- it creates a wrapper object instead of working with the direct JS object prototypes, so code that's expecting the additional functionality can use it, and code that might somehow rely on the original implementation won't know the difference.

I'd really like to see the code in a non-minified, at least somewhat commented/documented format -- especially Element.prototype.$p. That function looks interesting, but I'm having a hard time following along with it as a one-liner with arguments simply named a and b. Especially the for .. in condition -- a in b=a? I've never come across an assignment used like that before. I'm not saying it's wrong by any means, and maybe it's really common and I just missed it in my journeys, but it doesn't seem very intuitive or easily understandable; that would definitely be worth a couple of comments explaining what it does.

Hope this helps -- or at least makes sense even if it doesn't.

Answer 3

The only thing that I can see is that b is escaping into the global scope in $p(). However, b doesn't seem to be accessed globally anywhere else in the code you have posted so I only mention it as something to be careful of for future expansion.

You can avoid this without having to use a var statement by including a parameter b to $p and never passing a value for it:

Element.prototype.$p=function(a,b){for(b in a)this[b]=a[b];return this}

Answer 4

For returning a specific element I would recommend using document.queryselector when no index is provided as it would be more apt.

This might be especially appropriate in the edge case that a very large list could be returned. querySelector could also be optimised by the browser.

For example if($('li')) { ... } to check if a list item is present at all within the page.

Answer 5

Others have commented on the general idea of this library, I agree. You should only use this for one-man projects.

Still,

function $q(a){return doc.querySelectorAll(a)}

could be simply $q = doc.querySelectorAll;

Also this seems overkill:

//creates a class that hides elements (notice the use of the function above)
$("head").appendChild(doc.createElement("style").$p({"innerHTML":".wqh{display:none}"}))

It just makes much more sense to have this in a css file and give it a proper name like hidden.

Finally, if you are going for short, you might as well use d instead of doc.