I'm just wondering the most common uses of JavaScript / jQuery in your day to day web development. I have a feeling myself that the most common feature is queries (as every other operation depends on queries). And if it is, how complex are your queries and why. (This is beyond simple document.getElementById) This can be a general JavaScript thread as well.

I'm just wondering the most common uses of JavaScript / jQuery in your day to day web development.

I use jQuery to make JavaScript suck less.
Javascript's object model, particularly it's esoteric and seemingly inconsistend this keyword, is a little confounding even to the JavaScript afficionado.
jQuery allows you to always have a handy reference to what this would mean in a more object oriented context.

Its DOM and AJAX stuff are nice, too, but mostly I use it because it's convenient.

I use jQuery to make JavaScript suck less.
Javascript's object model, particularly it's esoteric and seemingly inconsistend this keyword, is a little confounding even to the JavaScript afficionado.
jQuery allows you to always have a handy reference to what this would mean in a more object oriented context.

Its DOM and AJAX stuff are nice, too, but mostly I use it because it's convenient.

No more complex than they need to be.

jQuery fecks around with the this object like it made fun of it's mother. Why in some cases does it have to be wrapped, and some cases it returns the jQuery object itself, why is it so hard to allow the user to do this, and why do events behave different from functions regarding "this"? It also augments some objects with it's own sugar (breaks the original functionality see: originalEvent);

JavaScript has the following options.
apply, call, bind and passing an object to act as a surrogate this. It's well documented. Functions in window scope have this = window. Calling in object scope makes this = the object. Apply, call and bind can assign these to whatever you wish. It's a context object.

If your queries are not complex, why use Sizzle? Why not target either IE8+ with pure QSA? Or even get a smaller library such as NWMatcher which works better. All these engines use QSA anyway unless it's sub IE8, and they are painfully slow in those contexts. Use conditionals to load a query engine into sub IE8 and you've gotten rid of a lot of extra wasted space. Even better, don't write queries at all, learn how to traverse the DOM for your commons cases.

It's not my attitude that's meant to be helpful. The code will suffice. Anyway, I'll dig less into jQuery, I really just want to highlight how to get things done in a concise manner with the least amount of script necessary.

most recently, it's been used for handlebars.js templates to help with heaps of repeating data and reducing the amount of unnecessary and redundant code being created with the help of handlebars helpers.

precompiled templates sent to the user on first visit to the site, 10k json responses sent via ajax after that is quite efficient.

And I use jQuery for to make javascript suck less. I thought I was quite clear on that.

I don't think it's JavaScript that sucks.

Quote:

Because I don't write Internet Explorer applications.
I don't even use Windows to develop.

It works in all current browsers (webkit, trident, mozilla) besides IE browsers less than IE8 and other edge cases. Good news! You can use it right now.

Quote:

What's your metric?

JSPerf. Or do you want to compare a native function to a wrapper of a native function?

Quote:

Quite frankly I'm not sure I should be listening to your advice on JavaScript development at all.

Why not? Do I not know what I'm talking about? Or do you just not want to learn?

Also, my personal opinion doesn't matter. Ask the right questions, I'll give you the answers if you need. jQuery is not a context driven API, so if you need one, you need to write it yourself. If you don't, fine! People who might need one.
Mobile Application developers.
Low Powered Devices.

Adding a huge library isn't going to help. People on shared hosting deliverin 90k (no gzipping on many shared hosts) scripts to mobile devices that won't cache the data might want a solution.

If you don't need this, then why continue to bash Answer the poll if you'd like though.

most recently, it's been used for handlebars.js templates to help with heaps of repeating data and reducing the amount of unnecessary and redundant code being created with the help of handlebars helpers.

precompiled templates sent to the user on first visit to the site, 10k json responses sent via ajax after that is quite efficient.

I've used something similar before (I've moved away from this though, but it's still nice). I can see the advantage if you were continuously loading json data to be templated and you always had the same cached template loaded (or inlined), and the templates remind me of Razor. I use server side snippets more though, for big loads of JSON, the JSON might have more overhead than sending the processed HTML! (If the JSON contains a serialised object for example, you might not use all of that object in generating a list, but the whole things gets sent down the wire unless you just send the required properties, most frameworks do the full object by default or rather it's the most common thing done, which is why it's important to highlight)

You haven't. At all. You've been really obscure and not very highlighty at all.

I've gleamed you need an XMLHttpRequest Wrapper (you don't use IE, so you don't need to probe for ActiveX objects!), document.querySelectorAll (which i've provided). And you need bind it seems! (which i've provided).

That's about 2k of script, or 15k if you need to get a query selector engine in there which in fairness is mostly for older IE (still under the iphone limit and about 4k if you count gzip which iPhone doesn't unfortunately). If it's obscure, I'm sorry, but can you see the point of what I'm doing at least? You might not do the sort of development that needs granular scripting to improve performance, which is lucky!

No, I use jQuery because it makes DHTML generation on the fly (particuarly regarding binding events) easier to cross platform. It gives a consistent, cross platform, reference to the calling object. I like its XHR wrapper. I use its Tree walking abilities in processing returned XML.

I'd say I use about 60-80% of jQuery's functionality, project dependant.

Event delegation for dynamic DOM is trivial, it's taken until 1.7 for jQuery to have a unified method of doing so. Again, creating a consistent, cross platform reference to the calling object is also trivial. You just write a wrapper to handle forking for different browsers (I mean, jQuery can't do anything JavaScript can't do). Fair enough about the XHR wrapper, although they've gone and changed that again. And DOM is a pretty simple node list to traverse, which is handy for XML. Although jQuery can mess this up with expando properties and should never be used for XML if you are serious into accurate processing of properties (jQuery will in some cases create new properties on the fly just by calling .attr / .data but you could do this yourself anyway if you didn't know what properties your XML had)

Again, you have use for jQuery, I want to talk about how to get to the root of what people need rather than throwing the kitchen sink at a problem. I think I can help with that.