JavaScript / jQuery: Your most common uses

Giblet

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.

Giblet

I guess no-one gives a **** about JavaScript! And to think I was going to tell people how to write a context driven library!

CuAnnan

Giblet wrote: »

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.

Giblet wrote: »

And if it is, how complex are your queries and why.

No more complex than they need to be.

CuAnnan

Giblet wrote: »

I guess no-one gives a **** about JavaScript! And to think I was going to tell people how to write a context driven library!

That's not a very helpful attitude.

Giblet

CuAnnan wrote: »

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.

<script>
var $;

if(document && document.querySelectorAll){
    $ = function(selector){ return document.querySelectorAll(selector);}
}
</script>
<!--[if lte IE 8]>
<script src="myEngine.js"></script>
<script>
   $ = function(selector){ return myEngine.Query(selector); }
</script>
<![endif]-->

$ is a terrible name for a function though. Query would be better.

Giblet

CuAnnan wrote: »

That's not a very helpful attitude.

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.

Creamy Goodness

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.

CuAnnan

Giblet wrote: »

jQuery fecks aorund with the this object like it made fun of it's mother.

this is not an object.

Giblet wrote: »

Why in some cases does it have to be wrapped, and some cases it returns the jQuery object itself

$(this) will always work
this will not.

Giblet wrote: »

why is it so hard to allow the user to do this, and why do events behave different from functions regarding "this"?

Because JavaScript is object based, not object oriented.

Giblet wrote: »

It also augments some objects with it's own sugar

Yes, and thank the binary digital gods it does.

Giblet wrote: »

JavaScript has the following options.
apply, call, bind and passing an object to act as a surrogate this. It's well documented.

And poorly implemented.

Giblet wrote: »

If your queries are not complex, why use Sizzle?

I use jQuery, not its spin-off project Sizzle.
And I use jQuery for to make javascript suck less. I thought I was quite clear on that.

Giblet wrote: »

Why not target either IE8+ with pure QSA?

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

Giblet wrote: »

Or even get a smaller library such as NWMatcher which works better.

What's your metric?

Seriously, I see an awful lot of personal opinion that doesn't address why I use jQuery at all.

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

CuAnnan

Giblet wrote: »

I really just want to highlight how to get things done in a concise manner with the least amount of script necessary.

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

Giblet

CuAnnan wrote: »

this is not an object.


$(this) will always work
this will not.

Exactly. You double wrap it in some cases.
this is not an object?. What do you mean by your next quote then?

Because JavaScript is object based, not object oriented.

Prototype based. this is a context defined object. It's passed with call. Hell you could have done

typeof this

returns "object"
Depends on context though, but it's not special in any case.

If you want a discussion on Host Objects, Props & Methods and the dangers of doing typeof's though...

Yes, and thank the binary digital gods it does.

Why? So it can break your code unless you fix it? (see touch events)

And poorly implemented.

Where? (I know where and I know how to fix it)

var bind;
if(Function.prototype.bind){
    bind = function(fn, thisObject) {
        return fn.bind.apply(fn, Array.prototype.slice.call(arguments, 1));
    };
}
else {
	if(!!Function.prototype.call) {
	  bind = function(fn, context) {
		var prependArgs = Array.prototype.slice.call(arguments, 2);

		if (prependArgs.length) {
		  return function() {
			fn.apply(context, Array.prototype.concat.apply(prependArgs, arguments));
		  };
		}
		return function() {
		  fn.apply(context, arguments);
		};
	  };
	}
}

You have now got bind!

I use jQuery, not its spin-off project Sizzle.

Sizzle is a dojo spin off, jQuery uses it, so yes, you use it.

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.

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.

What's your metric?

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

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.

Giblet

Creamy Goodness wrote: »

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)

Giblet

CuAnnan wrote: »

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!

CuAnnan

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.

Giblet

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.