About Dave Methvin

CTO, PC Pitstop http://pcpitstop.com

jQuery Foundation 2014 Annual Report

Posted on by

The jQuery Foundation exists to support web developers in creating web content built on open standards that is accessible to all users. We accomplish this through the development and support of open source software, and collaboration with the development community. The Foundation houses open source projects that are essential to this vision.

What we’ve accomplished

We’ve always been known for our namesake projects and their excellent documentation. In the past year, the jQuery Foundation has continued its quest to ensure that web developers have the tools and information they need to get their jobs done, beyond just jQuery, jQuery UI, and jQuery Mobile.

The past few months in particular have been incredibly productive. In October, we adopted the jQuery Mousewheel plugin. In December, Google transferred ownership of the Pointer Events Polyfill (PEP) to the jQuery Foundation. Finally, in January, we announced adoption of the Esprima project, a JavaScript parser that is used by dozens of developer tools. We’re working to foster the continued development of all of these projects, and welcome contributions from the community.

In 2014 we started work on the Chassis project to create an open standard for CSS libraries. We’ve had discussions with developers from Topcoat, Zurb Foundation, Filament Group, Cardinal, Famo.us, Yandex, WordPress, Automattic, 10up, 960grid, Unsemantic, jQuery Mobile, jQuery UI, Intel App Framework, Cascade CSS, Portland Webworks, Adobe, Hulu, and Bootstrap. We’re looking for additional contributors and input from the community about what you want in a CSS framework.

Our year by the numbers

Today, the jQuery Foundation hosts 45 open source repositories at GitHub. These include both code and documentation.

If you need evidence that jQuery Foundation projects are used everywhere, look no further than our Content Delivery Network (CDN) powered by MaxCDN. The 290 billion requests in 2014 transferred nearly 11 petabytes of data. That, of course, does not include the requests for locally hosted copies of jQuery and to other CDNs such as Google, Microsoft, or CDNJS. No doubt the overall number of requests is in the trillions.

Even the best code project can be unusable without good documentation. Web developers don’t just tell us our documentation is good, they tell us that it’s excellent. There were 149 million page views of jQuery Foundation documentation in 2014, coming from 230 countries. All of our documentation sites are available on GitHub so that developers can open issues and make pull requests to improve them. Open source isn’t just for code, it works equally well for documentation!

The jQuery Foundation also hosted, licensed, and participated in 10 events around the world during the past year, including jQuery Conferences in San Diego, Chicago, Vienna Austria, Toronto Canada, and Oxford England. These events always include a wide variety of subjects, and are not just about projects hosted by the jQuery Foundation. The common thread in all the conferences is that they cover topics that web developers should learn in order to do their jobs well.

Future plans

This year we will continue to drive standards forward based on the needs of web developers. Our participation in groups such as EcmaScript TC39 and the W3C has given web developers a say in this process that, until recently, was primarily controlled by large for-profit companies and browser makers. We also plan to increase our participation in the Unicode Consortium as we ramp up our investment in Globalize, so that developers can easily make their software usable worldwide.

Our recent adoption of Esprima highlights another area where web developers could use some more help: development tools. The tools landscape for processing JavaScript, CSS, and HTML is incredibly fragmented. There are multiple processes for authoring, creating, modularizing, and consuming JavaScript, none of which have established themselves as a standard. There are more than a dozen package managers, each with its own unique set of advantages and drawbacks. We’d like to work with developers to settle on a smaller set of options that impose fewer burdens on both the producers and consumers of JavaScript libraries.

2014 Financial Information

Thanks to generous contributions from members and sponsors, we were able to fund a variety of activities that gave back to the cause of open source. The majority of our investments were dedicated to fostering development of jQuery Foundation projects and furthering the use of those projects through events and educational opportunities.

2014 Revenue Chart2014 Expenses Chart

Acknowledgments

We’re proud of the accomplishments of the jQuery Foundation, all of which were realized by the continuing hard work of our team members. Many thanks also to the web developers who take the time to report issues, fix documentation, or contribute code patches. By improving jQuery Foundation projects, you’ve improved web development for everyone.

We’re also grateful for our jQuery Foundation members and their support. In the past year, companies such as IBM and Famo.us have joined and provided resources that allow us to accomplish our mission. Let’s all go out and do even more in 2015!

Esprima 2.0 Released

Posted on by

Last week, the jQuery Foundation announced our adoption of the Esprima project, the widely used JavaScript parser that powers many code analysis tools. Today we’re pleased to announce the release of version 2.0, now available on npm.

Up until now, the official releases of Esprima have only parsed ECMAScript 5 standard syntax. However, the experimental “harmony” branch has been adding ECMAScript 2015 (also popularly known as ES6) features for quite some time. A lot of the work there has been driven by Facebook. Now that the syntax for many ES6 features has stabilized and even shipped on some browsers, there is a need for tools that support the new syntax.

Esprima 2.0 introduces many stable ES6 features brought from the harmony branch, where they’ve been pretty reliable. This new baseline for Esprima makes it possible for tools such as code coverage analysis, style checkers, and linters to start to process the new ES6 syntax.

Since ES5 is likely to be with us for quite a while longer, Esprima 1.x will continue to be maintained for now in order to provide ES5-only parsing. Tools that currently use Esprima 1.x can continue to do so until they are ready and able to process ES6 constructs.

The 2.1 release of Esprima should follow relatively quickly, based on feedback on the stability of the 2.0 release. That means the Esprima team needs feedback from the makers of Esprima-based tools to know whether there are any problems. If you have built an Esprima-based tool and have problems with this release, please report them. (Note that the project is now using GitHub for issues rather than Google Code.)

We’re excited to see where Esprima goes next!

jQuery Foundation adopts Esprima

Posted on by

The jQuery Foundation is excited to announce that we are now hosting the Esprima project! The Abstract Syntax Tree generated by this JavaScript parser is used by many important developer tools such as ESLint, Istanbul, JSDoc and JSCS.

Ariya Hidayat has decided to transfer ownership of the Esprima project and its repo to the jQuery Foundation. We’re glad that Ariya has taken this step, since Esprima is such an important part of so many projects and is downloaded more than 2.5 million times every month from npm. Many thanks to Ariya for entrusting this project to us.

The adoption of the Esprima project, following the recent adoption of the Pointer Events polyfill, are the initial steps in a big shift toward realizing our mission to improve the open web and make it accessible to everyone. The jQuery Foundation looks to ensure that other important tools and emerging standards are also given the chance to grow and shape the open web.

The jQuery Foundation is committed to providing support to Esprima and opening it up for contributions. If you’ve been a contributor to this project already, we want you to continue that work and are always open to new contributors. Please stay tuned, we’ll be making more announcements soon.

jQuery 1.11.2 and 2.1.3 Released – Safari Fail-Safe Edition

Posted on by

Season’s greetings! After a thoughtful review of the Naughty and Nice lists, we have decided to leave a small present under the tree to finish 2014: jQuery 1.11.2 and 2.1.3! These releases include several bug fixes to make your cross-browser development experience better.

The most significant fix in this release is a workaround for a serious querySelector bug in Safari 8.0 and 7.1. When this bug popped up we were hopeful that it would be fixed in patch releases but that did not happen. Apple is by far the least transparent browser maker, and we have very little information about when the Webkit patch for this bug might be pulled into Safari. As a result, we have decided to patch this in Sizzle, the selector engine used by jQuery.

A bug like this one emphasizes the benefit of using a library like jQuery rather than going directly to the DOM APIs. Even modern browsers can suffer from bugs that aren’t fixed for a long time, and there are still cross-browser feature differences with several browsers in wide use such as Android 2.3. Special-case code for obscure browser issues can seem unnecessary until you spend a day trying to debug a problem in your own code caused by one. Or worse, lose a paying customer because they couldn’t use your site from their old phone.

Another bug that makes it difficult for us to test jQuery on iOS 8 is that the user agent of the simulator is incorrect so the iOS 8 simulator is not recognized by our unit test infrastructure. The fix for that issue is very simple but Apple won’t tell us if we can count on it being done. For now we’re doing our iOS 8 testing manually.

In addition, this release includes several changes inside jQuery to avoid holding onto DOM elements unnecessarily. Although the old code generally wouldn’t cause things to run incorrectly, web pages might run slowly and use more memory than necessary.

You may notice that we skipped a patch release number in the 2.x branch. We didn’t actually skip it, we built it and found a problem that caused problems when jQuery was used with node. (Many thanks to Denis Sokolov for letting us know immediately and prodding us to fix it!) Rather than shipping those files to the other CDNs, we decided to create new releases.

As far as the potential for compatibility or regression issues, we believe this is a very low-risk upgrade for anyone currently using 1.11.1 or 2.1.1. We are making this release ahead of jQuery 3.0 to ensure that you can use a Safari-safe version of jQuery without the need to review your code for compatibility with changes being anticipated in jQuery 3.0. If you do encounter bugs, in upgrading from the previous version, please let us know.

You can include these files directly from the jQuery CDN if you like, or copy them to your own local server. The 1.x branch includes support for IE 6/7/8 and the 2.x branch does not.

https://code.jquery.com/jquery-1.11.2.js

https://code.jquery.com/jquery-2.1.3.js

These updates are already available as the current versions on npm and Bower. Information on all the ways to get jQuery is available at https://jquery.com/download/. Public CDNs receive their copies today, please give them a few days to post the files and don’t be impatient. If you’re anxious to get a quick start, just use the files on our CDN until they have a chance to update.

Many thanks to all of you who participated in this release by testing, reporting bugs, or submitting patches, including Chris Antaki, Denis Sokolov, Jason Bedard, Julian Aubourg, Liang Peng, Michał Gołębiowski, Oleg Gaidarenko, PashaG, Richard Gibson, Rodrigo Rosenfeld Rosas, Timmy Willison, and TJ VanToll.

Since the last release of jQuery we have moved from a Trac installation to GitHub issues, so there are currently tickets for this release in both bug trackers. References to the Trac tickets have been migrated to GitHub issues, however, so you can use this GitHub Issues query to review all the tickets.

Thanks for all your support, and see you at jQuery 3.0!

jQuery 3.0: The Next Generations

Posted on by

It’s hard to believe it’s been nearly eight years since jQuery was released. Web development has changed a lot over the years, and jQuery has changed along with it. Through all of this time, the team has tried to walk the line between maintaining compatibility with code from the past versus supporting the best web development practices of the present.

One of those best practices is semantic versioning, or semver for short. In a practical sense, semver gives developers (and build tools) an idea of the risk involved in moving to a new version of software. Version numbers are in the form of MAJOR.MINOR.PATCH with each of the three components being an integer. In semver, if the MAJOR number changes it indicates there are breaking changes in the API and thus developers need to beware.

The concept of versioning gets a little more nuanced with jQuery, where browser compatibility can be just as important as API compatibility. In order to create a slimmer jQuery, the team started shipping two versions in 2013. The first version remained numbered in the 1.x line and, currently at 1.11.1, maintains compatibility with a maximal number of browsers. The second version, starting with 2.0.0 and now at 2.1.1, dropped support for browsers like IE8 or lower in order to streamline the code. Both the 1.x and 2.x versions of jQuery have the same public APIs, even though they differ somewhat in their internal implementations.

Our next releases will use a different nomenclature. As before, there will be two different released files. The successor to what is now version 1.11.1 will become jQuery Compat 3.0. The successor to jQuery 2.1.1 will be jQuery 3.0. There are two different packages on npm and Bower, but they share the same version to indicate they have the same API behavior.

We’ll also be re-aligning our policy for browser support starting with these releases. The main jQuery package remains small and tight by supporting the evergreen browsers (the current and previous versions of a specific browser) that are common at the time of its release. We may support additional browsers in this package based on market share. The jQuery Compat package offers much wider browser support, but at the expense of a larger file size and potentially lower performance.

Despite the big version number jump, we don’t anticipate a lot of migration issues for most current jQuery code. We’re just being good semver citizens with this version bump. Changes such as removing deprecated methods will be detected by a new version of the jQuery Migrate plugin to make them easy to find and fix. We’ll have more details on the changes in future blog posts.

So, here’s the TL;DR for version 3.0 of the jQuery API:

  • If you need support for the widest variety of browsers including IE8, Opera 12, Safari 5, and the like, use the jQuery-Compat 3.0.0 package. We recommend this version for most web sites, since it provides the best compatibility for all website visitors.
  • If your web site is built only for evergreen leading-edge browsers, or is an HTML-based app contained in a webview (for example PhoneGap or Cordova) where you know which browser engines are in use, go for the jQuery 3.0.0 package.
  • Until we announce otherwise, both packages will contain the same public APIs in correspondingly-numbered major and minor versions. This should make it easy for developers to switch between the two and be maximally compatible with third-party jQuery plugins.

With each future release, we’ll be making both packages available on npm and bower. Both packages will also be available as single-file builds on the jQuery CDN. Using them from there is as simple as including either jquery-compat-3.0.0.js or jquery-3.0.0.js depending on your needs. We’ve talked with the folks who run Google’s CDN and they will also be supporting both packages.

As we make further progress on version 3.0, we will update everyone with the details about code changes, supported browsers, and the like. Stay tuned!

Volunteers Wanted: Trac Enhancements

Posted on by

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.

Don’t Use jquery-latest.js

Posted on by

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!

jQuery 1.11.1 and 2.1.1 Released

Posted on by

Ah, the air is sweet with the scent of spring and new jQuery 1.11.1 and 2.1.1 are in bloom. These are minor patch releases and shouldn’t pose any major compatibility issues. Throw a Cinco de Mayo party and have your friends come over to test. If you dig up a problem, let us know at bugs.jquery.com, and be sure to provide a simple test case using jsfiddle.net or jsbin.com to demonstrate the problem.

You can include these files directly from the jQuery CDN if you like, or copy them to your own local server. The 1.x branch includes support for IE 6/7/8 and the 2.x branch does not.

http://code.jquery.com/jquery-1.11.1.js
http://code.jquery.com/jquery-2.1.1.js

The Google and Microsoft CDNs will be getting their copies today just like you did, so please give them a few days to post the files and don’t be impatient. If you’re anxious to get a quick start, just use the files on our CDN until they have a chance to post.

Minified files (for production use) and map files (for debugging) are also available. If you want to use the map file for debugging the minified code, copy the minified file and add a //# sourceMappingURL comment to the end of the file.
http://code.jquery.com/jquery-1.11.1.min.js
http://code.jquery.com/jquery-1.11.1.min.map
http://code.jquery.com/jquery-2.1.1.min.js
http://code.jquery.com/jquery-2.1.1.min.map

Many thanks to all of you who participated in this release by testing, reporting bugs, or submitting patches, including Benjy Cui, Christian Kosmowski, Jason Frank, Julian Aubourg, Jens Simon, John Hoven, John Madhavan-Reese, Jonathan Sampson, Jörn Zaefferer, Leo Balter, Louis-Rémi Babé, Michał Gołębiowski, Oleg Gaidarenko, Philip Jägenstedt, R.G. Otten, Rhys Evans, Richard Gibson, Rick Waldron, Rob Graeber, Rodrigo Rosas, Roman Reiß, S. Andrew Sheppard, Scott González, and Timmy Willison.

Here are the changes since the last official releases (1.11.0 and 2.1.0):

Common to jQuery 1.11.1 and 2.1.1

Ajax

Attributes

Build

Core

Css

Data

Dimensions

Effects

Event

Misc

jQuery 2.1.1

Ajax

Attributes

Core

Css

Event

Manipulation

Selector

Support

jQuery 1.11.1

Css

jQuery 1.11.1 RC2 and 2.1.1 RC2 Released

Posted on by

Spring has sprung, and these release candidates for jQuery 1.11.1 and 2.1.1 are in full bloom. You know what that means? It’s time to get serious about testing! We really want our next release to be solid and reliable, and to do that we need your help. Please try out these files in your projects and pages, just a quick test would be appreciated. If you unearth any problems, let us know at bugs.jquery.com.

The beta files are located on the jQuery CDN, you can include them directly from the CDN if you like (but don’t use them in production!). As always, the 1.x branch includes support for IE 6/7/8 and the 2.x branch does not:

http://code.jquery.com/jquery-1.11.1-rc2.js
http://code.jquery.com/jquery-2.1.1-rc2.js

Here are the bugs fixed since the last official release (1.11.0 and 2.1.0):

Common to jQuery 1.11.1 RC2 and 2.1.1 RC2

Ajax

Attributes

Build

Core

Css

Dimensions

Event

Misc

jQuery 1.11.1 RC2

Css

jQuery 2.1.1 RC2

Ajax

Attributes

Core

Css

Event

Manipulation

Selector

Browser Support in jQuery 1.12 and Beyond

Posted on by

With Microsoft ending Windows XP support this month, we’re giving the jQuery community some long-lead-time notice on changes to browser support.

First of all, don’t panic! Nothing is really changing with respect to the browsers that can run jQuery for at least six more months. Our goal is to let everyone in the web development community know what the jQuery team intends to do over the next year, so that you can plan accordingly.

What’s Changing?

There are no firm dates, but we plan on releasing jQuery core versions 1.12 and 2.2 this year. jQuery 1.13/2.3 will be released some time in 2015.

jQuery 1.12: This will be the last release to support Internet Explorer 6 and 7. As of today, no feature requests or bug fixes will be landed for them. Only serious regressions for these browsers will be fixed in patch releases (e.g., 1.12.1). jQuery 1.13 will support IE8 as its minimum browser.

Both jQuery 1.12 and 2.2: These will be the last releases to support Opera 12.1x and Safari 5.1. As of today, no feature requests or bug fixes will be landed for them. Only serious regressions for these browsers will be fixed in patch releases (e.g., 1.12.1 or 2.2.1).

Both jQuery 1.13 and 2.3: We will remove patches and workarounds that are specific to API conformance for the browsers we no longer support, in order to simplify the code base.

What you need to do: If your projects use a package manager that pulls in the latest release of jQuery, keep in mind that the 1.12-to-1.13 or 2.2-to-2.3 upgrade will reduce browser coverage. You may want to stay on 1.12 or lower if support for older browsers is required. See the instructions of your package manager for details on how to do that.

The Meaning of “Support”

Defining what “support” means is trickier than you might think. Under the premise that “untested code is broken code,” the jQuery core team prefers to say we fully support a browser if the project regularly runs unit tests against that browser. The unit tests ensure that every API returns a consistent set of results in all browsers.

Even when we support a browser, there can be bugs we can’t reasonably fix. For example, Internet Explorer 6 through 11 fire focus and blur events asynchronously and the code required to make them appear synchronous would be significant. Safari on iOS doesn’t support the onbeforeunload event which is pretty much impossible to shim. Until last month, Firefox didn’t respect overflow: hidden on a fieldset element. We try to work with browser vendors to get these bugs fixed.

On browsers that we don’t officially support, we still work hard to eliminate “killer bugs” such as script errors during initialization that make the page totally unusable. If you want to see the lengths to which we go to deal with obscure problems, look at this browser-crashing Android 2.3 bug on Japanese phones which was extremely intermittent and hard to diagnose. With the help of several users we were able to track down and work around the problem.

It comes down to this: We can only ensure high-quality continuing support for the browsers and environments we constantly unit-test. However, we will try to provide some reasonable level of support to browsers in any popular environment. The highest priority will be on ensuring the browser doesn’t throw errors. Low priority will be put on ensuring that old or rare browsers produce the exact same API results as modern browsers.

Who Uses Old Browsers Now?

When looking at browser stats, don’t look at where they are today. Think about where they will be in 2015. All told, we think all these browsers will be in the small single digits of market share by then. If numbers from StatCounter can be believed, these browsers are already there and will be even less prevalent when jQuery finally drops support.

Ultimately these whole-Internet stats don’t matter though. What really matters is whether the visitors to your site or users of your web application are running a particular browser. That is something that only you can answer. The decision to upgrade to a new jQuery version is always in your hands as a developer.

The Myth of Browser Consistency

Today and long into the future, jQuery will still contain dozens of browser-specific fixes to normalize behavior. At this point, the most problematic and troublesome browser for jQuery 2.x is the one in Android 2.3. That version is still a significant 20 percent of the Android installed base, and still being shipped in new mobile products. Several JavaScript features like element.classList are not supported there, and it’s one of the last browsers to still require -webkit-prefixing for standardized CSS properties.

jQuery projects are all about making your development life easier, so we’ll continue to support the fixes that are needed to smooth out inconsistencies on popular browsers. As the market share of specific browsers dwindles to zero, we’ll take the opportunity to remove their patches and de-support them in order to streamline our code bases. That makes all jQuery pages a little bit faster.