JQuery 1.3.2 Released. | Hacker News Reader

JQuery 1.3.2 Released.

docs.jquery.com

31 pointsazharcs18 comments

The test suite has broken 1500 tests (1504, to be precise).

Maybe "surpassed" would be a better verb here.

Those are some very substantial speed improvements. Great to see, especially since this was just a point release.

We want to make sure there's some nice candy for those who upgrade. Getting people to upgrade can be tricky - we do our best to reduce any outstanding bugs (1.3.1 and 1.3.2 have helped here) but having a carrot on the end of the stick helps a lot, as well.

Way to go, John. I think it's safe to say the developer community really appreciates your carrots!

I love jQuery so much... it's exactly what a JS framework should be: easy ways to select and modify DOM elements. The new visibility stuff is great! I've always dreaded having to deal with "...but are its parents visible?"

There are some things jQuery isn't too great at (event normalization is slow in IE, for example, and .remove() kills events and data), but I've never not been able to easily extend jQuery to use my own implementation.

Thanks again for jQuery.

Glad you're enjoying it so much!

As to the points you mention: "event normalization is slow in IE" Do you have any information on this? This should've gotten faster in 1.3 - but it's definitely something that we would want to improve, if that's not the case.

".remove() kills events and data" I agree that's lame. I have a new method penciled in on the roadmap: .extract() - it removes an element from the DOM but keeps all the data intact. I think this is what you're looking for!

As per the IE performance... I usually feel the inclination to dig deeper and figure out what the cause is, but not this time. It only reared its head because it was on mousemove, which obviously gets fired a lot. I have a hunch it's in computing the source element in certain cases, like floats or absolutely positioned things.

To get around this, I use my own event normalization that seems to work across all browsers and only normalizes what I need in any given project, for example:

  var e = e || window.event;
  var fixed_e = {};
  fixed_e.pageX = document.all ? e.clientX + truebody.scrollLeft : e.pageX;
  fixed_e.pageY = document.all ? e.clientY + truebody.scrollTop : e.pageY;
  fixed_e.X = (e.offsetX ? e.offsetX : e.layerX) || 0;
  fixed_e.Y = (e.offsetY ? e.offsetY : e.layerY) || 0;
  fixed_e.source = e.target ? e.target : e.srcElement;

Another problem with jQuery events is unbinding is tricky.. I don't like how I have to have a reference to the bound function laying around somewhere so that I can unbind it. In my event system, adding an event returns a handle, which allows you to simple call ".detach()" or ".attach()" or ".trigger()" .. it's worked out very well for me.

As per the remove, I added a simple extension that's worked perfectly:

  $.fn.rm = function(){ 
    return this.each(
      function(){
        if (!this.parentNode) return;	//already removed.
        this.parentNode.removeChild(this); 
      }
    ); 
  }

You can take a look at the event fixing code here: http://dev.jquery.com/browser/trunk/jquery/src/event.js#L285

There's really not much to it - and it's really not much different from the code that you show above. A lot has changed since 1.3 so if you're still having problems, perhaps its not here and with some other aspect of the event handling code. Any more input would definitely be appreciated.

"I don't like how I have to have a reference to the bound function laying around somewhere so that I can unbind it."

Here are a couple ways to unbind an event handler without needing the original function.

  $("div").bind("click", function(){});
  
  // Unbind all bound events
  $("div").unbind();
  
  // Unbind all click events
  $("div").unbind("click");
  
  $("div").bind("click.tmp", function(){});
  
  // Unbind all click events with the name 'tmp'
  $("div").unbind("click.tmp");

The last one is probably what you want.

Sometime today I'll try to reproduce the conditions. It was definitely event fixing (or something in jQuery) that did it, because even if I cleared out the mousemove function, it would still be laggy. But if I didn't bind it, the lag would go away.

You're right, the event namespacing was exactly what I was looking for.

BTW, is there a list of "reserved" words in jQuery? For example, jQuery has to store this information somewhere... possibly it gets attached to the DOM element itself. Where does ".data()" live? I often directly access the DOM elements, and want to be sure I don't interfere with jQuery.

Update: I don't see myself having time to set-up a situation where IE lags... I've got so much stuff on my plate -- trying to launch in a week. Sorry John!

We maintain all of the element data (including events, etc.) in an internal data store. We attach a single expando to an element - whose name is randomly generated (this allows jQuery to, not only, co-exist with other libraries but also to coexist with other copies of jQuery, since there'll never be a collision with the name). I hope this helps to clear it up.

Incredible job as always. Congrats to all jQuery team. What are the problems with Opera 10 alpha?

In our tests it seems as if an input's .enabled property gets messed up if it's inside of a display:none element. This causes some tests to fail in our suite. This may be the only problem, but we'll have to wait for beta 2 to find out.

This is a perfect example of how you should release new versions of code.

A well written explanation and good visualizations and statistics of what changed (with the appropriate credit due).

It makes me want to upgrade instead of begrudgingly do so.

Extremely important update if you care about your IE users. In 1.3.1, ready() was broke in IE so it only ran on window.load instead of DOM ready. I'd recommend upgrading asap.

I can't say enough good things about jQuery. I did a google search for "jQuery changed my life" but not much came back :-(

truly the live callback has allowed me to do all sorts of crazy and creative stuff with my apps. Thank you.

While all these updates seems welcome, I'm a tad sceptical against changing API-behaviour in minor versions.

That way I can know an upgrade from 1.3.1 to 1.3.2 is safe across the board.

Reply on news.ycombinator.com