Come help the jQuery Foundation

Posted on by

For many years now the jQuery team first, and then the jQuery Foundation as an organization, has helped developers all over the world to write simple, concise, and clean code that isn’t affected by all the browser incompatibilities that developers are well-accustomed to. As you know, all the jQuery Foundation projects are maintained by a group of volunteers who keep the libraries relevant and in line with modern browser APIs and issues. The team also keeps the API documentation and educational guides up to date.

In the next few months, the team will work on the several jQuery-related websites to ensure an even higher standard of quality to help millions of users write their code. There is so much to do and our resources are limited, so today we are asking you for help. Part of the team is currently focusing their attention on the Learning Center, but we appreciate help in any repository. If ever the jQuery Foundation projects have saved you work and frustration, this is the right time to give something back. There are many ways in which you can contribute, and you don’t have to be an expert developer. You can help the project by fixing issues in the code or improving the documentation. Everything counts. The jQuery Foundation welcomes contributions from anyone willing to put in the time and effort to help us and our community of users.

To learn more about how you can contribute, visit the Contribute website, sign our Contributor License Agreement and start helping. In case you can’t help us by addressing code or documentation problems but you still love our projects, you can help us by making a small donation.

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

Getting on Point

Posted on by

We’re excited to announce that the Pointer Events specification has become a W3C Recommendation! As we’ve said before, we love Pointer Events because they support all of the common input devices today – mouse, pen/stylus, and fingers – but they’re also designed in such a way that future devices can easily be added, and existing code will automatically support the new device. While reaching Recommendation status is a monumental moment, there’s still much work to do.

Pointer Events aren’t a viable solution until they’re usable in all of the browsers that developers are supporting. While that day may seem far away, the jQuery Foundation is dedicated to getting usable Pointer Events in every developer’s hands as soon as possible. We’re working on PEP, our Pointer Events polyfill that Google transferred from the Polymer project to the jQuery Foundation. PEP will be integrated into projects such as jQuery UI, jQuery Mobile, and Dojo. We’re hoping to get out our first release in the next few weeks. If you’re interested in helping out, let us know.

Microsoft is already shipping a full implementation of Pointer Events in IE11 and they had a mostly complete, prefixed implementation in IE10. Mozilla also has a full implementation for Firefox on Windows Metro, though it’s not currently enabled. Both implementation are passing 100% of the W3C Pointer Events test suite. You can follow Mozilla’s progress for all of their supported platforms on https://wiki.mozilla.org/Gecko/Touch.

Of course, the world ain’t all sunshine and rainbows. There’s still no sign that Apple will ever implement Pointer Events. Because of this, Google has decided not to ship Pointer Events in Blink, but rather to try to extend Touch Events to have the power of Pointer Events. The work to extend Touch Events is happening in the Touch Events Community Group to ensure interoperability and standardization. However, there is reasonable concern that adding several extensions to Touch Events will just result in an even more fragmented landscape, eventually worsening the situation rather than improving it. It’s not clear that Apple would implement all of these features anyway, and adding support for hover would require awkward APIs due to the logic that already exists in Touch Events. Even if the power of Pointer Events were added to Touch Events, the awkward event interface isn’t nearly as nice or easy to transition to from Mouse Events.

Despite Google’s current position, they’re willing to continually re-evaluate if shipping Pointer Events will help move the web forward. We’re hopeful that Google will reverse their decision in the future and Apple will eventually be compelled to implement Pointer Events once Safari is the only major browser without support. The Chromium issue for implementing Pointer Events is already in the the 99th percentile of all issues (open and closed) based on number of stars.

As a community, we can shape the future of the web right now. We need to stop letting Apple stifle the work of browser vendors and standards bodies. Too many times, we’ve seen browser vendors with the best intentions fall victim to Apple’s reluctance to work with standards bodies and WebKit’s dominance on mobile devices. We cannot let this continue to happen. The jQuery Foundation is dedicated to driving standards, like Pointer Events, to improve the developer experience and in turn, make the web a better, more accessible place for everyone. Together, we can push the web forward and let standards and better APIs win. We can choose Pointer Events over Touch Events. And we can do it right now, with PEP.

jQuery UK: Europe’s jQuery Conference

Posted on by

jQuery UK will take place on March 6, 2015 in Oxford, UK. This event is organised by White October Events with support from the jQuery Foundation.

jQuery UK is the UK’s largest front-end developer conference. Now in its fourth year, two packed tracks will feature the biggest names in front-end, including Bootstrap creator Mark Otto, Standardista Estelle Weyl, Google Engineer Addy Osmani and Jenn Schiffer of Bocoup.

Practical sessions will cover topics including architecting client-side code for resilience, making your code more readable and expressive, and designing for displays that don’t exist yet.

There are four hands-on workshops taking place the day before the conference. Choose from:

  • Practical & powerful HTML, CSS, and JavaScript
  • Advanced jQuery Techniques
  • AngularJS Foundations
  • Web Developers Workflow

Space for these workshops is strictly limited, so book early to secure your spot!

Tickets are on sale now at £190 + VAT.

To book tickets or sign up for updates, visit jqueryuk.com. You can also track jQuery UK on lanyrd.com and follow @jquk for updates.

Famo.us Joins the jQuery Foundation

Posted on by

In case you haven’t heard, Famous Industries (Famo.us) announced today that they are joining the jQuery Foundation as a Founding-level member.  Famo.us joins our other Founding-level members, WordPress and IBM, and our growing list of member companies, who recognize the power and importance of the jQuery Foundation’s open governance for JavaScript technologies.

For those who are not familiar with Famo.us, they offer a free, open source JavaScript platform that enables engineers to build beautiful, cross-platform web apps. It is the only framework that provides an open source 3D layout engine fully integrated with a 3D physics-based animation engine that can render to DOM, Canvas, or WebGL.

Famo.us also provides extensive free training, examples, and tutorials through Famo.us University. Their live coding environment allows students to see their code rendered in real time and work through topics at their own pace. We plan on taking advantage of their passion for education by partnering with Famo.us to deliver a top notch developer event in San Francisco in mid 2015 (stay tuned!).

Today, jQuery continues to be one of the most preferred JavaScript libraries available with 8 out of 10 of the top JavaScript enabled websites and over 60% of the top one million websites* choosing jQuery-enabled libraries. As our community grows and continues to innovate, so do we. This makes the support of our members more critical than ever.

We are working on a number of new initiatives: Making improvements to how our innovative technical community collaborates. Famo.us has a number of widgets they intend to make available as jQuery plugins and we look forward to taking advantage of their support and expertise as we work to improve the extended community guidance around jQuery plugins.

Famo.us developers will be joining our technical efforts so please say ‘hello’ and make them feel welcome. Co-founder and CEO Steve Newcomb has been elected to the jQuery Foundation board of directors. We look forward to benefiting from the unique perspectives, business acumen and life experiences Steve will bring to our board in helping us move forward toward accomplishing our mission.

It’s going to be a great partnership and a busy New Year. With that, please join us and give Famo.us a shout out and welcome them to the jQuery Foundation!

*stats from BuiltWith.com

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

jQuery.com September 2014 Security Retrospective

Posted on by

During the last two weeks of September, we found our way into the headlines due to a series of attacks on our web servers. Today, we wanted to give everyone a brief update on the status of our websites and a recap of what happened over the last two weeks.

jQuery Under Siege

Early on the morning of September 18th we were hit with a DDoS and went offline. We were down for a couple of hours. The sites were brought back up later that day on September 18th and all seemed well.

Later, during the afternoon of September 18th, we were contacted by a security company named RiskIQ reporting that their crawler had reported malware being served by our content sites. There were never any reports that the jQuery libraries nor the CDN were ever compromised. Immediately upon receiving that report, we completely destroyed and reimaged all of those machines, revoked and reissued all associated SSL certificates, and confirmed that there was no suspicious content being served at that point. Since then, our own team and security folks from Mozilla and MaxCDN have worked to analyze logs and attempt to confirm the impact of this attack.

On September 23rd, RiskIQ went public with their report which picked up steam throughout the day on various media outlets and Twitter. The next morning, September 24th, as DDoS attacks on our properties continued to increase both in frequency and magnitude, CVE-2014-6271, otherwise known as the ShellShock vulnerability, was issued. As we continued to respond to the media discussion and communicate to the community what had happened on September 18th, we were victimized again in a series of much more public attacks involving the repeated defacing of jquery.com.

Investigations into our systems have yet to find the initial attack vector. However, we did take some steps to make ourselves more secure. For instance, some of our WordPress installs were out of date, all of our servers were vulnerable to the recent shell vulnerabilities, NGINX was slightly out of date as well as maybe a few other patches etc. that needed to be made. The infrastructure team dove in and began making those changes and started building new, fully patched and secured servers to host our sites. It appears these changes were effective as the defacing stopped and we have not seen any evidence of intrusion since.

Later on September 24th, a massive and unrelenting DDoS attack began. It seemed as though it would come in waves, but did not stop until late on September 28th. Most of the time on September 26th and 27th was spent trying to implement various products and solutions in order to keep the servers alive. We fought day and night to try to keep the sites up. We have to commend Corey Frang, Adam Ulvi, the rest of the infrastructure team, and others; they worked through the nights and in alternating shifts to try to keep us on the internet. Without their efforts, we would not have had the short amounts of uptime we did. One significantly important step that we took was to reach out to CloudFlare, who generously and rapidly gave us access to their Enterprise service which has helped tremendously in mitigating these attacks.

Moving Forward

jQuery and the jQuery Foundation are important to the web ecosystem, as is evident from the amount of press and the number of concerned individuals and organizations that have reached out to ask questions about this attack. The jQuery Foundation works on a daily basis to maintain and improve our projects and the infrastructure around those projects. The goal of this work is to continue to make web developers’ jobs easier and make sure they have a voice in the world of standards and browsers. However, these objectives take a large quantity of resources. Whether those resources are provided by access to expertise of a company’s employees or services, or through financial support, we would be unable to continue this important work without the support of the open source community and our supporting members.

We have been asked several times throughout this ordeal about why we didn’t have XYZ service in place or why we didn’t have our security team keeping a closer eye on these types of risks. The simple answer is that our budgets are tight and resources are limited. Our infrastructure team, and most of our teams for that matter, are made up of volunteers who give their time for free to make sure things keep running. The Heartbleed and ShellShock vulnerabilities are recent examples of how badly things can go when open source projects are taken for granted and just assumed to be OK. Eventually something is going to fall through the cracks and those cracks become larger and more frequent when people are doing what they can in their spare time.

So how can you help? As an individual, get involved in one of our projects. We can always use help writing code, designing, maintaining servers, working on events and the list goes on. Take a look at contribute.jquery.org or come say hi on IRC in one of our many channels listed on irc.jquery.org. As an organization, we would love to hear about any service you may be willing to donate, any developers or other skilled professionals that you could spare for a few hours a week or if you can help financially. Send us a message at [email protected] and let us know how you can help.

We haven’t wanted to say too much about these attacks as they have been happening because we remain a juicy target in the eyes of hackers who are continuing to attempt to infiltrate our servers even as of this writing. In sharing all of this information with the community now, we’ve tried to balance the need to explain what’s been happening with the potential backlash that could happen as a result of coming out publicly and saying that we believe we have the situation under control.

That said, we do at this point believe that we have the situation under control. For this, a huge thanks is due to the entire jQuery infrastructure team, who rolled up their sleeves and worked tirelessly on these issues to get us back to a good place. We will continue to be vigilant in ensuring the reliability and safety of all of our resources for our community of users.

Update on jQuery.com Compromises

Posted on by

Today at 11:15AM EDT, the jQuery Infrastructure team received widespread reports and confirmed a compromise of jquery.com. This attack was aimed at defacing our sites, and did not inject malware like the attack that was reported on September 18th by RiskIQ. We believe that these are separate incidents that may have used the same attack vector.

We took the site down as soon as we realized there was a compromise and cleaned the infected files. We are taking steps to re-secure our servers, upgrade dependencies, and address vulnerabilities.

At no point today have there been reports of malware being distributed from any of our sites, nor has the code of any jQuery libraries on our website or CDN been affected or modified today or during last week’s reported attack. Some of this confusion stems from last week’s attackers having set up a domain name intended to dupe users into thinking it was the official jQuery CDN. Please note that the official domain for jQuery files hosted from our official CDN is code.jquery.com.

There has also been concern that the user accounts of developers and administrators who use jquery.com and the rest of our WordPress sites have somehow been compromised by this attack. However, the only people who have a user account for the WordPress sites affected by these attacks are members of the jQuery team; we do not have any public user registration for any sort of account on any of the affected sites.

We are continuing to actively work on and monitor this situation and will update you as we learn more.

Updates

We have moved http://jquery.com to a new server only running code we trust and are continuing to monitor the situation closely. – September 24, 2014 at 5:07 PM EDT via Twitter

Was jquery.com Compromised?

Posted on by

Lastest update on the compromise: Update on jQuery.com Compromises

Earlier today, RiskIQ published a blog post stating that the jQuery.com web servers were compromised and serving the RIG exploit kit for a short period of time on the afternoon of September 18th. Our internal investigation into our servers and logs have not yet found the RIG exploit kit or evidence that there was in fact a compromise.

RiskIQ was able to make contact with the jQuery Infrastructure team on September 18th, at which point with members of the RiskIQ team tried to find evidence of compromise. So far the investigation has been unable to reproduce or confirm that our servers were compromised. We have not been notified by any other security firm or users of jquery.com confirming a compromise. Normally, when we have issues with jQuery infrastructure, we hear reports within minutes on Twitter, via IRC, etc.

At no time have the hosted jQuery libraries been compromised.

Currently the only potential system compromised is the web software or server that runs jquery.com. We have asked RiskIQ to help us look through our server logs and systems to help identify when and how a compromise happened. Please check this blog post for updates on the situation.

Even though we don’t have immediate evidence of compromise, we have taken the proper precautions to ensure our servers are secure and clean. If you happened to visit any of the our sites on September 18th and are afraid of your system being compromised you can follow the advice RiskIQ recommends:

  • Immediately re-image system
  • Reset passwords for user accounts that have been used on the system
  • See if any suspicious activity has originated from the offending system