7 ms·

JQuery 1.4 released

214 points by mati 17y ago

Raphael 17y ago
Live Q&A at 4pm EST. http://ustream.tv/channel/14-days-of-jquery http://ustream.tv/channel/14-days-of-jquery
defen 17y ago
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 17y ago
  I haven't looked at Live events yet, is there anywhere I can read through a rundown of what they offer?
  - defen 17y ago
    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/ http://api.jquery.com/live/
    - qeorge 17y ago
      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 17y ago
        Awesome! I didn't know how it actually worked. Thanks a lot!
  - tr4nslator 17y ago
    .live() : DOM event handling :: CSS : DOM styling
krakensden 17y ago
Making jquery.browser engine-centric is a nice touch, especially now that webkit based browsers are breeding like rabbits.
mark_h 17y ago
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-testing 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/3fd62eae9df3159fc238a515bb748140a942313d http://github.com/jquery/jquery/commit/3fd62eae9df3159fc238a...)
- jeresig 17y ago
  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).
  - zackattack 17y ago
    # .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.
    - jeresig 17y ago
      Good catch, thanks.
      - zackattack 17y ago
        Thanks for jQuery :)
  - mark_h 17y ago
    Awesome, thanks. (and just donated too; thanks again!)
  - TeHCrAzY 17y ago
    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.html#export http://code.google.com/closure/compiler/docs/api-tutorial3.h... Extern: http://code.google.com/closure/compiler/docs/api-tutorial3.html#externs http://code.google.com/closure/compiler/docs/api-tutorial3.h...
ableal 17y ago
I found the page linked under the words "reduce the complexity" ( http://ejohn.org/blog/function-call-profiling/ http://ejohn.org/blog/function-call-profiling/ ) a rather exemplary tale of profile-and-optimize.
uggedal 17y ago
Just upgraded http://wasitup.com http://wasitup.com to jQuery 1.4 without issues.
deleted 17y ago
[deleted]
bdr 17y ago
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 17y ago
  Constant fraction? It's a 4x speedup - that seems like more than enough to help you out!
  - seasoup 17y ago
    That's a constant fractions... 16/4. :)
  - bdr 17y ago
    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 17y ago
      Actually, we did reduce the complexity to a constant: Went from n^2 to just n: http://ejohn.org/blog/function-call-profiling/ 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 17y ago
        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.
DannoHung 17y ago
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 17y ago
  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.
evgen 17y ago
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 17y ago
  There's raw numbers at the very bottom of the page
  - evgen 17y ago
    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 17y ago
      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.
      - neilc 17y ago
        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.
zackham 17y ago
Consistently crashes Chrome 4.0.266.0 on Ubuntu
jqueryin 17y ago
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.
dlevine 17y ago
Sounds awesome. I'm going to have to update ASAP. Great work - coding javascript is seriously easier than it was before JQuery came along.
Nycto 17y ago
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 17y ago
  "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.
- wvenable 17y ago
  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.
tennisman120 17y ago
Congrats to the jQuery team!
twidlit 17y ago
Fixed a jquery 1.4 alpha related bug over at http://twidl.it http://twidl.it for our reTwidl function! In the nick of time too (we encountered bug yesterday). Thanks Jquery team!

214 points by mati 17y ago

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

defen 17y ago

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 17y ago
I haven't looked at Live events yet, is there anywhere I can read through a rundown of what they offer?
- defen 17y ago
  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/ http://api.jquery.com/live/
  - qeorge 17y ago
    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 17y ago
      Awesome! I didn't know how it actually worked. Thanks a lot!
- tr4nslator 17y ago
  .live() : DOM event handling :: CSS : DOM styling

krakensden 17y ago

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

mark_h 17y ago

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-testing 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/3fd62eae9df3159fc238a515bb748140a942313d http://github.com/jquery/jquery/commit/3fd62eae9df3159fc238a...)

jeresig 17y ago
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).
- zackattack 17y ago
  # .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.
  - jeresig 17y ago
    Good catch, thanks.
    - zackattack 17y ago
      Thanks for jQuery :)
- mark_h 17y ago
  Awesome, thanks. (and just donated too; thanks again!)
- TeHCrAzY 17y ago
  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.html#export http://code.google.com/closure/compiler/docs/api-tutorial3.h... Extern: http://code.google.com/closure/compiler/docs/api-tutorial3.html#externs http://code.google.com/closure/compiler/docs/api-tutorial3.h...

ableal 17y ago

I found the page linked under the words "reduce the complexity" ( http://ejohn.org/blog/function-call-profiling/ http://ejohn.org/blog/function-call-profiling/ ) a rather exemplary tale of profile-and-optimize.

uggedal 17y ago

Just upgraded http://wasitup.com http://wasitup.com to jQuery 1.4 without issues.

deleted 17y ago

[deleted]

bdr 17y ago

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 17y ago
Constant fraction? It's a 4x speedup - that seems like more than enough to help you out!
- seasoup 17y ago
  That's a constant fractions... 16/4. :)
- bdr 17y ago
  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 17y ago
    Actually, we did reduce the complexity to a constant: Went from n^2 to just n: http://ejohn.org/blog/function-call-profiling/ 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 17y ago
      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.

DannoHung 17y ago

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 17y ago
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.

evgen 17y ago

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 17y ago
There's raw numbers at the very bottom of the page
- evgen 17y ago
  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 17y ago
    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.
    - neilc 17y ago
      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.

zackham 17y ago

Consistently crashes Chrome 4.0.266.0 on Ubuntu

jqueryin 17y ago

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.

dlevine 17y ago

Sounds awesome. I'm going to have to update ASAP. Great work - coding javascript is seriously easier than it was before JQuery came along.

Nycto 17y ago

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 17y ago
"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.
wvenable 17y ago
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.

tennisman120 17y ago

Congrats to the jQuery team!

twidlit 17y ago

Fixed a jquery 1.4 alpha related bug over at http://twidl.it http://twidl.it for our reTwidl function! In the nick of time too (we encountered bug yesterday). Thanks Jquery team!