17

When is jQuery going to get updated to the latest version?

The event.layerX and event.layerY are broken and deprecated in WebKit. They will be removed from the engine in the near future. messages look bad.

Besides the fact that the messages look bad (perhaps not the best reason for an upgrade) is there a technical reason to not upgrade (just curious)?

Now that we can't use: If it ain't broken don't fix it.

Although broken is a big word :)

Or is the jQuery update already being tested / in progress or something?

Improve this question
0

2 Answers 2

Reset to default
6

As of January 3, 2012, Meta uses jQuery 1.7.1.

Improve this answer
37

Now that we can't use: If it ain't broken don't fix it.

That's precisely the answer, and I don't see why we shouldn't be able to use it. The event.layerX deprecation warning scare crow has been running around the internet for a while now, but so far, these warnings haven't appeared yet. Note that the question you link to is about the canary build; if we started considering that a supported browser, we'd have no time to answer Meta questions anymore, being knee-deep in Chrome bugs 24/7.

That said, the reasons we upgrade the jQuery version are usually one of these:

  1. Plain ol' bug-fixes. Something is broken in the jQuery version we use, and fixed in a later one. "Broken" is defined as "actually impacts us". An issue that causes IE6 to puke when appending a flash object to the DOM if your Windows ME machine has less then 128MB of RAM does not make jQuery broken for us.
  2. Awesome features. The reason to upgrade to jQuery 1.5 were Deferred objects. Pretty much the only reason. They rock, are useful all over the place, etc. Did I mention that I love them? (And yes, I'm looking forward to .always(), which was only added in 1.6, but that alone is not a reason to upgrade.)
  3. Somewhere in between those two: jQuery fixes an issue we're having (work around a browser bug etc.). Now one of these usually isn't enough to make us upgrade, but they can stack.

Well, if we suddenly find ourselves in 2028 and still running jQuery 1.5, that may be a hint as well…

Anyway, what we definitely don't do is upgrading for the sake of upgrading. An upgrade always comes with issues; often very subtle ones.

Example: Until a few months ago, chat was still running jQuery 1.4.2 (I know, shudder, right?); however, when we made some changes to the list of "people in this room", something broke with the animations. This was a bug in jQuery 1.4 causing animation of the width of a display:inline-block element to fail. That bug was fixed in 1.5, so I upgraded chat to use the same version as the main site.

It took a long time until someone noticed that this silently broke the "replied-to message" highlighting in the transcript – because between these versions, $().live("hover", ...) was changed from raising mouseover events to mouseenter events.

Things like that are the reason why we don't upgrade just so. In particular, we very much avoid upgrading to 1.x.0 versions; experience has shown that rule number 1 (above) will make us upgrade to 1.x.1 very soon anyway.

Now, when/if the deprecation warnings start appearing all over the place, that will probably be a good reason to upgrade. It's not like we don't like using the shiny new stuff; it's just that such an upgrade always comes with maintenance costs.

Update: Meta is now running on jQuery 1.7.1, we'll be monitoring it for issues for a while and then roll it out to the rest of the sites.

Improve this answer
8
  • 3
    Why the change now?
    – Martin.
    Commented Jan 3, 2012 at 12:06
  • @Martin: As I said, when/if the deprecation warnings start appearing all over the place, that will probably be a good reason to upgrade
    – balpha StaffMod
    Commented Jan 3, 2012 at 12:22
  • @balpha Until a few months ago, chat was still running jQuery 1.4.2 (I know, shudder, right?); What really made me 'shudder' is the fact that .live() was used instead of .delegate() on jQuery 1.4.2
    – PeeHaa
    Commented Jan 3, 2012 at 17:50
  • @PeeHaa: .delegate() was only added in jQuery 1.4.2, chat was started with an earlier version. Not to mention the fact that .live(".sel", ...) is just fine when you mean $(document).delegate(".sel", ...) (or these days, $(document).on(..., ".sel"))
    – balpha StaffMod
    Commented Jan 3, 2012 at 18:11
  • @balpha just curious: do you guys upgrade your code when a new version if something comes out with performance benefits (either client / server side)? Or is the same answer applicable as in your answer above? This isn't an attack on anyone I'm just curious how you guys handle such things.
    – PeeHaa
    Commented Jan 3, 2012 at 18:15
  • 1
    @PeeHaa: If there's actual benefits -- sure. The code is in constant flow; in particular when changing something else and noticing, "hey this can be improved with the current jQuery version", nothing speaks against updating stuff. What we don't do (to stay with the example) is say "hey, we've got .delegate now, let's kill .live() everywhere". In particular when it's totally unnecessary (as far as actual performance is concerned, not theoretical one).
    – balpha StaffMod
    Commented Jan 3, 2012 at 18:19
  • @balpha Ok. Thanks! Just one more last question though. What do you mean with theoretical performance?
    – PeeHaa
    Commented Jan 3, 2012 at 18:21
  • 2
    @PeeHaa: Obviously it's more effecient to pick the closest-possible container as the delegate, but in most cases, the actual benefit you get from that is so low that even spending a thought on swapping .live() for .delegate() and making sure it has no unwanted side effects is a waste of time. As always: Optimizing is good; premature optimizing isn't.
    – balpha StaffMod
    Commented Jan 3, 2012 at 18:38

Not the answer you're looking for? Browse other questions tagged .