 We're gonna get started with the next part of the program which is kind of something that we are trying for the first time. So sorry guys, if you kind of become the scapegoat of this experiment but that's how we learn, right? So the next thing that we have is kind of trying to make it a little bit more fun and inclusive by you know having people ask questions they might have for the jQuery foundation. So I would like to invite the three folks we have from the jQuery foundation Dave, Chris, Scott. And we have, you're gonna see keynotes from each of these guys. You're gonna get their detail introduction. I'm not gonna go into detail introduction right now. Most of you probably know them. We do have one chair that is left empty. The reason for leaving that chair empty is if any of the questions that asked to the panel here you feel they have not done justice to the answer then I would encourage you to please come up, take the chair and try to answer the question, right? And trust me we've done this kind of thing before which is like a fishbowl where anyone can come and participate and we've actually seen people give really good answers and you know it's it helps everyone out here. So again would encourage you guys to take their empty seat. You know these three guys are gonna be stuck but if anyone wants to come take the seat, answer, go back. We'll leave the seat for someone else, right? So we try to model this on Aapki Adalet. How many people are familiar with that? Hopefully everyone should be because that's been the longest running you know like reality show in some sense on the Indian television some 11 years plus maybe more. So just for the benefit of everyone here what we're gonna do is we're gonna accuse these guys for committing certain mistakes, certain creating certain problems for the community and we want to see how they're gonna respond to that. But before we get into this let's put the disclaimer out. I know there are people who believe that jQuery is no longer required we've kind of moved way beyond it but it doesn't matter what you think today without jQuery I don't think the state of the web today what it is would have been this, right? So again thanks to these guys for really making the web an awesome experience, right? I mean let it be standardization, let it be trying to deal with all the compatibility issues with the browser standardizations of certain things making. How many do you guys have any count on how many plugins exist for jQuery? I think infinity. According to the blog post I see every month there's a hundred best plugins every month, right? You do a search on Google anytime and you'll see if you just search for best jQuery plugins you'll see a ton of articles, blog articles, most of them spammy and they're all the best, right? I don't see how there could be a hundred best plugins of the same kind. That's because you guys did an awesome job. I guess so. All right, so we're gonna get started and then I'm gonna open the floor for people to ask questions so I'm gonna get started with a few teasers and then hopefully everyone else will chime in and ask questions so keep thinking about the questions you have, the accusations that you want to make on the jQuery foundation. We'll get started with the first one which is kind of a little fun and easy one so we'll see how you guys respond to that. So I believe jQuery foundation and the jQuery project is a non-profit and open source project but the alias that you chose for jQuery is dollar. Why? Why not like an underscore? Well, it's a historical reason actually. Dollar was used originally by Prototype, the Prototype Library. So when it came time to choose a character, obviously one of the things about jQuery that everyone likes is its brevity. They want the fewest number of characters you have to type and if you go back and see John's original post from late 2005 before he actually had the name, he was talking about how he could remove the number of characters and you liked the character dollar sign but it was taken by Prototype and that's why there's a jQuery.no conflict because you can use it with Prototype and you can use jQuery as something other than dollar sign. Okay, so is that okay with everyone? So we can forgive these guys for doing that. All right, let's move on to the next one. JavaScript in general, people get confused the heck out of what does this mean in JavaScript like this in so many different contexts, this could mean at least three different things. And then jQuery came along and added a fourth meaning to it, right? Which is basically if you're inside a plugin then this essentially means the element on which you call the plugin. Now that's at least to me not very obvious and it kind of confuses even more. So how could you guys afford to do that? Yes, so when you're inside of a method, this is actually funny because my answer was going to be that you're inside an instance of jQuery. So it should be that this reference is a jQuery instance. But that wasn't true, I actually don't know the reason for this. I do know that all the original methods were not on a prototype and who was it that told them? Michael Geary. So yeah, jQuery originally did not use a real constructor and did not have a prototype and there was just a collection of methods and all the methods got copied onto the object that was created. Yeah, so the answer I have is not true. So I actually have no idea why that's the case. But it makes sense today. I think the reason why there's fads that happen. So in 2005, 2006 timeframe, all the JavaScript developers were like this, what a cool idea, everything should be so object-oriented. So today, this is something that everybody wants to avoid. So like arrow functions, this is inherited because nobody really wants to use this. And in fact, there's all kinds of other new ways that people can bind a different this because it's kind of inconvenient to always have it be one value. But at the time, that was the exciting thing, right? This in a plug-in was going to be the jQuery object and this in a handler, or in most other cases, was gonna be a DOM element. Now you have to remember in 2005, 2006, most developers were used to dealing directly with DOM elements. They weren't thinking, they were using jQuery on top of it and they were happy that it was shortening what they had to type. But they weren't scared of the fact that they were working directly with DOM elements. So some of it has to do with history. jQuery was so successful that we think of this as, most of the time as being a DOM element. But it's amazing how many people don't even use it as a DOM element. They wrap it in dollar sign this because that's just the way they've been taught. Okay, so I guess that actually depends. Were you talking about within a jQuery plug-in itself, this being the jQuery instance or within the callback? It will be the element on which you call, right? Inside the plug-in. It will be the collection, the jQuery collection. The jQuery collection, so that's what you were talking about. So that's a fourth meaning that it's confusing. The feature callback or the event listener, then you have the DOM element itself. And that is mimicking the DOM. That kind of takes us to the next question, which is- In the next accusation. Next accusation, right? I'm not good at this, as you can see. JavaScript and DOM are two different things. But I think jQuery has done a wonderful job to confuse people that they're the same thing. People were already confused. Everyone that hated JavaScript hated the DOM and they just thought that they hated JavaScript. So we didn't make it worse. We just didn't make it any better. That's a good way to get out of it. All right, let's move on to the next one. Plug-in architecture. We already touched upon the whole plug-in ecosystem that exists out there. I think the fact that every day maybe there are at least a few plugins contributed, if not publicly, at least privately. It's just amazing how easy it is for someone to go ahead and create a plug-in. Would you agree, right? Even though you don't have inheritance or any of that stuff, just extending a plug-in using the plug-in architecture is just amazingly simple, in my opinion. And I think that's a fantastic job that you guys have done. But then when it comes to having all these plugins, and then how do you manage dependencies and versions between them? And that's just become a train wreck, in my opinion. So what do you have to say for that? We don't make it worse. We just make it bad. No, actually, this kind of relates to some of the complaints that people have today, where they say jQuery is too big and it should be split up into pieces. Which is really going to create a problem just like you have with plugins today. But I don't think when you're looking at plugins, I mean, it's chaos out there, right? You have to be very careful about choosing the right plug-in. If you choose a well-maintained plug-in, it's well-behaved. And so if you look at something like jQuery UI where it's a set of plugins that work well together, then you're pretty convinced that they'll into the future be well-maintained and they'll be consistent about the way they were. But when you go out and you look for the 100 best date picker plug-ins of 2015, a lot of those have been written by somebody who thought it would be fun to write one, and then they decide that they don't have time to maintain it. And when that happens, then yeah, it becomes a little bit messy for the person who starts depending on it for their project. That's a separate accusation. The whole rating and ranking problem is a big one, right? How do you ensure through some type of community ranking or whatever that what you, if we're not the people who wrote that plug-in, how do we assure that that plug-in is going to be good for even a year or two years or five years? I'm sure you've probably had a plug-in that you've used in one of your projects and you say, I found a bug and you go to GitHub. And it's last updated four years ago and there's 15 or 20 or 500 bugs sitting there untriaged and the person who owns the project, it's basically not working on it. So the problem there is that we can't control that, right? We don't really, when you go to select plugins, you just have to be very careful about choosing ones that are well supported and active projects versus ones that when you search, you find a reference from 2011 that sounds like it's a good deal. And then you start using it and realize, 2011 it was a good deal, but it's not in 2015. There's actually two problems here. One is how do you choose which is a good plug-in given that there's an ocean of plug-ins out there. The other problem is trying to understand if this plug-in is gonna work with this version of jQuery that I have. And just managing the versioning between the plug-ins. I think those are two kind of boiling issues in some sense, which is a good problem to have the fact that we have so many plug-ins. But I think at this stage, jQuery gets a lot of bad name for not solving that problem. And what's funny about that is if you look at NPM, which is sometimes touted as a solution to that, it's not a solution to that. If you have a complex NPM project, just try to go and update all your dependencies one day. Or see what happens when something several levels deeper in one piece that you depend on has incorrectly declared a dependency. I mean, we have seen situations like that where things just blow up. And it's really just a question of which dependency hell you wanna live in. You can live in the jQuery plug-in dependency hell or you can live in the NPM dependency hell. It's a hard problem. You can see what, all the way back to Windows, what they did. They had the same problem and they did essentially what NPM does, which is they save every version of everything possibly used onto the drive. Which for a client side developer, that really doesn't work. You can't tell your client, well, I'm using three different versions of jQuery to pull those in. And then I'm using two different versions of the same plug-ins to pull those in. At some point, you have to rationalize those and figure out how to get ideally one version of jQuery, so. So is there something that as a foundation, you guys are trying to do to address these two issues? I know it's a hard problem, I don't know actually if any other ecosystem has really, really solved the problem. But the whole dependency management, versioning seems to be a hard problem. Especially when you have a lot of contributors contributing things. What's, what is cooking up in the foundation to address that? So we just delegate to NPM for this. We just use package JSON, that's what we use with the jQuery registry, the plug-in registry that is now read only. You had to use a manifest that was very similar to package JSON. And you defined your dependencies and their version ranges. And now we're just telling people to go use NPM. And you do the same thing, right? You define your dependencies and their versions. And it's really up to the plug-in authors to get those dependencies correct. But it's hard to see into the future. So when you release a plug-in, the version range that you have may not be correct if it's liberal. So if you declare your own plug-in, say a jQuery plug-in, and you say I'm compatible with every version of jQuery above 2.0, then you're trying to look into the future, like Scott said. And you probably can't look that far into the future because you certainly don't want to look beyond 3.0, because at each major version there's a potential for breaking changes. So you have to be careful as a plug-in author. If you're making a component that someone else will consume, it's much better to be extremely conservative about what version you need. Otherwise, you can run into the problem of inadvertently breaking lots of dependent projects because they're using your project, and you've declared a dependency incorrectly. And there have been some changes in NPM, the version 3.0, which is currently in beta, is going to support a feature that we have been asking for, which is flat dependencies. So if you use Windows and you try to pull in a lot of NPM projects, you probably notice sometimes it can create paths that are so long that they can't even be deleted, that project can't be removed. That's because right now it's a complete deep tree, even if there's duplicates. So the NPM 3.0 makes it so that everything will be maximally flat. It only creates subdirectories of subdirectories if there are conflicts and versions that can't be resolved at the top level. You can also say, as a client-side developer, I don't want to include multiple versions of the same project because I don't want to have that extra bite count in my project. But those are coming in NPM and we're trying, I think the entire industry, you may notice, for example, that a lot of people are not talking much about Bauer anymore. I think the entire industry is trying to coalesce around NPM because we don't really think we need to have five or six solutions to that problem. It would be nice to have one really good solution. And then we'll try to solve the issue of education. I think it's primary education to make people understand that they can't say I'm compatible with every version above 2.0 because they can't see into the future. All right. I'm going to pause, I'm going to turn to the audience if they have any acquisitions to be made before I continue with my list. I see one hand going up. I see no hands being raised right now. At least one person. Darcy. What would be great is if you did something similar to what Gulp and Grunt do and you essentially search for plugins that are published at NPM but have some sort of jQuery flag, our keyword essentially. NPM is doing that with ecosystems. Okay. So are you guys going to have both? Because this is a problem, right? So the thing is that Grunt shouldn't have to solve this problem and then have Gulp solve the problem and then have jQuery solve the problem. Instead NPM should solve the problem once and then you have a Grunt ecosystem and a Gulp ecosystem and a jQuery ecosystem and it's all maintained by NPM. So when are you going to, I guess, moonlight the plugin registry then? When are you going to kill it? We'll probably kill it whenever enough people move over to NPM. So we have information on the site and we don't want that information to go away until there's a better resource. And so it will just linger in read-only mode until enough people move their plugins over to NPM. Can you update a plugin that's already been... Right, so that package that's living up there is getting out of date if I'm updating on... Yes, but the only thing that's out of date is like the read-me and dependencies. Because it's not housing the actual files. It's just going to link off to GitHub or whatever site exists for that plugin. Actually, I think that our decision to eliminate our own plugin registry was actually a sign of our desire to collaborate more with the other people in the industry rather than try to create our own solutions. So we could have headed down that path and in fact, had there been community support for it, we might have continued that. When we launched the plugin registry, that was a case where we applied some of our finances with Adam Sontag to work on that plugin registry. And the blog post announcing it said, we would love for the community to come and help us because we wanted to do things like ratings and rankings so that people would know what would good plugins. And we got really no feedback from the community, no help from the community that... And really that open source needs that. It can't be something where we're the ones just alone driving the project because we just don't have the resources to do that. So we decided that it was, again, better to look at other people who were working on those problems and try to support them versus trying to do our own thing where we already knew that the community didn't have a sufficient interest to put any effort into it. So you're not going to kill it anytime soon? You're not going to get rid of it? Because it's like out of date information, essentially. It is, but it's like there's tons and tons of plugins that are out of date as well that people still depend on. So I think to Scott's point, until there's something better out there, the fact that it's there, I don't think hurting anyone. We still are encouraging people to move to better solutions like NPM. All right, let's move on to the next one. Does anyone have another one? We're going to try and time box things to go a little faster. We I know we only have 16. This is about the promises and efforts. I hear from many developers saying that JQuery doesn't follow common Jspec of promises and efforts. Oh, that's one of my favorites. Do you want to repeat the questions? Yes, it was about JQuery's deferred. Deferred implementation. In JQuery 3.0, we have a Promise A compliant implementation. If you use the subset that is currently being shipped with ES6, which is basically just a then method and catch. If you look back to when we actually put deferred in place, which was 2011, I think, it was quite a while back, and there still were a lot of things unsettled about exactly how that would fall out. Promise A didn't exist by then. There was Chris Zips, I think discussion on that was out, but it was a very short, non-specific set of things. JQuery 3.0 will make it so that you can use Promise A if that's what you want. I would warn everyone, most of the things I think guaranteed async for resolution are great, but I think one thing that is going to trip up a lot of developers is the fact that errors are swallowed by default. If you go out on the internet and you Google for Promise examples, you will find that probably 80%, and I am not lying, 80% of them do not properly handle errors. They assume everything goes well, and as we know in programming, it rarely goes well. So what you will find is those examples out there, if you accidentally typo a function name, you will say nothing happened, and the reason why nothing happened is because an error was thrown and you didn't catch it. So it is really critical as you move to promise-based programming. One of the things deferred did was it exposed those errors. Now that caused its own set of problems, but with Promise A, if you don't catch those errors, they simply disappear and you will never see them. The native implementations have some browser support for showing you those errors, but most software-based Promise implementations do not. Cool. You had a question here? This is the thing of the past, but I am really curious to know that jQuery was supporting IE678 right down until early 2013. Why did it take us so long to shun them? And I mean, just to show context, how many of you have been given hell by Internet Explorer at least once in your lifetimes? Thank you. It took us that long because people are still asking for support. Even now, people are saying, well, we need IE8 support, and we still provide a compat version that does provide IE8 support, but IE6 and 7 were still around, and that was a controversial decision at the time because even though XP was on death's door, people said, oh, no, no, it's, you know, there's still a lot of it out there, but by the time we actually removed support for it, I don't think a lot of people felt like it was a major problem. Yeah, I mean, you know, of course, none of us will use IE6 or IE7, and the people that we talk to won't use it, but that doesn't mean that there weren't still a lot of people, especially in certain countries. I mean, you have to look at the worldwide usage, and even if you're cutting off, you know, only 1% of users, that could mean 20% of users within a single country. And when you look at the statistics that way, that's a terrible decision. So it's important when looking at browser statistics and how much something's being used to look at many different markets and not just complete worldwide usage and not just within a single country, but within many countries. Also remember that JQuery is the foundation for a lot of projects out there. You saw the numbers that Chris showed. If we don't support IE8, then it's going to be really difficult for you as developers to support IE8. So your decision to not support IE8 may be fine, but if we make that decision for you, then you're going to have to go to your bosses or your clients and say, sorry, but this is going to be 10 times more difficult because I have to do this all myself. And that would be something that people would definitely yell at us about. Yeah, that actually brings us to the next question, which is not really a question. It's actually an appreciation for what you guys have done and this is something I wanted to point out. So when you look at browser detection, that's a huge challenge today, I think. Is that a fair statement to make that browser detection, especially in client-side scripts, is a huge problem. And I think one of the ways jQuery's solve that problem is by using feature detection. So you basically put in a little script, see if that works, if not fall back. So you kind of have a feature detection instead of relying on the agent screen or other kinds of mechanisms that are out there. And I think that's a really interesting and powerful way of dealing with that problem. How did you guys come up with that? Who came up with the approach and how? I don't remember. It wasn't on our team. It was actually something that people were advocating to us. The early versions of jQuery used browser detection in certain cases. I mean, the most common scenario that I can think of that existed all the way back to, even before jQuery existed, is detecting if you had to use add event listener or attach event. You know, some people did the user agent string detection, but most people just check, you know, does attach event exist or does add event listener exist and just use the one that does exist. And so that's the earliest example I can think of a feature detection. So really just taking that and applying that same concept to any time that we hit a browser bug that needs to be detected. The time when that really hurts is when you have a situation where the only way to detect a feature is to actually put something into the page and measure. For example, if there's a problem with the way the browser measures margins, you can detect that with a feature. You insert something into the page and you see what the margins are and if they're not what you expect, you know it has the bug. But that turns out to be a very expensive thing to do because it can force layout and cause other issues. But quite often that just makes us, gives us more ammunition to go to the browser maker that's causing this problem and say you need to fix this bug. That's gotten much easier than it was in the IE 6, 7 and 8 days because the browser makers usually don't want to hear from us when we have something to complain about. So they'll fix the problem to make us go away. Cool. All right. Time for one more question. Yeah, I think you've been raising your hand, so that's it. You want to use the mic so everyone can hear? So jQuery is used around like in 84% of the websites, right? And request animation frame has been there for a long time. But now you have been including it in the next version, right? And it's mostly said that web animations are sluggish on mobile or desktop devices and most of them use jQuery. So do you want to take the blame that for the web animation sluggishness jQuery was responsible? Yeah. That's an acquisition. I think that the reason why it took us so long, we actually tried using request animation frame what, three, four years ago. And when we did, we discovered a lot of bad assumptions by developers, essentially. What happened was someone would say, do an animation for 10 seconds. And we would use request animation frame to perform that animation for 10 seconds. And then they would have a set timeout for every 10 seconds saying, we do that animation. So the net effect was that there was a set timeout restarting the animation every 10 seconds. And then this request animation frame doing the animation. It turns out that when the window was out of focus, request animation frame never fires. So if you kept the window out of focus for an hour, then it would queue up a bunch of 10 second animations. And then when you put the window back in focus, all of those animations would cascade and try to run all at once. And that was because people had made bad time assumptions. They had tried to use a set timeout and request animation frame in combination, assuming that a 10 second animation would always complete in 10 seconds. And that's not guaranteed. So really the reason why we backed off and went back to set timeout for all that time was because there was too much code out there that broke in a way that we just felt like we weren't doing anybody any favor by letting it stay broken. We hope most of that is gone now, but if it's not, we have basically a backup so that when we see a window go out of focus, we'll clear the queue. But those are decisions we have to make all the time. When you try jQuery 3.0, and I urge you to do so, you will see code that you have break. And you'll be thinking, why did they break this? I'll be talking a little bit about this in my talk tomorrow. The problem we have is we can't give you the best practices and convince you to do things the best way without breaking some code you already have. And that's the problem we had there. In that case, we decided to wait. We said, well, let's hope that people fix this problem and we'll come back later. But we either have to hold back on best practice and on performance in order to make it so that your code continues to work, or we have to break your code. And that's a tough choice. All right, that's a very good answer. I think we have last five minutes left. So we could take one more question, but before that, I have not really an acquisition, but a question I want everyone to answer, which is basically if you had a time machine and you could go back in time, what was the one thing that you would not do in jQuery? I have a bunch of them. I really do. Your favorite one. I'll pick one. I guess if I had to pick one, it would probably be Ajax. Our Ajax implementation, I think Scott would probably agree with this one. I was going to say that, but I wouldn't take the original Ajax out of jQuery. Oh, well, but I think we both agree that the current Ajax implementation is extremely complex and it's one method call that tries to accomplish every form of communicating with the server. And by doing so, it makes it very difficult for the end user to figure out what's going on. And it also tries to make, there's a term that we use almost as an inside joke called intelligent guess. And essentially when jQuery tries to communicate with the server, it tries to figure out based on what the data looks like and what data type comes back, what it should do with the data. And inevitably because of poorly configured servers or bad data or whatever, something goes wrong and the user doesn't understand why things are working incorrectly. So the idea of Ajax, we all know we need it, but the implementation of the API could have been broken up into smaller numbers of methods that were more specific to functionality and some of those options could have been turned into helper methods, for example. All right. Yeah, Ajax is the thing I complain about the most, but I think if I could go back in time and change one thing, it would be getting people to listen to me when I told them not to implement the furs the way they did. Then we would have had no compatibility issues and everyone would be a lot happier. I think without browser support for some type of error handling though, I think it would have been very difficult. We would have just never heard the end of that. Yeah, but we could have at least done what Dojo did and then not have strayed. Yeah. Unfortunately, when you lead, when you're that early on, I think there's a lot of design decisions. What came out of Promise A was very good, but it took three years, four years before it solidified, Promise A plus. I mean, by that point, every one of the things had been specked out. We were kind of trying to implement ES7 features three years before ES7, and it's always an iffy proposition to do that. All right. Chris? I guess I would say creating jQuery mobile separate from jQuery UI. I am. Wait, can we extend this another hour? Because now it's, now we have to do a ton of work to bring them back together, right? And it just makes sense to have a single UI framework or UI library that handles all of the widgets. And then jQuery mobile can just be the separate framework bits for page navigation and things like that. And so that's what those projects are working on doing now, but it's been years of time where they could have been working together. Right. We have Ajax. We have people listening to you. And we have not having mobile and jQuery UI as separate projects. Cool. All right. So we have time for one more question. Go there. I think this should we have. What prevented jQuery from using namespaces? JavaScript. Well, you can't squarely blame it on JavaScript. You could always invent your own namespace so it goes back to the first question about this. This will not work with a namespace. That's the reason. Well, still dojo does get around it, right? They don't have this. So if you wanted jQuery to look like dojo, then sure. And we would have never taken off. Oh, that's a strong statement. That's what you want. That hurts at least one person in the audience. All right. So this is the reason why they don't have namespace. So you can get rid of this and namespace both together. We'll get rid of JavaScript. All right. I think we'll go quickly here. One moment. So will jQuery 3 use TypeScript or ES6? No, it won't. And the reason is because that would be a project in itself just to rewrite it. And it would inevitably be larger. And if there's one complaint, everybody can always complain about till the end of time is jQuery is too big, which basically means they don't want to do their own custom build or that they don't really want to realize that that one megabyte image that they use as their hero image is significantly bigger than anything jQuery has in it. But there's no reason to rewrite. I mean, it would be cool to use all those features. And it would actually shrink the size of the source. And it would be fun to write, but it wouldn't make jQuery better in any way. So no, we're going to stay with plain old JavaScript. It won't be transpiled. One more question. Like for jQuery core, so like unlike other people like extjs or dojo. Who is asking the question? There's a question coming from somewhere. Yeah. Who gave that man a microphone? Okay. So like unlike dojo or extjs, why jQuery is not having a data store concept? Like store API, breast store or like JSON store. Yeah. So jQuery doesn't have a data store. And that's because jQuery is a DOM library. So people have this misconception that jQuery is like a library for implementing applications and websites using JavaScript. But it's really an abstraction over the DOM and then Ajax was thrown on top of it. And so all these accusations that like jQuery does not provide a way to organize your application or it doesn't have, you know, X feature is, it's just misdirected, right? Like it's there's no reason that a DOM library would have anything related to a data store. And they're very good libraries out there for that, like underscore or dojo. Yeah, use the dojo store just by itself with your jQuery code and then you'll be fine. Okay. So this is like a legitimate thing to do, right? And really dojo 2 is probably going to work that way. But that's the idea, right? Dojo is written in a very modular way and it's designed for building applications and so it solves all of your problems. You have request abstractions, you have storage abstractions, and then they have their DOM abstraction. And so you can use jQuery as your DOM abstraction and still use something else for your data store abstraction something else for your request abstraction. If, and then you could completely get rid of Ajax from jQuery and then you don't have to deal with all the bad stuff. So, so that's jQuery is a good part, yeah. This is like the proper way to use jQuery, right? jQuery, if jQuery is the thing that defines how your application is architected then you're doing it wrong. And that's the truth and it's that simple. So we get a lot of complaints about this, right? Like people start using jQuery for something simple and then they just grows and grows and grows and grows and then their entire application is nothing but document readies and event listeners and then they say jQuery is terrible for building applications but really they just they didn't actually sit down and figure out how do I want to build my application and then use jQuery for the DOM parts. They started with the DOM parts and just grew it until it was a full application. And you see this happen even with new, I want to say frameworks, but like with React. The Facebook guys say React is not a framework because it isn't, it's just meant for rendering views. And so you, you know if you try to misuse a tool or if you just say well this is all I need then you're going to find as you try to grow with it that unless you have some other way to organize the rest of what you need, it's not going to work well. So I completely agree with that. All right, we are running out of time so you guys did really well. Thank you so much. Just for the record none of this was rehearsed before. So these guys came up with all the answers impromptu so really appreciate that. Thank you very much. So we're going to move on to the next part of the program which is basically kicking off the jQuery hackathon that we have in support of the Joomla project. I did talk about it in the morning. I just want to kind of touch upon a little bit of logistics so that anyone over here who wants to participate in the hackathon is welcome to participate in the hackathon. It's happening in the room right around the corner. It's called a square hall and what we're going to be doing there is we have a bunch of people who've already signed up for projects that they have. Either they want to build those new projects or ideas or they have something already and they're kind of coming here to work with other people and take it to the next level. We're going to kick it off at 2.15 that's right now and then it goes on till tomorrow 2pm and then at 5pm tomorrow or 4.30pm tomorrow we're going to have each of those people who've done the projects come here and kind of show a demo. Each person gets three minutes or five minutes depending on how many projects are completed to showcase what they have done and then you guys are going to be the judges to decide who wins the hackathon. It's kind of called a hackathon but it's more than a hackathon so it doesn't matter. But the point is we wanted to get involved more people to come and do something at the conference as part of that and that's kind of why the whole idea of hackathon came along and then the folks from the Joomla project came along and they said you know what this is a good idea and we want to kind of support this and that's how we got the Joomla project interested in the hackathon itself and to come and participate at the jQuery conference. So with that I'm going to call sort of from the Joomla project to kind of quickly come and talk about what you guys plan to do and kind of also talk a little bit about encouraging more people to contribute to open source because that's one of the themes that we have is how can we make it easy for more people in India to contribute to open source. My pet peeve has always been that probably we have the highest number of developers in the world as a country but if you look at our contributions to open source community it's probably minuscule and maybe the jQuery foundation can further add some stats to it saying how much percentage of it happens. In fact I was talking to the founder of Stack Overflow and he was talking about the thing that amazes him is India has the highest number of hits on Stack Overflow. The highest number is like if you did a bubble chart India would basically encompass everybody else within it. India has the highest number of hits on Stack Overflow and the least amount of contribution on Stack Overflow. So yeah we have something called SDT Stack Overflow Driven Development SDT which is what a lot of people do, Google do that but you know what is preventing us from not being contributing to these communities out there. I mean going and answering a question is not that difficult I'm sure each one of you can do that but something is preventing us. So there is a theme in the hackathon which we are trying to see if there are things we can do as a community to improve that right. So I would encourage you guys to participate in it and I will let sort of kind of talk a little bit more about the Joomla project itself and what you guys are trying to do. Take this here. Sim I'll give him seven minutes. That's a lot of minutes I will save a couple of them I hope so. So meanwhile like as you know Naresh was telling like we have so many people in India that we can contribute so many projects into but still we are not coming up and I still see there are so much lack of you know interest I don't know maybe or maybe people are still you know hiding afraid of I don't know with the community or introverts or whatever you call us but I think you guys really need to go and you know these kind of events come up with the new ideas and join and you know make the things happen and that's what the open source is. Make the community build something great and move on. Make something better. So let me talk about one of the projects which I mean you know interested since long time and working with which is Joomla which is open source CMS and before that a little bit about me. I'm from Pune and I love open source. I'm into open source since like almost eight years now and I still love it every time I you know talk about open source and I love travel and technology. I have been many of the events around the world and it's like my favorite thing to do but apart from that I'm a basically Joomla holic. I have never touched any other CMS. Of course I have tried but I have stick to one and I still love it and always be. So I'm a board member of the open source matters which is kind of a organization which supports the Joomla project with the financial or trademark things and everything together and a lot of you know team in Joomla. Also I'm a representative of Mozilla in my region. Of course there are a lot of people but I do volunteer my time in you know another open source projects as well. So what Joomla is basically? How many of you have heard word prayers or any other CMSs? How many of you are already working with them? Blogging with them I guess? Yeah. So Joomla is another one CMS you know you can say which is having a lot of community so much popular for small kind of a business or a large or non-profit organizations and client love them because it's easy to manage and we are trying to make them better with the community. We have so many you know so many people around the world which actually really do some things for open source projects and Joomla is one of them which I have seen a lot of diversity you know from different part of the world and people are coming in every every city I mean wherever you go and have those kind of amazing events and you know join. So what are the features? Of course it's a open source project and people are you know multi-link sorry come from different part of the world and it's a multilingual you know feature which we have over 57 languages covered so far and we still are growing so if you're interested you know you can join those translate translation team as well then we have a one upgrade which you don't have to worry about you know what the CMS does and everything it just takes rest of the things you know itself. It has a help button in every page of you know system so if you have any problem you can just click and find something better which all documentation also a media management just one one folder where you can manage everything together then there is a banner management as well where you can have your advertisements and etc of course the content management so you you have a lot of different parts you know in the CMS which you can manage but it's an easy way to manage there also smart search feature nested categories these are all you know we have seen probably in many of the CMSs as well but the best thing you know I've talked about in many things and I mean many events and what I found people are you know interested in building something called as extensions in JUMLA and these are many things I would like to talk here in Eckerton as well as well as you know because you guys are friend and developers I see here and jQuery we are using like you know throughout the project and we are so much interested to get you guys into the project so we can you know get something better with the CMS and we need help to optimize this code as well so if you see any you know bugs or if you have any unit testing or anything you would be interested in you know I would love to hear from you and take help you know from this community as well so I'm not sure I have more minutes but I'm almost done so if you want to get started you know these are the two sites you can go these are free and you can just start get launched you know this site and learn about them also if you would like to you know be a part of this community you can just go to the volunteer portal which we have and just register there and you can find everything over there so let's talk about the Eckerton as Naresh said you know we have three different groups but I would like to hear more from you guys as well like what kind of ideas you have what kind of things you can build and you know what we can do with this Eckerton something interesting and something important out of this you know event and almost we have a one one day I hope so so I'm interested you know all night long if you would guys like to sit here or something talk and build something so we can do as well and we do have to offer some you know free goodies we have a jumlah world conference coming and it's in the same city Bangalore which we have previously in different part of the world in Mexico and Boston and everywhere and now this is the time like it's in India I have bring this to India because we have so many talented developers and I would really like you know Indian people to get involved in the project as well and of course to the Asia people so and we have many great speakers you know lined up here and we are still trying to get more people which probably you might know or all of you know so if you guys are interested in this I would love to talk and you know just fine wing I won't I won't bite I promise so thank you guys you can contact me any of this you know channels if you would like to hear more so thank you very much and thanks for giving me time thanks guys so with that we're going to close this and now we're going to split the halls again and final sessions are going to get started right thank you again