 We're going to get started. But before I get started, does anybody here play Ultimate? Does anybody know what Ultimate is? This is so sad. So I've been playing Ultimate for most of my life. It's a disc sport. I will say the terrible word frisbee. So I've been playing for most of my life. And I've been fascinated watching the sport grow. Because when I started playing, like the typical response is the response I got here and nobody knows what this sport is. But now it's actually like on ESPN3 and it's getting lots of public attention. It's probably one of the fastest growing or potentially the fastest growing sport. But just last week, the U23 Worlds was in London. And India competed for the first time ever. So Sushmita Azad from Bangalore said that being part of India U23 team means that I get to represent India in a sport that is the microcosm of the ideal world. There are no referees, no body contact, no heckling. Just highly competitive play, which only works because of the integrity of everyone playing. And so I think that has a lot of parallels to the communities in free and open source software. So I brought a few jQuery disks to give away after my talk. Do you want one? Throw it to you. Come see me after the talk. So it seems appropriate that I would be giving a talk about the community here at the first ever jQuery conference in India because India actually accounts for 13% of sessions across all the jQuery foundation sites, which makes it the second most active country following the US. And for comparison, the third most active country, Germany, only accounts for about 4.5% of sessions. So broken down by a city, Bangalore is actually the most active city, not just within India but across the entire world. And India accounts for six of the top 10 cities. We do the Bangalore, Chennai, Hyderabad, New Delhi, Mumbai, and Pune. Also, we have three projects going on right now in Google Summer of Code. And two of the three students are from India. So it's pretty exciting to be part of this conference with such a vibrant community, even if it turns out that all you do is go to Stack Overflow and steal answers. So as an open source project, jQuery UI benefits quite a bit from the contributions of the community. And despite the relatively small size of our code base, we have a lot of moving parts. It takes quite a bit to keep the project running. We are, after all, the most popular JavaScript UI library in the world. So we're quite fortunate to have a very active community as a result. Nearly every aspect of jQuery UI has been created or improved by hundreds of individuals, from bug reports to patches to documentations. We'll find community contributions in all the normal places. But the community contributions actually go well beyond this. We have logo designs, site designs, site implementation, we have style guides, language guides, event organizers, people answering questions on Stack Overflow, forums, IRC, testing pre-releases, giving feedback on proposed APIs. The list goes on and on for community contributions. So there's been increasing awareness recently that successful projects are built on more than just code and creating a welcoming environment for everyone, not just developers, is very important for their community and the project. So it's something we've been passionate about since day one and we're glad to see that more projects are taking strides in the right direction. And in fact, one of the contributions that had the biggest impact on me wasn't code, it wasn't even a traditional type of contribution. At some point during the 1.8 release cycle for jQuery UI, Andrew Powell mentioned to me that our upgrade guides weren't very good. So I took a step back and I read through our upgrade guides from the standpoint of someone that's not intimately familiar with the code base and it was very obvious that he was correct. So at that point, I started to really understand how important high-quality documentation is. And this made a big impact, not just on jQuery UI, but in a lot of my personal projects as well. And as a result, we received fantastic feedback with the 1.9 upgrade guide, which was massively more detailed than any previous upgrade guide we had written. So even just providing feedback is an important contribution and it could be something that sparks a change that could affect hundreds, thousands, or even millions of other individuals. So beyond just the individuals that participate in our community, we also rely on lots of other projects and teams. We rely on services and projects such as Git, GitHub, WordPress, FreeNode, Travis, Jenkins, QUnit, TestWarm, Node, NPM, Grunt, W3C, TC39, JSCS, JSHint, CSSplint, PhantomJS, BrowserVendors, plenty of other projects and teams. Let's just go on and on and on. So as you might expect, there's a lot of overlap in these communities. So contributions to one project often have a widespread impact that have affect other projects and communities. So over the past seven years, members of the jQuery UI team have been active in several of these communities and building upon these existing projects and sharing our own contributions enables us to improve the landscape for more than just the jQuery UI community. By fostering a collaborative environment and ensuring that we have open lines of communication, we're able to solve not just our own problems, but those of other projects and teams as well. So perhaps one of the most illustrative ways to explain why this is a natural thing for us to do and how we've helped build up the community is to just walk through a typical day as a jQuery UI developer. So let's say I'm working on a bug fix. I'd probably start by writing a test and we write our tests in QUnit, but we support several versions of jQuery Core and currently we support 16 versions of jQuery. So manually running the test suite against each individual version is pretty tedious. So a while ago I created an extension for QUnit that lets you run many test suites and then it aggregates the results and then you can see them in, basically creates a new QUnit test suite that is the aggregate of many QUnit test suites. So with the help of others, this has become a QUnit plugin called QUnit Composite and that's now maintained by James Green. And so as I'm writing code, I often wanna view a diff of the changes that I've made, but I don't really like working with the command line diffs. I much prefer using an interface like GitHub, but obviously I can't use GitHub while I'm doing my local development before I've committed and I don't wanna install a GUI to deal with everything. So as a result, I created a module called PrettyDiff. PrettyDiff has the exact same API as GitDiff except that the result is a web page that looks very similar to a GitHub-style diff. So I can just go to my command line, run PrettyDiff and get a diff that I actually enjoy working with. And PrettyDiff is freely available on NPM and it's becoming an indispensable tool for myself and many others. But this tool probably never would have happened if I hadn't been able to benefit from all the improved UX and workflow of working with GitHub on a daily basis. So once I've got my test written and the code's patched and I've reviewed my diff, then I run the full test suite. And that includes lots of tools like Grunt, JSCS, JSCint, CSSlint, Uglify, PhantomJS, GruntHTML and a few others. And the projects that I've listed were either created by JQuery YT members or they were improved by JQuery YT members or they've had bug fixes by JQuery YT members. In some cases, the team members have even joined the core team for these other projects. For now, I'll just talk about GruntHTML. GruntHTML is a module that validates HTML files and we use this to run our demo and test pages through them to make sure that they are well formed. So Jiren Zephyr is the dev lead for JQuery Y and he's also a dev lead for many other projects. He created and maintained this module and he worked with Mike Smith from W3C to get the validator.new code so that you could run it against a large set of files locally in a very short amount of time. So cross-project collaboration like that is very beneficial and it allows us to cut down on development time and work with multiple communities. So since Mike was already familiar with the validator.new code and Jiren was already familiar with writing Grunt plugins, we were able to get this done very quickly and the result is that we now have automated validation that was previously a little tedious but it was very time consuming and now it's not tedious at all and it's very fast. Plus it's available to a large audience of web developers, right? It's not something that's JQuery specific. So once all the tests pass, I'm ready to commit but JQuery projects actually have fairly strict commit message guidelines. So Jiren Zephyr built another plugin or another module called commit please and commit please works by installing a commit message hook in Git. So we have it listed as a dev dependency in JQuery UI and then when you run MPM install on JQuery UI it installs this commit message hook and what that does is every time you go to commit it will validate that the commit message conforms to the commit message guidelines and if it doesn't it will reject the commit and then it will show you your original commit message and an explanation of why it didn't conform to the guidelines. So this can be really valuable having consistently formatted commit messages. So for example we can use this to generate the change log for any release just by parsing through the commit messages because we know that there's a specific format and we know that if there are ticket references or pull request references that they're gonna be in a specific place within the commit message and they're gonna be in a specific format and we can parse out all that information automatically. So if you'd like to enforce any rules in your own projects you might wanna check out commit please. So across the various JQuery projects we run a lot of other tasks during builds as well. Many of these have also been built and developed by various team members. For example some of them are Bower copy, Compare size, ES format or Git authors, JSCS, Grunt spider, Perf janky. This just keeps going on and on because we like to automate lots of stuff but we won't talk too much about the other tools because I'm a busy guy and there's still a lot more to do. So now that my changes are committed I'm ready to push them up to GitHub and once the code's pushed up to GitHub then it kicks off the CI build in Travis. As part of the CI build we run the full test suite against all of our supported browsers and we accomplish that through a mixture of test warm, Jenkins and browser stack. This actually has some interesting history. So test warm was created by John Rezeg back in 2009 and there were no tools like this back then. So he actually designed it to be more like study at home rather than a tool that could be used with an automated process that can spawn browsers on demand. The idea was that for every commit to one of our projects it would create a new job in test warm for every browser that we support and then anyone from the community could just join test warm with whatever browsers they have available and those browsers would just wait for jobs to be available and when they are they would run the test and then they'd report the results back to test warm. This worked out pretty well but it did have a few issues. We mentioned, Dave mentioned earlier about the change to request animation frame and that not running in the background. So we had problems like this where people would connect to test warm and then they switched to another tab where they switched to another application entirely and that would mess up the test runs because the browser behaves differently in the background than the foreground. We also had some problems with people installing browser extensions and then the extensions would interfere with the tests and we'd get all these false negatives and we'd have to rerun the tests and see if they were gonna pass for somebody else. So it definitely improved the amount of time needed to test because if anybody's ever tried to run their test read against every change that they make in 10 different browsers, you'd probably go insane. So luckily in 2011, Ritesh Aurora reached out to me within a few hours of releasing the browser stack data and within a few weeks of that, there was an API that was designed by Adi Esmani, Oliver Morgan and Matthias Binance and as soon as the API was available, I built a module, a node module to connect to the API and we started leveraging browser stack to connect to test form. But since then, the cross browser testing landscape has changed quite a bit and so now we're working on moving over to intern. Intern's a Dojo Foundation project. It has much wider scope than test form in addition to just replacing the job queue and the results aggregation. It also has support for web drivers so we can do real automation testing and it also directly integrates with browser stack and many other services. So we've been working with intern for a few months now and we're migrating over the projects one at a time and this will not only improve our testing but it will enable us to improve the intern project as well. So just as we've been active in other communities, we expect to become active in the intern community and help build up more infrastructure and improve that tooling. So that's an overview of everything that's involved in just a simple bug fix. So if you were to spend a few minutes thinking about all the tools and services that you use on a daily basis while you're doing development, the number would actually be pretty high. And so then if you think about all the people that are involved in maintaining all of those projects and all the time and effort that's been put into maintaining those projects and building the features that you need, you can see why it's important to have strong communities that are helping maintain these projects. So we rely heavily on the work of others so that we can more efficiently do our own work and as open source developers ourselves, we understand that value that the community contributions bring. And so because we understand this value, we strive to create mutually beneficial relationships with other open source projects. So for example, we've worked with the Drupal team before to replace their autocomplete widget and this benefits the Drupal team because rather than focusing on building common UI controls like autocompletes, they can focus on building a first class CMS. And it benefits the jQuery UI team because any enhancements or bug fixes that the Drupal team works on will get pushed back upstream to us and then all jQuery UI users would benefit rather than just users of Drupal. So when we found out that Drupal would be introducing dialogues into their admin panel in Drupal 8, I started a discussion with them to find out what it would take to get the jQuery UI dialogue into Drupal. And so their team did a review of our dialogue widget and they said that it met all of their use cases. They just needed a few accessibility updates. So we worked with them to get those updates in and then did another round of testing with them. And then we shifted around our roadmap and our release schedule to make sure that the updated dialogue would be out in a stable release of jQuery UI before the Drupal 8 feature freeze. So sometimes these projects, these collaborations cross many projects. So we had previously worked with the WordPress team to get CSS touch action into jQuery UI interactions. This allows things like drag bones sortable to work properly on Windows 8 devices. But today it's even more important with more devices supporting touch action. So TJ Vantol, one of the developers for jQuery UI, had put together a patch and when he was ready to send his pull request, he ran into an interesting problem. When he went to run the bill, as I mentioned we validated our CSS through Drunt-Contrib-CSSLint and it was failing the validation because touch action was such a new property that CSSLint didn't know about the property. So it said it was invalid. So as you might expect, Drunt-Contrib-CSSLint is built on Nicole Sullivan's CSSLint and CSSLint is in turn built on Nicholas X's Parcelib and Parcelib is what knows about all the actual CSS properties. So TJ sent a patch to add touch action support to Parcelib and then we had to wait for that to bubble all the way back up. So it started as a feature in WordPress, resulted in a new feature in Parcelib, CSSLint, Drunt-Contrib-CSSLint, jQuery UI and WordPress. So this does have some additional upfront overhead but the long-term benefits are well worth the effort of working with all these other projects. Sometimes we identify portions of a project that are large enough to become their own projects and splitting off into a new project has a few pretty big benefits for us. First of all, the one big benefit is just having code completely separated from jQuery UI just makes maintenance easier because you don't have all that coupling. But starting a new project can also entice new contributors and new adopters of the project. So as part of the merge between jQuery UI and jQuery mobile, we need to get to the point where we're using the same CSS framework. So rather than continuing to build CSS frameworks in the confines of our projects, we decided to build a standalone CSS framework but we didn't want to just add to the dozens of existing CSS libraries and frameworks either. So what we did instead is we just contacted the project leads for like two dozen of the most popular CSS frameworks and we explained to them what we were trying to accomplish. What we really wanna do is define a set of common classes and markup that we can use for common widgets and page layouts. So imagine if there was a gallery that you could go to where you could view themes that would work jQuery UI, jQuery mobile, digit, bootstrap, Kendo UI, foundation, and any other UI library. Based on the number of community created plugins that leveraged the jQuery UI CSS framework, we knew that this was a feasible concept. What we really care about is basically creating an interface for us to conform to and then the user can load any CSS framework they want as long as it implements that interface. So several of the project leads that we reached out to were interested in this idea and so we held an initial meeting and we had all the interested parties attend and we laid out a plan for how we would move forward and as a result we now have the CSS chassis project which is being led by Sarah Frisk. So even though this project was born out of the needs of jQuery UI and jQuery mobile, most of the team for chassis is actually not from either of those teams, it's its own team and this allows us to just like Drupal can focus on being a CMS and not have to worry about building an autocomplete widget, now jQuery UI and jQuery mobile can focus on building our JavaScript libraries rather than focusing on building CSS that will go with it and so chassis can focus on CSS only and then we can just pull that back into the projects. So even without an alpha release we already have interest from some notable projects. Digit which is Dojo's UI library plans to use chassis in version two of their project and WordPress has also expressed interest. Once there's a stable release of chassis they plan to build their next default theme. They release a new theme every year and they plan to build their theme on top of chassis once there's a good stable release out. So it's exciting to see such large projects with interest so early on. So we've done something similar for touch devices and this is a fairly hot topic so I'll give some history on this. Back in February of 2009, Paul Bacaus, the creator of jQuery UI, had filed a ticket to add touch support to jQuery UI and he included a patch. This was six and a half years ago now and you may be aware that we still don't support touch events. And the reason is because when Paul filed this ticket touch events only existed in Apple's proprietary fork of WebKit and I was fundamentally opposed to supporting a proprietary event system especially one that the developers just had absolutely no input into. There was no open standard for us or even other browser vendors to follow. It took a year and a half just to get the touch events implementation into the main WebKit repo and that only happened because Google reverse engineered the work that Apple had done. Half a year after that happened, Mozilla released their own implementation of touch events with Firefox 4. Mozilla's API never caught on which is a bit of a shame so it was later removed in Firefox 18 but then eventually Microsoft released I-10 developer preview and that included their own take on touch events which was a new concept called pointer events. Meanwhile, the W3C formed a working group called the web events working group to standardize touch events and the idea was to just take what was in WebKit and write a spec for it so that there was an actual standard for others to follow. That working group had representation from every browser vendor except for Apple and it's worth noting that even though we had all the browser vendors as members they were there mostly because they believed in getting web compatibility not because they thought that touch events were the right answer to the problem. So I represented JQuery Foundation in this working group and I tried to bring community awareness around the problems with touch events and that included legal issues with patents, an awkward API and just a dreary future with everything that was going on with all the different event models. So as part of this work I published a blog post and that contained a call to action from Microsoft to submit a proposal to the W3C to standardize pointer events. So after much encouragement from the community Microsoft did submit pointer events to the W3C and the pointer events working group was formed. Again all the browser vendors except for Apple participated in that working group and while the specification was being written there started to be a lot of polyfills popping up. So I asked the working group if everyone would be on board with selecting a single polyfill for us to promote and this would give us the W3C, the browser vendors, JQuery and Dojo all saying this is the one polyfill that you should use and hopefully that would get rid of the competition and people would focus on a single implementation since there's really no reason to have multiple ways to polyfill pointer events. So everyone was on board with this and we settled on the Polymer polyfill that was implemented by Daniel Friedman from Google. Since then Google has transferred the project to the JQuery foundation and we renamed it to PEP which stands for the pointer events polyfill. So just like Chassis PEP has no dependency on JQuery and it's just standalone polyfill that we will then pull into JQuery UI and JQuery Mobile. And this is important to us because we want all web developers using pointer events as soon as possible even if they're not using JQuery in their projects. So we also have members from Microsoft and Dojo helping with PEP as well. And in addition we're working with the HammerJS team to build proper CSS touch action support. So right now PEP relies on a touch action attribute because you can't really polyfill CSS and it builds on top of touch action. So we're working with the HammerJS team and Microsoft to see if there's a way that we can get at least just support for touch action through CSS so that the polyfill is 100% matching the spec and there's no slight deviation there. The Hammer team is also working on a build of Hammer that expects pointer events to exist. So right now Hammer provides an abstraction over a mouse, touch, and pointer. The purpose of using Hammer is to get gesture recognition. And so they're working on a build that will expect pointer events to exist and the idea is that you would load PEP and then you'd load Hammer and that way you can get a smaller build of Hammer. So this is a great example of how we work with browser vendors and standard bodies to push the web forward. The jQuery foundation actually does quite a lot of work like this because we think it's one of the most effective ways to improve the landscape for everyone and I'll talk more about that in a little bit. First I want to talk about the largest project that was ever born out of jQuery UI and that's Globalize. So in 2008 we introduced the date picker widget in jQuery UI which is actually our most popular plugin and it didn't start in jQuery UI, it was created by Keith Wood and Mark Verbansky as a standalone plugin. We pulled it into jQuery UI with the 1.5 release. At that point we had two dozen handcrafted localization files. So today we ship 74 localization files but they're still handcrafted and they're still limited to only the dataset that the date picker widget cares about. So in 2010 we started working with Microsoft to create Globalize which is an internationalization and localization library and it's based on the .NET locale information. The initial work for that was led by David Reed from Microsoft and it brought a lot of benefits to us. So by leveraging the .NET locale information we jumped up to 350 locales plus we had access to more information than just the limited set that our date picker was using. In addition to having more data we were also no longer responsible for maintaining that data so it's great when we don't have to keep track of the locale information for all these locales because we don't speak the languages, we don't know the customs and so we just have to, when somebody sends a pull request saying this thing was wrong and they fixed like part of a locale we have to go try to find another source to verify it. There's quite a pain so not having to maintain that data anymore was pretty important. And of course globalize is completely decoupled from jQuery why it doesn't even use jQuery core. But we've since switched to use Unicode CLDR instead of the .NET locale data. And CLDR is the largest and most extensive standard repository of locale information. So this actually gets us 740 locale and even more data per locale than we had with .NET. So the switch to CLDR along with all the new APIs to support all the new data that's available is being led by Hafiel Chavier. And we're in the process of rewriting the date picker widget and updating the spinner widget which also uses globalize. So if they use the new globalize APIs no should ship with jQuery why 113. As part of the work that on globalize Hafiel has been working closely with members from Unicode, Twitter and Adobe. And there's also been encouraging conversations from the Moment.js team as well as IBM and Dojo for the work that they're doing on their ECMO 402 polyfill. Hafiel has done a lot of work to bring the JavaScript globalization community together. He compiled an extensive comparison list of all the major libraries that exist for globalization. And it compares the goals and feature sets of all the projects. And so that way potential users can come and look at this list, compare to their needs and decide which project is best suited to what they need to do. All the data for that comparison list is public and the individual project leads can come in and update it as they make changes to their projects so that the information's always up to date and accurate. Hafiel also created a mailing list so that he can consolidate all the communication about just JavaScript globalization in general. Because as I mentioned before, open lines of communication are extremely important. And that work provides a lot of value to developers even if they don't end up using Globalize and maybe they use some other library. So at this point, the pattern should be fairly obvious. As we work on J4UI, we look for more general solutions to the problems that we're trying to solve. And if we can identify any of them, then we determine how much work is involved in creating that general solution. So sometimes that results in new projects like chassis or Globalize. Sometimes it just results in new J4UI plugins like the position utility. But either way, we just try to find the solution that makes the most sense for the most people. So again, we're trying to just address issues for as many people as we can. So let's jump back to the standards work that I mentioned earlier. I talked about my involvement in the web events working group and the pointer events working group. Helping to find standards is, it pretty much guarantees that we're gonna reach the largest audience, right? Because once we define standards, that affects everyone on the web. So that's why this type of work is fundamental to the JPRI foundation and all of its projects. Another way that we help shape standards is by providing feedback based on our past experiences and knowledge. So for example, when the new number type inputs were being added to HTML5, we were working on our Sprinter widget. Now I'd noticed that our Sprinter widget had step up and step down methods that defaulted to taking one step. But what we expect said that the step up and step down methods default to take zero steps. So what that effectively means is those methods were designed to take exactly one parameter and so just calling step up with no parameters doesn't actually do anything. So I emailed the, I posted a message on the WhatWig mailing list and a week later the spec was updated and now the APIs matched between jQuery UI and HTML5. So with jQuery UI being used on over six million sites and getting 10,000 downloads every day, we're well equipped to gauge developer reactions to proposed APIs and various implementations. So an excellent example of this is focus handling within dialogues. We've tried out a few different implementations of this and we still don't think we have the best possible implementation so we're trying to figure out what algorithm to use to determine which element should get focused when the dialogue is first opened. Unfortunately right now the ARIA specification and HTML specification don't quite match on what they say should happen for determining which element gets focused. So we'll just keep iterating on this and gauging feedback from the community to see which implementation is ideal and once we have an implementation that we think works well then we can go back to the standards bodies and say this is the experience we've had, these are the things we've tried, this is our recommendation for how this should be handled and then hopefully get the ARIA specification and the HTML specification to be in sync with each other. In addition to standards bodies, we have a great relationship with all the major browser vendors, all of them except for Apple. Jacob Rossi and previously Tony Ross from Microsoft have been a huge help in tracking down and fixing bugs in IE. Boris Zabarski from Mozilla is our Firefox liaison and he's just a great resource for history and web compatibility and just general questions. Mike West and Paul Irish from Google are available on the jQuery dev IRC channel along with Mike Taylor from Mozilla who previously worked for Opera. We also use non-jQuery IRC channels and mailing lists so we can communicate with some other teams as well and whenever possible we try to get bugs fixed directly in the browsers because again that affects the most people and it also keeps our projects smaller and cleaner. So hopefully this has given you some insight into how the jQuery UI team operates and all the work that's involved in maintaining the project. I only touched on some of the projects, organizations, teams and individuals that have been involved in this work but most of this would not be possible without the support and help of the community. So maybe you've built one of the tools that we use every day or maybe you've sent a pull request to one of our projects or maybe you've only searched on Stack Overflow. Either way you're an important part of the community so I'd like to thank you for coming out to the first ever jQuery conference in India. I hope you've enjoyed your first day or second or third depending on if you're at open webcom for any of the workshops. Hopefully I'll see you around at dinner and during networking. If anyone has any questions what happened to the jQuery UI grid? That's a good question. So we started working on the grid back in like 2010 I think and it was a very ambitious project. This actually gets into like questions that came up earlier about data stores and it turns out that building a grid properly is a massive project and there are already good solutions to this and so after spending like a year or so on the project we decided that it was not a good investment of our time because there were already good solutions and people were already using good solutions and we figured we could focus our effort on dealing with standards, working with other communities and just maintaining what we have and finding smaller controls that can be built on top of rather than trying to tackle a large project that's going to deal with data binding and data storage and lots of other components too. So we just after a while we felt it was just not a good use of our limited resources. Anybody else? Elaborate on grunt.html. Yeah, so if you go to npmjs.org slash package slash grunt.html, grunt.html you'll see the readme and a link to the repo. There's documentation on how to use it. Basically you just feed it a list of HTML files and it will spit out a list of validation errors and you can control for specific errors if you want to suppress certain errors. You can suppress those. For example, we have pages that are intentionally not well formed because they're sub-resources of another page, right, like for an age-act request and so we want to ignore the fact that there's no title or something like that. But the way that it works is it actually runs the validator.new code. So it just runs it locally and then processes all the files and gives you back any errors. Anybody else? Thank you. I think he'd made a bold move by not having any slides and doing a slide-less keynote. I really appreciate because I know as a speaker how hard it is to do a presentation without any slides. He did have his little notes, I guess, here. But just keeping people occupied without anything to see is pretty hard. Did you guys like the keynote? Lot of information, lot of touching upon real challenges, right, not just hand-waving but real stuff. So I think that's really appreciated. Thank you, Scott.