• Querying (16%)
  • Events (20%)
  • Attribute Manipulation (12%)
  • Style Manipulation (20%)
  • Ajax / Dynamic DOM (32%)
Giblet Registered User
#1

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 Registered User
#2

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 Registered User
#3

Giblet said:
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 said:
And if it is, how complex are your queries and why.

No more complex than they need to be.

CuAnnan Registered User
#4

Giblet said:
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 Registered User
#5

CuAnnan said:
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 Registered User
#6

CuAnnan said:
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 Registered User
#7

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 Registered User
#8

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

this is not an object.

Giblet said:
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 said:
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 said:
It also augments some objects with it's own sugar

Yes, and thank the binary digital gods it does.

Giblet said:
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 said:
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 said:
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 said:
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 Registered User
#9

Giblet said:
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 Registered User
#10

Giblet Registered User
#11

Creamy Goodness said:
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 Registered User
#12

CuAnnan said:
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 Registered User
#13

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 Registered User
#14

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.

Want to share your thoughts?

Login here to discuss!