 There we go. All right, so welcome, everybody. Thanks, Heaps, for joining. So yeah, my name is Jack Taranto. I'm the front end lead at Previous Next. And yeah, I'm coming to you live from my trendy loft office. And yeah, this talk is about modern JavaScript development. So yeah, this is going to be not a talk about doing decoupled front end sites or Drupal as an API. This talk's just going to be about doing JavaScript within a Drupal site, so in your theme, in your front end inside your Drupal site. And there's not going to be much JavaScript code. It's mostly just going to be a focus on your build tools. So I'll get started with just a look at the current JavaScript technologies in Drupal. So yeah, jQuery. I think most of us cut our teeth on jQuery. In the early noughties, I think it was kind of a necessity. It's been around since Drupal 5. Yeah, during that time, I guess browsers were pretty much all over the place. They all had different sets of functionality. And jQuery was really just there to kind of equalize all of that. Yeah, so it started in Drupal 5, but it's been around. They're like, it's still there now in Drupal 9. And jQuery UI basically powers most of the interactivity in the admin theme. So yeah, besides jQuery, we've got Drupal.behaviors. So it's kind of the closest thing to a JavaScript framework that we've got. And it's called the JavaScript API in Drupal. And it's kind of telling that we're in a PHP ecosystem when you see that it's filed under the MISC directory. So yeah, so this is my six-step plan, basically, to modernize all this kind of stuff. And yeah, step one is just to stop using jQuery. It's 100 kilobytes of stuff we can kind of do really well with vanilla JavaScript. So yeah, you don't need to use it. And I think probably most of us have, like said goodbye to it a long time ago. So that's why this is just step one. Yeah, step two, maybe slightly more complicated proposition. Yeah, should you stop using Drupal's JavaScript, only JavaScript framework? Like for me, it's an emphatic yes, definitely. Basically every recent project I've worked on, I haven't really seen much of a strong use case for it. So just dropped it entirely, really. And I guess why? Well, yeah, take a look at this code boilerplate here. And this is kind of like what you need to do before you can actually write anything. So you find yourself like copy and pasting this constantly when you're writing these things. Yeah, I mean, it doesn't make a lot of sense, I think, for JavaScript developers not familiar with Drupal's. So like to go through it, you can see jQuery is baked in at the top. There's this context argument, which is being passed through to the function there. I think most people just go like, what is that? And it's pretty confusing because it changes depending on when this is being called. Sometimes it's the whole document. Sometimes it's an individual HTML element. But the kind of key is that like Drupal is running these behaviors over and over and over again throughout the page cycle. So it runs it when the page is loaded. It runs it when the page is updated. And your code keeps getting called over and over again. You've got to use a plug-in called jQuery once, which is kind of a bit of a blocker to getting jQuery out of core in Drupal 9. So yeah, you're using this jQuery plug-in to stop your code getting run again and again and again. So for me, it's kind of a bit of a no. You can't lose control of when your JavaScript is getting called. And you're just handing it over to Drupal to do everything. So yeah, that's basically one of that's the main reason I don't like to use it. But there is kind of a use case for it around like Ajax calls if you're using Drupal Ajax calls. So that's kind of where it comes in handy. But I'd probably say you shouldn't be using that stuff either. Maybe doing things differently in general. So yeah, I'm seeing less and less of a reason to use this in a modern site. So yeah, step three, we're definitely on to the path of the light now. So yeah, just write your own JavaScript. Use vanilla JavaScript. Use React. Use View. Just use whatever you want. And you can kind of use all of the above if you have use cases for it on different pages inside different mini applications that you might have throughout your site. So I guess the point is that Drupal shouldn't be defining your JavaScript technology inside your fun end. Like the functionality itself should be defining that. And of course, your team's skill base. So yeah, Drupal comes with heaps of JavaScript dependencies just like the JavaScript API. They're stored inside the MISC directory. They're loaded inside cause libraries.yaml file. Don't use these either. So they're basically there. I see them being there for kind of Drupal's admin site, basically. And I don't think these dependencies should ever cross over into your front end. It's tempting to use them because they're there. They have libraries provided for them. But you shouldn't really be using these kind of libraries which are attached to a core version number. You've got to upgrade core for any of these kind of dependencies to change. So yeah, it's much easier just to use NPM, install your own JS dependencies. You can really simplify your package.json file. So it's just including these keys. You really just need a dependencies key. And the private equals true. And this is really your package.json's really just a list of your dependencies. It shouldn't be anything more unless you're kind of publishing it to an NPM repository. So yeah, definitely use ES6 in general. But yeah, using ES6 imports is kind of where it's at. So nowadays, ES6 imports are natively supported in most browsers. So you can just write code that looks like this. And browsers are going to interpret that. And they're just going to use that. They're going to look for those dependencies in those files. And this is all kind of running natively in the browser, which is a huge, huge step forward for ages. Imports syntax has basically just been an abstraction. We've had our build tools pull in the dependencies and just combine it all into one big bundle. But yeah, you don't need to do that anymore. These things are running natively in the browser. And yeah, I mean, this kind of looks like a PHP use statement. We're sort of at that level in JavaScript now. So yeah, you just need to change a couple of things in your build steps to stop producing these kind of big mega bundles. So you need to enable code splitting in rollup or Webpack also does code splitting too. So yeah, we're using rollup for our JavaScript builds. I have used Webpack as well. So kind of settled on rollup as a tool, mostly just because I just find it way cleaner to configure. It's also kind of, it's just as configurable as Webpack, but it just has a cleaner interface on Inc. And it produces cleaner output in terminal and in CI as well. So it's a little bit prettier. And it's definitely, I think it's definitely got better documentation as well. So yeah, this is a little example from a rollup.config.js file for code splitting builds. So we've gone with an entry.js naming convention. So we're using the globby module there. So it takes these three globs and it's looking for entry points inside either a profile or a module or a theme. So you can write your JavaScript in any of those three places. And yeah, the globby module takes those globs and it just outputs a full list of paths to all your entry points. So if you think that the entry points, kind of like your main JavaScript file and that's the file that you're gonna load into Drupal. So yeah, you pass that array through as an input and then that output directory at the bottom there that's gonna spit out all these entry points into your Drupal libraries directory. So that way, all of your JavaScript gets exported into one place, which is kind of nice. You don't need to export it out into each theme or into each module. You can just put it all in the libraries directory and yeah, you don't include that when you're committing and yeah, that all kind of gets built on CI. So yeah, behind the scenes rollup is running its code splitting build and it's gonna output a chunks directory as well into that same place and the chunks are where all the common exports get outputted to and it's gonna optimize that. It's gonna put them all in common files as it needs to and does all that without any user input. So yeah, we're not gonna say goodbye to all of Drupal's dependency management just yet. Drupal's library system is really good and it does a great job of getting JavaScript and CSS under the page, so use it. You probably won't use its built-in dependency management. You're doing all that in the JavaScript file itself so you won't need to kind of include other libraries. You'll just be using it to define libraries really. So yeah, a module, you can define module, script tags like this. So yeah, I'm just referencing the file that has been built by rollup inside the libraries directory and yeah, you just need to add that attributes type module config at the end and that's gonna output a module script tag. So yeah, code splitting has got two major benefits that I see. I think the obvious one is just import syntax being great. It's quick, it's easy. Yeah, you can pull down a whole dependency via NPM and start using that with literally one line of code. So it's just, yeah, it's really transforming things, I think. And yeah, the other one is just being JavaScript file sizes being optimised out of the box. So yeah, you don't have to worry about including dependencies or duplicating dependencies throughout your code base. You don't have to worry about committing certain dependencies or where they live, you know. Yeah, so yeah, as far as reasons for ditching jQuery and dribble.behaviors, well, besides jQuery's file size, well, jQuery's file size being 100 kilobytes, that whole file size is basically there to make it easier for us to write code. So it's sort of like, yeah, it's a step, you know. I think as JavaScript developers, we need to learn vanilla JavaScript and understand those quirks basically and without having jQuery there to do that for us. It shouldn't be, we should be doing that ourselves rather than pushing that on people's browsers in the form of 100 kilobyte library. So yeah, drippled.behaviors, I think besides the reasons I mentioned earlier, it's not, you know, it's kind of confusing and it's not really like any modern JavaScript framework. It's the pure total dribble-ism and yeah, I think now we don't need dribble-isms. We don't need any more dribble-isms in our front-end basically. I think we've got the theming system and that's basically enough. We can deal with that and we can write JavaScript down anyway. So yeah, Internet Explorer 11 is obviously a daily worry for many of us, I think. So yeah, it's basically evergreen. There was an announcement last year, in August this year about Microsoft dropping support for it in 2021 but yeah, it kind of caught the headlines but they're actually just dropping support for it in their own 360 services. They're actually gonna continue security updates. They're gonna continue patching it forever, I think. So we basically, it kind of remains to be saying how long we're gonna be dealing with this in Explorer but of course it doesn't support ES6 modules at all. So we've got a workaround for that. That's what this looks like. So this is our roll-up config and yeah, we're actually passing, we're exporting a config array here. So we can have a separate build step for our no-module builds. So the no-module builds are the I-11 builds and also any of the other browsers which don't support modules which is some of the older, you know, browsers that might be kicking around. So yeah, basically here we're just looping over the entry points and we're adding a separate build step for each, you know, for each no-module file because we're not passing an array through as an input, it's gonna output a separate file for each thing. So you can just update your library's definition with that no-module definition at the top there. So it'll add a regular script tag with no-module equals true which most browsers will just skip over whereas the module script tag, yeah, that's gonna get ignored by I-11, which is great. So to do this, the easiest way is using Babel's environment presets. So this allows you to have two separate kind of Babel settings for your module builds and your no-module builds. To do, to use environment presets you just need to pass through this end, name config into your plugin config inside your rollup.config. So that's what that looks like, just a little excerpt of that. And then yeah, here, so yeah, this is the actual Babel.config.js file. You can see we've got M presets there for module and no-module. And yeah, we're just using the standard preset M module and yeah, we're passing through targets there. The ES6 modules equals true is something that that preset M supports. So that's gonna automatically target any browser that supports modules. And then I'm specifically targeting I-11 for the no-module build there. I-11's a suitably low baseline for any of the other kind of transpiling that needs to go on for ES6 codes. So yeah, that tends to work pretty well. You can also use CoreJS as well. So that's just gonna automatically polyfill everything for you basically. I think I'm almost out of time, but yeah, that's kind of all I had. So I'll see if I can jump to some questions before it cuts me off. Got 34 seconds, it's keeping down. Yeah, that question from Max, I think that's answered. I think, yeah, is there anything else? Cool, all right, well thanks heaps guys. Thanks for hanging in there.