> 1) i've got a philosophical beef with the change in clone()'s
> behaviour. Calling clone(false) is not functionally the same as
> calling clone().empty(), as clone().empty() can require an arbitrarily
> large amount of extra work which will then be discarded by the empty()
> call. i rather liked the option to deep- or shallow-clone an object
> (though i admittedly only used deep copying once, preferring shallow
> clone for most of my use cases to date).
Only using shallow copy? You're definitely in a very, very, small
minority, then. What are the use cases for shallow copying a large DOM
structure, that has a ton of child elements?
When analyzing the feature, we were unable to find any uses of shallow cloning.
> 2) i'm at a complete loss to understand why the load/getIfModified()
> convenience funcs were removed. To save a few bytes in the core lib?
> If so, those bytes have simply moved into client code (in the form of
> the more verbose $.ajax() call), possibly multiple times (once per
> call point). The end result is probably a net enlargement of included
> JS, IMO.
Because we want to move away from one-use specialty methods. arguing
against the removal would be the same as arguing for the inclusion of
getIfNotCached or getSynchronous. It doesn't make sense to reduce the
user to using a single option, when they should be using the
much-more-powerful $.ajax() function.
I'm confused about your complaint of file size, as well - we're
literally talking about the difference between:
$.get("url") and
$.ajax({url: "url", ifModified: true});
> 3) eq()/lt()/gt() are dead. Long live eq()/lt()/gt(). Again, the
> client-side code doubles from lt(3) to slice(0,3) (5 chars to 10
> chars). If i hung out on the developer's list i would probably
> understand the reasoning behind deprecating eq/lt/gt, but since i
> don't hang out on that list i'll just grumble about the change.
You don't have to hang on the dev list to be in tune with what's
happening. These changes were put up on the wiki back in mid-June:
http://docs.jquery.com/JQuery_1.2_Roadmap
and subsequently announced with jQuery 1.1.3 (July 1st) and again with
jQuery 1.1.4 (Aug. 24th).
That being said, those method - 3 of them - were specialty methods
that were only capable of performing one task - and they weren't
terribly good at it either, as they had to interact with the selector
engine in order to use it (which is, comparably, quite slow). Slice is
a couple things: 1) Faster. 2) Uses an existing idiom, making it
easier to use and learn. 3) More Powerful. 4) A reduction of the API.
> 4) $(...).evalScripts() automatically happens now. Does that mean that
> if i load the JS code of a script for display (e.g. a "view code" link
> which load()s the code), that the loaded code is now executed? If so,
> i think that's evil. If not, ignore this item.
No, "evalScripts" only occurs when when HTML is injected into the DOM
- so if you load HTML from a remote page, the scripts contained in the
HTML won't be executed until the HTML is actually inserted into the
document.
--John
