JQuery 1.4 released
jquery14.comThey'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?
(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...)
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).
Awesome, thanks. (and just donated too; thanks again!)
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.)
Exports: http://code.google.com/closure/compiler/docs/api-tutorial3.h...
Extern: http://code.google.com/closure/compiler/docs/api-tutorial3.h...
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.
# .val(“…”) on an option or a checkbox is no longer ambiguous (it will always select by value now, not by text value). (Commit)
The hyperlink on "(Commit)" is broken.
Good catch, thanks.
Thanks for jQuery :)
The performance boost is great but I think the thing I'm most excited about is "All Events Can Be Live Events". Thanks jQuery team!
I haven't looked at Live events yet, is there anywhere I can read through a rundown of what they offer?
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.
See here: http://api.jquery.com/live/
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:
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).<div> <p> <span>Hello World</span> <p> </div>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:
Although this would work, binding 1000 callbacks, one to each td element, will seriously impact browser performance.$('td').click(function () { makeCellEditable(this); } );With live events the syntax is very similar:
The difference is we've only bound 1 event, so the browser's performance will not be adversely affected.$('td').live('click', function () { makeCellEditable(this); } );Hope that helps.
Awesome! I didn't know how it actually worked. Thanks a lot!
.live() : DOM event handling :: CSS : DOM styling
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.
There's raw numbers at the very bottom of the page
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.
No, it is not a good visualization.
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.
I think you're being deliberately obtuse.
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.
"var self = this" provides a workaround that isn't too verbose, so maybe it diminished the need for "bind" enough to put it off.
FWIW, I do use a $.bind method that I got from somewhere in my own jQuery code.
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.
Live Q&A at 4pm EST. http://ustream.tv/channel/14-days-of-jquery
Making jquery.browser engine-centric is a nice touch, especially now that webkit based browsers are breeding like rabbits.
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.
They are not ordered by speed. I'm not sure how they are ordered, but the height of the color is the amount of time it takes in that browser.
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.
Constant fraction? It's a 4x speedup - that seems like more than enough to help you out!
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. :)
Actually, we did reduce the complexity to a constant: Went from n^2 to just n: http://ejohn.org/blog/function-call-profiling/
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.
Great link, thanks. Looking at the patch I can now why it's n^2 -- I didn't realize it was that bad when I looked at the code before.
That's a constant fractions... 16/4. :)
Just upgraded http://wasitup.com to jQuery 1.4 without issues.
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!
Sounds awesome. I'm going to have to update ASAP.
Great work - coding javascript is seriously easier than it was before JQuery came along.
I found the page linked under the words "reduce the complexity" ( http://ejohn.org/blog/function-call-profiling/ ) a rather exemplary tale of profile-and-optimize.
Consistently crashes Chrome 4.0.266.0 on Ubuntu
Congrats to the jQuery team!