 This is the State of the Frontend. I'm David Wong. I'm at Eatings. And this is Brian Wald at Brian Wald. One of us has a much more easy-to-remember handle. I'll let you figure out which one that is. We work for Aquia as evidenced by the shirts, and we are both frontend developers by training, if not by our everyday-to-day experiences. And we'll go in a little bit about that later. Just as a show of hands, who here saw us talk at Austin? Who saw my brain as full? Okay, great. So this recap section is totally useful. We didn't know if we were going to go over old things. We have three sections to our talk today. We have yesterday, today, and tomorrow. And we'll talk first about yesterday. And some of this is going to recap what we talked about in our previous talk, but it'll be good to follow along. So last time on My Brain Is Full, which was the talk that Brian and I gave, we talked about how frontend has changed a lot. I don't think anybody here can deny that of all the facets of practice that we discuss about at DrupalCon, frontend is the one that's undergone the most amount of changes in the shortest amount of time, Drupal8 change is notwithstanding. And actually, even taking into account Drupal8, frontend has probably changed more than any other practice within the Drupal Aegis. In that time, Drupal itself hasn't changed very much. Frontend has changed. We'll talk about this in a little bit here, but the frontend developer experience, starting from 2006 or 2007 or so to the frontend experience of 2014, is a dramatically different enterprise, whereas Drupal is still pretty much Drupal. You're entering things into forms, you're hook-altering things and that sort of thing. And more importantly than that, as frontend has changed and Drupal hasn't, we haven't been very good at predicting things. We've laid our bets pretty heavily in some places and those bets have paid off in, say, JQuery. And then we've also had really long bike sheds and discussions about things like BAM or O-O-Z-S-S, or other things where we might not have fallen on the right side of history. And it's not even so much about predicting as it is. When Drupal7 was released, for instance, we had a very set way of doing things, and so things were kind of baked into the CMS in that manner. So what we expected to see in Drupal7 changed dramatically as we got throughout the lifecycle of where we are in Drupal7 now, which is at the horizon of Drupal8 being released. So this is a slide we used in our last session. And essentially what we're talking about here is you can't see the very bottom, oh, you can, is some dates there. And what this is talking about is the lifecycle of Drupal versus the lifecycle of front-end technologies. So when we first launched Drupal7 blueprint grid system, 960 grid system, things like Kufon, which is managing your fonts and so forth, we're kind of the normal. And then as we progressed throughout the time, that changed, but Drupal is still exactly the same. So if you look at that first part of that, as I was talking about, those were what we expected when we started Drupal7. And then we go to the next part, and this is not what we expected when we started with Drupal7. So we have a lot of conflicting pieces of information coming to this. So we have to kind of retrofit what we're using on the front-end to move it into Drupal so that we can do the things that people are expecting in 2014 from their websites to perform. The gist of this being that front-end's moving way faster than Drupal, right? I don't think anybody here would say, Drupal Core Development happens at such a clip. I can't keep up. Maybe you can reasonably say that in the last month or so, but you can't historically. Drupal is geologic time compared to the speed at which front-end technologies have moved. And this is not even counting things like just responsive, but even things like today's JavaScript framework is yesterday's laughable pile of spaghetti. There are things on the front-end space that move so much faster that iterate and operate and come into and fall out of fashion faster than Drupal itself can ever keep up with. And this includes things like contributed modules as well. And lastly, the one thing that we covered that was really important, and I think everybody here would agree, is front-end is a thing, like a thing thing, right? Front-end isn't... Front-end is its own practice. Front-end is a discrete skill set. Front-end isn't the place where you just shove your junior developers and then say, you know, write modules one day. You know, front-end is a distinct practice with its own skill set, tools, and best practices that are robust and as solid as any other facet of Drupal development. And this is what... It can't be undersold. This is one of those things where, you know, front-end developers and Drupal, you know, the alliance has been not very, you know, very easy at times, and equal footing is definitely a thing. And ultimately, the reality is that when it comes to the requirements of the web and the kind of technology that's driving Drupal technology forward, it's the front-end that's pushing it. It's not the back-end. Front-end is pushing Drupal forward, not the other way around. So today, not literally today, but, you know, today. You know, after those benighted days that we just spoke of. Play it again, Frank. Okay, so Frank Camaro. Does anybody here know who Frank Camaro is? There is a designer, formerly the New York Times and other August institutions, who is rather opinionated and writes blog posts, and we cited a blog post from our previous talk. I actually asked for a response for him regarding that, and this is what he wrote. Quote, We need to do a better job of describing the connective tissue of making things for the web. Everyone is describing the one little piece they've created, but don't explain, or even reference, the larger concepts of how all of these elements link together. This is, in my mind, just a symptom of the web stack being so deep. The more interconnected and complex a system becomes, the more difficult it is to tease apart. You have to see the progress while it's happening to decipher it. So if you're like me and missed out on a couple years, you only see the tangle of Christmas lights. Frank Camaro on designer news in July 2014. I have to preface this every time I quote Frank Camaro. Frank Camaro is under the age of 35, so he's not an old-timer. He's not somebody who's, you know, lost his way. He's somebody our age doing the same things we're doing, you know, having the same struggles that we're describing. So welcome to the new normal, the post-responsive world. I wanted to put up an even more graphic and destroyed landscape, but I don't want to think responsive is a bad thing. It just sort of cleared the table and set new rules, and I think we're still picking up the pieces of what it means to have our sort of precious ideals you know, pre-responsive, you know, be so utterly destroyed and reset. So the table stakes to the new front-end game. Responsive, right? Responsive. Responsive is a thing now. Responsive design isn't... It's expected. It's expected, exactly. These are all things that are expected now. They're expected to do responsive, expected to manage devices that have touch. It needs to be performant, and that doesn't just mean, you know, you're compiling your CSS code. This means that you're running, you know, tests and console, you know, evaluations of how your scripts are running. You're, you know, taking into consideration how the JavaScript libraries work together. All of these things, you know, you're doing a lot more engineering than what was a part of, you know, the yesterday of front-end. As I just said, JavaScript is cool again. So it's, you know, this concept of everything has a framework. Everything runs based off of, you know, everything's running in the DOM now. We're not doing everything from the server side. We can do a lot of things just straight with the JavaScript injected into the site, which is another reason why it's not playing super well with Drupal, because that's not how it was built to be made. So go ahead. Multiple frameworks are everything. I think it's everybody here has played with at least one framework in the Drupal. Does anybody here make a Drupal site without a single framework, CSS, JavaScript, or otherwise on it? Okay, there we go. For the video audience next week, that was zero people. Everybody uses a CSS framework of some kind. Multiple CSS frameworks. People use multiple JavaScript frameworks if necessary. You have CSS frameworks on top of CSS frameworks. You have, you know, their own individual theming, you know, if you use something like Bootstrap. There's multiple pieces that have to be assembled. This gives us lots of powerful new toys. We have a lot of power at our disposal now. More power than we ever had before with all the capabilities that we have. But there's two sides to this. So good news, everybody. As a front-end, as a designer and a front-ender, you have almost no limits. So, for example, this is Huijink.com. I'm not, this is not, when I'm getting paid by them, they just had a very trendy site. Scroll-jacking, flat colors. You know, this crazy tiling thing that's going on. They have embedded media. You know, they have a hamburger menu. I mean, who doesn't love the hamburger menu? You know, this is everything 2014 design and bodies, right? Flat colors. Boom. And so the bad news is that designer and front-ender have almost no limits. The exact same problem. For example, let's take a look at this Microsoft site. Same idea, but this is what I would consider design for design's sake. You know, if I were to interview these developers, they'd probably say, well, that's because I could. And not because, you know, we're using these tools in the right way. So there's two sides to the coin, and that's part of the piece of, you know, where we come in as conductors and orchestrating these things. So as designers, now we design and design dynamically along so many more facets than before. It's not simply opening up Photoshop anymore and drawing something. You have interaction design, you have to consider it. Personalization design, application design, multi-device design. It's so many more axes than were previously considered normal. So for developers, there's been an explosion of tools to help us meet this. And so, you know, they recognize that, and it catches up to us. It's this idea that, you know, we're always chasing something here. So for example, some of this says that automation, testing, performance, leveraging new features, managing the browser in context, writing less code, DRY, which is you're probably all familiar with. Do not repeat yourself. Keeping up to the pace with the checks and modularity so that you can swap things in and out. You know, using front-ends that are not Drupal-facing, not using the template system, you know, quote-unquote, headless Drupal, for instance, and building repeatable units for functionality. So, spoiler alert. Lucky for you, there are sessions on all of these topics. Let's kick it back a little more. So, all of these on testing, on automation, on performance, on new features for browsers and in languages, managing your browser's context, and things like writing less code, keeping your pieces of check. I think there's two sessions on layouts, non-Drupal front-ends. There's, I think, three sessions on non-Drupal front-ends. And then John Albon here in the front row is talking about web components that is packaging up functionality in a more meta way than we've ever done before. There are sessions on the front-end track and also a little beyond the front-end track as well that everybody should go see because these are the new normal for a Drupal developer and you should be up-to-date on these things. Because we say so. No. So, as expectations and capabilities have grown for your website, your web app, your application practices emerge to meet them. So, these things are coming out of the ether. These aren't things that have just magically sprung up for no good reason whatsoever. It's because people wanted to do something new. They wanted to be able to fill in functionality they didn't have before. They wanted to have tools to make these things easier. The goal of these techniques and these practices is to make your life easier, to make it possible, not to make your life harder, even though they might do that as a side effect. So, this is a quick tip, though. Many, if not all of these practices are outside of Drupal. Your CSS frameworks? Drupal doesn't care. Your JavaScript frameworks? Drupal doesn't care. All of these things. The modern front-ender skill sets are mostly non-Drupal centric. The things that you have to know as a front-ender concern themselves mostly outside of Drupal and Drupal is sort of a secondary, if not tertiary concern to you. Which is, I think, kind of ironic, given that we're giving the first talk in the front-end of the reality that we face. And going off of that, the complexities aren't always just about building. It's not always about having a hard time managing your grunt tasks or whatever it may be that you're doing for your website. These are also business concerns as well. Take, for example, when you built the site in 2008, 2009, you could be very predictive. You could make really, really educated guess on how long it's going to take you to build the front-end of that. You know, a lot of times we're seeing budgets go way over and beyond what you expected because there's just a lot of components that you just can't take into consideration. You know, when you're getting into a lot of different devices, way that things are interaction patterns that haven't been thought about when you get into an iPhone or an Android device, for instance, and become very complex. And the other side of that is that when you do actually scope something relatively accurate to what it takes to do in the front-end now, you have another problem, and that's that clients say, well, I used to be able to build a website, you know, the front-end, the design piece of it, the front-end piece of it only took, you know, 70 hours. Why is it taking 400 now? What's changed? I don't get that. And so they don't understand that how fast this has changed means that it's a lot more complex and there's a lot more that we have to manage. You can't just make a site mobile. So tomorrow. And not literally tomorrow, but the figurative tomorrow. So we came out in the 90s where, you know, this was your, this is web design. This is web development, right? Shove it into a table, make the table as complex as you need to, boom, it's done. A lot of people still do it this way. And this is what you were designing for. These are your targets. You had a funky PC or a Mac. You had these two browsers, and you had these two viewports, maybe even just one of them to concern yourself with. So now, this is more likely what you're dealing with in this project now. These are all the things that you have to take into consideration. You have to consider, you know, ten different devices, five browsers at least, a ton of viewpoints. Not only, you know, when it's just looking at it, but also if they rotate it into portrait or landscape, mobile view is what happens when somebody uses touch. How are all those things taking into consideration? Those are much bigger problems to be solving than we used to be solving in development of these websites. So, you know, it's not going to be that way. That list is never going to grow shorter. It's never going to grow shorter. It's only going to get bigger. Like, there is no unwinding the clock and going back to the 90s. So where does this take us? So the front end will always be chasing the next big thing. I mean, that's a... But, you know, this concept of us chasing things is not something that's going to go away and it's not something that's particularly new. That we just pulled from the keynote of the iWatch release, and this is just a sort snippet of this, but I'd like to play it for you. For example, if you take a gesture like pinch to zoom... Let's try that again. Over here. It covers the content. Oh, did you just... Well, it only plays if you play on the big one. For example, if you take a gesture like pinch to zoom, it covers the content. It obstructs your view. It just doesn't work. So... And so we placed extra functionality in a mechanism that's been on the watch for decades. It's this dial. It's called a crown. And on the Apple Watch, it's called a digital crown. The digital crown includes infrared LEDs and photos... This is not supposed to stop. So... The idea here... Hold on. Let me get back to a little bit of a difficulty here. Don't you, Apple? So who's ready to build some dial-based front-end? Right? This idea that... Oh, yeah, we figured it out now. Oh, you know, phones. We got it. We've got phones down. We've got tablets down. Oh, great. Now we have to create for a watch. And it's not just a smaller device. It has this dial. And this is an interface that we hadn't considered before. So this is what I'm thinking about. I'm thinking about building my comfortably held mastery of responsive front-end. So... And we are kind of, you know... This is sort of a point that we're making that's a little ridiculous, but it's not, either. Because... It's the reality. I mean, new devices come out. New techniques come out. New design patterns come out. And you have to respond to that. And you have to be able to meet the needs that you may be designing for an interface on a watch. It's very possible. So here it is. So the goal. This is, you know, what we wanted to talk to you guys about here today. And the goal is to be truly device-independent design and development. For example, Headless Drupal, that is such a popular trend right now. API-driven Drupal, which is the same idea, which is essentially being able to normalize your content, normalize how things are displayed, and letting the device make the decisions and design pattern for that device. It doesn't always have to be, you know, starting with the mobile or starting with web and then making it work on every other device. You know, that kind of technique, as you've seen, as we've... as everything is getting more complex, as there's more devices, as there's more browsers, as there's more screen resolutions, is never going to work. And you're always... It's gonna be becoming more complex to manage. So this isn't something that just front-enders are working with. And it's unfortunate that Jeff Eaton isn't here. Has anybody seen Jeff Eaton talk about the battle of the body field or his content strategy talks? Has anybody... Okay. Has anybody seen the Karen McGrain talk from DrupalCon two years ago about content strategy? And so similar ideas exist outside the front-end world, and in the content strategy world as well, that the idea that we're writing, designing, publishing, and developing for a set number of contexts is a fool's errand. And that we're going to be... We can continuously chase that down that rabbit hole forever and never come out winners. The idea that we can just, you know, pick... Oh, we'll just add today's device to the list of devices that we support and drop this other one off the list when it becomes deprecated is a fool's errand. Like, that's never going to be a winning strategy. That's always going to be just piling on more work for you, building fragile sites that only kind of work or target specific devices. I mean, who remembers the days of ActiveX, right? You know, like that kind of idea, specifically targeting contexts and devices is not going to win. And in the end, what we need is something that's much more ecumenical, something that's much less device-centric, that's much less context-centric, the content that you can display anywhere, the site that you can view on any device, the design that accommodates tons and tons of contexts irrelevant of whether it's a privileged one or not. That's the goal. It's a bit of a, you know, it's a bit of a unicorn, but, you know, there's nothing wrong in setting the sites high. And so this idea of chasing, this idea of always being one step behind it in technology is not a new one, and it's not something that's going to go anywhere either. For example, I have a video here from a lecture in 1969 with the philosopher Ellen Watts, who was talking to the IBM engineers about the problem of this exact problem. He's talking about the problem that technology is moving so fast that you'll never keep up. You'll never keep up with it. And so I'll just play you a quick piece of that. And this is when he's talking about managing catalogs, which is, you know, a little different context, but it's the same idea. Let's get on. And it's exactly the same in almost any other field. There's an information explosion, like a population explosion. How on Earth are you going to scan information? Yes, of course you can get computers to help you in this direction. But by Parkinson's law, the sooner you become more efficient in doing this, the more the thing is going to develop so that you will have to have more efficient computers still to assimilate all the information. You'll be ahead. But only for a short time. So, what did you do last time to make this? Just click on the outside. So you see this is the problem of the sort of... Alan Watts mounting us from the grave. All right. Maybe. What did you do? This is what we get for implementing all the technology. Using a JavaScript library to manage your slideshow. Ambitious front-end developers reveal we'll fail you. So the operative quote here, you'll be ahead but only for a short time. And that's really kind of what front-end development is these days, right? You catch up, you catch up, you catch up and you kind of get ahead and you discover this library that fixes things for you and like, bam, I've got this touch thing solved, right? Or I've got this CSS library. I finally have this breakpoint thing nailed, right? Or that. But it's only for a short time. None of that's permanent. They're called hacks for a reason. I mean, these things, the things that we do to Drupal do the things that we needed to do are, you know, shims. They're little wedges that we shove into Drupal to make it work the way that we want it to work, because it's moving so slowly. And to continue to develop a practice around that is foolish. And Brian and I have been talking about this a lot lately and you can't build forever on top of hacks. Like, there has to be a better way than this. Yeah. And so, you know, essentially here what we wanted to get to at this point is we wanted to talk about, we wanted to, since this is one of the beginning sessions of the Front End Track, we wanted to challenge you guys. We wanted to talk with you guys about, you know, stepping outside of your professional work day and thinking in terms of what you're doing right now with CSS and SAS and your front-end technologies is this sustainable? And if not, if you agree with us that this is not sustainable, what are some better ways of handling this? You know, what we brought up last Drupal con about how this Drupal and that turned into such a big thing is because I think everyone, it's kind of on the tip of everyone's tongue that we can't keep going on this way the way that we're developing right now and we need to take a step back and think about how we can manage content, how we can have a CMS that manages content on the front-end in a seamless way that is sustainable and maintainable as well. So... Let me jump ahead a bit here. So this is kind of our challenge. So we don't have pat answers and as we get to go first, we're not expected to have pat answers, but we do have a challenge for you and it's as much a challenge for ourselves as it is for everybody else who's attending this room. Design isn't how it looks and the front-end isn't just how it's styled. So if you come to this session expecting to talk about designing things better or how to style things better, we have a greater challenge for you and that's to learn something new this week that's beyond that. Think bigger than making things pretty. Think bigger than a new tool that you can add to your front-end toolbox. Think bigger, learn something, contribute your voice to the conversations here. The front-end in Drupal 8 is extremely fluid right now that is yet to be done and there's a lot of voices that have not yet been heard and there's a lot of sessions that are going to be talking about the things that are available to you and what we'd like for you, for those of you who are interested and are still sticking around on Thursday, is to come back and reconvene on Thursday at 2.15 p.m. and talk to us about what you've learned and talk to us about what you've taken away from your sessions and talked about the things that have challenged you in your conversation. We don't want to poke you and send you off. Start to build the strategy. That's my goals. I want us to sit down and say, let's think of a strategy as we move into Drupal 8. We have a lot better templating system in Drupal 8. But that's not the end all be all. Managing our JavaScript libraries become easier, all of those things. What I want to know is where are we going to go from there? That's how we manage the today. So, I think at that point, we have a thank you slide. And our handle is as well. He's Brian Wald. I'm Brian Wald and you can... I'm David Wong, talking about that if you'd like. We were told that we must be rated. And so this slide is courtesy of DrupalCon's Stephanie Amsterdam. So, yeah, I think at this point we do have a fair amount of time. It would be good to talk to you guys and if you have questions, please let us know. I don't know if there's a mic for this room, but if anybody wants to... We'll take hands. There's probably a mic. Hands and or just open, I'll cry. Really, no questions. Done. Wow, that was easy. All right, Lewis, yes, hi. So, Lewis asked if there's any existing outside tools for front-end. Do you envision any of them coming into DrupalCore or into Contrib? Yeah, I see a lot of things going into Contrib in Core. There's already been... So those who haven't looked at Drupal8 very recently, Modernizers in Core, Backbone is in Core, weirdly enough. There are a number of projects that are already in Core, but I don't know if adding more things into Core is the way to go. Well, it also... One of the better pieces I think about is that we've removed things in the sense that we don't have the dependency of jQuery, for instance, on the front-end anymore. You'll find that out if you start to load a theme and try to write some jQuery without loading the library. You won't be able to do that anymore. So I think that's actually the better direction is being a little bit more agnostic, but making it simple for people to add in what they need at that right time to do that. John. John asked... So we made the point in DrupalCon Austin to know everything there is to know about Drupal's front-end systems, the entire breadth of everything available to us. Oh, front-end practice. Abstract front-end practice in general. I kind of feel that's still true. I think part of the problem is that you're not only expected to know all of front-end practice, you're also expected to know all the weirdness of Drupal as well, and that's already two brains worth of things. You have to be a really, really proficient front-end developer. I think we termed Drupal bullshit like in our last talk. And it's kind of true. You have to know all these other things about Drupal that are in no way intuitive to any other system and bespoke to Drupal itself, and you have to be an expert in backbone or you have to be an expert in jQuery and you have to know this CSS system, you know, soup to nuts. And I don't think that's a reasonable proposition to make and I think Drupal 8 does make step strides in the right direction towards making it less dependent on knowing that drupaliness, I'm not certain it goes far enough. You know, I... You know, so in conversations with others, you know, one of the things that's always come up is, like, why do front-end developers leave Drupal, right? And, you know, front-end developers leave Drupal for a variety of reasons. For a lot of them is that wrestling with the Drupal beast becomes less fruitful than rolling your own Node app or, you know, working with React.js or, you know, whatever sexy front-end framework you like. And there's something to be said of that being our competition. You know, like, as developers, that's really the competition that we are measuring Drupal against. Like, what... how easy is it to build... You know, it's easy to build Drupal sites for these following reasons, but from the front-end, how do we measure up against this alternative system? All other merits aside, you know, taken away. You know, say nothing about content modeling, to say nothing of, you know, like complex architectures. How easy is it to, quote-unquote, theme a site in Angular versus Drupal? And I think for... If you hit a certain proficiency level, the scales tip in the opposite direction against Drupal than with. Any more questions? So on over there? Oh, hey, go ahead. Oh, my favorite... we're Brian. Me? Favorite tools and frameworks today? In Drupal or just in general? In general. Well, I think that there's... I personally like to run everything on Node and run an Angular front-end, but that's because I work on the Angular project, so I'm a little bit biased. But I think that, you know, some of the really cool things that excite me about where front-end is going is actually some of the tools that are just managing all of these libraries and managing all of these tasks, for instance, grunt, right? You know, running grunt or ant are one of those methods for compiling and doing a lot of the heavy lifting for you, so you're not constantly managing those things over and over again. You're able to, you know, run your lint, you're able to run compressions, you're able to, you know, just manage a lot more and making your life a lot easier. So when you get into situations where you're running an Angular app and then all of a sudden you, you know, some other developer comes in and wants to strip that out, you can make those kind of modular changes easily that way. Please. This is a great example of how you can manage your web components and polyfills or decrease complexity of the front-end. John, who is sitting in the first row, is giving a talk on web components. Sorry. Preston's. Preston is doing a session on web components and John's doing one design components. Brian and I are a big fan of components, like in the lowercase c sense, breaking up manageable chunks of things, breaking up the front-end of things in front-end. You can argue it's maturity in the Drupal space, but, you know, the general, the wind is blowing in that direction. You know, if we were... Yeah, as much yes as I can. I might look foolish a year from now, but we'll say yes for now. Sure. And part of the talk is that, you know, a lot of people look like idiots now for saying we should have put blueprint into, you know, Drupal core overriding blueprint every Drupal site you make now. Well, you laugh, but that's the same thing that people are doing at Drupal 8 now, too. You need to add these things in here, and then in a year, that's not going to be relevant anymore. So that's why I'm a big fan of making it available to swap those things out as you need them, rather than forcing something down them. Any other questions? Oh, please. Yeah. If we had to place bets on what might not be smart to have put into Drupal 8. Well, I mean, if you are someone who was of the mindset that, you know, headless Drupal and content API driven Drupal, I think that would be anything on the front end, right? Because if you have a template system like Twig, right, which we are as much improved over the original with the PHP template system that we're using right now, that system still isn't going to be sufficient for headless necessarily. I mean, it serves a better purpose and that you can take the content out of the site and be able to display that in the template system, but forcing any template system inside the CMS is going to make that a harder issue. There's two sides to that, though, because then what happens with those people that don't want to do that and they just want to run a Drupal site, then they don't have a theme layer? That doesn't work for people either. So I think that when you're working with a Drupal where you're catering to such a large audience, you have to knowingly make some decisions that you're like, right, this is the best thing that we've got right now, so let's go with that. And maybe that's not going to be the best decision later, but you can say that about anything. Hindsight's 20-20. I do think that what we have chosen to go in there makes a lot of sense. So I think that what we're going to do with the CMS libraries or however you want to manage that is a lot more maintainable than it was before. So those types of things I think are steps in the right direction. What's the state of external libraries in Drupal 8? Is Teo in the room? Is Teo Beata? No, he's not. I couldn't tell you as of the last two weeks. I don't know if that's changed about JavaScript. He's giving a core conversation of JavaScript in Drupal 8 core later this week. That would be a great question to ask him. Or not. He goes by not. Anybody else? Was your hand up over on the side somewhere? No? Okay. I don't think so. Would it be a good idea to put SAS into Drupal core? Who said no? Yeah, though. So that doesn't compile on the server side and things along those lines. I don't think that you can force those types of ideas onto a platform that runs that way. I think that that would be a step in the wrong direction in the same way. I think that forcing jQuery to run would be the wrong step as well. We've seen with the jQuery update that there's multiple ways to compile SAS. That's true. Yeah. So John said that there's multiple ways to compile SAS. You can compile it verbose, debugging, the way that SAS live. Or then what libraries do you have to run Compass? Are you going to force those types of things? Or are you going to run Scotch? I'm not going to force those types of things. I'm not going to force those types of things. I'm going to force those types of things as well. If you're going to go down the SAS route what else would you add? That's not always enough anyway. None is probably better than one in that case. Any more questions? Sorry. Anybody else going once? Great. Thank you very much for coming. Thank you, guys. Appreciate it.