jQuery Foundation 2014 roundup

In January 2014, now 11 months ago, the jQuery Foundation published its new mission statement:

To improve the open web, making it accessible for everyone, through the development and support of open source software, and collaboration with the development community.

I was one of the directors of the jQuery Foundation who worked on that statement, along with the more detailed explanations. There are two areas in particular that I want to go into, explaining what we’ve done in those areas in the past, this year in particular and what we’ve planned for the future. This is my own perspective.


Working with standards bodies, such as W3C, WHATWG, and TC39, to build the open standards that browser vendors and developers rely on.

The jQuery Foundation became a member of both W3C and ECMA when we founded it in early 2012. Since then we’ve had Yehuda Katz and Rick Waldron, as representatives of the jQuery Foundation, on the TC39 committee, which is responsible for the ECMAScript specification, also known as JavaScript. Rick has been publishing notes of the meetings, providing visibility into the complete proceedings. Yehuda has also been involved in various groups at the W3C, like the TAG (there’s a photo here with the TAG from 2013, including Yehuda and Tim Berners-Lee). There’s probably a lot more going on, but without a somewhat abstract overview, it is rather difficult to follow. This is one of the problems we’ve been discussing on the board: How can we communicate to the public what we’re doing for web standards? We want the attention and feedback of web developers that eventually have to use those standards, once implemented in web browsers. Following the many W3C and other standards mailing lists is hardly practical for most web developers.

I intend to write more about this in the future. Maybe I can interview Yehuda every once in a while and then write about his standards activities. Or work with Rick to create summaries of his meeting notes, that are more accessible to those not attending the meetings, by focusing on the higher level concepts, not so much the nitty gritty details of the language specification.

Libraries and tools

Working with individuals and organizations to implement libraries, frameworks and tools for web developers.

This is something I’ve been involved in much more directly. An important point here is that those libraries, frameworks and tools don’t have to be owned by the jQuery Foundation. In some cases that makes sense, but there are many projects where we collaborate with other projects.

jQuery Core

Of course we still maintain jQuery itself, often referred to as jQuery Core. The Core team recently published their plans for jQuery 3.0 and jQuery Compat 3.0 (note that its Compat, from Compability, not Compact). From the announcement:

  • 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.
  • The point of the jump to 3.0 is mostly to change jQuery’s implementation of Promises, to make them compatible with the standard. The decision to make that change took a while, since the implementation in jQuery existed long before the standard was written, and breaking code that relies the implementation in jQuery is not something undertaken lightly. But for the sake of standardisation, its going to happen as part of the 3.0 major release.

    jQuery UI

    jQuery UI has been around almost as long as jQuery Core, though I think its future is much more exciting, and where jQuery could be considered almost done, we still have a lot of work ahead of us for jQuery UI. One of the efforts that has been going on for several years by now is the adoption of pointer events, to replace both mouse and touch events. Pointer events provide a sane unified event model, unburdened by Apple’s patent threat. While Chrome recently decided not to implement pointer events, we hope to change their mind by getting to the point where a pointer event polyfill (PEP) is only needed in Chrome, thus making it the slowest browser to handle pointer events, which they hopefully wouldn’t let sit for long.

    Another big effort is in the area of CSS frameworks. jQuery UI introduced its own CSS framework with 1.7, released in March 2009, but since that focused on styling widgets and not generic page elements like headers or forms, it never gained as much popularity as more recent projects like Bootstrap or Zurb Foundation. We’ve looked into adopting an existing CSS framework to replace the one in jQuery UI, and talked to many project teams for that. In the end we’ve decided to start a new effort, yet unnamed, to create a new CSS framework (the GitHub repo will probably be renamed once the project has a name), to be used by jQuery UI and jQuery Mobile, but also, hopefully, many other projects. Even if everyone still rolls their own, we hope to create at the very least naming conventions that can be shared. As Scott wrote:

    The first layer is a set of class names and DOM hierarchies for everyone to follow. Then we’ll build an implementation of that, which hopefully many will use. But the most important thing is that no matter how many implementations may exist, if they all use the same class names and DOM hierarchies, then they’ll all be interchangeable.

    Hopefully we end up with lots of “themes” built on top of our structural work, rather than lots of varying implementations of the structural parts, since we’re trying to reduce the amount of duplicated effort and the overwhelming choice that developers face today.

    Another important point of this new effort is to implement CSS performance testing. This is something the Topcoat team has been doing, and I’m excited about them joining our effort. Again, even if everyone is rolling their own, sharing tools to test and improve the performance of CSS frameworks will benefit everyone.


    A new release of QUnit is right around the corner, introducing better APIs for async testing, ala grunt with an assert.async() method and with direct support for Promises, and many other improvements. In parallel to the new release we’ve also started a project, lead by James Greene, to create a standard for reporters for testing tools. Let’s say you want to run your JavaScript unit tests on BrowserStack or SauceLabs or inside PhantomJS, or on Travis or Jenkins or other CI systems. In each case, you need to report the results back to the user. Currently each testing tool of the above has to write a separate custom integration layer for each unit testing tool, like Mocha, Jasmine or QUnit. This is something the js-reporters projects addresses. So far we’ve worked out a list of event names that can be used by all unit testing frameworks. There’s a lot more to do and as usual with standards efforts, it takes time.


    Globalize is another jQuery Foundation project that has been around for a while. It started with a culture database extracted from Microsoft’s .NET platform. This was a decent starting point, since it covered a lot of cultures, many more than gathering contributions from individual users would have provided. But there were also many issues in this database. Either entries were just wrong, or categories were missing, for example data to format relative time, like “5 minutes ago” or “in 2 years”. The idea to migrate to CLDR as the culture database came up in 2012. The ball got rolling when Rafael Xavier, a member of the jQuery UI project, started looking at the newly released JSON version of CLDR. Since then he rewrote Globalize on top of CLDR, significantly extending the available features, e.g. adding plurals and message formatting.

    A few months into this effort we realized that other projects could benefit from CLDR as well. We suggested collaborating with Moment, probably the most popular library for formatting and parsing dates. Moment still uses a culture database based on user contributions. The maintanence of that database caused the original Moment author, Tim Wood, to abandon the project. Unfortunately migrating to CLDR is a big effort that the current maintainers haven’t been able to make progress on.

    To reduce the effort of using CLDR, Rafael has published two modules: cldr-data makes it easy to specify CLDR as a peer dependency (in npm; in bower it’s a simple dependency), cldrjs simplifies traversal of the CLDR JSON data structure. Both can be used independently of Globalize, for which they’re dependencies. Rafael has started a pull request for IBM’s ECMA-402 (Intl) polyfill to use cldr-data. We’ve also had discussions with the team at Yahoo behind FormatJS to adopt cldr-data, and also to focus efforts on a single Intl polyfill.

    Recently Rafael started a mailing list, to discuss and collaborate on globalization projects for JavaScript. He also created a site and gathered many contributions to list globalization projects, their strength and weaknesses, along with a feature grid. This is both a great help for maintainers of these projects, since they can see what others are doing and where they should concentrate their efforts, and for users, since they don’t have to find and compare all the available solutions.

    We’re currently working towards Globalize 1.0. Once that is done we’ll spend more time looking at ECMA-402 aka Intl, to see if Globalize could wrap or use the formatting APIs (Intl has no parsing). We want to get everyone to use and contribute to a single Intl polyfill (there’s currently at least two). We’d still like to get Moment to switch to CLDR, and discussed them adopting Globalize for their date parser and formatter.

    There is more going on within the jQuery Foundation’s own projects. For the rest of this post, I want to cover one of the projects we’ve been contributing to.


    jscs is the “JavaScript Code Style checker”. Unlike jshint, which looks at code semantics, jscs only cares about code style. Together they are very useful tools for writing consistent JavaScript. jscs was started by Marat Dulin. The two most active maintainers are now Oleg Gaidarenko and Mike Sherov, both members of the jQuery Core project. Within the various projects of the jQuery Foundation, we’re using jscs with its “jquery” preset, one of currently eight presets. The presets are a great way to start using jscs without spending much time configuring it. I’ve recently started using jscs on a project and tried several presets, then picked the one that produced the least number of errors. After fixing the remaining errors, I now have jshint and jscs preventing regressions in code semantics and code style, running locally on each developer’s machine and remote on a continuos integration system.

    There are many more projects we’re contributing to, but that’s also something for another day. For now I hope that this post gives a good idea of what the jQuery Foundation is doing for the open web and web developers everywhere.