Remove POS selectors

[timmywil]

Of all of the features in Sizzle, positional selectors (:first, :last, :eq, etc.) are the most cumbersome and problematic. If these were removed from Sizzle, it would greatly simplify the codebase, reduce code size drastically, and set Sizzle on the same track as the Selectors spec. Obviously, this would have a major impact on user code, but we could start with a branch and make it an optional replacement in jQuery. Hopefully, we could see positional selectors phase out of Sizzle completely some time in the distant future.

Note: this is a much more significant size decrease than dropping old IE.

[mgol]

You mean in 3.0?

[timmywil]

Yea, thanks

[timmywil]

Actually, may not be 3.0 either.

[gibson042]

This is a HUGE change, but I'd be much happier with a POS-free Sizzle. How can properly we evaluate the palatability of dropping those selectors, though?

[timmywil]

@gibson042 I figure we can start by keeping it separate from Sizzle master and see how much traction we can get.

[alexandernst]

I can't really see any third-party-developers benefit from this. The entire idea behind jQuery is "let me do things easily, whitouht having to implement them myself". If you start stripping features just because jQuery is getting fat, you're basically giving up the idea behind jQuery.

[timmywil]

The benefit is not just size/simplicity. These selectors were created before qSA existed and we've discouraged their use since then. Even if they don't get removed, don't use them. The better alternative is to use POS methods like .first().

[alexandernst]

Just to be sure I'm not missing anything here. Can't .first() and :first use the same "internal" codepath? And If "yes", why should that be even a thing to discuss? I mean, if .first() and :first perform exactly the same way, why aim at removing the selector?

I can't see any pros, while I can see huge cons, like breaking pretty much every single jquery-based code.

[dmethvin]

The selector syntax is its own language that must be parsed and executed. That's Sizzle's job. The :first selector is parsed by Sizzle. The .first() method is inside jQuery, not Sizzle. But even if Sizzle called jQuery, it would still need to parse the selector. That's the hard part, not the one line of JavaScript that takes the first element of a collection.

The entire idea behind jQuery is "let me do things easily, without having to implement them myself".

Right, but we would prefer to let people do things that represent good performance and best web practices. A gun can shoot your foot easily, but that is generally not considered best practice. Over time we've removed things like jQuery.browser that are definitely not good practice, yet we have provided comprehensive tools such as jQuery Migrate to ease the transition.

[alexandernst]

You're mixing good-practices with easy-to-use tools.
Checking the browser with jQuery.browser is a bad practice, and we all agree on that. But stripping features that ease the development because they might add a small performance penalization (prove me that parsing a selector is actually that big performance hit) is a hole another thing.

A selector (instead of a call to a method inside jQuery) that would add a few ms to the total amount of time required to do the thing is hitting the 99.99% of the "yeah, I can live with an extra 15ms in my code" cases. Now, for the other 0.01% of the cases that actually use :first to iterate a bazillion elements, well... they're doing it wrong anyways, the extra 15ms per call is probably not what is causing the "this code is dog slow!" problem.

Long story short: don't try to over-optimize jQuery by stripping useful (and used!) functions just to make it faster and lighter, because in the end of the day you're trading speed for developer's time (which is why jQuery exists in the first place).