 Well good afternoon, I hope you're not too sleepy after lunch, so I try to make it quick for the actual interesting part. So I'm going to talk about what you need to do as a module maintainer or as a custom module writer to port your JavaScript from Drupal 7 to Drupal 8. So my name is Theodor Bia-Dala, I go by node on Drupal.org. I'm a JavaScript maintainer for Drupal Core. I've been maintainer for a year and a half or something. I'm also a technical consultant with Acquia. So I'm not just in the core queue, I also know and see what's happening to project on a tight deadline and the kind of horrible thing that happens during those times. And just before we start, I just want to know a bit about how familiar you are because that's a beginner session. So who can write custom module here? That's great. Who knows about render arrays? That's great. Who knows about attached? Yeah, well done. Who knows about hook library? Yeah, a little bit less. All right. So I will need 10 minutes of your time. Just pay attention and then you can sleep. So the first thing you need to do with your JavaScript, your Drupal 7 JavaScript, is search and replace. So you need to search for Drupal.settings and replace that by Drupal.settings. So that's a global variable that we use in Drupal 8. I'll go into the why afterwards, but for now just bear with me, search and replace. Second thing you need to search and replace is Drupal.sim.prototype. Now it's just Drupal.sim. So that might be a bit less common, but still pretty common. A fairly uncommon one is when you implement custom Ajax callback, you need to implement a JavaScript function. And usually it's under drupal.ajax.prototype.command. But now it's under drupal.ajaxcommand.prototype. I mean, there are several reasons for that if you want to know, I can go into it, but not for now. And for the JavaScript, that's all you need to do. And your JavaScript will work on Drupal 8. But for the PHP, there's a few things that change. What we see usually in module is that you use Drupal.js to put your script file on the page, or that you use the script functionality of the info file. This for Drupal 8, don't do that, because that's going to be broken. And actually, right now in Drupal 8, you can't insert the JavaScript file from the info file anymore. We remove the functionality. So what can you use to do that? You need to use attached. So whenever you have an element, a form element, a render array that needs some JavaScript to work well, use attached to insert the JavaScript file with it. And then the hook library in Drupal 7 is renamed to hook library info. So for those who are not familiar with hook library, this is what it looks like. Basically, it just says MyScript needs those other things to work. So first you have the MyScript, so that's the key you will be using to reference that in other places of the code. So when you use attached, for example. Then you say MyScript is this file. It can be several files. You can have CSS files as well that are included by your library. And then you have the dependencies. So this one, I'm going to go back to it afterwards. That's very, very important. In Drupal 7, the libraries you can suppose are available on the page are jQuery, Drupal, Drupal settings, and jQuery.once. So when you declare your library like that, it's just like it was in Drupal 7. Now a bit more concrete example. Let's say I have a page that's a callback for some menu hook somewhere. Well, not a menu hook in Drupal 8, but you get what I mean. So that's in Drupal 7. I do Drupal.js, MyModulePast, Script.js, and boom, MyScript is on the page. But that you shouldn't be doing anymore, because that breaks several things where I can't detail them if you want. But I'm not going to go into details. What you need to do now is declare the MyModule library info hook, say, okay, myJava script file is module pass script.js. My dependencies are jQuery, Drupal, Drupal settings, and jQuery.once. And then in the MyPage function, you will use attached with library and MyModule, MyScript. So it's nested arrays that vary Drupal. Can't really go around that. Is everything clear so far? All right. Now there's a patch to make this a bit more user friendly. Because writing PHP arrays, that's not very fun. We have YAML file. And if this patch gets in, you will be able to declare your libraries in a YAML file. So that's still science fiction for now, but hopefully that will be, you know, what will happen by the end of the week or two weeks, maybe. I mean, if you want to fix that, there's a sprint on Friday. So the YAML file will look like that. So you have the MyScript and JavaScript dependencies, same kind of thing. We remove one array for the dependencies because, you know, it's not really needed. We can just put a slash and work the same. And in the library attached call, same thing, just put the slash and that will work. And you're done. So JavaScript work on Drupal 8. So, you know, we say Drupal 8 is a bit scary, but not for JavaScript. Thankfully. But why did we do all that? Because I mean, that's three search and replace, use attach, library info. It was available on Drupal 7, so why, you know, we enforce that now? Because Drupal 7 has some problems. It's a bit ugly sometimes. The first problem is that when you download jQuery, you have jQuery 1.4. That's three years old. And since then, there's been a lot of performance improvements. We are jQuery 2.1 beta now. So, you know, lots of things happened. You also have a critical bug on Drupal 7 that every single page Drupal serve is going to have jQuery and Drupal.js. And you can't remove them. So even if your page has no JavaScript in it, it will load those files. And that's because we assume every page needs that. And that's not the case. Another problem is that the core JS breaks pretty easily. So, for example, when you use jQuery updates, they have to do some workarounds to not break the core JavaScript. Also, the client validation module that extends some prototypes somewhere and breaks core JavaScript. So that's not very good because it makes life harder for Contrib. And also one of my problems and the whole reason why I started to get involved in Drupal Core is that the Contrib JavaScript is not great. I could say it's pretty bad, actually. I started contributing to mapping modules like the OpenLayer modules. And the way they do things, it was very similar to what Drupal Core was doing. Then I found some problems in SQL Server Script. And I was like, wait, that's copy-pasted from Core. So I thought, well, if I want to fix Core, if I want to fix Contrib, I need to fix Core first. And that's what we've been doing the past year and a half. So now, how can we address that? Because fixing Contrib, that's a pretty big task. And I can't do that by myself. So we have some solution for Drupal 8. And the first one, it relates to the outdated version of jQuery. That's every single library we introduced in Drupal Core is going to be updated through the release. So if there's a new jQuery version going out, we're going to update that. It's not so scary as it was before because now jQuery is pretty stable. Like they have this whole 1.9, 2.0 API compatibility thing, so they can't really break much. So that's good for us. And I'm going to list the big library we introduced as well. And all of them will have updates through the 8 release. Then another big and important thing is that you need to declare all your dependencies. So that's why we require you to use the hook library info. And that's so important, I'm going to make it bold. So that's how important that is. And you won't be able to use Drupal.js anymore. It's already a deprecated function. And right now as we speak, someone is writing the replacement for that. Like next door actually. And once you declare all your dependencies as well, Drupal Core can do optimization that it wasn't able to do before. Dependencies, that's a graph. And we don't really have now a dependency graph, but we are working on it. And once we have this graph, we can do very neat stuff to optimize the aggregation, to optimize the loading. And actually in the course of making the patch for Drupal Core, we were able to load everything through Require.js and AMD. So all Core JavaScript was AMD modules that we would load through Require.js. And because you declare your dependency, we will be able to do that in Contrib. So stuff like Lab.js or Head.js, those kind of script loaders, will have a much easier time doing that job in Drupal.js. And if you have questions in the middle, just stop me and raise your hand. Then we have the strict mode and JS int. So the strict mode is going to be used because we don't like global variable. And we want you to declare all your variable that you use. And if you don't do that, strict mode will just crash. So that was great to debug Core JavaScript, and I'm hoping Contrib will do that as well. So you know you can just search and replace three stuff in your JavaScript file. But if you want to do it properly, well you should embrace the whole new way of writing JavaScript we have. So strict mode going through JS int validation. So who doesn't know what JS int is? Okay, I'll show you. So JS int, that's a command line tool that will look at your JavaScript files and tell you that a few things are wrong. For example, if you use just two equal in your comparison, instead of three, it will say, okay, that's an error, you need to fix it. And there are several options that we use in Drupal Core that I'm hoping Contrib will use as well. Because through the JS int validation, we found bugs in Drupal Core. So you know that's not just fancy and because we can do it. It's really important. And to fix Contrib as well, we're working on coding standards. We have a few new ways of doing more abstracted programming through backbone and this kind of thing. So we're documenting that and hopefully that will go out in a few weeks like the new documentation that Contrib can follow without shooting themselves in the foot. So you know that was kind of the tool, the process. But for you as a Contrib developer, what's new that you can use well today or tomorrow? First, we have new libraries. All those things are in Core. They're going to get updated so you can rely on it and just declare like underscore or backbone as a dependency. So who knows what check rate two means? Who knows? Yeah, without IE8. So check rate two doesn't work on IE8. But I will go back to that later. And that's a really important point. It took months to get that in. So you have check rate two. You have underscore. That's a utility library. It can provide need function for manipulating arrays, objects and doing some templating as well. But we don't use that. You can if you want. We have backbone that's used to structure your code because I mean, check rate is just a dumb utility library. It doesn't give you any structure and you're left on your own to organize your code. Backbone kind of bring the MVC model to JavaScript, whatever MVC means. We have modernizer and core because we have a few poly fields that we need to run. It's a custom build. It's pretty small, so it's not the whole thing. We have CK Editor. So who doesn't know we have WYSIWYG in Drupal 8? That's good. And that's CK Editor. So you can write CK Editor plugins. There's an API in Drupal for you to provide it from your module to the CK Editor configuration. And we also have Joel Wright. Who doesn't know about the tool module? You all know about the inline documentation and everything? No, okay, so views is pretty complicated, right? So when you end up on the views page, like on the view edit page with the three columns, you have a button on the toolbar at the top right that say tool. When you click on that, you get little poppins that say this element, this link is used for this kind of stuff. And then you can go through the whole page and read what the links you can click on actually do. So it's like inline documentation, basically. That's really neat. So if you want to provide documentation for your module, you can just rely on that. And that's going to be easy. I mean, there are maybe a few other more minor library, but that's really the important ones. We have a couple new APIs as well. For example, we have drupal.anons. This one is for screen readers. That's used extensively by the new toolbar to provide information about what's happening with the toolbar states to screen readers. So if you want to make your script accessible and, you know, don't lose your blind user, you should be using that. It doesn't show anything on the page, but screen readers will pick it up. Then you have something drupal displays. That's a little tool to say, so how much the toolbar takes, how much space does the toolbar take at the top of the page and these kind of things. Probably not many people will use it, but that's available. Then drupal debounds. It's the same as the underscore debounds function. So if you have a scroll event, for example, and you have a pretty heavy computation to do during your scroll event, you don't want to run it all the time. You want to run it once every, I don't know, 200 milliseconds, for example. So you can use debounds to do that. You can wait 200 milliseconds, and then run your function, wait again, so you don't kill the performance of your event. And maybe the most useful one for contrib is going to be drupal.dialog. This one is using, for now, jQuery UI dialogs to provide the functionality so you can open pop-ins and these kind of things. And actually, if you want to just open a link in a model, there's just a data attribute to add to your link and it will work, so that's pretty neat. The API for drupal.dialog, it's very heavily inspired by the HTML5 dialog specification. No browser implements it right now, but once they do, we can remove the polyfill. I don't know, maybe 10 years because of IE, hopefully. And there's a bunch of other minor APIs that are going to be much more specific, so, you know, beginner session is going to go into that. But if you don't, we can talk about it afterwards. We have a few new features as well, so we have responsive table that's integrated to views, so you can say, on narrow screen, I don't want to show this column because that's not really important. So, you know, your table will fit on mobile. We need that because the administrative UI uses a lot of tables, so to make that readable, we need to have that. Then for front-end performance on mobile, we have responsive image, narrow screen, don't load a big image, and that's the picture module. That's in core, so you can just activate that and you won't kill the data plan of your users. We also have quick edits, which used to be called in-place editing or, yeah, call a few things. That's pretty fun. You can extend it. It's a bit hard, but, you know, it's possible. And, you know, many more features that you've probably seen in Driskey Note on Tuesday. So, back to jQuery, too. So that means I8 doesn't work, if you try to, you know, go on the Drupalite website. It took a long time to get accepted, and the reason why, I guess, there's a great code, Bad Cache, saying that we could look stupid by removing I8 support now, or look stupid when we still support I8 in 10 years. So, I guess being stupid now is better. But, I mean, that's really important to me because that means any bug field to contribute because it doesn't work on I8, the maintainer can say, well, I don't care. Drupalite doesn't support I8, so I don't need to care about your patch or, well, your problem. If you send a patch, why not? But that means also that you can use new features of the JavaScript language that are not available in I8, like the native forage function, the native bind function, these kind of things. Go ahead, go crazy, you can do that. But then, in Core, we have Droplet, a very good developer, JavaScript developer, and he's in China, and all his clients are, you know, in China, and they use I6, I8 at best, and he's like, well, I can't use IDrupalite with them. So I'm stuck with Drupal 7 and the overlay. So there's an I8 project now. And this project is, the aim is to support at least the administrative interface on I8 so that people can actually use it with their clients. So right now, the only thing it does, it changed the jQuery 1.9, jQuery 2 to jQuery 1.9, adds a few poly fields here and there for native JavaScript function, like forage and bind, but that's it. We're still waiting to see, well, who is going to want I8 support for Drupal 8, and hopefully they will send patch, but we know that works. And now everyone is happy. Everyone is happy. And I got way faster than I expected. So that's pretty much, wait, I got one. It has a sprint on Friday. So if you want to fix, if you want to know more about how the new aggregation works, how we can use the graph, dependency graph that we're building, how to port weird use case that you might have as the maintainers, come by on Friday, I'll be there so you can ask me questions or throw eggs at me because you don't like the new names of the JavaScript functions. And that's, yeah, I guess that's basically it. That's weird. So what I'm hoping now is that you have questions because, you know, I went through pretty fast and there's a lot more stuff underneath. And yeah, and the Microsoft booth has IE stickers. So you can, yeah, whatever. So if you have any use case or something that you say, wait, I don't know how I can solve that in Drupal 8, feel free to ask. Yeah. Yeah, so are there any plans to get the library, to keep the library up to date in Drupal Core? So there's a plan to do that because what I said, we were going to update the library throughout the 8 release. So if jQuery 2.1 gets out, we're going to ship that. So there's an agreement on the strategy around that, but there's no code to back it up. So the strategy goes like when you declare your dependency, you'll say you depend on a certain version or like this version or above of the library. And then it gets a bit tricky because if you have several scripts that require different versions of the same library, the idea is that you won't load the older ones. You just, you know, we'll forget about them. But since the library we have in Core are jQuery, backbone, underscore, they don't really break their API very much now. So I'm hoping it's not going to be too painful. And well, since the beginning, I was planning on going through the bigger country modules and pretty much fixing the JavaScript if an update breaks it. Well, at least the big ones. So I guess that's the idea, but as I said, no code to back it up. If you have a better idea, feel free to go in the issue queue and submit them because, you know, it's still open. There's no code. Yeah? Are Drupal behaviors still the same? Yeah, so Drupal behaviors are still the same. The Ajax framework, unfortunately, is still the same. If I didn't put it on the slide, it didn't change, basically. I guess the only change about behavior is that if your behavior crashes, it won't crash the rest of the behaviors. So it's a bit more safe now to run weird behaviors. So now just a little bit of your page is broken, not the whole thing. Yeah? Yeah, so was it module or theme? So for a theme, it's still possible to have script in the info file, but we're going to change that because if you do that, there's no dependency implied. Because if you put a script in the hook library and you don't say to require jQuery, jQuery will not be loaded. So if your script is alone on the page, it will crash. You can use the hook library info inside your template.php. That's why I'm hoping we get to the YAML file because Simer will have an easier time writing YAML than PHP arrays. But, you know, that's still a patch in process. So, yeah, even for theme, hook library. And then use attached. There's a couple of examples inside core that do that, for example, Bartik. You can look into it. There's a hook to alter the page render array and add the attached for your library. I don't remember exactly the name so I won't try to give it, but look in Bartik template.php you will find how to do it. So, yes, the code was chosen for the Drupal core framework. Yeah. Second one, what I need to do if I want to handle a JS on my Drupal page? I want to load this in US for some application. Yeah, so the first question about why backbone? Ah, so it comes from the inline editing stuff. Inline editing, at the beginning, we were using create.js, we returned to do, to provide this kind of inline editing functionality in an interoperable way. So typo3 is using it, we were using it, other CMS uses it, and that was using backbone. So we have backbone in core, and it was at the same time the toolbar got refactored, and toolbar used that as well. And then we took create.js out of Drupal core because it wasn't fitting our new use cases, but we kept the backbone toolbar. And then the new editing place code was written on top of backbone, because it was just, I mean, that's a pretty complicated script, so it's easier if it's well architectural, and backbone was helping for that. So that's the only reason why we have backbone. We could have gone with something else, but backbone is stable enough. It's well known, so why not? And I mean, doing a comparison with all the other libraries out there, it's a lot of work. I mean, even for CK Editor, that took months to decide on CK Editor, so I don't want to think about how long it would have taken for that. Second question about AngularJS, well you can just declare it in a hooklibrary info file, no, hooklibrary info function, and use that on your page, or declare that as a dependency of the script, and that's it. But then you would need to do the integration with the HX API and these kind of things. We, there's no pre-made way to help with that yet. Wow, I was super clear, or you're super bored. So why underscore and not lodash? Because we don't want problems. No, because it's just easier, and actually, because you declare libraries and their dependencies, at some point we will be able to say, I'm going to use lodash and replace all of underscore with my custom lodash build. So you still have the hooklibrary alter, hooklibrary js alter, something, to change the dependencies in the different modules and scripts, so you can replace underscore with lodash. But then you know, underscore one big file, lodash, you need the build system, and we're not very good at build in, well at least on the front end with Drupal yet, I mean we still don't have a way to minify everything at once, and that's a problem. I'm scared to be a little bit. Are there any resources you'd recommend if you're in the doc or anywhere else for someone who wants to know how to write? Well, first step is use js-int, because that will cover a lot of things. There are many, many things that will be fixed just by following what js-int tells you. And then if you want to go beyond that, it's more about the structure of your program. And since, you know, we're using backbone, but then we have several slightly different ways of using it in different places of courgette. I mean, we don't have like a perfect solution to give out. So at least fixing js-int stuff will take a bit of time already. And if you have problems with the structure, I guess reading up on frameworks will help. But yeah, that can be a lot of work. All right, see, if you don't have any more questions, I guess we can wrap up and have a drink. Thank you. Well, if you can use the time to go in a sprint and sprint on JavaScript stuff, that would be helpful as well, but you know.