 Good evening, everyone. I think the last session, so thanks for showing up, I guess. Today, we're going to talk about vanilla JavaScript and what does it mean, what can we do with it, do we have to use libraries, and these kind of things. So my name is Theodor Biodala. I'm a JavaScript maintainer for Drupal Core for a couple of years now. And we've improved Drupal JavaScript a lot in those two years, and so much that we do have some vanilla JavaScript in Core, and I'll show some of it during the session. So first, a bit of context. The first part, we're going to talk about vanilla JavaScript and what does it mean. And second part, we're going to look at some example of things you can use today, while depending on some variables in your project. So Drupal 8 vanilla JavaScript, we have three scripts that actually do something and that are useful and that do not rely on jQuery. The first one is Active Link. This script is used to highlight links that link to the current page, basically. So lots of selector and adding a class to links. So it's fairly easy, but no need for jQuery for that. We have Anons.js, which is an API to allow screen reader to read something that you want them to read. Same thing, no use for jQuery for that. And Drupal.js, which is just helper methods for translation, seeming, and a few other things as well that really don't need jQuery to work. Yay, the image is broken. All right, that sucks. So this was a slide of a big pot of sugar and some vanilla in it, which is basically the way we do scripts in Drupal other than the three that we saw. We just have a big piece of JavaScript syntax in sugar and some vanilla JavaScript with it. And it's not really great because we get addicted to sugar and we use it just everywhere. And we don't even think about can we avoid it or not. And I mean, it's much bigger than just a Drupal problem. It's a problem with the web because browser actually got much, much better in the last few years. And we have to use the improvement that they made so that they care. Because if we don't use them, they will stop implementing new functionality that we need in our job. So it's use it or lose it. And it's not that hard to use it. So we should make an effort for that. And also because Drupal 8, I mean, it's pretty big. So we have an opportunity to improve the web as a whole by pushing for standards and pushing for emerging standards. The best example is the responsive image. I mean, Drupal is the first CMS to have a solution in core, well, in its core. While in the Drupal 8, it's not out yet. At least we're doing something in core. And this just help developers use that properly and have browser notice that there's a big usage of this feature so that they should care about it. Yeah, no image, anyway. But sometimes vanilla.js is not enough or it's too hard to use. So what kind of criteria can we use to decide if we need to use vanilla.js or if we need to use a library, jQuery or something else? I think the first one is browser support. Basically, if you need to support I8, you're very restricted into what you can use. There are still some of it that you can use. You have polyfills, for example, that you can put on your page to use the same script and make it work on I8. But it's not great. Then you have code cleanliness. Sorry, second language. I mean, your code needs to be clear enough so you know the dependencies you have inside of your code. And if you use a library, you need to use it consistently so you're able to identify and maybe, you know, search and replace whatever you use. So I mean, you can't just go with it. You need to think a bit about it. So I don't think, for example, vanilla.js is good for a team that, for a backend team that needs to write some JavaScript, probably not the best way to go about writing your script. But they are front-end professionals, so they're not the only use case. That goes into team knowledge. If your team knows about JavaScript, it's much easier to go with vanilla JavaScript than just use jQuery. And I guess the last one is, you know, which are your priorities, performance, maintainability, or development time. So I would argue that vanilla JavaScript doesn't increase development time once you know it. It's just a bit of learning to do, but then it's just as fast as using jQuery. The resulting code might be a bit longer, but you're not paid by the keystroke, so who cares? And for browser support, we mentioned polyfills. In Drupal, we have a couple of them. We have class list. So this one is to manipulate classes on elements. There's an example afterwards, so we can go back to it. We have match media to do breakpoints in the JavaScript. So this is used by the responsive image and those kind of things. And picture field to do the image source swapping in responsive image on the picture elements, so this kind of stuff. But vanilla.js, sometimes it's very short and they are saying that a huge pain to deal with in vanilla.js. The main one for me, it's event handling. It's a nightmare to do with just JavaScript. For example, if you want to react to the focus event on the form input, you need to bind to the form input. You can't delegate that easily in vanilla JavaScript. Whereas jQuery allows you to delegate that very easily because they take care of all the crap, basically. So sometimes it's just much more handy and much more robust to use jQuery than to use vanilla JavaScript. Ajax and Ning as well, that's kind of a pain. Dealing with error, network problems, these kind of things, just jQuery helps you out on that. So there should be an image there, but too bad. The micro libraries, those are very focused libraries that give you a little bit of sugar at the smallest size possible for one feature. We use one in Drupal 8, that's DOM ready. And this one is used to initialize Drupal behavior. So when you load the page, the DOM content loaded events, you know, this is DOM ready, taking care of that. So we don't, oops, sorry. So we don't have to deal with differences between IE and Firefox and Chrome and all of that. It's like a one case script, no small, does a job well, and we don't need jQuery to do that. There are a lot of micro libraries available for events, for Ajax, and for templating, for building your own JavaScript framework, like Ember.js, Backbone. I mean, there's all kind of libraries out there. There's a big list in microjs.com if you want to have a look. So during Drupal 8 development, I looked into micro libraries to get rid of jQuery, which was kind of my crusade still is, but it's going to take time. And more specifically, using the bin library for events. But what I found was that the library was way behind jQuery event handling. There was bugs, feature were lacking, custom events were not working properly. I mean, there was, there were lots of problems. So micro libraries are great, but you can have duplication because if there's a pattern in two different libraries, they're going to implement their own version of it, and then you have a duplicate in your code, basically. The bugs are spread out, different GitHub projects, or even outside of GitHub. So you can't track the bugs in your library easily. So it's a lot of grand work to do, basically. And just like Drupal Contrib, the quality is very inconsistent. So it's not great, but there's a hybrid approach that we can use, and ideally what we would like is a size of micro library with the quality of jQuery. I mean, that would be great. So who knows about jQuery custom build? Okay, bit less than half of you. So it means that if you download the GitHub repository of jQuery, you can build your custom version of jQuery only with the parts that you need, basically. So if you don't need the selector engine, which is pretty big, you can remove it and get a smaller jQuery in your code. So I did some measurements. This is, as of Monday, if we build all of jQuery, so that's a 2.1.2 version that's going to get out at some point, it's 29.1 kilobyte minified and jazzy. I mean, the one we have in code right now, it's 32, so those are improved things over time. So who can guess a sizzle? Like who says it's more than 10 kilobyte, right? So less, well, it's actually a bit less. What about the core? Who says it's more than two kilobyte, the core of jQuery? Well, some of you, the event, so how big is the event? Like five kilobyte, 10 kilobyte? So basically, sizzle is a big part of the total size of jQuery, so it's 8.6 kilobyte. The core itself is two kilobyte, and that's kind of a lot for the doing much. And keep in mind, it's minified and jazzy, so as of row JavaScript, it's pretty big. But the event is 6.9, and that's something I personally can live with, given the pain that events are to deal with. So, trade-offs. And what's good is that all of these pass the jQuery test suite. So all the browser bugs and everything is taken care for in six kilobyte. And for example, the bin library, it's 4.5 kilobyte, but it's very buggy, so trade-offs. So I was saying, events and Ajax were pain to deal with, so if we combine the two of them, you have 6.97, you expect around 14, but it's actually 10. So with 10 kilobyte, you can take care of events and Ajax handling with jQuery, which is pretty good. I mean, with that, I'm happy to use jQuery. The problem is, it's static-based, the problem is it's static-built. You need to have Node, Node.js, Grunt, and everything to build your jQuery version, so you can't do that on the fly. You can't say, you know, I depend just on the event part of jQuery for my script, and have Drupal build that by itself. But it's possible to do. So, Franken-jQuery, that's, well, that should be a picture of Frankenstein. Sorry. So that's the name that JavaScript jQuery core developer gave to Node, this idea of building your own version of jQuery dynamically. This is the issue number and comment number if you want to look it up. And basically, it means that it's possible to separate all of jQuery into the, you know, discrete parts, event hijacks, compile that into files, and have the Drupal dependency system load them dynamically to build your own jQuery version, which means that if your script only use events, for jQuery, you depend on that, and only six kilobytes will be loaded for jQuery on your page. I mean, it needs to have a prototype to get some work done to actually work, but it's definitely possible. Yeah, so this one is the example slide. Yeah, just announcing it. Oh, this one works, good. So if you want to use vanilla JavaScript, there are a lot of methods added to different objects in the JavaScript language that you can use. So this table is going to show IU9 from 11, I think, and Firefox, Chrome, and some other JavaScript interpreter. So there's a lot of green in there, which means you can rely on all of this to work. So not everything works properly, but, you know, as a basic, in the basic use case, it does work. So let's look at arrays, for example. So you're used to, maybe, sometimes you use jQuery to loop of an array, like jQuery.each. I mean, don't do that, please. Use at least a for loop, or while, or whatever, but not jQuery.each. The JavaScript array has a for-rich method now that you can use, and the function that you pass to this for-rich is going to be executed for each element of your array. So if what you like into jQuery.each is a new function and a new scope you get for each iteration, you can have that with vanilla JavaScript as well. Then you have the map method to build a new array based on the arrays that you have. You can filter, there are a few more methods as well, like reduce some, every bunch of things. If you like to do functional programming, that's the kind of stuff that you want to have available. Arrays, usually you use that with DOM elements. You select a bunch of DOM elements. You want to loop over those elements to add a class, change a style, do something like this. So it's not as pretty as jQuery, but it works the same. And you don't need to load 29 kilobytes of jQuery, basically. And you can use the same thing for map, some, every, reduce, all of this, you can use them on DOM collections, objects. I see a lot of time people using jQuery.each to loop over objects as well, because you know it's easy to do, they know how that works. But the problem with that is that you don't filter the properties, so you actually go up the, dependent, the prototype chain, and you get every property that your object inherits, which is a bad way to loop over an object. There was a number of bugs in Drupal Core that were caused by unfiltered looping over an object. Now you can use the object.key function that will return an array of index, of your object indexed. And since it's an array, you can use for each afterwards to loop over that. So you don't need to have a filtered for loop to go over your object. And it's really handy. It makes also the code a bit clear because you can't separate the for each function. That way, you know, you separate what it does and where it does it. I mean, it's just cleaner. So anyone already uses those kind of stuff? Yeah? Not many of you? So I mean, so there's a few more examples, but what is stopping you from using those kind of stuff? Is it because you know jQuery or because you, IE, but this, which version of IE? Because you have polyfill to add like the object.key function that's easy to add. Same for the array prototype stuff. So is it because you don't want to load the polyfills? Or, right. Well, I mean, we'll get back to it. We still have, you know, a lot of minutes to talk about that. Function. Who use jQuery proxy method, usually in events? So this, you can use the bind function to say which, to which object this refers to. So inside the do something function, when you write this, it will refer to this object. So it's just like the jQuery proxy use in the basic case because the jQuery proxy does a bit more stuff that I, you know, shouldn't do, but hey. I didn't write it, so I can't complain. Selection. So I said Cesar was eight kilobyte. And usually you can, you know, avoid that because as we're working Drupal, we can control the markup to some extent. So we can make sure the selector as simple enough for you to use in query selector and query selector all. Who knows about this function? Who use that instead of jQuery? Okay, not many. And you know, you can use like query selector all and pass the result to jQuery to do stuff. You know? It's possible. So the first one is going to select all the elements that match the CSS selector. So everything that has an active class will be selected. And in the second case, it's going to select the first element matching your CSS selector. So here there's an ID, but if you have a class, it's going to be the first element with this class on the page. So if you have several things to select, query selector all, if you have one query selector, because usually what you see in jQuery stuff is selecting every element of a class and then first. So just to get the first one, you don't need to do that. So I was talking about class manipulation. I mean, a lot of those things got improved in the browser because jQuery came up with it and that was used by a lot of developers. So they said, you know, because a lot of people use that, they just put that into native JS so everyone can use it without jQuery. So it's the same as, you know, remove class, add class in jQuery, but native. So remove add, pretty straightforward. Toggle, you can say if that class is in the element, the element, remove it. If it's not added, and in the, you know, some version of browser, there's a second parameter to say, like a Boolean parameter, to say if you want to add it or remove it. But yeah, since that's not supported everywhere, they just not talk about that. And contains just, you know, does my element have this class or not? And then the DOM, who still use inner HTML sometime? Okay, so you use, I guess, jQuery happened insert before, insert after. So there's a native way of doing all of that. And it's actually since IE4, that it's in browser, and since Firefox eight, and Firefox was the last one to add this method. So basically the HTML is just a string of, you know, whatever HTML you have that you want to add on your page. And the position is going to be, where do you want to add that? So here you have before begin, after begin, before end, after end. So the position is one of those four choice. And you know, it adds your HTML whatever you say you want to add it. And it's actually much faster than inner HTML in most cases, because there's less work for the browser to do. And it doesn't mess up, like if you have event listeners and some kind of stuff in your element inner HTML trash that, this doesn't. So, you know, you can use that instead of jQuery for a lot of, you know, adding HTML to the page. I have no idea what this image was, but it was pretty good. So all that is to say that when we talk about mobile first, it really is vanilla first, in case of, you know, JavaScript, CSS, maybe there's another meaning and everything, but for JavaScript, it's really try to get rid of any library you use to be as fast as possible on mobile. I don't know who went to the session about delivering content under one second to mobile. Yeah, a few of you. So, I mean, if you add JavaScript to the page, it just adds 300 milliseconds, so that's a lot. And also I would like people to help make the front end jQuery stuff happen so that we can separate out jQuery and build whatever we need, depending on your script dependencies. Because right now in Drupal 8, you need to declare all the dependencies for your script. So, the more specific we are, the better it is. So, who knows about the dependency stuff in Drupal 8, actually? All right, so quickly for those who don't know, if you write a script in Drupal 8, it's probably going to use jQuery, so you need to declare jQuery as a dependency of your script. Same if you use anything from Drupal.js, you need to declare a dependency. Because if it's not declared, Drupal will not load it. So, in Drupal 7, we just assume you wanted jQuery, so it's loaded on every page, even if you don't use it. And that's a big, you know, performance issue, actually. Yes, there's an issue about Drupal 7 and jQuery. There's a patch also that needs review, and that works. So, there's a spring tomorrow. You can, you know, help out. I don't know. So, that's about it, about what I have to present. I got a few questions for you. So, is there anyone who has code that kind of wonder how it can be made to use vanilla JavaScript? Also, if you do use vanilla JavaScript, how do you draw the line between using a library or using just JavaScript? What's the threshold? And also, a big one is what can jQuery do, Drupal do, to help you as developers, you know, rely less on libraries and more on proper JavaScript. So, if you, yeah, can go to the mic. I think I'd just like to say that the whole, this whole concept of the vanilla JavaScript is something that's really true to my heart because it's over the past few years I've been, I set myself a bit of a challenge two years ago and I said, I'm gonna put myself on a jQuery ban. So, I banned myself from using jQuery and I did everything with another JavaScript. And it wasn't actually, it was a challenge at first, but then after a while it actually made not only my JavaScript better, but there's so many things you can do and it's such a beautiful programming language, especially like Node.js stuff and all sorts of things. So, and I've had so many struggles with Drupal's jQuery stuff with like you have to install the jQuery update module, you have to do all sorts of things like that. So, I think it's not really on one of your questions, but it's the main thing I have to ask is how do I get involved? Like say tomorrow or are there specific sprints to do JS stuff in Drupal and things? So, I wasn't planning a sprint, but if people are interested, we can do that tomorrow, yeah. And also, so what was the main problem you had when you banned yourself from jQuery? Like the main thing that was nice about it? I think at first it was like the selectors and that sort of stuff got, yeah, that worked. At first there was things like that relied on like the animations and that sort of thing that I was using and then I realized that actually that was a really good Eureka moment and I realized if you do it in CSS of transitions and CSS transitions, you just change the class and if you change the class from one class to another, I now don't do any animations in jQuery or JavaScript at all, I just change the class and CSS transitions are so beautiful now, you can actually do background colors, you can do everything and it's just so much cleaner and just faster. So, I think the events in the Ajax stuff is still something I do use jQuery stuff for, but you can parse JSON in most things now. You can do some stuff. I think a really good resource is like the Mozilla website where they have the polyfills and something like that for each question that got asked over there, which was just not being able to support IE8 and that sort of thing, it's just like seven lines of JavaScript that you put in from the Mozilla website in a separate file that's called IE.js or something and that shouldn't put people off from doing this sort of stuff because there's so many beautiful things and they're really well documented and I think people should be using them more. So, sorry. Thanks. So what's preventing you from using vanilla JavaScript in your projects? Yeah, so jQuery plugins. Yeah, also one thing I didn't really mention in my talk is that when you review your code to see if you can use vanilla JavaScript or not, sometimes there's code that just is not needed. I mean, there's a lot of craft in the code that can be removed or rewritten in a better way and I guess sometimes plugins also, you use a plugin but maybe there's no need for it. Well, I don't know. It depends on the use case, but it's just general laziness. If nobody talks, I'm going with that and you're all lazy. jQuery, you write jQuery faster, right? But it's kind of a habit, right? Because sometimes if you know how to use vanilla JavaScript, you can get similar speeds. Well, I guess it depends on what you do, but yeah. I think that then hides and then shows it's really, really simple stuff that you can do in five lines of JavaScript and some CSS. Just make your own, just make your own slide that don't use all these jQuery plugins that do things that have to happen to pieces. Just you can do lots and lots of stuff just by yourself and the plugins are very often unnecessary. Yeah, and sometimes of bad quality as well, but yeah. So I guess it comes down to a skill level. I mean, you're lazy and unskilled so far, so you better speak up. So what you mean, you mean I didn't actually hear what? Yeah? All right, poly fields. But the thing is with poly fields, usually it's I8, that's a problem, and I8 still understand conditional comments. So for example, the class list poly fields that we have in Drupal Core, it's within conditional comments for I9 and under. So the proper browser don't get the extra script. But yeah, sometimes it's not only I, that's a problem, so it depends, but usually it is. And I mean, if you don't use jQuery, there's a lot of JavaScript you don't load, so even if some browser have to load a poly field, it's not that bad. Right, so problem is time or backend people. And the stability of accessing scripts, I guess, and feature sets, which is a fair point for some use case. Well, I also mean there's a big difference between having a website and an application, sort of. So if you do a JavaScript application or one page, whatever, like the very fancy stuff, headless Drupal and all, vanilla JavaScript is probably going to be a huge pain to deal with. But most websites are not like that. It's just an accordion or a menu, drop-down menu of some kind. And for that, you don't really need jQuery. You can use some JavaScript to do that. So who has a fairly simple website with not a lot of interaction to take care of? Nobody. So you're all doing like application and web, whatever, number, one, zero. That's surprising. So what kind of industry are you working in? There's no NGO, no education people in here. Yeah, and it's very complex, or yeah, so yeah, some side. So is that a team issue or is that convenience? Right. So just convenience. So what if we had like the Franken-JQuery stuff where you have to decide which part of jQuery you depend on? Like would you use something like that? Or would you just use jQuery and be done with it? Well, actually, the jQuery is getting smaller because it was 32, a few months ago, now it's 29. So it, right. So I guess you're saying performance is not high on your priorities. Because I mean, yeah, yes. So it depends on the site. So who here tried to browse without JavaScript enabled on website? Yeah, so you've seen the difference. It's like way, way faster. And part of the reason is because of all the scripts and jQuery is pretty big. So I mean, question? Yeah, so for like, d8 contribs space, I think there's been a kind of long standing expectation or maybe not d8 necessarily specifically, but Drupal and jQuery have really grown hand at hand. The jQuery update modules this, probably one of the most popular modules on d.o. So now that kind of developers expect that I'm doing the download drupal, I'm gonna get some kind of antiquated version of jQuery and then we can install jQuery update. Aren't we just saying to them, we're taking jQuery out of core potentially and now the first module you have to go install is this one that just jams jQuery back in because all your clients want to use it and all your contrived modules are gonna need it too. Have you thought anything about that? So that was a fair question when, so when two years ago when I started the issue, remove jQuery from core, which got renamed to reduce dependency on jQuery. Yeah, I got enough publicity on that. It was a concern that we would remove jQuery from core, but it's not actually what the plan was. It's more like jQuery UI situation where it's in core but nothing uses it. Oh well, not a lot. So they're still going to be the full jQuery in core but the way we use it, I think we could improve it basically and make sure that people who know what they're doing are well know what they're doing and can do it. Thank you. Anything else? I think removing jQuery from core wouldn't necessarily be a bad thing. Maybe not feasible but wouldn't be bad because country would have to stop and think and do I need jQuery? Can I solve this with vanilla JavaScript? Which would in my opinion be a good thing. Well in the mind too, but well talking as a maintainer, it's really hard because then you get lots of complaints. Yeah, yeah. That are fair, you know. Yeah, yeah. It was just a comment on the fact that people would, if it was removed from core would just go and download jQuery update or something similar which I don't think would necessarily be the case. If it's not in core, people would try, well I think if you write a module, you try to have a small amount of dependencies. So adding a dependency to a module that adds jQuery just adds on that. So to some extent I agree but then you have the problem of fragmentation that now we are standardized on jQuery. So there are lots of things we don't have to deal with just because everyone uses jQuery. So if we put a new, well if we allow people very easily to use a new library, it might be more pain than it's worth. And now with the headless stuff, people are going to use whatever. So, I mean, I agree but yeah, reality is a bit harder, yeah. And also as a side note about the versions. So Drupal 8 is going to update to the latest version of jQuery all the time. So there's not going to be a four years old jQuery version in Drupal core. Like right now we run with 2.1. So no IEA support and those kind of stuff. And whenever there's a new release for point release of Drupal. So 8.1 would get the latest jQuery version available at this time. Because right now there's much less breaking between jQuery release. So we can do that fairly easily. Who uses jQuery update, yeah? Almost everyone. I guess if there's no, oh yeah. It was a big problem where it broke views jQuery update to the latest version of UGUI completely. I'd be worried if that happened again. Yeah, so views UI breaking, well it won't happen again because views isn't in core. So we have to fix it. Yes, it kind of sucks but yes. Yeah, so is it still using that now? Support. I think we removed that. Yeah, because when you go with jQuery 2 you have the migrate jQuery plugin stuff. And we on purpose didn't use it when we ported everything to point something. So it shouldn't use it now. Yeah, so it won't happen. If it does we should write a patch. If we already started with versioning and deprecated properties, are there any plans on relying on external libraries for module developers like the libraries module but I think it doesn't, are there any plans to make it work with this whole attached array? Well I mean it does work. So the problem is the libraries module is kind of complicated. On purpose it was not put into core because it's very complicated for a very specific use case that doesn't happen usually. But the attached stuff, the new library declaration. So everything that works is going to work with libraries. So there's no new API that's going to be used. It just, you know. Because I tried to write the module which depends on an external library which shouldn't be inside the module but downloaded it into the library's directory. And it was hard to figure out how to make this library a triple internal library without running through library info alter and tree writing stuff. So yeah I don't think you can get away with not using library info alter and those kind of things. I don't know what are the plans for the library module. But I mean usually when people develop projects and they have external libraries it ends up in a sim somewhere. It's only for content modules that's a problem. And I don't know what the solution for from the library module. But we can see that tomorrow. For example. Who's going to stay tomorrow for the sprint? Everyone's going to work on JavaScript? Almost, yeah. One. Well I guess we're done. Thank you very much for coming.