JQuery 1.7 Released | Hacker News Reader

JQuery 1.7 Released

blog.jquery.com

335 pointsdmethvin46 comments

My favorite part of the release notes: "Despite jQuery.isNaN() being undocumented, several projects on Github were using it. We have contacted them and asked that they use jQuery.isNumeric() or some other solution."

This is an excellent reminder of how much things have changed in the last 10 years in our space; a popular tools vendor can go query a massive source code repository and reach out proactively for transitioning deprecated functions.

Kudos to the jQuery team for the great attitude; and of course all hail github, but they know I feel that way since they charge my card every month. :)

This is one of the reasons why Google killing Code Search is so sad.

Bit of a me too post, totally agree, so sad.

"To optimize the code for the most commonly used forms of selectors, we examined a cross-section of code from Google Codesearch."

I assume they found those github projects using code search. Code search may not be used a lot, but the people and projects using it have a large impact. Is there any way we can convince Google it's worth keeping it available?

Yes! Whenever someone on the jQuery team wonders, "But who does that anyway?" we turn to Google Codesearch. Often, we don't like the answers we find. But at least we find the answers. For example, the 600 occurrences of `$("document")` that should be `$(document)`.

http://www.google.com/codesearch#search/&q=\$\%28\%22doc...

There is one ambiguous case: If the data argument is a string, you must provide either a selector string or null so that the data isn’t mistaken as a selector. Pass an object for data and you’ll never have to worry about special cases.

I'm being picky I know, but wouldn't it just be easier to use something like:

    $("#div").on("click", {
      selector: "span",
      data: "blahblah",
      handler: function()
    });

Perhaps it's far too verbose, now that I've typed it out. But it just seems like it would do a good job of removing ambiguities like this.

The data feature isn't used that frequently, and when it is the best way to use it is by passing an object anyway. So although it's mentioned it is likely to be very uncommon.

I use event data a lot, but I didn’t even realise you could pass a string.

Yeah, for bind and live I was under the impression that only an object would work from the docs.

Haha, well it has always been documented to be an Object but turns out that there are a lot of people who don't read the documentation and pass strings or numbers. So rather than break their code in 1.7 we decided to document the fact that plain types can be used if you're careful.

The Create web editing interface uses event data a lot: https://github.com/bergie/create

Can someone describe to me how these jQuery releases make their way into Rails 3.1 land? Does the maintainer of https://github.com/rails/jquery-rails do an update and then it's up to us Rails users to execute a "bundle update"?

It looks like jQuery versions get updated occasionally in that repo, but you'll have to check and see when 1.7 gets put in.

My recommendation would be to maintain dependency versions yourself, i.e. download the version of jQuery you want to use and //= require jquery in application.js - then grab a new version of jQuery whenever you want it updated

I submitted a pull request with the update to 1.7, so hopefully it'll get released officially soon.

Correct. You could also manually download the latest jQuery and include it.

The gem is a very thin wrapper around jQuery, jQuery UI and jquery_ujs, which basically makes the files available for inclusion in your manifests, and adds a jQuery specific helper method for your tests.

Yes, most likely. And hopefully the version number is incremented semantically so `bundle update` doesn't break anyone that really needs 1.6.

If you haven't tried rails-behaviors[1], I recommend it. It's a modular, drop-in replacement for jquery_ujs, and I think @josh will update it shortly for 1.7

[1] https://github.com/josh/rails-behaviors

The quickest way to drop it in vendor/assets. Anything there will override any gems. so `//= require jquery` will just find your local copy instead. Shouldn't have to change any requires.

curl http://code.jquery.com/jquery-1.7.js > vendor/assets/javascripts/jquery.js

One thing I don't like about jQuery's evolution is the size. This version weights at 92K minified / 33K gzipped, which for mobile phones is a PITA.

Agreed, and we plan to do something about it. There will be a jQuery blog post coming soon.

I've been leaning more and more toward Zepto for mobile. It's still lacking a fair bit of jQuery's functionality, but the basics are there and the syntax is compatible. You lose a lot of IE/older browser support, but if you do some device sniffing and serve jQuery to desktops and Zepto to mobile devices, that's not really an issue.

Zepto is great if you're targeting iOS devices, or any webkit-based browser. But you'll need something else to handle Opera, which is 'quite' popular among mobile devices.

Why isn't there a tool that analyzes which functions / features of jQuery your project is using and generates a smaller library with only the stuff you need?

I'm not really a developer so ignore if that's not possible / makes no sense.

That plus server-side browser sniffing to serve only what the user's browser needs could result in an extremely reduced file size. But of course the PITA would then be to maintain that.

Google's Closure compiler can apparently do that.

Doesn't work on jquery. To use that functionality of the closure compiler without breaking your code, the source has to be annotated in a special way, or it has to be incredibly simple.

I don't know much about this, but do you mean http://code.google.com/p/closure-compiler/source/browse/trun... ? That suggests that it will be available at some point, at least...

That's somewhat mitigated with the CDN version (most users won't have to download it).

That doesn't apply in mobile though, you basically have to think as if the cache is always empty, because it usually is. Especially on iOS.

I had split jquery 1.6 to two parts just put some code to string an then used exec, hack but work.

Why eq: 1.css 14kb -250ms engine.js 12kb 250ms

jquery 33kb 320ms ???

jquery1.js 13kb - 243ms jquery2.js 14kb - 250ms

So my page open 100ms faster :P

Dude, I don't understand you. You did what?

I don't think you gain anything by splitting it in 2 files. It could happen if the browser downloads the 2 files in parallel, but it can make your page load actually worse because you do not have a guarantee of parallelism (there's a limit to how many resources you can download in parallel from the same domain and adding multiple domains is not without cost because of the extra DNS lookup, which is also a big problem on mobile phones) and you're also introducing eval().

If anything, a better hack would be to load it such that it does not block the page being loaded.

See a sample how it's done in this project: https://github.com/alexandru/crossdomain-requests-js/wiki/Us...

Firefox is 6 parlsee but my website is 3 files so

http://stackoverflow.com/questions/7133749/can-i-split-jquer...

Is there a good set of jQuery tutorials that uses 1.7 (so you don't learn non-best practices)? I know it was just released, but these things are often built along with the development.

The docs site has a "What's new in jQuery 1.7" section that might help. As far as what is non-best practice, we'll be covering some of that in a blog post next week so stay tuned.

There is nothing I see in the release notes that indicate you would develop non-best practices by using something like 1.6.

Get to coding ;)

I'm really excited about being able to load jQuery as an AMD module. This means you can load jQuery with RequireJS and write nice, modular code. I highly recommend anyone doing large-scale web projects to use Require, it changed the way how i write Javascript.

Very interesting, the chart show significant performance gain in IE 7, 8 etc compared to the previous jQuery version. Congratulations.

I can't wait for the Closure Compiler extern file for this new version!

It's always nice with new features and enhancements but some bugs should first be fixed, like e.g. this one (i cannot update my code to a version higher than 1.5.x due to customers still using IE7): http://bugs.jquery.com/ticket/9646

Hear hear.

I had to work around this insidious creation http://bugs.jquery.com/ticket/8205

It creates a memory leak (it hit my getJSON calls) that slowly strangled one of my apps until it crashed the browser.

I list a lot of hours on that one...

We closed a huge number of bugs in 1.7, but yes there are about 100 open bugs plus another roughly 100 more that are either feature requests or unverified. For a project the size of jQuery and considering the installed base, I think that is pretty good.

And the way these bugs get fixed is by someone spending a lot of time to track them down. As the 1.7 blog post mentions, we definitely welcome any help we can get. We are all volunteers so we don't have the time to quickly track down and fix every bug.

In the triage process we put priority on fixing the worst bugs that affect the most people. I personally triaged both #9646 and #8205 so we could mark them as verified, but tracking down and solving older-IE problems can be torture given the crude stone debugging tools available in those environments. If you have a high threshold for pain, we could certainly use your help.

Anyone have the documentation on jQuery.Callbacks?

Sorry, they're the last thing to be done and there was a lot to document because of its API surface. Addy Osmani did a writeup a few weeks ago:

http://addyosmani.com/blog/jquery-1-7s-callbacks-feature-dem...

This makes me so happy. Those of us developing on Chrome 16 have been suffering through a storm of event.layerX/Y deprecation warnings.

This new release fixes the issue and I can confirm the fix works like a charm.

Free jQuery & jQuery UI eBook (Reference Manual) has been updated:

http://www.heronote.com/files/jQuery.htm

The best thing is the new, unified event API.

They've also improved event delegation performance by a factor of 2.

Love the delegate event performance improvements!

Reply on news.ycombinator.com