The jQuery Foundation’s mission has always been about more than just our namesake projects of jQuery, jQuery UI, and jQuery Mobile. We already host several projects such as Sizzle, QUnit and Globalize that are not dependent on the jQuery library.
This wider web-oriented mission is evident in our jQuery Conferences, which span a wide range of developer concerns beyond jQuery, including Node, CSS, tooling, testing and much more. Over the years we’ve had talks on build tools, accessibility, security, performance, design patterns, and frameworks such as Ember and Angular. At our San Diego conference this past February, for example, Lenny Markus gave a great talk on PayPal’s continuing adoption of Node as they move away from Java and proprietary solutions, Catherine Farman talked about real world responsive design, and John Dimm gave a talk on the HTML5 speech APIs.
Beyond the technical compatibility between our projects, we also share the open source model and all the benefits it provides. The Foundation adds the benefit of a top-level structure designed to serve the projects, providing the resources they need but letting the contributors decide the best direction for the project based on community input. Any project that joins the Foundation is given the ability to serve their community’s needs rather than be constrained by the goals of a for-profit company.
Though this has been our mission for a long time, we felt we needed to make this clearer. We are excited to start bringing this part of our mission into the light and start actively working toward a more open web accessible to everyone. If you are excited as well, please help us. Contribute your time to Foundation projects. Offer your company’s services. If you or your company have an established open source project that you believe could benefit everyone and flourish by becoming part of the jQuery Foundation, check out our philosophy around projects joining the Foundation and let us know you’re interested. If you would rather just support the existing and future projects of the Foundation through financial support, become a member of the Foundation. Open source projects will only thrive if everyone who benefits from them contributes back in whatever way they can.
The jQuery and jQuery UI teams use Trac to do their bug reporting and tracking. The jQuery Core bug tracker could really use a Trac expert to migrate us to Trac 1.0 and fix a few nagging issues we’ve been having. If you’re an expert Trac-meister, or just someone with good Trac setup/configuration experience who’s up to the challenge, we’d love to talk with you! Send a message to dave(at)jquery.com and we’ll be in touch.
Since some of you will inevitably ask: GitHub’s integration between issues and commits is wonderful, but it’s not anywhere near as powerful as Trac when it comes to searching and reporting. In addition, our projects have more than seven years of history comprising thousands of bug reports with important data in them. That’s a non-trivial amount of data to import into GitHub issues and groom to be useful once it’s imported. We feel that staying with Trac is the lowest-effort way for us to give us the bug tracking abilities we need.
Earlier this week the jQuery CDN had an issue that made the jquery-latest.js and jquery-latest.min.js files unavailable for a few hours in some geographical areas. (This wasn’t a problem with the CDN itself, but with the repository that provides files for the CDN.) While we always hope to have 100% uptime, this particular outage emphasized the number of production sites following the antipattern of using this file. So let’s be clear: Don’t use jquery-latest.js on a production site.
We know that jquery-latest.js is abused because of the CDN statistics showing it’s the most popular file. That wouldn’t be the case if it was only being used by developers to make a local copy. The jquery-latest.js and jquery-latest.min.js files were meant to provide a simple way to download the latest released version of jQuery core. Instead, some developers include this version directly in their production sites, exposing users to the risk of a broken site each time a new version of jQuery is released. The team tries to minimize those risks, of course, but the jQuery ecosystem is so large that we can’t possibly check it all before making a new release.
To mitigate the risk of “breaking the web”, the jQuery team decided back in 2013 that jquery-latest.js could not be upgraded to the 2.0 branch even though that is technically the latest version. There would just be too many sites that would mysteriously stop working with older versions of Internet Explorer, and many of those sites may not be maintained today.
As jQuery adoption has continued to grow, even that safeguard seems insufficient to protect against careless use of http://code.jquery.com/jquery-latest.js. So we have decided to stop updating this file, as well as the minified copy, keeping both files at version 1.11.1 forever. The latest released version is always available through either the jQuery core download page or the CDN home page. Developers can download the latest version from one of those pages or reference it in a script tag directly from the jQuery CDN by version number.
The Google CDN team has joined us in this effort to prevent inadvertent web breakage and no longer updates the file at http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.js. That file will stay locked at version 1.11.1 as well. However, note that this file currently has a very short cache time, which means you’re losing the performance benefit of of a long cache time that the CDN provides when you request a full version like 1.11.1 instead.
So please spread the word! If you see a site directly using the jQuery CDN’s jquery-latest.js or the Google CDN equivalent in their script tags, let them know they should change to a specific version. If you need the latest version, get it from the download page or our CDN page. For both the jQuery and Google CDNs, always provide a full version number when referencing files in a
<script> tag. Thanks!