ESLint Joins the jQuery Foundation

Posted on by

After last week’s announcement that JSCS is merging with ESLint, this week the ESLint team is announcing that they are bringing their project to the jQuery Foundation. We are very excited to be the providers of a long-term, openly governed home for ESLint. We are also looking forward to seeing the outcomes of this new partnership with JSCS.

At the Foundation, we are constantly striving to find ways to make the development experience better for JavaScript developers. We believe both ESLint and JSCS have been leaders on this front. With these two incredibly bright teams coming together at the jQuery Foundation, we expect to see and support accelerated development of ESLint and an easier discovery and decision process for developers looking to bring JavaScript analysis, linting and code style checking to their projects.

Going forward, we hope to continue supporting innovation in the JavaScript space while at the same time, providing a suitable environment for collaboration in all aspects of the JavaScript development world. For more information about why ESLint chose the jQuery Foundation and how this impacts the teams and users involved, check out their announcement on the ESLint blog.

Living up to Our Commitment to Diversity

Posted on by

Following through on our renewed focus on diversity, education and accessibility that we announced over the summer, the jQuery Foundation has in the past couple of months hosted one event and sponsored another devoted to increasing diversity in tech through outreach and education.

jQuery Developer Summit

October 16-18, the jQuery Foundation, along with partners Women of Color in Tech Chat, Manhattan JS, Girl Develop it, and Coalition for Queens, hosted 50 developers in New York City for the jQuery Foundation Developer Summit.   

This free three-day event, which was generously hosted by Digital Ocean, was designed to make open source development more accessible to, and inclusive of, members of underrepresented groups in technology. Participants of all skill levels and disciplines learned best practices and essential skills from current open source contributors and project representatives, and made contributions to an open source project that interests them.

The event heralded several firsts:

  • the first jQuery Developer Summit in three years
  • the first jQuery Foundation event in New York City
  • the first time we’ve been able to run an event that’s free to participants
  • the first time we’re working with partners to focus on improving the representation of diverse communities in open source
  • the first event that brought together project leads from both the jQuery Foundation and Dojo Foundation after our recent merge of these organizations

In creating this event, the jQuery Foundation sought to remove as many barriers as possible to attending a tech event and getting involved in open source. To achieve our aim, we scheduled the event on a weekend to avoid work conflicts, made it free to all attendees to remove income barriers, kept the size small to ensure a low mentor:attendee ratio, partnered with local organizations for underrepresented groups, and followed the jQuery Foundation Code of Conduct. Our efforts paid off, making this event a safe and welcoming environment for everyone.

The Agenda

Friday night we had a nice meet and greet with food and drink. Mentors helped get everyone’s laptop set up with all the software they’d need to hit the ground running Saturday morning.

Saturday began with a series of introductory presentations by experienced developers and in many cases leaders of jQuery Foundation and other Open Source projects. The intent was to orient new attendees to the why, how and what of contributing to Open Source projects.

Why Contribute?

Anne-Gaelle Colom, Content Lead for the  jQuery Foundation and Teaching Fellow at University of Westminster shared how she first got involved with mobile programming in 1996, and how her eventual involvement in jQuery projects helped her gain recognition and status as a woman in a male-dominated profession and University department. Find her presentation here.

Additional presentations, which ran during the morning on Saturday and Sunday, covered all the basics one needs to understand in order to get started contributing to Open Source. The speakers and content were really great. Where possible, the slide links are included below.

  • Adam Sontag – Intro “Fixing a simple bug narrative”
  • Dave Methvin – Reporting and Triaging Bugs
  • Ashley Williams – Pull Requests, Code Review, Automated Checks (CLA, CI, etc)| Open Source licenses and CLAs
  • Brian Brennan – Command Line + Git + Pull Requests
  • Adam Ulvi – How does this all go live -> Virtual Machines / Vagrant
  • Nick Hehr – Contributing Code
  • Leo Balter – Unit Tests
  • Sarah Frisk –  Project Communication, Open Source principles applied to the workplace/your career
  • Rushaine McBean – Community/Inspirational/Aspirational – “Soft” ways to get involved (meetups, conferences, speaking etc)
  • István Szmozsánszky Flaki  – Browser Dev Tools Workshop

Skills

At the end of the presentations on Saturday, all of the mentors gave a quick overview of their project and attendees paired up with the project that most interested them.

Mentors walked attendees through setting up their environment with virtualbox, node, npm, git, and an editor.

Disciplines

Participants worked in teams made up of members of different disciplines, ensuring that everyone was able to make a meaningful contribution in line with their strengths and interests. These include:

  • programming
  • documentation
  • server/network administration
  • design
  • community development

Projects

Participants worked alongside project team members, making contributions in all these disciplines to popular open source projects, some of which included:

Results

Several attendees responded to our post-event survey. Here’s some of the feedback:

The Summit benefitted me in so many ways. I really valued the proportion of mentors to mentees. It was great to have so many experts floating around to be able to spend one on one time with you wherever you might have been in your path. I liked the casual flexibility of it all.

I think you did an awesome job of getting a variety of people to attend.
I am really glad that you included the LGBTQ community. I have NEVER EVER seen such diversity at any other event or conference I have ever attended in my 21 years in tech.

The most valuable aspect was contributing to open source. The summit made me realize that open source is more than just code.

We also asked mentors for their thoughts:

The almost 1-on-1 ratio of speakers/mentors to attendees made this event so intimate and gave me the opportunity to really meet people and find out about them, what their interests were and how they could benefit open source and how open source could benefit their life.

The enthusiasm of the attendees and their desire to get involved was amazing! It’s obvious that so many people just don’t get involved in open source because they can’t get past the on-boarding and that is somewhere we can definitely help!

Mozilla View Source

November 2-4, the jQuery Foundation sponsored the Diversity in Tech Corner at Mozilla’s View Source event in Portland, OR.

The goal of View Source was to provide an in-depth, practical look at current and on-the-horizon technologies, with plenty of opportunities for conversation.

Caterina Paun, Director of the Portland Women Who Code network greeted attendees in the Diversity in Tech Corner and led discussions about women in the engineering workforce, how to join an all-male team as a woman, and how companies can support the careers of women.

While there is undoubtedly much work yet to be done to make the collective of web builders as diverse as the web’s consumers, judging by the Twitter conversations, this event at least served as a beacon for inclusiveness.

Recurring and important theme at #ViewSource is focus on users/humanity through technology, not fetishism of shiny new technology.
— Lucas Myers (@unthunk) November 4, 2015

Once in a while I lose my way in terms of what I do and what I want as a web developer. Conferences like @viewsourceconf help me refocus.
— Alicia Sedlock (@aliciability) November 4, 2015

With day 1 complete, I must say, the most striking part about the day was the amount of smart women who took the stage. @viewsourceconf
— Elaine Oliver (@evoliver) November 3, 2015

Next Up for the jQuery Foundation

We still have a long way to go and a lot of work to do but as we continue to execute on our goal to increase diversity in open source, keep an eye out for announcements of future event sponsorships, speaking engagements and developer summits going into 2016!

Grunt, Rebooted

Posted on by


Grunt is one of the best-known and most popular task runners in the web developer’s toolkit. Now that this project has joined the jQuery Foundation, we’re looking to get the project rolling again. Ben Alman, the creator of Grunt, is looking for contributors who can take over the reigns. The team could use some help with triaging a stack of issues and pull requests, then getting a new release out the door.

This is a great opportunity for you to get involved in open source. If you’ve used Grunt in your projects, this is also a chance to give back and help the web development community.

Interested? Post in this Grunt issue.

PEP 0.4.0

Posted on by

Today, we’re happy to announce a new release of PEP: Version 0.4.0. Notable changes include better support for module bundlers such as webpack and browserify and the inclusion of a WIP build on the CDN. The WIP build can be found at http://code.jquery.com/pep/pep-git.js but should only be used for testing (please don’t deploy the WIP build to a production site).

For full details on what’s included in this release, see the changelog.

To get started with PEP, you can get the files from npm, bower (pepjs), the jQuery CDN, or the GitHub release. Check out the samples or view the project README for more details. If you run into any issues using PEP, please file an issue or join us on IRC in #pep on freenode.

Thanks to all who helped with this release, specifically: Anders D. Johnson, Colin Snover, John-David Dalton, Jörn Zaefferer, Mike Mariano, Scott González, Stefan Neubert, Stuart P. Bentley, Will Binns-Smith.

Announcing Globalize 1.0

Posted on by

The jQuery Foundation is excited to announce the 1.0 release of the Globalize project, our internationalization (i18n) library. This release has been a long time coming and as Globalize picks up steam and gains more and more adoption every day, we are proud to finally announce the first stable release of this project. We could go on about the features and benefits of this latest release but we felt it was important that you hear it from the source. Below, Rafael Xavier, the lead for the Globalize project, details everything you need to know about the 1.0 release of Globalize and what is yet to come.

An always up-to-date, modular and simple i18n library

Allow me to skip the details and jump to the fun part. Below is what you get with Globalize today, which provides number formatting and parsing, date and time formatting and parsing, currency formatting, message formatting (ICU message format pattern with gender and pluralization support).

Date formatting and parsing

The date module provides methods that convert dates and times from their internal representations to textual form (formatting) and back again (parsing) in a language-independent manner. Your code can conveniently control the length of the formatted date, time, datetime.

locale .dateFormatter({ datetime: "medium" })( new Date() );
en "Feb 20, 2015, 12:15:00 PM"
zh "2015年2月20日 下午12:15:00"
zh-u-nu-native "二〇一五年二月二〇日 下午一二:一五:〇〇"
es "20 de feb. de 2015 12:15:00"
ar "٢٠‏/٠٢‏/٢٠١٥ ١٢،١٥،٠٠ م"

Your code can even select the fields individually, completely independent of the locale conventions. The pattern “GyMMMd” selects era in its abbreviated form, year, month in its abbreviated form, and day.

locale .dateFormatter({ skeleton "GyMMMd" })( new Date() );
en "Feb 20, 2015 AD"
zh "公元2015年2月20日"
es "20 feb. de 2015 d. C."
ar "٢٠ فبراير، ٢٠١٥ م"

 

Relative time formatting

In addition to formatting dates and times, the relative time module provides internationalized messages for date and time fields, using customary word or phrase when available.

locale, value .relativeTimeFormatter( "day" )( value );
en, -15 "15 days ago"
en, 0 "today"
en, 1 "tomorrow"

 

Number formatting and parsing

The number module provides methods that format and parse numbers. Your code can be completely independent of the locale conventions for decimal points, thousands-separators, or even the particular decimal digits used, or whether the number format is even decimal. Though, it can still conveniently control various aspects of the formatted number like the minimum and maximum fraction digits, integer padding, rounding method, display as percentage, and others.

locale .numberFormatter()( Math.PI );
en (English) "3.142"
es (Spanish) "3,142"
ar (Arabic) "٣٫١٤٢"

Formatting thousands-separators:

locale .numberFormatter()( 1000000 );
en-US (English as spoken in the United States) "1,000,000"
en-IN (English as spoken in India) "10,00,000"

Formatting percentages:

locale .numberFormatter({ style: "percent" })( 0.15 );
en (English) "15%"
es (Spanish) "15 %"
ar (Arabic) "١٥٪"

 

Currency formatting

The currency module provides methods that allow to format a currency. Your code can be completely independent of the locale conventions for which currency symbol to use, whether or not there’s a space between the currency symbol and the value, the side where the currency symbol must be placed, or even decimal digits used by particular currencies. Currencies can be displayed using symbols (the default), accounting form, 3-letter code, or plural messages.

Formatting currencies using symbols:

3-letter currency code en (English) de (German) zh (Chinese) ar (Arabic)
.currencyFormatter( "USD" )( 1 ); "$1.00" "1,00 $" "US$ 1.00" "US$ ١٫٠٠"
.currencyFormatter( "EUR" )( 1 ); "€1.00" "1,00 €" "€ 1.00" "€ ١٫٠٠"
.currencyFormatter( "CNY" )( 1 ); "CN¥1.00" "1,00 CN¥" "¥ 1.00" "ي.ص ١٫٠٠"
.currencyFormatter( "JPY" )( 1 ); "¥1" "1 ¥" "JP¥ 1" "JP¥ ١"
.currencyFormatter( "GBP" )( 1 ); "£1.00" "1,00 £" "£ 1.00" "£ ١٫٠٠"
.currencyFormatter( "BRL" )( 1 ); "R$1.00" "1,00 R$" "R$ 1.00" "R$ ١٫٠٠"

Formatting currencies in their full names:

locale .currencyFormatter( "USD", { style: "name" })( 1 );
en (English) "1.00 US dollar"
de (German) "1,00 US-Dollar"
zh (Chinese) "1.00美元"
ar (Arabic) "١٫٠٠ دولار أمريكي"

Formatting currencies in the accounting form, which, for example, in the English locale uses parens instead of the minus sign for negative numbers:

locale .currencyFormatter( "USD", { style: "accounting" })( -1 );
en (English) "($1.00)"

 

ICU message format support (with gender and pluralization support)

The message module provides methods that allow for the creation of internationalized messages, with optional arguments (variables/placeholders) allowing for simple replacement, gender and plural inflections. The arguments can occur in any order, which is necessary for translation into languages with different grammars.

Globalize.loadMessages({
  en: {
   likeIncludingMe: [
      "{count, plural,",
      "    one {You have one task remaining}",
      "  other {You have {count} tasks remaining}",
      "}"
    ]
  }
});

 

locale, count .messageFormatter( "likeIncludingMe" )({ count: count });
en, 1 "You have one task remaining"
en, 99 "You have 99 tasks remaining"

 

Built on standards

Globalize is based on the Unicode Consortium standards and specifications (UTS#35) and it uses its Common Locale Data Repository (CLDR), the largest and most extensive standard repository of locale data available. CLDR is constantly updated and is used by many large applications and operating systems, so you’ll always have access to the most accurate and up-to-date locale data.

CLDR content

Globalize needs CLDR content to function properly, although it doesn’t embed or host such content. Instead, Globalize empowers developers to load CLDR data the way they want. Vanilla CLDR in its official JSON format (no pre-processing) is expected to be provided. As a consequence, (a) Globalize avoids bugs caused by outdated i18n content. Developers can use up-to-date CLDR data directly from Unicode as soon as it’s released, without having to wait for any pipeline on our side. (b) Developers have full control over which locale coverage they want to provide on their applications. (c) Developers are able to share the same i18n dataset between Globalize and other libraries that leverage CLDR. There’s no need for duplicating data. For more information read our documentation on CLDR Usage.

Browser and Node.js Support

Globalize is systematically tested against desktop and mobile browsers and Node.js. So, using it you’ll get consistent results across the various browsers and between client and server. For more details read our Browser Support section.

Get Started

Install it and use it today. See examples for AMD + bower, or Node.js + npm, or plain JavaScript in our Usage section.

If you’re coming from Globalize 0.x, don’t panic. We’ve created a migration guide for you.

Team and Community

We’re grateful for all the support we have received, specifically from Jörn Zaefferer and Scott González for their help with the initial rewrite concept and for being constant advisors; John Emmons, Steven R. Loomis, and Mark Davis (Unicode) for their help with CLDR and UTS#35 specification questions; Alex Sexton and Eemeli Aro for their messageformat.js and make-plural.js libraries that power respectively our MessageFormat and Plural modules; and the jQuery Foundation for the community building, collaborative efforts and its continued support of Globalize and web internationalization.

We want to also thank Nebojša Ćirić, Mihai Niță, and Shanjian Li (Google); Steven Loomis, Steven Atkin, and John Emmons (IBM); Rick Waldron (Ecma-402 2nd Edition editor); Caridy Patiño and Eric Ferraiuolo (Yahoo); Christophe Jolif and Clement Mathieu (Dojo); Cameron Dutro and Kirill Lashuk (Twitter); Craig Cummings and Tex Texin (jsi18n.com); Santhosh Thottingal and Kartik Mistry (Wikipedia); Axel Hecht (Mozilla); Bruno Lewin and Daniel Goldschmidt (Microsoft); Lily Wen (Adobe); Edwin Hoogerbeets (LG); Eirik Rude (Oracle); Xiang Xu (Paypal); Iskren Chernev (moment.js); and Tingan Ho (l10ns.org) to have joined us in an effort to better coordinate the globalization (internationalization and localization) activity of the JavaScript community. If you want to get involved or read more about it, head over to the javascript-globalization@googlegroups.com mailing list or take a look at our JavaScript Globalization overview page.

Upcoming

We’re working on even more exciting features that will soon be part of Globalize. To name a few: runtime optimization and non-gregorian calendar support. So, if any of these are of your interest, make sure you chime in. Express your thoughts and your needs (e.g., which calendars you want to be supported).
We are always looking for contributors to join our team. If you want to get involved, please read the contributing guide. Your help is very welcome.

Announcing PEP 0.3.0

Posted on by

Today, we’re happy to announce the first release of PEP (jQuery Foundation’s Pointer Events polyfill) since Google transferred the Pointer Events polyfill to the jQuery Foundation. There’s more work to do in order to address changes to the Pointer Events specification and flesh out our test suite, but you can start using Pointer Events in your projects today! Other projects, like jQuery UI, jQuery Mobile, and Dojo are in the process of switching to Pointer Events with PEP.

To celebrate our first release, Alex Schmitz built a little demo which he used to show PEP working on different devices.

P drawn on desktop ChromeE drawn in Chrome on AndroidP drawn in Mobile Safari

Since the transfer, we’ve been focusing on moving over to new infrastructure to allow easier contributions and faster development. We’ve switched the tests over to using Intern and set up continuous integration with Travis CI, using BrowserStack to run the tests in all of our supported browsers. We’ve also switched away from plain file concatenation to using ES6 modules via Esperanto to make the cross-file dependencies explicit. Lastly, we’ve moved to our common release infrastructure to ensure consistent releases.

To get started with PEP, you can get the files from npm, bower (pepjs), the jQuery CDN, or the GitHub release. Check out the samples or view the project README for more details. If you run into any issues using PEP, please file an issue or join us on IRC in #pep on freenode.

Esprima 2.1 Released

Posted on by

We’ve just released Esprima 2.1.0! This release introduces support for several new pieces of ES6 syntax: Classes, Rest Parameters, Computed Property Names, let and const. See the release notes below for full details. We’ve also made various improvements to our testing infrastructure to make the codebase more contributor friendly. A big thank you to all those who contributed patches to this release: Ariya Hidayat, Bei Zhang, Brandon Mills, Mike Rennie, Mike Sherov.

While working on bringing more ES6 features to Esprima, we began collaborating with other JavaScript parsers and parser consumers to help define a community standard for JS AST generation. The result of that effort is the ESTree spec, located here: https://github.com/estree/estree. We wanted to say thank you to all who are contributing, which includes members from Esprima, the Mozilla SpiderMonkey parser, the Acorn parser, and Babel, to name a few. A full list of contributors is located here: https://github.com/estree/estree/blob/master/README.md

Expect a 2.2 release to follow in a few weeks bringing even more ES6 support. If you’d like to help contribute, we hang out in the #esprima room on Freenode IRC, and have a weekly meeting at 2PM ET on Wednesdays in #esprima-meeting on Freenode IRC as well. We look forward to seeing you there!

Release Notes

  • Support ES6 class #1001
  • Support ES6 rest parameter #1011
  • Support ES6 computed property name #1037
  • Support ES6 lexical declaration #1065
  • Expand the location of property getter, setter, and methods #1029
  • Enable TryStatement transition to a single handler #1031
  • Tolerate unclosed block comment #1041

QUnit 1.16 Release and Roadmap

Posted on by

We’ve just released QUnit 1.16, an important milestone for the project. This release introduces several new APIs that will become the default in QUnit 2.0. To help migrate to these APIs, you can start using them today in 1.16. Our 2.x upgrade guide provides all the details you need to change your existing test suite to the new APIs.

Here’s a quick overview of the new APIs:

QUnit.test( "assert.async() test", function( assert ) {
  var done = assert.async();
  var input = $( "#test-input" ).focus();
  setTimeout(function() {
    assert.equal( document.activeElement, input[0], "Input was focused" );
    done();
  });
});

You still define tests by calling QUnit.test and passing a name and a callback. The callback receives a assert argument that contains all assertion methods. The assert.async() method is brand new, replacing the old stop() method. The returned callback, here named done is later called when the test is finished, replacing the old start() method.

In addition, QUnit 1.16 contains several improvements and new features:

  • Promise support: As an enhancement for the async control, test blocks are now Promise aware, meaning QUnit will wait for the test to resolve with the pass or fail statement.
  • QUnit asynchronous tests can also now be defined using the new var done = assert.async() method instead of the old stop()/start(), making them specific to the test block.
  • QUnit.skip: This method can be used to define tests that aren’t executed, as placeholders or to temporarily disable an existing test (instead of commenting it out). The skipped test is still displayed in the HTML reporter, marked prominently as “SKIPPED”.
  • testId URL parameter: When clicking the “Rerun” link for a single test, a hash of the test name is now used to reference the test, called testId, instead of the previous testNumber. Using a hash makes sure that the order of tests can change, and QUnit will still rerun the same test you’ve selected before.
  • CommonJS exports: QUnit now also looks for a exports object and uses that to export itself, making QUnit usable on Rhino with the -require option.
  • There are a few more minor changes. For a full list, check out the changelog.

Roadmap

For future releases, we have several improvements planned as well:

Standardized reporter interface

Currently integration of any unit testing library into other tools like PhantomJS or browserstack-runner or Karma requires custom integration code, a combination of library and tools. We’ve started an effort to create a standard reporter interface that all testing libraries could implement, called js-reporters, to be consumed by those tools. Coordinating between the various projects and getting them to agree on and implement a common API takes time, but will yield better testing infrastructure for everyone.

Better diff output

When writing unit tests that compare objects with deep structures or many properties, like Ember models or Moment instances, the current diff output is slow and inefficient. There are also comparisons where the diff is hard to read. Replacing the diff library and implementing custom optimizations, like only showing diffs for leafs in big objects, will make QUnit’s HTML reporter even more developer friendly. We have a list of all diff-related issues.

Better support for writing custom assertions

Custom assertions are a powerful method of abstraction in test suites. They are currently underused. We want to investigate better APIs for writing custom assertions, along with better documentation of existing and new APIs.

Support for nested modules

Nesting modules, like Jasmine and Mocha support it, gives more flexibility in structuring test suites. There is existing discussion and prototypes, but no consensus on the API, yet.

For any breaking changes, we’ll apply the same migration model that we’re currently using. All backwards compatible changes will make it into the next minor release, any incompatible changes will be introduced with a migration layer in a minor release, removing the migration layer in the next major release.

The QUnit Team

The QUnit team also would like to use this opportunity to introduce itself:

At the jQuery Conference in Chicago, September 2014, from left to right: Jörn Zaefferer, Timo “Krinkle” Tijhof, James M. Greene, and Leonardo Balter

 

jQuery Foundation Adopts Mousewheel Plugin

Posted on by

The jQuery Foundation is pleased to announce that Brandon Aaron has donated his jquery-mousewheel plugin to the jQuery Foundation. Brandon is a jQuery team alumnus and he leaves the plugin in great shape with very few open issues. It’s a very popular plugin, one that’s often used along with jQuery UI and other widgets.

Adopting the mousewheel plugin is part of the jQuery Foundation’s mission to make a web developer’s work easier. We want to ensure that web developers can use this plugin and be confident it will be supported into the future. We can’t do this alone, of course, and encourage the community to pitch in with pull requests and by providing support to the jQuery Foundation. You can find it at https://github.com/jquery/jquery-mousewheel/.

Abandoned or neglected open source projects can be a thorn in the side of web developers. When a developer’s personal project becomes wildly popular, it often exceeds that person’s ability to maintain and support it. More developers should take the step that Brandon did, seeking out someone who can take over the reins when they no longer have the time. As Eric Raymond says in The Cathedral and the Bazaar, “When you lose interest in a program, your last duty to it is to hand it off to a competent successor.”

The jQuery Foundation and Standards

Posted on by

Most web developers think about jQuery in terms of its roots, as a library that tries to bring sanity to a disparate set of APIs and quirks that vary from browser to browser. Although that’s one of the things that jQuery was built to do, and still does, it’s not the only thing. jQuery defines a useful API that makes it as easy to work with one element as it does for a dozen. jQuery shortens verbose DOM API names and removes tedious boilerplate code, making it easier to write and to read code. jQuery adds functionality beyond the standard APIs for the work that web developers often need to do.

In short, jQuery isn’t just an API repairman for browsers. To the extent that we need to fix problems, we do it. But we’re even more interested in getting browsers to fix their problems, and in shaping future standards to avoid problems, so native APIs will work properly from the start. Then we can all build useful functionality on top of that solid foundation.

jQuery team members bring plenty of real-world experience that guide standards in the right direction. The earliest example of this is the querySelectorAll method, where John Resig pointed out that the implementation wasn’t quite what JavaScript developers needed. Unfortunately in the case of querySelectorAll, it was too late to do anything to fix the problems.

How jQuery Can Shape Standards

In order to provide input into emerging standards, the jQuery Foundation joined the World Wide Web Consortium (W3C) and ECMA International last year. In fact, it’s one of the main reasons the Foundation was formed. W3C and ECMA members tend to be representatives of the companies that make browsers and commercial software. We believe that we bring the voice of the rank-and-file web developer to the standards process.

Yehuda Katz and Rick Waldron have been active in the ECMA TC39 group, which defines the language officially known as EcmaScript but that we know as JavaScript. Rick’s excellent meeting notes can give you an inside view of the deliberations that go on during their in-person meetings.

Scott González and Kris Borchers have been working to refine the Pointer Events standard. It brings simplicity, regularity, and sanity to the handling of pointer technologies so that developers don’t have inconsistent (and conflicting!) event models for touch and mouse. During the transition, developers will be dealing with three pointer models–mouse, touch, and pointer. jQuery and jQuery UI want to simplify this transition to the standard.

Julian Aubourg has been participating on revisions to the XMLHttpRequest standard, a position for which he’s been battle-tested by jQuery’s $.ajax implementation. Knowing all the problems that jQuery has worked around provides him with experience to avoid the same problems in the future.

Scott González and TJ VanToll have been active in helping to define HTML5 input types such as <input type=”date”>, providing practical input based on experience with jQuery UI. TJ’s talk at the Portland jQuery Conference does a great job of covering the pitfalls of using HTML5 input types today, and emerging standards like Web Components that could make things easier for web developers.

The jQuery Foundation is also a strong advocate of accessibility; we want to make it easy for web developers to reach all users including those with vision or motor impairments. The W3C addresses those issues through the Web Accessibility Initiative, and specifically with Accessible Rich Internet Applications (ARIA). jQuery UI widgets are incorporating ARIA attributes, and Foundation member Deque Systems has sponsored several events on jQuery accessibility issues.

Finally, we coordinate and pass along bugs reported to jQuery that are due to standards violations in a particular browser. With most browsers updating every few months, it often doesn’t make sense for jQuery to incorporate large and complex bug fixes for temporary problems. But we’re committed to getting them fixed by the browser makers as soon as possible.

A Standards-Driven jQuery Future

jQuery isn’t a highly opinionated framework that demands control over all the DOM. In most cases you can (and often should) use the DOM APIs alongside jQuery. That was always the intended design; you can see it in aspects like the this object inside an event handler being a DOM element, not a jQuery object. About the only place where jQuery requires control is when elements in the DOM are replaced via methods like .html() or removed with a method like .empty(), so that any associated jQuery data can be cleared out.

Similarly, the built-in HTML5 input types can coexist with jQuery UI input widgets. jQuery UI is committed to providing user interface widgets that provide great functionality without sacrificing accessibility, inherently supporting standards such as ARIA.

The jQuery Foundation wants standards-based APIs and cutting-edge JavaScript features to be usable directly by developers. The good news is that the community is making good progress on that goal, and jQuery team members are helping through our participation in the standards process. Yet the continuing evolution of web standards and practices, combined with a vibrant third-party ecosystem of plugins and knowledge, still provide compelling reasons to use jQuery. Web developers deserve to have the best of both.