 Yes, I'm not a front-ender. I am much more the back-end type. I have been learning quickly, but still it would become rapidly apparent. My lack of knowledge about actually doing things well. So the other more serious point, though, is that the sands of Drupal 8 continue to shift. And I'm gonna be talking about things that we would like to bring in here, but we're not exactly sure how much we'll make in, so I'm gonna try to keep it as clear as possible. And towards the end, I talk about the sort of three different rough things that we could shoot for. But yeah, keep in mind that none of this is fixed, and it's especially applicable to the code, which is intended to be illustrative, not functional. Also, just with the amount of things that have been shifting, I mean, I've had to rewrite significant portions of this presentation in the last two weeks, and even the last 72 hours, based on conversations that I've had. And is Chris Wallsmith here? Yes, no, maybe so. No, okay, awesome. He's the author of Ascetic, and so I figured he was gonna tear me a new one afterwards, but I'll just have to meet him later, because I believe he is here at the conference. But without further ado, let's talk about asset management. So when I say asset management, at least for these purposes here, I'm also, to be clear, just talking about style sheets, CSS, and JavaScript, not talking about images. That is something that Ascetic also helps us with, but that's not my focus so much here. So with respect to asset management, there are a few different parts to it that go into it. So first is how you declare them. That is how you tell the system you're operating in that they're there. And in a system like Drupal, this is actually fairly complicated. The different places you say I have this asset, I want it added to the page. Whereas in a lot of other systems, it may be less complicated. If you just have template files, will you just write in the, you write in a script tag or a link tag that says this is the asset that I want. It's more complicated in Drupal. How you can write them, that is do you have to just write JavaScript or CSS or can you use SAS or Compass or any of the other interesting new ways of writing assets. Since right now, it's a pain to try to do. How many folks try to use CoffeeScript, SAS, whatever else in Drupal 7 right now? How many folks enjoy the process of trying to get it to work? I have one hand up until, oh yeah, actually try, okay, good, good, that's this last year. Well hopefully it'll be better. But yeah. Then there's really the trickiest question in Drupal which is how you organize them all together and we'll spend a fair bit of time on that. But finally, there's the question of how the browser gets them and how fast the browser gets them since of course your asset management strategy and how much you can aggregate, bundle, et cetera, has significant effects on your front end performance. So right now, Drupal collects information in a few different ways. For one, there's the information you put in the theme info file says I have these assets, add them please, always. There's also libraries and we've moved more and more things over to libraries but inside of hook library info you declare different, you can declare actually JavaScript and CSS together as a single library and then other systems can say I depend on this library and that will ensure that that library and its contained assets are brought in to the page. And there's attached which is especially for front end folks that is show of hands, who knows what attached is? Yeah, who knows what the render API is, render arrays. So Drupal's internal system for deciding what it's actually going to render, we have this whole system we instituted in Drupal 7 called render API where we basically build big arrays of instructions about things to render and it's full of lots of these pound attached values. It's very, it's inspired by form API which is a set of instructions for how you render a form. Well, this is generalized to doing all rendering and the purpose of pound attached is to say I have additional attached resources that should be added when this thing is being rendered and it's used to do things like say add this piece of JavaScript or the CSS or also declaring that this library should be included, things like that. But it is as I'll talk about more later the sort of primary base mechanism that we're trying to move towards. Then of course there's Drupalad CSS and Drupalad.js and I was familiar with those. Yeah, considered a bit more common. So those are going away. That's maybe the only thing that I can say for mostly sure is that we're trying to get rid of those. But beyond that and especially when calling Drupalad CSS and Drupalad.js, we have a few extra meta properties that we attach to our assets. The scope that they live in, group, browser information and then of course also some things like the media query to use with style sheets at the very least. So we have a sort of collection of things that serves the different needs and purposes. We have themes that need to say I have these assets, there's also themes that need to manipulate the other assets in the system. There's modules which I guess sometimes at least need to add their own assets. And really the purpose of the attached case though is kind of the more sensible one. It says I'm putting some like maybe a block on the page and the block needs some CSS to go with it. So I'll put pound attached on the block bringing its CSS and JavaScript. So these things kind of suck because first, who can tell me the weight of jquery.js just offhand? Does anybody know? What is it? Minus 20, yeah. We use explicit weights for all of our assets. It's the way that we manage it. You don't always see it but when we build up the big array of all the JavaScript or all the style sheets that we're gonna add to the page that each have a weight assigned to them. This is how we get them out in the correct order. It's kind of crazy because the way it actually works is the order in which you call Drupal add CSS like it adds just a little teensy bit to the weight for each one thing that gets called. So we really just sort of hope that everything gets called in the right order and it works out well enough most of the time. But since we have explicit weighting, it's a poor solution since the problem we're trying to solve really is making sure that well if I depend on jquery then I want to be added after jquery. Having a weight that makes you get added after jquery accomplishes that but it also means that there might be a whole bunch of other things that you are weighted after that you don't actually care about. It doesn't actually matter. You have a bunch of unrelated JavaScript that is still an explicit weight ordering and ends up having significant effects on how we can do aggregation and bundling. So explicit weight is a very mediocre solution. Global Functions, Drupalats, CSS, Drupalats, JS, they are death to caching, to good, proper ability to, I really did not do that. They are death to our ability to cache the page in a proper way, mostly because you can call them from anywhere and they change page output from anywhere and if we can't predict what the page is gonna look like then we can't cache it. So this is why the primary reasons that we're trying to get rid of these global functions. As I said before, using SAS, CoffeeScript, et cetera, all these new systems that actually make you want to be a front-under is awkward at best and folks come up with sort of one-off strategies but we don't have any systematic way of supporting this right now. There's also problems because the list of declared assets is opaque. So by that I mean if you are in a theme and you're trying to look at the list of all the JavaScript or CSS that's been declared, you wanna manipulate them in some way. You have no idea if you're looking at the scope value or the media query or anything else that's been set on any of the assets, whether that was actually something that was directly set by the code that added the asset or if that's just a default that was added onto it later on. So you are really just sort of poking around in the dark when it comes to, ideally if something actually explicitly set a value when they added an asset, you should probably respect it. They probably know more about it than you but if it's just a default that got added you probably know more than the system so you might wanna supersede that but you have no insight into this whatsoever with the way that we add assets right now so it's kind of crippling if folks wanna do meta-operations on assets and there was at least one other thing under that opacity that's in my speaker notes that we're never gonna know because I can't remember it. So, step one towards helping with these problems is aesthetic. Now who's heard of aesthetic? All right, aesthetic is a PHP library which is, it's an asset management system that's designed to handle assets. It's inspired by Python's web assets and it ships with Symphony now and it's, so it's an essential part of how Symphony works but really it's about assets and filters at its base. Assets are used to, so we have different classes to represent them and bear with me, this is a bunch of PHP here but yeah. File assets, glob assets, string assets and HTTP assets. File, string and HTTP should be pretty straightforward to understand but here. In aesthetic, to declare an asset you say new file asset, you give it a path to where that asset actually lives and it creates this object that we can use to load and dump and there's dump methods on it which will actually output the body of the asset. Well there's, I'll put a pin in that for a second. There's a lot of things you can do once you've actually created one of these asset variables. Remote asset is represented by an HTTP asset so you pass it the path to that. Literal string, you just pass in the body of the asset that you want right there. And then a glob, something we don't, we won't be looking so much at with the way we're using this Drupal but the principle here is yeah you can pass it a path with like a star in it and it will capture all the assets in a sub directory or something and glob them all into one combined asset. Filters are where it's interesting so you declare one of these assets then you can apply filters to it. There are lots of different filters that a static ships with. This is a, I mean a small sampling coffee script filter, compass filter, CSS embed, JS mint, SAS, CSS compressor, JS compressor. There's a bunch more. One of the big issues of course is that most of these things are not actually written in PHP. They require an external binary of some kind that you've downloaded. Maybe it's Node, maybe it's Ruby, maybe it's Java but the purpose of this system and what a static gives us is we have a one simple way in PHP land of declaring an asset and then saying I want to apply this filter to it. I want to take my coffee script file and turn it into a Java script and you do that by just adding a filter to it. So we say new file asset path to drupal.css. We now have a representation of our asset and then we ensure that the CSS mint filter is attached to it. Now it's incumbent upon the system to make sure that the Java binary or the Ruby binary or whatever that actually will do the work is present and that that's been registered but the way that we will be doing this in core is we'll see how we do it in core. But ideally we will have at least some subset of the filters that a static ships with. We will hopefully package in some of these binaries so that you just get them for free. You have to do absolutely nothing. You don't have to download additional libraries or install anything additional on your server for it to work. It'll just work by downloading Drupal 8. So yes, you get these for free. Even if we can't ship all the binaries that we might want with Drupal 8 though, it's very easy for, it'll be very simple to download them yourself, put them in and in a settings file you'll just say this is the path to the binary and it'll work just like this. You add whatever filter you want to apply to your assets and they will work. Yeah, and so then the dump method here will, what we would see the output of asset dump here would be Drupal 8 CSS after having been run through CSS modification. So the way that's, and actually, sorry, I'm gonna go back real quick here. I'm intentionally not going into many of the nitty gritty details about aesthetic, apart because I think it would not be ideal for this audience, but there's also plenty of resources out there. I will put these slides up online and maybe a link on the page, but this link down here at the bottom if you can see it, is a slideshow presentation that's a couple years old but it's still the sort of best, simplest introduction to how you put things together with aesthetic. So this may make it a little bit easier to understand aesthetic's role. So everybody knows twig? Yes? Yes. So in a twig template, you might use aesthetic this way. Say, aesthetic and then you pass it the path to your, in this case, coffee shop file. You indicate that the filter you want to use is coffee and you tell it that the output directory should be JS and then the name of the file should be script. Then you have the actual literal script tag here for script source and then the generated asset URL. And behind the scenes aesthetic will do the two things, one of actually generating asset URL, which turns out to be JS, script.js and then writing out the corresponding asset to disk. It will read in your coffee shop file, it will run it through the coffee shop filter and it will actually write that out to disk at the appropriate location. So this right here though is indicative of why the sort of more standard way of doing things in symphony is not quite so applicable to the way that we operate in Drupal because we're not really writing literal script source tags in Drupal. Pretty much ever, that's something which is delegated to another part of the system, which means that what we have to do is it's perfectly fine for us to use the asset classes and to declare filters and stuff, but we have to solve the problem of how to organize them and then ultimately. So in Drupal aesthetic, the first thing we need is some of our own versions of those asset classes, the file assets, string asset, HTTP asset, and glob asset, along with some others. So first, and this code is written, not in, but written, the first change is that instead of having a generic asset type that isn't specific to the type of asset you're including, we have ones that are. So we have JavaScript file, JavaScript external, JavaScript string, and style sheet files, style sheet external, style sheet string. They follow the same pattern. If you want to include a local file, that's CSS or will become CSS after running a filter. Over it, then you call style sheet string asset. Or you, sorry, you make a new style sheet file asset to represent that. We also have then the asset library and the asset library manager that's to replace the old system for declaring libraries, but they end up looking pretty much the same. But so here in the old system, if you were to call Drupal as CSS and say path to file that CSS and then specify that its media type is prints the new system, you would say, make me a new file variable that represents this file asset, set the media type to be prints, and then call Drupal as CSS in the file. Drupal as CSS in the file is a lie, as I said, we're getting rid of those, but this is the idea, it's roughly the equivalent. Now as I said before, since this is having to do with the opacity issue, I don't know where, how, what value got set. In the new system, we can actually tell the difference between a default value versus a value that the code creating the asset actually set. So we make this new file asset, path to file, that CSS, and then if we explicitly call set media on it and say prints, then when some other code somewhere else calls, get media on it, it will get back prints. But if it calls get media default, then it will probably get back all, assuming that that's the default. Allowing, which means that other code somewhere else can be much smarter and understand, oh, there actually was a value, a real explicit value set. If we hadn't called set media print, then get media would just return nothing. And we would know that, hey, we can set our own value if we're doing something that way. I've had a number of people bring up this issue to me as being something that makes it very difficult for them to work with the assets that are produced by Drupal system right now. Asset bag is the simple system that we have for grouping assets together. If you have a bunch of different ones to clear, then new JavaScript file asset, new style sheet file asset. Here I've also included just a little sample of how it looks to attach filter. And then you add them to a bag. The bags are useful because we do need to be able to pass these around and keep them in order. Bags actually do a lot of different things, which I unfortunately don't have pseudo code to demonstrate, but bags are the central thing that we add all the assets to. Blocks produce, well, actually. I'm gonna leave that out, I'll come back to it later. Bags are our way of passing around groups of assets. Libraries get converted to the new system. So the old way, this is old hook library info from a system module. We're saying, the part that you look familiar is what's here in the middle core MISC JQuery JS that is in group JS library and has weights of negative 20. That pretty much goes away in favor of make a new asset library class for that. We add to it the jQuery.js. We don't have to set grouping or scoping and we don't have to set weight. That's stuff that we can handle implicitly because of the metadata on the asset. And then we just give a title and a version to the library in the same way. We pass that back along. Here's something that's maybe actually exciting. I'm hoping this is exciting for folks. The way that we get rid of weights is with these nifty little depends on system. So I make a new JavaScript file asset. Paths to a script. And then I say, I want my asset to be dependent on jQuery. All you have to do is this simple thing. Script depends on jQuery. And then when we're actually doing all of our page assembly calculations, we can take into account the fact that you should depend on jQuery and we will locate you somewhere after it. But you don't have to care about the 17 things that might be in between you and jQuery. We can have it to dance around with specific weights. We can also do some things. The dependency indicates that it must be there and I must come after it. It's also possible to just say my asset should come after this other asset if something else adds that asset. But I'm not necessarily saying it has to be there. Just make sure I'm after it if it is there. So you have a style sheet that you wanna make sure comes after system. I mean, you know the system will be there, but if you don't care if it's actually there or not then yeah, you can use this mechanism. Either way, it's much easier than having to dance around with weights and manipulate those. All you do is just say after it depends on or you can clear that value out and the system takes care of figuring out order. This is a lot, it's very similar in principle to things like require.js, anything that handles script loading and ordering for you. And in fact, the goal here is that when we put all these things together into a big giant asset bag that has the however many dozens of assets that have been added to the page, we can write them all out directly or we can basically hand off responsibility to something like quite a little least work for the JavaScript side of things. But yeah, the issue is really we need to kill the global functions, Drupalad CSS, Drupalad JS. And there are a couple of different strategies for doing it and here we are with the three different ways that things could go in core. So the first one, the sort of lowest common denominator that we're shooting for is that we just use attached everywhere. If we do that, then we don't get core aesthetic or the Drupalad editions that I've discussed. So you don't get nice easy access to the filters and using CoffeeScript and all those other lovely things in core. It could still be put in and contrived but it would be awkward. I'm not really sure how we would do that if we don't have it as part of the base system. But themes are still declaring their assets via .info and now .info.yaml file. And everywhere that we call Drupalad CSS or JS that ends up being replaced with attached on a render array. But attached declarations look the same as they always have. They don't change at all and our asset grouping and aggregation strategies are also pretty much unchanged. How many folks have ever looked at the asset grouping and aggregation strategies in core? Apart from WIM, everybody knows WIM's done it. All right, yeah. It's awkward. And anybody who really cares about front of performance should look at it and kind of cringe. We have like five different axes that we group things on and it makes it basically impossible to nearly impossible to get down to a really, really tight set of just two or three style sheets that you send out. Yeah, so that's option number one. Option number two is attached plus aesthetic. Still themes declaring their assets via their .info.yaml file. And we're still replacing Drupalad CSS and JS with attached on render arrays except now attached declarations use the new aesthetic asset classes. You're doing new style sheet file asset if you're adding something there. Although again, I imagine for a lot of the folks in this room, you will never ever type new style sheet file asset or anything. You will be perfectly fine with just populating things in your .info file and this will work behind the scenes for you. It's only if you wanna get into more advanced manipulations of the assets that have been added to the system that you'll start working with these objects I'm describing. And yeah, once if we have the asset objects in place then grouping and aggregation, we can make much more pluggable and hand off to a nice little service which will make, we can do much better things with front end aggregation. And the third option is scotch which is in disrepair right now. Scotch the Drupalad initiative of which I am co-lead. So once again, themes declare assets via their .info.yaml file but attach is less important. The goal here would be that there's really only three places that assets come from. You have like Drupal core system gets to declare some assets, some systems, CSS, things like that. And that's harvested first and then we have the entire page composed of blocks on a layout. Those are all the top-level elements and then blocks have a formal way of declaring the assets that they have. And so that's basically the only additional assets that get to make it onto the page beyond what the system says and what the theme says is blocks that have actually been put on the page get to add assets other than that, no. So modules don't get to mess around and stick a bunch of random assets on the page that you have to deal with in the theme. Then finally after we've processed block assets it's theme assets. Once that's done the theme is the only thing with an opportunity to actually go in and change the asset stack. So again you don't have modules mucking around in there. And then finally we hand off to an aggregation process and then we spit it back to the browser. We still do use attached a little bit like below the block level. So if you're defining different types of render elements then you can still put attached on there but ultimately everything comes up into blocks. We have a much simpler top-level system and we understand where all of our assets are coming from. Yeah. So that's my wonderfully disco-ordinated presentation. How long did this take? I have no idea what time it is. All right, so questions. Yeah, I should use the mic though. Beside to take what symphony components are being used in the asset management. Ascetic. So that's the only one. Yeah, what else would there be? I was just checking the one you were showing like how we are doing the conversion. Or like it seems like similar to the page router conversion how we are doing like page callbacks converting into the new symphony component. Is there any conversion taking place for the asset management? Not yet because we haven't gotten the base system in place yet. Like I said, shifting sands. Yeah, I know Ascetic is a pretty standalone system that covers this need almost entirely. So there aren't really any other components to pull in. Like I said, the only additional pieces you really need to pull in beyond Ascetic itself is the external binaries to compile something from SAS into CSS. Apart from that, there are additions. There are these numerous additions, our own classes, the style sheet file asset, et cetera, which we are writing and which would be a part of Drupal itself. But yeah, no, there are no additional components from symphony for the system specifically. Thank you. So I have some concerns about wanting to include binaries. When Drupal, I'd say if you want to include SAS or Compass, then you have to include Ruby. And it's like doing local dev on OS 10, trying to have, like I'm using version three of the SAS on theme, which includes Ascetic in it. And trying to pass SAS or Compass through RVM or anything other than the system where Ruby is a big pain in the ass. And even using side tools like mixture, code kit, fire, I always end up just going back to my basic command line Ruby, so I want to include a gem. And I don't want Drupal installing another Ruby on my system, and it just seems like that would be a massive pain in the ass for you guys to maintain and keep current. I tend to agree, and we probably are not going to ship many. It's, yeah, that is, we have so many discussions between here and then. It's good feedback to get, though. I think that what will probably be, the solution we'll probably put in place is if we get, what we'll probably do is we will just figure out some sort of paths of these resistance, and then there are gonna be some draw scripts for it or something like that, that's my guess. So I mean, I think, and if you are gonna try and do it, have it be like a user initiated thing after install, like you install Drupal, now if you want to try to automatically fold the stuff and have it blow up, here's the draw scripts. Okay, cool, okay. Good feedback, thank you. My question relates to using Drupal at JS, but more, I guess specifically with Drupal.settings and how to pass runtime kind of variables to the front end, essentially, which might be done in a module or moved into a theme, but at the same time, what you said about caching is like, blah, blah, blah. I was just wondering what you guys are thinking about in terms of how you handle some of that. Yeah, so I mean, there are a couple pieces there. I did neglect the settings part. I have elected not to make a JavaScript settings asset because it doesn't really make sense in my opinion. Kind of be like a JavaScript string asset since you're just passing in some variables that are gonna be translated to JSON. But there is actually on the asset bag, there's like an add settings method. So this is one of those places where the asset bag is really intended to be this meta thing that's passed up and it can contain settings. But that's definitely one area that I have not come to like a clear, this is how we should handle it. I will also say that while there are, it's not like we've completely removed any module's ability to tap into the page and make modifications to it. We're removing some of the more easily abused global mechanisms. But there still will be ways to get your settings onto the page for sure. Yeah, for the most part what we're really just saying though is that we're trying to decrease the situation where modules come in and make sweeping changes to the site without any knowledge of whether or not the thing that they're doing, the thing that they're responsible for is actually happening on the current page. That's why we're trying to, in scotch, we're trying to tie things more to blocks. If you have a block on the page, then you have some skin in the game. Otherwise, go away. So I'm gonna ask you a couple of follow-ups on the lazy automatic compilation of CoffeeScript, SAS, or whatever other pre-compiled languages for those assets. I've been doing a bunch of work with CoffeeScript and SAS both. And when you're in development, most of those tools have some kind of watch command that can sit there, and when you make a change it automatically recompiles and generates your CSS or JavaScript. If you're in production, you really kind of want a build step that generates that stuff and packages that up so that you don't have each PHP head responsible for having the exact same version of the exact same binders, the exact same gems, and duplicating that effort across those different environments. You want to make your, not to mention that if you're lazy compiling that stuff, that means that's yet one more thing that you have to do that's computationally intense before you can actually serve a freaking Drupal page. And I tend to think we don't need more of those. Ten to agree. So I'm not sure I see the use case at all for having Drupal take responsibility for it, which like the workflow that seems like it makes a lot of sense is you have those tools that do the compilation, do the compilation while you're in depth, you have them watch it. So it's really not a problem that you have to have it recompile. I don't really want Drupal trying to watch my .coffee or .sas files and figure out if it needs to retrigger a compilation. Because when would it even do that? Presumably, all right, with the aggregation stuff makes it more complicated, but that's like a hard problem to solve that feels like Drupal isn't the system that should be worried about that. My build step and deploy step to actually get stuff out to production should do that compilation and do it once. And in development, I really don't want Drupal taking responsibility for it because those tools are gonna be better at it. So I'm not sure I actually see the use case or how this makes working with those external tools easier at all. It's a good point. The, I mean, there are a few points. You don't have to, obviously. You can just perfectly find for you to tell Drupal about the target place that those tools are compiling to and not actually directly say that this is the filter to be used for it. In symphony, the way that this is done is symphony actually serves, symphony typically expects that its assets are served by PHP and when the initial request comes in in the sort of more standard configuration, when the initial request comes in for one of these assets, it will end up going to a static and it will do the compilation process and it will create it once and then it writes it to disk and then you don't have the problem anymore. You don't have a good overall answer to it apart from saying, I do agree. Like, this is not something that I really want Drupal watching. This is not something that I include the other tools are gonna be better at watching it. I think there are some uses for it. Certainly it can be useful if you don't mind having it done in development that way at the very least but yeah, I don't know. There's a lot of best practices to be worked out for sure. You have a follow up? So I've been using ascetic on triple seven and one thing that really makes easier is keeping the sass near parent child themes. Like, if you want to inherit, that's something else to say but then I ran over here and slipped my mind. Well, we've got a lot of people so let's move on to the next person. Thanks, Howard. I comment on that and I think one value of this is that 80% that use Drupal that don't come to DrupalCon and work on smaller, simpler projects and don't have the time to actually build, put together, build processes and all of that, having Drupal do this for them is a big win for those people. Those are the sort of people that wouldn't know where to start to install Ruby to load a Ruby Jam or whatever. My question is about loading scripts last. This is probably my biggest pet peeve with Drupal but it's not something I've wanted to fix but not got around to. So if you've looked at front-end performance, most people know that the biggest one you can do is load scripts at the end of the body tag, not on the head and not at the beginning of the body tag. DrupalCon doesn't do this. It should, that's the ideal solution. So there's two parts to the question. One, will this make it easy to fix in DrupalCon and two, what's the work around solution? Currently the work around solution is you just put print scripts at the end of your page.tip-of-it. Yeah, and that's not a great work around for, but yeah, this actually makes it drastically easier. A lot of that, the sort of crappy metadata that we assemble makes it, I've talked a lot about dropping JavaScript at the footer or something like the footer and the fact that we are building a real dependency tree that says I actually need to be after this thing and not I am after this thing, I happen to be after this thing because my weight is set in such a way. Means that we can make much more intelligent decisions about where we actually put things on the page because we have real knowledge that this has to go after this, but they can technically be located anywhere. So we have, since we have the real insight into that. Yes, so that's it, it definitely addresses that use case. Yeah. I think part of the problem in Drupal six and seven core is that sometimes scripts do actually have to be in the head. Right. Either because they're poorly written or they might have a legitimate use case occasionally. And the problem is that with Drupal edge AES, it assumes that everything goes into head by default. Right. So then people write it to work as though it's in head and then they don't realize it doesn't work if it's not. Right. Will that default change with this or is it kind of unrelated? I mean, it is a little tangential since some of it has to do, well, it's slightly tangential, but I would like to see it change. Yeah, that we can initialize either that we, really what I would prefer to see is that we just don't have something and says you have to be in head. That we don't say either way where you have to be. And so for those few things which actually do need to be in head, then we can add that marker to them. We know that. But for the rest of the stuff, we can let it float, which means we can push it down. And that, yeah, that is my plan is to write the defaults that way. Right. So the aim is for a default to follow. Well, it would default to nothing and then we would push it as far down as we can, which means the fodder. Yes, that's what I would say. Yeah. Cool. And my last question, how can we use acidic in Drupal 7? I don't know. But somebody else has ideas about that. They were just picking me this morning. He said that there's a theme called Sasson that's available for Drupal 7. Hi, Sam. Yes. First of all, thank you for all of your work that you've been but again for this. I know it's incredible. I had a question because I didn't understand one certain thing they were saying. In the scenario where Scotch is a thing and we are going to be using plugins in order to handle this problem, I don't understand exactly how handle this problem. Means you're saying that in the annotations of the plugin, we're going to say which of the acidic buttles we're going to be bringing in a block, not plugins. So well, it's our plugins, but yeah, so a block would specify, there's a fair bit to it, but the simple concept is a block specifies in its annotation. In order to, if I am placed on a page, then I have associated assets that should also be placed on the page. I have some JavaScript, I have some CSS. So it will have in its annotation something that's like add style sheet file asset and then a path. This is the real question. I suppose, maybe it's because I don't understand plugins very well. For every case where we have an annotation that describes the things that that plugin has, is it also possible to do those same things without the annotations? The annotations are an inherent part of the plugin itself and are required to, yeah, they're required part, why? I'm not, I'm not sure I understand. It's just a code preference. I don't like putting code into comments. Yeah, I, there was a lot of discussion about that. Yeah, okay. Thank you. All right, yep. So I was wondering about why are JS, you mentioned it briefly, and but also about aggregation of JavaScript and CSS. So are we going to be able to, for a Drupal site where you've got different pages, say using a backbone, like one app page or one page app kind of thing, are we gonna be able to get backbone in all of those dependencies and that stack sort of bundled together, being aggregated and what would, and how do you see required JS being potentially used or? Right, well, I mean there's just a couple, there's actually just a couple overlap. The idea of using backbone for some front end things and not others is complicated in and of itself. So yeah, this would be a long answer and kind of meandering. So you can feel free to ask me about it later and we can talk more about it. But yeah, I don't know exactly what that end change would look like at the moment. That's the easiest answer I can give at this point. Okay, yeah, I'll ask you about it. Hi, my question is about filters. You didn't really clarify, I guess. There's different kinds of filters that would do different kinds of things. So you're gonna have aggregation and compression and processing. Will some filters happen automatically or would we have to depend on every module declaring JS man for compression? That's another one of those defaults that we can set. I didn't show, but there are factories that we can use to make it a little bit easier to declare these as well. So instead of doing like new style sheet file asset and manual set, you can kind of compress that down into a set of calls and formulas. And you had to do a factory and the factory has a bunch of defaults set on it, like apply all of these filters and those will just be propagated on. So there's a lot, when it comes to setting defaults, those apply to the properties we're used to having as well as applying filters. I think we're almost like at time here, if not, yeah, we're past time here. So why don't you guys come up, you can ask questions and thank you everybody for coming.