

JQuery 1.4 released - mati
http://jquery14.com/day-01/jquery-14

======
mark_h
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...](http://developer.yahoo.com/yui/theater/video.php?v=resig-testing) 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...](http://github.com/jquery/jquery/commit/3fd62eae9df3159fc238a515bb748140a942313d))

~~~
jeresig
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).

~~~
TeHCrAzY
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...](http://code.google.com/closure/compiler/docs/api-
tutorial3.html#export)

Extern: [http://code.google.com/closure/compiler/docs/api-
tutorial3.h...](http://code.google.com/closure/compiler/docs/api-
tutorial3.html#externs)

~~~
jeresig
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.

------
defen
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!

~~~
TeHCrAzY
I haven't looked at Live events yet, is there anywhere I can read through a
rundown of what they offer?

~~~
defen
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/>

~~~
qeorge
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.

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.

~~~
defen
Awesome! I didn't know how it actually worked. Thanks a lot!

------
evgen
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.

~~~
FiReaNG3L
There's raw numbers at the very bottom of the page

~~~
evgen
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.

~~~
seasoup
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.

~~~
evgen
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.

~~~
seasoup
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.

------
Nycto
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.

~~~
mcav
"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.

------
Raphael
Live Q&A at 4pm EST. <http://ustream.tv/channel/14-days-of-jquery>

------
krakensden
Making jquery.browser engine-centric is a nice touch, especially now that
webkit based browsers are breeding like rabbits.

------
DannoHung
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.

~~~
seasoup
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.

------
jqueryin
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.

------
bdr
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.

~~~
jeresig
Constant fraction? It's a 4x speedup - that seems like more than enough to
help you out!

~~~
bdr
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. :)

~~~
jeresig
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.

~~~
bdr
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.

------
uggedal
Just upgraded <http://wasitup.com> to jQuery 1.4 without issues.

------
twidlit
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!

------
dlevine
Sounds awesome. I'm going to have to update ASAP.

Great work - coding javascript is seriously easier than it was before JQuery
came along.

------
ableal
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.

------
zackham
Consistently crashes Chrome 4.0.266.0 on Ubuntu

------
tennisman120
Congrats to the jQuery team!

