Tell HN: jQuery is way slower than plain Javascript
http://jsperf.com/jquery-vs-document-queryselector
http://jsperf.com/jquery-css-vs-native-dom
http://www.leebrimelow.com/native-methods-jquery/
http://jsperf.com/comparing-jquery-and-native-js/11
http://jsperf.com/jquery-css-vs-native-dom
http://www.leebrimelow.com/native-methods-jquery/
http://jsperf.com/comparing-jquery-and-native-js/11
There's also the fact that you don't have to include a gigantic library of functions you'll never use, just to show a box when you click a button. 37kb is way over 10% of my ideal page load for a simple to moderate site.
i'd say 87% of the pages on the web have graphics whose importance is sketchy, and whose total size dwarfs 37k.
and since i almost always do _something_ which has been found to show cross-browser inconsistencies, the peace that jquery gives _me_ is well worth those paltry 37k...
that's me. other people might be different. but that's me.
-bowerbird
jQuery adds padding for browsers that don't support certain features or have certain quirks (yes, IE, we're mainly looking at you). This is overhead that will slow things down.
That being said, if you can afford to develop for modern browsers only, then by all means, use plain JS.
(Same applies for other, non-UI-specific JS: Need Array.forEach()? Use it. Define Array.prototype.forEach() for legacy IE, rather than piping all browsers through "MyLib.forEach(myArray, function(item) {... })".)
and i certainly don't want to do the work of figuring how to sidestep incompatibilities that _are_ present.
even if the distastefulness of _that_ was half as bad, i would still rather make my users "wait" for that 37k.
again, that's _me._ not telling anyone else how to do it.
-bowerbird