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.
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.
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 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
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.
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.
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.