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. :)
"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)`.
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:
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.
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.
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"?
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
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.
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
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.
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.
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'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.
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.
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.
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.
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
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.
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. :)