JQuery 1.4 released(jquery14.com) |
JQuery 1.4 released(jquery14.com) |
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...)
Exports: http://code.google.com/closure/compiler/docs/api-tutorial3.h...
Extern: http://code.google.com/closure/compiler/docs/api-tutorial3.h...
The hyperlink on "(Commit)" is broken.
See here: http://api.jquery.com/live/
FWIW, I do use a $.bind method that I got from somewhere in my own jQuery code.
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.
edit: and yes, 4x is a constant fraction, as opposed to an asymptotic improvement. :)
Great work - coding javascript is seriously easier than it was before JQuery came along.
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.
Traditionally, you would do something like this:
$('td').click(function () { makeCellEditable(this); } );
Although this would work, binding 1000 callbacks, one to each td element, will seriously impact browser performance.With live events the syntax is very similar:
$('td').live('click', function () { makeCellEditable(this); } );
The difference is we've only bound 1 event, so the browser's performance will not be adversely affected.Hope that helps.
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.
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.