 My name is Celine and I'm the delivery director at Just After Midnight was created five years ago by our founders, Chris Croucher, who is also another speaker here today and some booth based in the UK. I myself, I'm in Melbourne here in Australia. Along with myself, Chris and Sam, we're all part of a fast growing international digital agency called Reading Room as part of our previous careers and it was before it was sold to EY. On that journey at Reading Room, we were increasingly asked to build more and more critical business websites and apps for clients in corporate and government, many with Drupal at their heart and some not. One question that we found in different ways kept rising, which we and our clients find hard to answer. And the question, what are you going to do just after midnight when my website is down on fire or something is going wrong and being attacked? And invariably, we like many clients, teams and digital agencies without significant out of hours operations, struggle to answer the question. So that's where the idea of just after midnight was born. Today we are the go to support people for brands, government, clients, the agencies and software managed cloud teams. In building an amazing 24-7 team and support product offering across four continents. So we are APAC, Australia, Singapore, US and the UK. We've also built an incredibly strong managed cloud and DevOps teams specializing in AWS and Azure. And we are the 24-7. Some of our more interesting customers include Dyson and making sure that people around the world can still buy a very expensive hair stretchers and vacuum cleaners. Also another one recently is the Department of Home Affairs, making sure that the government comes, people can get their content around changes to visas, arrangement during the COVID pandemic and all that stuff. Volvo is another one supporting their digital assets throughout their round clock US Super Bowl campaign and many more. The Drupal community is one of the most engaged and open technology communities we know of. So we are really proud to support our friends in the Drupal community as all of you gather for Drupal South. And so it's a pleasure for me to now introduce you to Ricky. Ricky is a front-end developer at Prevots Next. She has a passion for accessibility and over 10 years experienced developing Drupal websites. She loves expanding her PHP knowledge and find her design background has been a great asset, translating a design into a workable interface. So on that note, I'll leave you with Ricky and all her experience. Ricky? Hi, everyone. So yeah, hello, Drupal South from my living room in Melbourne. I hope everyone is well in their various states of lockdown. This is a deep dive into the best tools and methods for optimising your Drupal things. Probably don't need to do an intro slide, I've just been introduced, but you can tweet me at Ricky or chat to me in the Drupal Slack. I guess, yeah, as mentioned, I've been in the industry for around 13 years now. And front-end development has certainly evolved a lot. And thankfully, the browsers have too. This talk is mostly relevant for this kind of setup. Components are isolated and organised. You're utilising core asset library system. Component assets are only loaded on pages which actually have those components. So for example, you have a library of global stuff loaded via the themes info file and separate libraries for component assets. Which are only loaded when the component is used on a page. For example, attached in a twig template or a render array. So no other page gets CSS or JavaScript that it doesn't need. But what about different browsers and their varying needs? Can we optimise this even further? IE 11 is the last of the ancient browsers. End of life is only 10 months time. But I think about how much of your HTML, CSS and JavaScript gets written just for it. Do you really want to keep writing code this way? Do you still need to support it? This is a serious question to ask your clients or stakeholders. Can that browser just get basic content without features or fancy layouts? And is it really worth the performance hit to the majority to have such updated code? If you truly do need to support it, then make a clear plan for when that changes. If it's a huge refactor job, maybe get a head start. You don't want that legacy code sitting around for another five years. Either way, you can probably stop writing code for IE 11 right now. Write one code instead. Code that the majority of browsers already understand. It's faster and more interesting to write. Or even better, write tomorrow's code today. Learn what's new and plan in CSS and JavaScript spec. Be ready for the next wave of improvements. Keep your skills at the cutting edge. Then use tooling to support the various browsers. Tooling isn't new. There's always several options for doing something which can be overwhelming. Do you spend too long just getting them all running? Are they helping or hindering? And when was the last time you reviewed them? SaaS is still a hugely popular tool. It was fantastic when it first came out. But it's a very big and complex tool that hasn't evolved much. It's also quite dangerous. If you're not really careful with your mixings and extends, you can end up with huge output. Two megabytes of CSS is never okay, even on a large website. But I've seen it happen too often with misuse of SaaS. Real CSS is the future. Yes, CSS is way older than SaaS, but it's native to browsers. It's not being replaced anytime soon, even if you write it inside JavaScript. CSS specification has evolved a lot. It now fills a lot of the gaps that made SaaS a necessity. Like custom properties, basically CSS variables, but better. And CSS grids, instead of all those grid row and column mixings from SaaSworld. You don't need any tooling to write and serve pure CSS. So no nasty surprises with output. This is what CSS custom properties look like. You can use all of this in modern browsers today. They can be responsive. So anywhere this property is used, automatically changes at this break point. You can override them for a selector. It's called scoping. Notice I don't need to rewrite the font size rule. Just update the custom property. And this is what a fully responsive CSS grid could look like. It's pretty small, huh? It's just one example. CSS grids are incredibly flexible. Again, native to modern browsers today. There's no margins, especially no negative margins, needed for it or its children. It repeats so a new row is made when needed. And it's content aware. The break point is a minimum of 20 character units. So a column will only shrink that far before folding. The columns are always equal width. If you do need a grid system, for IE, you can do a flexbox fallback and use at supports to replace it for modern browsers. This is the progressive enhancement approach. Keeping your fallbacks or legacy code separate helps when it comes time to pull it out. You don't need to refactor your modern code. So those last few examples can be used right now. But tools like Post-CSS allow us to use future CSS. Code that is likely to be implemented in browsers just hasn't been done widely enough yet. It also helps us support older browsers like IE11. As well as some workflow improvements like Auto Prefixer, Imports, and Minifying. It does a lot less than SAS, so it's faster and much easier to set up. These are examples of future CSS spec. You can use nesting, custom properties, custom media queries, custom selectives. And then just set up the Post-CSS plugin, preset ENV. In your Post-CSS config and tell it what you want to support or not support. It refers to your browser list config, so if you need IE11, list it there. And when IE11 dies, just remove that from the browser from the list. No refactoring. The output is much closer to the input compared to SAS. The nesting resolves, the media query resolves, the custom properties get fallback values. Or you can disable custom properties and just have the fallback value in the output instead. But please keep it simple. You can go crazy with Post-CSS plugins and recreate everything that SAS does. Some good questions to ask when adding a new plugin are, is this supporting CSS that browsers are going to implement? Is this essential to my workflow? And can a utility class do what my extend or mixins did? JQuery is also the past. Another fantastic tool that let us write much simpler code. But it's old and can be a bit of a bubble. It's very easy to only write JQuery and not have any understanding of the underlying code, basic JavaScript. That's knowledge that doesn't really transfer to the decoupled JavaScript frameworks. There's also a performance hit in needing a third-party library to load. Vanilla JavaScript is the future. Just like CSS, plain old JavaScript or Vanilla.js is old. But it's native to the browser. It's the foundation of every decoupled framework and it's much more performant than JQuery. Also, the JavaScript spec has evolved to do a lot of what JQuery did. There's no third-party library needed and you don't actually need any tooling for it. This is how easy it is to iterate over a group of elements and some other JQuery equivalents. We have click events, closest, toggling classes, append, prepend, remove. All much simpler to write than it used to be. This is a JavaScript class with customizable options exported as an ES module. This is an example of importing that ES module and then extending it. This is great for building upon existing functionality. Yes, ES modules are supported today in modern browsers. You don't need to bundle the imported module into the file for a modern browser to use it. And if we are supporting older browsers, we can exclude these ES module files from them. Using the type equals module attribute. We can send ES module files only to browsers who can read them. IE will not execute files with this attribute. Then we can use no module attribute to send some files only to older browsers. For example, things like polyfills, which modern browsers don't need. Modern browsers will not even try to load this file. If you're not supporting IE, just give everything type equals module and IE will be JavaScript free. Again, ES modules can be used right now but tools like Babel allow us to use future spec, just like Post-CSS did. New JavaScript syntax that might not be widely supported just yet. Combine Babel with your rollup or webpack setup for even more performance and workflow optimizations, like node resolving the imports, tree shaking, code splitting and minifying. By code splitting, I'm talking mostly about entry point code splitting, where a Drupal steam JavaScript is often broken up into individual components, so each component's JavaScript file is an entry point. But there might be some shared dependencies across components, so to prevent duplication, we can use code splitting. Say we have three components, all importing ES modules. Two components import the same one, a shared dependency. We still want a JavaScript file for each component, so we can attach it when we need it, but we don't want to have the same imported ES module bundled into both components. If they both get added to the same page, that creates duplication. So we can use our tooling to build shared chunks instead. By adding Babel into our bundler, we can generate two versions for each component. One file like the previous slide, importing any shared chunks as ES modules, which we give type equals module. Then a second file that bundles in any imported modules, and is transpiled for IE 11, which we give the no module attribute, like in the polyfill example. IE gets bigger files, so a performance hit, but our components still work. More importantly, modern browsers get the smallest possible file. This is our Babel config. We create two environments, one for module and one for no module. We use CoreJS to include polyfills for us, based on our usage. And just like post-CSS, the preset ENV package allows us to use our browser list config. So it's easy to pull out IE 11 support. The targets option, by default, will defer to your browser list. But for our module environment, we're saying all browsers that support ES modules. Rollup has supported this for a while. Parcel has added it to version two, but I haven't tested it yet. And Webpack is working on adding support for the ESM output format. So the following config is for rollup. First, we create a glob array of all our components as entry points. Then we set up any plugins needed. We pass in an environment variable to defer to our Babel config. Then we set up config needed for the module output. The input is our glob array. Rollup knows what ES modules each file is importing and exporting, which is called tree shaking. Our format is ESM, so it knows we want to use our ES modules in the output instead of bundling them. Then we tell it where to put the chunk files, our shared ES modules. We learned our plugins by calling the base plugin function, passing in the module environment for Babel. This is our config for the no module output, which is a function that accepts a single file. The format is an ife, which ie11 understands. We pass no module as the plugin environment for Babel. And finally, we build a complete config array with a separate no module config entry for each file in the glob. There's a link at the end of these slides for a repo with this set up in it, so you can refer to that. So for each entry point, we get our two versions, which we can send to the relevant browser. No older browser gets JavaScript that they can't understand. And no modern browser gets JavaScript that they don't need. Another form of code splitting is called dynamic imports. It allows you to lazy load or conditionally load an ES module, which is also native to modern browsers. Instead of importing the polyfill at the top of the file, we're first checking if the browser needs the polyfill before importing it. So if a browser has native support for the HTML5 dialogue element in this example, it won't load this polyfill. But Firefox, for example, will load it. The import returns a promise which we can then use. However, this doesn't work with the ife format we're using for our no module output. I haven't tested enough to know what the best format is, but I probably wouldn't worry about IE11 if you want to use this. Yes, there are ways in varying levels you can support IE still. But surely that effort could be better placed elsewhere. Some users have no JavaScript turned on. Why not just treat IE11 like them? If the content is accessible, isn't that enough? You can skip the no module stuff and the grid fallbacks. Free yourself from IE. So to sum up, writing modern code is fun. You'll hopefully learn something new. Performance will greatly improve for the majority of the site's users. If you are supporting IE11, it's easier to undo. And this reflects what's happening in Drupal Core, so it ensures you're in a position to contribute to its front-end. It's a return to the basics with a look to the future. So those code examples are in this top link, this repository. I've blogged about this before, various levels on the previous next blog. There's Drupal issue queues for removing jQuery from Core. And there's tons of resources online about writing one front-end code. And that's me. I ran a little bit quick. Thanks. Thank you very much, Rikki. That was actually very, very interesting. From my perspective anyway, I used to be a front-end developer many, many, many years ago, so yeah, it's gone a long way. It has, yeah. Definitely completely outdated now. From my time. Does anyone have any questions at all? Please put it into either the Q&A or the discussion forum. If there is no questions or anything like that, there is, you know, we can finish a little bit earlier, just reminding you guys all that the lightning talks and round table session starts at 2 p.m., so we're a little bit ahead of time. So, yeah, if you guys have any questions or anything else, if not, then thank you again, Rikki, for this very informational session. Thanks. So I'll give you guys a couple of minutes. If not, then... Okay, correct. Awesome. There are a couple of questions. The first one, how do you decide what browsers to drop support for? Statistics for what are supported seems spotty. Yeah, that's a great question. So, obviously, there's the sort of global statistics of what what average usage is, but we find it more valuable to just get our clients to check their Google Analytics and see how much that browser is being used by their customers. And that usually determines whether it's worth the effort to put in to support it. Great. Another question we have here is do you have any tips for converting away from SAS? I mean, it's a process, especially if you're refactoring SAS files on an existing theme, I'd probably recommend just on your next new project starting with Post-CSS and not including any of your SAS stuff. But, yeah, it's just sort of work your way through the files and replace things and, yeah, convert to utility classes where you've used to extends heavily and things like that. Excellent. Great. Hopefully that answers your questions. Anything else that you'd like Rikki to help you with? Thanks, Drew. I don't think there's any others coming. Well, it looks like we're all going to go and start using Post-CSS and not worry too much about SAS soon. Great. Well, thank you very much again, Rikki, and thank you everyone who joined this discussion. I hope this was as valuable as it was for me, actually. And, yes, we will share if you can put, I'll put again the last slide with all of the URLs if anyone wants to copy it. And I'll tweet a link to those slides as well. Awesome. Thank you very much. Excellent. Well, thank you very much, everyone. Thanks, guys. Yep, and Jess also wants to remind everyone that the live session starts at 2pm. So you have about, I think, 18 minutes. So, yeah. Thank you.