thissitesucks

> you're kidding me right? Obviously you filter your queries to the closest node.

You again. Smart-ass doesn't suit you.

Obviously, you can use standard DOM methods (e.g. gEBTN, gEBCN) with the "closest node" as well.

And, assuming you mean an element node, you just bought yourself a world of hurt. jQuery and the like will use the Selectors API (e.g. QSA) when it suits them, and due to their disagreement with the specs, element nodes don't suit them.

When they use their own query code, performance and compatibility go right down the toilet.

In other words, use QSA with the document node, unless you want to relearn how queries work.

> The single biggest performance killer... far more important than tree traversal is event overhead. As long as you think long and hard before applying a new event handler (and use delegation whenever possible) you'll be fine even with those 'Frankenstein' queries hehe :P

Again, event delegation is unrelated to queries. It's silly to assume you can use wasteful queries with impunity as long as you don't attach too many listeners.

And yeah, those "Frankenstein queries" are the exact opposite of self-documenting code (something jQuery proponents get backwards).

> If your decision not to use jQuery (or another lib that makes your life easier) is because of performance then you're optimising much too early.

LOL. That's the stupidest thing I ever heard. This is John Resig, isn't it? :)

> Personally I optimise for developer time first and raw performance much further down the line.

Yeah, you just set a new precedent. :(

> And dom querying is not usually the bottleneck in most sloppy sites...

You are allowed more than one bottleneck.

> its way too many event listeners. And jQuery comes to the rescue once again with extremely easy (to read and write) event delegation.

You just have no frame of reference.

Change your goal to something other than "learning how to program around all of the browser quirks". Why would you need to do such a thing?

And if you "enjoy" jQuery, you have no frame of reference. It's far more inconsistent than the DOM implementations and the documentation is terrible.

That's completely contrary to what I've experienced. Only browsers that "need" a little extra JS/CSS are the old IE versions. Quotes indicate you don't necessarily need to enhance pages in those browsers at all these days.

If your experiences indicate otherwise, you are simply doing something wrong.

PS. jQuery is horrible. Every time you think you've figured out all of their undocumented quirks, they change the logic. It's famously inept in IE 6/7.

Nooo... you don't.

You are one of those guys that figures anything popular must be smart. Good luck with that. :)

> But if you absolutely have to support IE6, then yeah, use JQuery.

Absolutely NOT. The results vary per jQuery version as they have been struggling to grasp the subtle differences for six years.

> Why not just use a extremely well tested library that automatically gives you full browser support?

LOL. Which library would that be?

> Having css3 query support in legacy browsers is awesome.

No it isn't as you send all of the supporting junk code to the newer browsers that don't need it.

> Not to mention productivity gains from method chaining and batch assignment such as $('.somehting').find('*').css({'font-weight': 'bold'});

Chaining has nothing to do with queries.

> Do you really want to type the 10-20 lines of JS that are required to make that happen? I don't.

Then learn to write (cross-browser) functions that fit your needs. Leave the ham-fisted queries alone.