They're using the Google Closure compiler as their minifier now.
Resig in this presentation (warning: video autoplay), in response to the last question, said that while it's slick if you simply throw jquery into it you'll just get broken javascript out: http://developer.yahoo.com/yui/theater/video.php?v=resig-tes...
I wonder what has changed?
Yeah, we only use simple mode - it's advanced mode that everyone needs to watch out for - it doesn't do what you expect (it's optimized for combining multiple files, not producing one file).
If you carefully read the instructions, you can learn how to compile libraries with it - there is explicit support for this use case. (which is likely what jQuery have done.)
Actually it's not really efficient for us to do that - since we would need to expose literally everything and in the end we would end up with the same result as running it through the simple minifier. As it turns out though the simple minifier is quite good - giving us a 13% improvement over YUI Min.
In a nutshell you can bind to selectors dynamically - so if content gets added to the document that matches an existing Live binding, jQuery will go ahead and create the binding for you. It didn't work with all event types in previous versions of jQuery; now it seems that they're essentially all covered.
That's a good explanation, but its not actually that jQuery automatically binds events to the newly inserted elements, its that it takes advantage of Javascript's event bubbling to match the selector at the highest level it can.
Basically, if you had HTML like this:
<div>
<p>
<span>Hello World</span>
<p>
</div>
and the user clicks on the span, Javascript will raise a click event not only for the span but for each of its parents (p, div, body and html).
jQuery's live events take advantage of this by "trapping" the click event (or blur, focus, etc) at the highest level. This leads to 2 distinct advantages:
1) Elements inserted into a page after the script is initialized don't need to have events bound to them. (this is what defen was referencing)
2) You don't have to bind a callback to every single element.
The second can pay dividends even if there is no dynamically inserted content. For instance, lets say you have a table with 1000 cells and you want to make them editable when the user clicks on them.
What is up with the stacked bar charts used to show performance improvements in various css/html features? I can't really think of a seeing a more useless/opaque chart in quite a while. They make it impossible to do effective 1.3 -> 1.4 comparisons for specific browsers and since no one is running on all five browsers at once the weird style chosen doesn't even coherently communicate an overall point.
Which you don't see until you scroll all the way down there. What annoys me about the chart is that it is obvious how to do something like this (two bars, before & after, for each browser) and the creators of the page apparently know how to create such a graph because the first graph is exactly in this format -- it is all of the remaining graphs that use the information-free format.
This is a very standard way libraries have been presenting their speed comparison for quite awhile now. You can look at the individual slivers to get a rough estimate of the size difference, and overall cross browser comparison, and see which browsers are the slowest.
It's a very good visualization, letting one compare the same browser across two version of jquery, an aggregate of browsers across both versions, and the speed of individual browsers against each other on the same version, and individual speeds across the different versions. It's very data packed.
You cannot easily compare the same browser across two versions of jquery because each browser starts at a different point on the Y axis for each column; you cannot easily scan from one column to the next to see the difference but must jump back and forth figuring out start-end points and trying to guess at differences.
It makes it difficult to compare the individual speeds across different versions because the nature of the chart compresses the vertical space to make the larger of the two stacked bars fit into the graph, artificially compressing the Y axis (which measures the only thing we care about in this graph) and diminishing the scale for all of the items being compared.
The only thing it makes easy to see is an aggregate of browser speeds across versions (and since nothing runs on all browsers at the same time this measurement is not very valuable) and as a comparator of individual browsers against each other, which is the second least-important metric in these charts.
Take the Performance of .css() and .attr() chart. I can tell very easily that in FF 3.5, time to execute cut in half, ie 6/7/8 and Opera 10.10 are ~2/3 what it was, and safari and chrome about 1/2. You can also see that in 1.4 FF comes in third, behind safari and chrome and ahead of opera 10.10, and that ie is the slowest in order or 8,7,6.
It also shows that FF 3.5 has great gains with this release, as it was behind opera in 1.3
That's a lot of information packed into one tiny chart. Yes, diving into the specifics takes some doing, but the primary purpose of the chart is to show the overall gain in 1.4 vs. 1.3. Breakdown by browser is a bonus.
While it is possible to compare the same browser across two different version of jQuery, it's pretty difficult to do so: you need to manually "extract" the slivers from the two different bars and compare them visually, which is difficult and imprecise. I think it would be more useful to have one pair of bars for each browser (old vs. new jQuery version), and then a pair of bars for "total over all browsers" (old vs. new jQuery). That is slightly more verbose, but more useful too.
I've been a Prototype user for a few years now. I've always kept an eye on jQuery, but my knowledge of it is incredibly shallow. I have to say, I was shocked when I saw that they added the "proxy" method. This description makes it sound exactly like "bind" method in Prototype. Is that a valid comparison? If so, why did it take so long for this to appear in jQuery? At this point, I don't think I could write a snippet of javascript without relying on that method.
jQuery is a much smaller scope than Prototype or Mootools -- it doesn't try and enforce a JavaScript framework. I previously avoided it because it provided so much less general programming tools than the alternatives.
However, in the years since I made some of those technology decisions, jQuery has become the leader and thus more and more 3rd party technologies have been built around it.
I've recently switched to jQuery from mootools but I had to seek out a lot of plugins and other libraries (and build some stuff myself) to reach the same levels of capability but ultimately I'm happy with the results.
Those graphs performance graphs per browser are very confusing. I'm guessing that the individual colors show the time taken per browser, but the fact that it's stacked makes me think that the slowest ones are on top and the fastest ones are on bottom, but that can't be right since IE6 is always second from the bottom.
Congratulations to the jQuery team for the optimizations in 1.4. It's hard to believe such gains were made over 1.3 considering how significant that change was over 1.2.
This is cool. remove() was a bottleneck for my app, but a constant-fraction speedup won't be enough to fix it. I'll have to dig in and see if it actually works differently now.
Well it was taking like 20 seconds to do my cleanup. Five seconds still sucks for users. IIRC, remove has to recurse to every child to check for stored data, so I'm just removing the nodes manually and eating the tiny data memory leak.
edit: and yes, 4x is a constant fraction, as opposed to an asymptotic improvement. :)
The 4x number was wall-clock time for the particular tests - so obviously your mileage may vary. In fact, the more complicated your case the better your eventual gains will be.
Fixed a jquery 1.4 alpha related bug over at http://twidl.it for our reTwidl function! In the nick of time too (we encountered bug yesterday). Thanks Jquery team!
Resig in this presentation (warning: video autoplay), in response to the last question, said that while it's slick if you simply throw jquery into it you'll just get broken javascript out: http://developer.yahoo.com/yui/theater/video.php?v=resig-tes... I wonder what has changed?
(Maybe just not running it in advanced mode; at any rate, they're reporting a 13% decrease in file size: http://github.com/jquery/jquery/commit/3fd62eae9df3159fc238a...)