 It's basically going through each file, seeing what's wrong and fixing it. So there's a lot of files and lots of things wrong, so text time. We are mostly there and like the main changes that went on for the past few months is using strict equals because JavaScript type check is a bit weird. So if we do that strict, that's much better. There's no guessing what it's going to be. The four, having that filtered, so doing a four dot, well, if object has an property, whatever, to check that we don't go up the prototype chain, this was actually a bug in autocomplete. So this kind of things fix bug, even if it's not just making things pretty. We are using the strict mode of JavaScript, so we're not going to use the advanced object things. We're just using it to check that we don't have any global variable that's leaking because it was not properly declared. There's been quite a lot of them, so now it's fixed. And the context change, that was a big one. So because I8, we can use query selector all, and changing all the jQuery to use this format, it's very close to what we're going to do afterwards by not using jQuery. So it just facilitates the change. And well, actually it's a bit more performant as well, but it's little useless, so that's it. So that's what's happening right now. But we have a lot of things to do, and now I'm just going to talk about each of them for one minute or two, and then we're going to be talking about the... No, that's fine. I'm going to be too light of the words. Thanks. Yeah, so talking about each of the points for one or two minutes, and afterwards we can... Well, we can discuss the rest of it because there's a lot. It's just going to be for 20 minutes or so, and after questions. First one is JavaScript and CSS processing. Currently, when you add JavaScript file to Drupal, you have to use Drupal at JS, and then you have some aggregation going on, and maybe some CSS optimization, but it's very hard to not use modules like LabJS, have to do a lot of complicated things to take over what Drupal does, and make that better. So what we want to do is make it pluggable. So not necessarily with Drupal plugins, but just a way to say that, well, my set of files that I added, I want them to be in some group, and I want to minify them, or zip them, or these kind of things. Currently, if you just use what Drupal provides, you can do that, but if you want to have your own thing, it's not possible, or very complicated to do. So we want to make this change for Contrib to provide more things for JavaScript. If you want to use less, it would be possible to add a plugin to transform your less into CSS, and these kind of things. But currently, you can do that, or you can after a while. We are talking about using Assetik, which is a symphony component to handle these kind of things. It's used by a lot of PHP projects as well, so it works well, works great. We need to integrate that. Minification. Matt Farina in Denver talked about that, and if you remember, there were some issues around licensing, because when you minify, you strip out the commands, and license is in the command, and you can't check reliably to say that this block is a command and is a license, and you don't remove it. So it pretty much killed the issue, and we're going to ship with minified files, because there's no way around that. So it's going to be like jQuery, they have their development version, and their production version. So we're going to have the same kind of things. So it's going to be one extra step for a Jupyter release, but I mean, that's going to give a lot of improvement, so that's something we need to do as well. Performance. This links to the jQuery issue. I'm not going to talk about that, because the mobile conversation should give you a lot of information about performance, and JavaScript. We can talk about that if you want, but not now. After we want to have JavaScript modules. So any of you know Node.js? Yeah? Yeah. Yeah, so you know Command.js, which is the format to make Node modules. So you have a variable equal require of something, and this kind of stuff. So that's great, but we just can't use that in Drupal right now, and we need to. So there are a few steps to do to have that available, but the most important thing is that it's not, we're not talking about turning Drupal JavaScript into Command.js, or AMD, which is the same kind of specification. We're talking about defining the dependencies for everything. So we have the hook library info, when Drupal installs hook library, and this allows you to say that this library is going to add JavaScript, CSS, and other dependencies on some other library. So that's exactly what Command.js and AMD do, but we do that from PHP, because that's what we do, that's Drupal. And the last issue is something that was started Sunday, and it's pretty much done, and it just turns everything into libraries, and use Drupal add library to add everything. So there's something that's linked to that, it's a Drupal bug. So right now in Drupal 7, you can't have a page without JavaScript. It's not possible. There's always jQuery and Drupal, even if you don't use it. By declaring all the dependencies, we can avoid that, and it actually solves the problem by itself. So it's not just about pretty JavaScript as well, it's fixing bugs. I think there are two tests that are still failing, but should be enough to fix, so that's good. So when you do changes, you need to test them. And basically right now, we are at the same level as Drupal 6 for PHP. You make a change, you hope it doesn't break, and it breaks. So we need testing somehow. There's a test swap module, which works great. It's just not really going to be in core for Drupal 8. I mean, there's too much work to be done, and this is not in the scope. But it works, and you can test Drupal with this module. There are some tests, but we need more. So we need people to write them. The test swap module actually catch bugs in Drupal core, and regressions as well. So I mean, this stuff works, you can use it. And we want to have new features, because that's the way it works. I put jQuery UI because today Drupal 8 doesn't use jQuery UI anywhere. It just defined in the hook library, but nothing uses it. It used to be dashboard, but now it's out. So it's just convenience for contrib, but it's outdated. So well, we need to find a way to make that work better. View is going to get into core, hopefully. And this will add models, drop-down buttons, stuff from C tools. And we need to figure out how to integrate that best with Drupal core. Then there's a WYSIWYG thing, like the Spark Initiative. I'm not sure what is going to be changing for Drupal core, but that's something to keep in mind later on. And there's also feature detection for mobile. So to say that this browser doesn't support the date input or something, and you want to add JavaScript to polyfill that. We don't have feature detection in core. I don't think we should have it, but that's not up to me. We need discussion and agreement. And that's where you guys can help. What are the use cases, the problem you would encounter with feature detection and this kind of stuff? We need to have data to make a decision somewhere. And with new features, it's new code, more code, and we need better code. And the first step is coding standards. We have them for PHP. We have code checking for them. And we have other stuff. And in JavaScript, not really. So we went with JS int. Do you all know about JS int or JS lint? Yeah? No. You don't know about that, all right. So basically it's, you can go to JS lint.org, and basically you have a text area. You copy paste your JavaScript into that, and it's going to check for command mistakes. For example, you didn't declare a variable, so it leaks to the global scope, or you did a weird construct that's error-prone, these kind of things. It can tell you to not do that. And this is an automatic check, so there's a command line tool for JS int, and you can run that anytime on the JavaScript of code, or a country called JavaScript. We are mostly done with fixing that. It's in the to-do of the rest of the cleanup. The first thing to solve is JS int, because it's warning and, I mean, just moving code around to make it better. So that's easy enough to fix, but it needs to be fixed. And there's maybe five files that still need to be resolved. Then we have selectors. So jQuery selectors are great, but the way we used them, it was not very good. It wasn't very performant because of weird constructs, and we need to make that simpler and faster, because that's the main reason why a script is slow, at least in code. The bad selectors. We need to refactor a lot of JavaScript, like table header, table drag, pretty much everything, basically, because that's old code, like I said earlier. It's five years old code, it's not like that, we don't do that anymore. And there's the rest of the JavaScript cleanup tag to solve as well. Yeah, so, I mean, it's maybe 20, 40 issues for that, so, I mean, you can do JavaScript work if you want to. But, oh, yeah, bugs. Yeah, because that happens sometimes. So I'm just taking the JavaScript component. So if you go to dupal.org and you search for issues, you can select by component. I'm just selecting bugs from the JavaScript component. But keep in mind that there's a JavaScript tag as well, because there's JavaScript in overlay. Well, everywhere there's JavaScript. So this is just the component and bugs for dupal 7 and 8. So since you all have IRC and you can ask the bot to resolve the titles, you can see that the first one is something I broke on Sunday. It's the overlay. So that's a one-line fix, but it's practically overlay, so that's bad. The second one is a dependency thing I was talking about, that in dupal 7, you can't not have JavaScript on the page. So this is mostly fixed, but it still needs some work. Yeah, so that on the white background. The third one is the table header overlay fragment mess. So when you follow a link with an anchor on another page, if you use the overlay, it's not going to work. And if you don't use the overlay, you're going to have the table header on top of that, or the toolbar even. So this is something broken, and we need to fix it, but it takes work to fix that. So from C tools, we already have the state API, which comes from the dependency script from C tools. And this is the issues in being credit something. So it's great. It works well for... Sorry about that. It works great, but there are still big bugs on it. I mean, nobody uses it, so that's fine, but it needs to be fixed pretty quickly. And the blue ones are table related bugs. So that's table header, table drag, and this kind of thing. So you can see that there's like 50 issues just for bugs in JavaScript. And there's four times as much as many when you take tasks, feature requests, and JavaScript tag. So I mean, it's been one month show for a few months. Now people are starting to get interested in it, but we still need a lot more people to contribute. When you fix bugs, you need to tell people not to do it again. So that's documentation. And we didn't use to have documentation because that's commands in a JavaScript file, and it makes the file bigger, and we don't want to make the JavaScript file bigger. So now that we are going to minify it, it's going to get removed, so we can actually command and document our JavaScript. But then the problem, which tool are we using to document that? JSDoc works really well. But the head of documentation at some point traded out and didn't... There are still bugs that make it... We can't really use it right now because there are a few things to change in JSDoc. But the maintenance for JSDoc is very nice. You can... I mean, I send a blue request, he integrated that in a few hours, so that's very easy to contribute to. And the problem with JSDoc are pretty easy to fix. So if we have someone who can contribute back, we can have documentation in our JavaScript and hopefully at some point on api.jupor.org. And this is a very big issue because some of the consultants have traveled a lot, and I see a lot of people and Drupal people. And they just don't know about behaviors because that... I mean, it doesn't say anyone that you should be using behaviors and not jQuery.ready to do things. And when you explain to them, it makes sense, and they use it, but they need to find out, and apparently they don't. So we really need that on api.jupor.org somehow. So this was about JSDoc, but there are other projects we can contribute to to make our JavaScript better. So jQuery, we already sent a few things to them. And the other one as well. We are not using jQuery UI in core because of accessibility issues. The autocomplete we have is better than the jQuery UI 1.8 autocomplete. And that's why it's not jQuery UI for autocomplete right now. But this was fixed in the 1.9 version, so we can actually change it. And there's a patch to review for that. And JSDoc to fix the last issues around that. So require.js actually not really because there's... Well, we use it in a sandbox, and it just works, so that's... But the guy who do require.js has a lot of knowledge, so we can benefit from that. We just need to come up with a proper way of managing JavaScript in Drupal, and we can benefit from the whole community of JavaScript developer. And I love because I was at the sprint with them, so it was last month, and they are very, very good JavaScript developer. And I mean, they know what they do, and that would be great if people like them came into Drupal to do Drupal JavaScript, because we need people like them. So that's it for me. I'm just putting the list of the thing we went through, and now it's questions. So do you want me to explain something, explain better differently, or just talk about something else? Yeah? I think you need to just walk up there. Yeah, it's for the recording. Where can we go to help you with all this? And you can go into the core issue queue. You can talk to me afterwards as well. That works. And in the core issue queue, you have the JavaScript component, you have the JavaScript tag, and you have the JavaScript cleanup tag to do some more specific and maybe easier review and fixes. So is that something? Yeah, because also we really need documentation, so explaining to people how to do JavaScript, because the current documentation on Drupal.org is not that good. Well, it does, so that's good, but it could be much better. Yeah, so basically reviewing and documentation, that would help a lot. Other questions about maybe performance? I didn't really go into details, but there's a 200 comment issue on that. All right, so performance, the problem is mobile. Drupal.org is supposed to be mobile, but jQuery is big. It's like 32 kilobytes of JavaScript zipped. And it's not a caching issue, because even if you have JavaScript in your browser cache, it takes a long time to initialize on page load. And this is not something that can be avoided because of the way it works. So basically, there's a jQuery.support object, which tells you if the browser is supporting a position fixed or some other CSS thing. And this is checked by adding domain elements to the body, doing some things and removing them on each page load. And that's something you can't avoid, at least not until jQuery 2. And that's why I wanted to not use jQuery to be able on some pages of Drupal.org to not have it, because we only use events of jQuery, and that's not 32 kilobytes of JavaScript to manage events. So that's the main reason why jQuery should be limited in core. And because we can use query selector, which is actually much faster than the Caesar way. I haven't checked the last update of Caesar, which is a jQuery selector engine. It's supposed to be much faster, but I don't know about that. I need to check. Also, something interesting about performance is that if we use modules like AMD, you can load your JavaScript asynchronously, so that maybe not something you want to do all the time, but it's something that would be possible if we had this kind of well-structured JavaScript or like on-demand script loading. So you click on a button, it adds a new JavaScript file because it wasn't needed before, and it does things afterwards. So that's something that could be done as well with better JavaScript. They came in too late. Nobody's talking now. We're just watching each other until it's finished. Yeah. I've got a question about the modules. Does that mean that you'll bundle the modules as well so that we can load one file rather than eight different JavaScript files, or did I miss that? Yeah, no, that's... Bundle minify module. That's actually possible to have several modules into one file. Well, I don't know about Command-JS, but I know that with IMD it's possible, and you can have several defined code inside of one file. So if you set the aggregation of JavaScript file, if we have the hook library thing in, we can actually generate the defined code. So we don't have to put that into the JavaScript files, and we would actually be able to get rid of the file-level closure, so the parent's function, jQuery, blah, blah, blah, we can get rid of that as well. We could. But so any who here knows about JavaScript, like it's confident that you can do good JavaScript. It's confident that you can do JavaScript. Okay. So why are we... We can maybe shut the door and get you to work on some issues. For a few days, because that would fix like most of the problems we have right now. I mean, it doesn't take a lot to contribute to JavaScript. It just, I mean, takes people to get started. Because I mean, JavaScript, the bugs are weird, but they are pretty easy to fix when you know what to look for. And if you need help with that, I can guide people to whatever is needed to do, to fix the issue, or maybe even teach people if that's what needed to get more contributor. Yeah. Not really badly need some help there. It's doing a really good job. Thank you. So please, people, if you understand JavaScript, help them. Yeah, and you know JavaScript, right? Yeah, and like I say, it doesn't take much. Any other question? I guess we can finish. I'm here until tomorrow afternoon, and I... Oh, okay, one more question. Is there any resource for documentation and getting to understand what JS is in Drupal at all? I do a lot of JavaScript, but I haven't used the Drupal part at all because there's no documentation, and I don't even really understand what behaviors are, actually. And so it's... So what's your... What's the main thing you don't get? So how do I... Well... Because I mean, I can't reply because there's nothing, like there's no resource to get that and apart from reading the JavaScript code and trying to understand it. So what's the main part I can start with? Yeah. Maybe I should join the documentation part. Yeah, that may be good. So I mean, and this is actually a very common use, a very common feedback I get is that, yeah, that's good. You have all that, but we don't know about it and it doesn't really make sense when you're not from Drupal. Yeah, so I'm going to be here until tomorrow and not after that, so if you have a JavaScript question, if you want more information or anything, you can ask me that until tomorrow and afterwards in the issue view. But yeah, yeah, we need help. Badly.