We've got Morton DK diff killer We've got John Elbin world-class lover. Hey, we've got Piers Warmer symphony foreigner So this is the twig eight session. I'm not gonna say anything else. Oh everybody Does anyone want to do a different introduction? Should I just get this slide? Okay, we're all on Twitter if you want to like ask us questions to be clear that they were joking about HTML classes when they Gave me my title That is a complete lie John is actually a first-class lover All right skipping this slide So we wanted to start off First by talking about why we're changing the theme system in Drupal 8 And so I want to say there are some really positive things about the dreams through the theme system in Drupal 7 Mainly that you can do whatever the heck you want with it as long as you know what you're doing Unfortunately, there were a lot of negative things as well. So we'll talk a little bit about those first starters the Syntax of our template files only exists in the world of Drupal It started from PHP template, which was a templating language that existed elsewhere and in Drupal 7 we completely Changed it into something that didn't exist anywhere else by adding the existence of calls like render right from our template So this is something that people outside of Drupal aren't familiar with There's a really confusing way that we deal with variables or sometimes these variables are objects and sometimes there are rays And we reference them in different ways So if you're taking people who are non developers and trying to get them to use template files They need to understand data structures in a way that isn't really necessary for their normal everyday job So that's really confusing for new people When we print things in template files in Drupal 7 sometimes we just print the variable print classes Sometimes we print render a variable which is also really confusing because it sounds a little redundant But we do it all over the place in different ways And that's also really hard for people to get a handle on when can I just print something or when do I have to render it? So that's confusing for new people as well PHP template is just PHP PHP is not terribly secure So you can do horrible things from any template anywhere if you want to when I was preparing this slide I accidentally dropped my node table by refreshing the page. I was looking at so That didn't go so well Don't do that There's a lot of stuff in our existing theme system We have way too many template files in core alone if you wanted to remove all of your classes from places You've got a lot of work to do just to get to a clean starting point and to make things even worse We don't just have template files in Drupal 7 We also have theme functions and there are hundreds of theme functions So sometimes your HTML was coming from a template file some of it's coming from a theme function Trying to figure out where the source of this code is that you're frustrated with in your theme is sometimes really hard Just can't track it down this is a simplified version of The theme system in Drupal 7 so if you wanted to know what was being passed from one place to another Well, you're not gonna figure it out There's just too much stuff going on and this is this is kind of the nature of open source Where you start with one solution and a couple others later like oh we need this thing and then you add it And you're like oh we need this other thing you add that too And you know and then here you are 10 years later And you're like we have a lot of things going on and it's no wonder that nobody can figure this out John made the diagram. Do you want to talk a little bit about how you did this or why? Yeah, so I gave a core conversation Drupal Con San Francisco before Drupal 7 was released I'm like this is what we're dealing with right now like and I tried to do to do a 60-second overview of this entire thing And I got really close, but it was actually took me about 90 seconds to explain everything I'm interested for core developers and at the time I figured there were maybe two or three people in the entire world who understood this whole thing It's just massively massively evil And and it turned out there was other symbology also sort of embedded in this as well The next slide you don't have the other side. Okay, that's fine. This one's better So all of these things added up to Drupal being way too hard for new people to figure out how to learn And there's a lot of people who come to Drupal from other programming backgrounds are working in other areas of the web And the first place they try and change something is the theme system. They go, okay Well, I'm gonna install Drupal. Let's see if I can work in HTML. I know HTML That's the universal language of the web and they try and start with the theme system. They're like, oh my god I can't do this is really hard. There's stuff going on everywhere. I don't understand what this render thing is What is it? When is it an object? When is an array? How do I print it? Do I need to sanitize it or not? Where is it coming from? And it just it becomes a detriment to the rest of the good stuff The Drupal does that new people just can't get into it very easily. I'm a developer I started in the theme layer a lot of current core developers started in the theme layer That's just how you get into it and this should not be the most frustrating part of working with Drupal So here's this list of stuff that we wanted to fix in Drupal 8. The fact that our template files are Drupal specific We've got mixed data types. We've got different methods of printing stuff. PHP template itself is really insecure We've got two ways of overriding markup templates and theme functions We have too much stuff going on too much of both templates and theme functions We've got a really complicated mix of all of the subsystems that add up in the Drupal theme layer And that just makes everything way too hard to learn. So let's see if we can tackle this list of problems So in Drupal 8 the first thing we've decided to do is change our theme engine So instead of using PHP template, which we've had around for a really long time. We're gonna use something new called twig So twig is a well-documented open-source PHP templating language that most of you may or may not have heard of And it's already in existence in the internet. It's not something we're making up ourselves, which is good It's extensible. So if it doesn't do something that Drupal needs it to do We can write an extension for twig to make it work for Drupal and we have which is good It's secure in PHP templates. You cannot accidentally drop your node table You can't accidentally I will not accept patches that allow you to write SQL queries in your template files You can it will not be accepted.  We're not gonna let it into core GitHub does not count. Okay. It's also really well tested. There's a bunch of sites out there already using twig and it's unit tested It's also pretty fast compared to other templating languages out there. Obviously PHP is really fast It's it's faster than some other things you might have heard of like smarty Which we used to have in previous versions of Drupal, which is good It works in your ID.  It's really great And it's a recognizable syntax. So those of you are like, oh, no, I've got to learn something new to work with Drupal Don't worry. You can read it. It reads just like logic like English like other things you may have seen on the web So it's not going to be scary and foreign and anyone who's worked in any one of these languages before will just pick it up really easily It's also written by the same guy who wrote symphony, which is also in Drupal 8. So it works really well with that and there's a lot of Philosophies that jive really well with how we're doing everything else in Drupal, which is good So we had a sprint at the end of the Bay Area Drupal camp this year to try and figure out some principles That we should use when refactoring the entire theme layer in Drupal 8 The first one is that we want to start with nothing so Rather than having Overcomplicated assumption of what people might want to try and do we wanted to start with zero and add to it So this is like right now in Drupal you start with everything and try and remove what you don't want We're gonna try and turn that around the other way and start with only what we want if people want to div They can add themselves. We're not gonna put it in there for them You don't know if we're actually gonna get this done. This is what we want. These are the principles. It's what we want We're gonna build from use cases So right now in Drupal 7 we have built a system where anything is possible because we assume that someone will want to do everything at some point But we don't have any use cases to back that up We're like well Maybe someone might want to add this thing in this way and we'll just make it possible We're not gonna do that. We're gonna say look We know what people want 90% of the time and we're gonna build them that and if they have some crazy edge case and That 1% or 10% that comes up they can do it themselves We're not gonna put all of this complication in the core for the edge cases that don't we don't really know exist We're gonna provide tools so rather than Trying to solve everything from the beginning We're gonna solve the 90% use case and give that 10% the tools. They need to do what they want So you want to write an extension for twig you can do that But we're not gonna make it solve all the problem side of the box We're gonna try and consolidate stuff. We've got way too many template files and way too many theme functions Let's recycle. Let's use the same code to write an item list every time you write an item list Whether it's a menu or whether it's a well or a UL or whatever. It's just gonna be the same It's not gonna have different divs depending on where it's called same thing for tables We want to have some components that we can reuse throughout core rather than having every module provide its own markup Uh visibility we want people to know what's going on Twig is pretty good at this already when you look at something you can kind of tell what's going on But we don't want to abstract things We don't want to hide things we want everything to be able to be kind of guessable, right when you're like Oh, I need to override a menu. You're gonna instantly look for a menu template You're not gonna look for an item list template. So we're gonna give you a menu template Just stuff like that that makes Drupal a lot more intuitive rather than One place right have to go through system Kind of begins to make sense with where they are maybe instead of what we have now where we kind of have You have to go through system.  Yeah, so we're gonna try and make it a lot easier to find everything too. So We'll see how perfect that Is that a feature or is that? No, that's a task. Yeah, all right So we're also gonna try and make everything a lot more consistent right now Depending on which piece of content is coming out in which part of the page it can be rendered completely differently You can have its own style sheet. You can look really different. It can have you know extra divs or not If we can start to consolidate and use the same functions everywhere or templates Then the code will start to be the same everywhere, which makes it a lot easier for friend and developers to style like Oh, it's not this table. That's different from every other table. I can style all tables at once So hopefully that'll help a lot too And we're not gonna try and dump it down too much In Drupal 7 there's a lot of this like oh well femurs aren't gonna understand that But it turns out that like if we make something that makes sense they can learn it And if we make something that doesn't make sense, no one can learn it So we're gonna try not to dump it down when we don't have to sometimes They're really complicated problems and they require complicated solutions and we're just gonna do it And when a complicated solution is necessary, we're gonna trust that our friend community can learn it We're gonna make it easier, but I'm gonna do it And the last step is that the way stuff is organized needs to be driven by the semantics and not Like a programmatic deconstruction of what's being written in HTML a really good example is the item lists Right like there are two specific Elements for an unordered and an ordered list in spite of the fact that they both contain less items And there's a reason for those being separate in Drupal We had one function because the developers looked at it and thought oh it's an ally tag That's exactly the same either way. We'll just flip but it's semantically a different thing And so we need our code in the theme layer to produce markup Semantically the way front-end developers think about it and when things start to work the way people naturally think about them Everything will make a lot more sense Moving focus from being a System built by the developers or more system that makes sense to front-end developers. That's kind of the whole idea I know it's crazy talk, but it's that's kind of the whole idea We just figured out over the years that maybe it made more sense Maybe you could actually get more front-end developers into using Drupal because it made sense instead of giving them the content Variable as the only option in a note and they can then use the next four years of pitching and morning So we're hoping to make things work the way they're supposed to work and not the way developers think they should work All right, so who wants to see twig? All right, so I've got some examples of templates that we've already converted Some of these screenshots are a little old and they might have been changed since then but generally speaking Anytime you want to print a variable you use double curly braces to print it Anytime you want to run a command You use a skirly curly brace in a percent sign and you put your little logic inside there And anytime you want to add a comment. It's a curly brace in a pound sign to add a comment People like that comment So The syntax should be really simple and intuitive. It's very straightforward. It just says what it does Generally speaking All of our theme functions are going to be replaced with template files So there will only be one way to override markup from anywhere It is crazy, but it's going to be awesome And there's going to be a heck of a lot less code because as it turns out it takes a lot less code to just write HTML then it does to write a php function to produce HTML HTML and the curly brace twig stuff. Yeah You're out of luck. All right, so the username function just becomes a link tag or a span tag The image function just becomes an image tag The link function just becomes a link tag Right back back to sanity So so when you go to print something in twig It'll sanitize it for you like you can take any like node, right? And in in triple seven you were responsible if you wanted to pull something out of a field You've got to clean it up and make sure it was safe to display Because of this problem like 100% of all themes are insecure. It was a little rounding error in there, right? This is going to prevent that you will never have to sanitize your own data because twig does it for you So twig can handle the translating and sanitizing you just say print and it'll be like I know we need to take care of this for you so Twig will make everything a lot more secure because of that because we don't need to put that Responsibility into the hands of people maybe never seen Drupal before and that's important or any database driven system, right? Or don't care. This just says you can print it and it'll handle all that stuff for you It turns out this is an example of our theme item list function, which in Drupal 7 was really messy When you turn into twig, it's actually kind of elegant So Yes So we don't need to prepare variables in twig because it all happens instead of before you render the template While you're rendering the template so you can say print items and it'll spit them all out Or you can say print items dot item and it'll print out one or you can say print items content It'll print out whatever's inside that so there's everything should be drillable right now if you look at Drupal 8 it doesn't do that we haven't built all of the Flattening compress a complicated object into string functions in yet, but twig can do that and that's what we're shooting for So it's you should if you wanted to print a link inside a menu You should be able to write a template file and just print menu dot item dot link dot content and get only a piece of that out If you want and it'll be secure and it'll be safe to just drop that into your file It's not done yet, but that's what we're shooting for so We we don't know I want to kill them all But we need to make sure that before we Before we remove that tool that we have a comparable tool for front-end developers to be able to do the same thing You want to add a variable to your template file you want to change variable in that template file You've got to have a way to do it So right now what we're doing is taking all the logic out of template files and moving it into preprocess The next step is to take all the preprocess functions and turn them into twig rendering magic But we've got to make sure that there's a twig render magic alter Something right so that so that whoever's using a template file can still change what they need to change And we haven't figured that step out yet So right now I'm gonna say they're still gonna be preprocessed because we're not taking tools away. That's really important No, eventually. Yes before jubilee chips. I hope We'll see Okay, so here's all the problems of triple seven. Let's see if we've adjust some of these So triple specific template can make fun can functions. We've got twig it exists elsewhere in the world fixed Mixed data types. Sometimes we have a arrow. Sometimes we have square brackets all Template variables in twig. It doesn't matter whether it's an object or an array or string already are all printed in exactly the same way fixed Different methods of printing whether you print or print render guess what we've removed all calls to the render function from all templates in twig fixed PHP template being insecure twig will not let you run a sequel query without Alteration And we're not gonna let it do that in core automatically sanitized fixed Two ways to override markup templates and theme functions and way too many of both we're eliminating all theme functions So that'll only be one way and consolidating them at the same time fixed Too many of everything. We've got most of these Consolidated already, but there's some core issues. We can use some help on it. So if you're around this weekend, that'll get fixed shortly And our complicated mix of subsystem. Let's let's see how we're doing with that Here's where we started right where we had way too much stuff. We're removing theme functions That means all theme overrides are also going to be removed Which means in your custom theme you'll just be overriding templates. So that removes two layers already Process functions only existed for the purpose of flattening things like arrays into strings We don't need that twig can do that for us. So that's obviously out Render I'll cost a render been removed from template files.  You don't need to worry about render or Drupal render all that so that's gone hook page alter will go away because we're Switching to the blocks and layouts system. So it's going to be a little bit different how we deal with that But we won't have that as part of our theme system anymore either Pre-process functions I talked about we want to kill them We're not really sure whether we can or not at least in this release cycle Eventually we should be able to get rid of them entirely and that's a lot of pieces of our theme system They've been removed. It's a little better, right? Still has the kind of like satanic star there in the middle, but You're gonna rearrange the bubbles or something So that's a lot better Okay, so most things are fixed except for this whole difficult to learn thing We're hoping that'll get taken care of to by doing everything really consistently treating our theme functions the same treating our Styles and classes and div tags and all of that the same all across core if it's consistent people should be able to guess What's going on and that should make that better too So let's talk about some other awesome things that we may or may not be able to do with twig Do you want to talk a little bit about twig template inheritance? Okay So one of the really cool features of twig is the your ability to override Components of the templates. I'm not sure how this is intended to be implemented in a in dribble, but You have a right. Okay, so There's an ability for one template to inherit a super template Usually in a simple context as a layout so you can have a template describing maybe a feed of posts and that inheriting your site layout in turn And it doesn't in a very simple and elegant way I don't know if we've got an example of a template like that, but it is a relatively simple process of doing There's also an override. It's sort of a Hierarchy we can actually override templates have been placed into twig So should you need to override something like something? I'd imagine that twig would be being built into Drupal core like Display page you can write customizations over the top of that so you can really get Your own presentation layer working relatively easily. So, yeah So this idea of twig template inheritance, how many people have like a theme that has like Five or seven or 80 node TPLs in their theme? Yeah, so So my idea of how the the template inheritance could work would be basically you you have your one node TPL And then a lot of those other TPL files are basically this like one line that you want to change So you can mark up in the sort of the the base node TPL to say this section. I want to be able to change in my variants or What are the what are they called in twig? Yeah, yeah, so see yeah You mark this one section and say this is a part that I want to change and you call that a twig block Yay naming conflicts. Oh, anyway And then in your other node TPL file, you don't repeat every single line You just say okay, I'm inheriting from the node twig file And this is the one block that I want to change and when you go and open it it makes it's a lot clearer What's going on you don't have to do like a diff and see what's different between why is there so many node TPLs? It's really clear that I'm just changing this one bit This is all in my head. I don't There's really great code templates of everything on the twig page Which gone out. I open an issue to change the name of blocks in Drupal, but that didn't fly Yeah, we're just gonna call them a block it will bigger. Yeah, I don't know. Well, it's It's a code block It's really straightforward So Well, if you look at template files today, there's actually a lot of logic in there already There's a lot of like if this thing exists print it or if this is a whatever print that so we right now are doing Exactly the same thing in twig as we're doing in PHP template There will be ability to change that around a little when we have more twig stuff, but right now it's kind of the same So I just want to say it's like in Drupal 7 a lot of these times we have we have these things that are in the system already and like oh We have this other completely different idea and we have the system that needs that it's implemented in the same way that we need to like Get into the system So then they just like tack on this extra functionality like theme hook suggestions being done inside Pre-process functions, which is just supposed to be about variables suddenly you're changing the control flow of which Template file you're using inside a mechanism that was meant to be I'm just altering variables, right? That doesn't make a lot of sense that kind of what you're talking about or so Yeah, so so variables In twig files work completely differently than they work in PHP template because in PHP template You like have to go um does somebody want this variable? I know I'll go and like render it and create it or at least create a render array for it So they do all this work to create all these variables just in case The themeer wants to use it in twig. It's like okay I'm gonna tell the twig system that these variables can be made if you ask me to make them Right, and then when you render the template it goes. Oh, I actually do need this variable and then go and grab it There's a huge Potential performance gain because right now what we're doing is a little bit wasteful with all of this preparation of variables That may never get printed to the page or with twig. It's kind of a Inside out as opposed to an outside-in process where you wait until the template file gets rendered and then twig says what's in this template file? Oh, it's this variable Let me go make that for you Whereas PHP template was like let me make all these variables and then when they're called we'll just spit them out So that's part of why we can get rid of pre process is because that whole phase of preparing stuff doesn't need to exist anymore We just need to make sure what was that? Right, it's like a mid-process right like while we're printing stuff we'll make it and in and PHP PHP template was was kind of sloppy and how it did all of this twig is really elegant and that all of your template files get compiled Into classes and they can get saved in memory Which could also be really fast too if you have one node with 300 comments on it in PHP template That file needs to get read from disk 300 times and have those variables inserted or if you're using a PC It gets stat 300 times and that's expensive if you have a class in memory you just execute it 300 times And that's really fast So this is the kind of thing where like it says much TBD because we have actually haven't had enough of it done to do any Legitimate benchmarking, but there's a potential here for a huge gain not only in performance But in like the amount of memory it takes to build a page right when you have a giant render array That's sitting there waiting for parts of it to be rendered or maybe all of it depending on which part of the cycle You're in it. It's messy But here you're just like you know We don't need any of that until the time that we render it and then we can go and get only what we need and print That's a page so it will be really nice We can get all this other stuff out of there So in Drupal 8 we're gonna have this concept of context that'll exist all the time and we haven't actually done a lot of work with the Blocks and layouts people to figure out how twig will have access to that But we know that it will so there will be a bunch of stuff That's available in kind of a global context that you can use to figure out like who's looking at the page How does it need to be displayed? Is this going to like a web services request or is it being printed to a browser? Like is it mobile or not like there's a bunch of factors that go into that like Global context of how this content should be created that twig can then use to print things differently even so It could be really cool. We haven't built it yet And then this last bullet point this is gonna exist in in contrib only so don't get too excited But we were talking about this in Munich where it's possible for the first time in history For your Drupal site to be aware of what's going on in your template files So right now if you're a themeer and you're like why are there all these if statements to see if variables are set before Stuff's getting printed. I don't care whether somebody went to the system page and like changed my whatever I'm just gonna print what I want to print and what that does is it breaks the Drupal's interface, right? Like I said no, I don't want a menu here And it's like well it printed anyway because I removed the if test in my template file to see if it was Supposed to print or not so now your interface is broken and that can be really frustrated Frustrating for for end users not to understand that their theme isn't respecting these Drupal settings Well now we have the ability for the theme to read the template files and say hey This is getting printed whether that setting is set or not So I'm gonna disable the user interface so that whoever's looking at this page doesn't think they can turn off the menu Or doesn't think they can turn off the user pictures or whatever it is And then you're six times on the down the boat the clients come back and want to change something in the on the note page And want to drag it around or you forgot that you kind of custom-built everything in this this note TPL and Instead of using this couple of hours to figure out why is my cash not clearing this data out and so forth and so forth We can actually make this magic land of unicorns where we can have an idea of what actually goes on So if you take this one step further and say okay Well if the user interface can be based on the template files, maybe we can just write the template files first Okay, that's the reaction.  I've created everything you need to match that Yeah, yeah, that's the that's the possible performance gains thing. Yeah So I mean menus are cached anyways. That's not a big deal, but there are things like that that are going to be Yeah But that actually it's down to when we're talking about how to get new people into this I mean the first reaction you got when you come into looking at these tpl files Well, where does all this crap come from instead of I have this ideal markup I know works in old browsers and every mobile phone and blah blah blah so you can actually now have new people coming in that doesn't know the magic of Drupal and No, just write them markup and make this no Double curly bracket kind of thing put the title in here like every other same template system would do so it's Kind of when we're talking about the Is this going to be hard for new people to learn we kind of expect it to be natural to learn it like hey Write your markup and put your variables in and you're done kind of magic way Well, um Well, I know at some some frontend meetups everyone we will have hard Hard time to find issues to bitch and moan about so we need to like change that way of communicating I know that the sql module that's kind of come out and get help will help us with that but still Yeah I've been developing php for a long time and when I approach Drupal it seems very very foreign to me So I'm trying to tie this into the broader community. I'm just going to have a few wins to drag New people into the Drupal world All right. All right. So one one one last thing on our ball list here's the second one is um We're going to try and build some really awesome variable inspector So if you get a template that says menu, you don't really know what's in that menu You can say hey twig. What's in this menu? And it'll be like here all of the variables that you can print and it'll work a little bit We hope like the token drill system right now or you're like, oh look, there's a node And you click on it and it's like here's all the stuff in the node and you can click through So this is one of these things we were hoping to get done by two weeks from now So if anyone wants to work on that this weekend, we're going to be sprinting and you can help us But um that that can definitely get in I think even maybe We can sell it we can get it in after but um, so we're hoping to make it really easy for people to figure out What they can do in their files So this whole thing like I actually wrote a new theme layer for Drupal called token template that did exactly that Um, but there's a lot of reasons a lot of people didn't like that Um, so what we're going to end up doing is there's a lot of similarities between like tokens flatten and sanitize and produce output And so we can use all of the functions that we're using in tokens to flatten and sanitize output in the render system Um, so there'll be recycling right where we don't have to rewrite a lot of the stuff because it already exists But we're not actually using token. That's also kind of a Drupalism, right? Whereas we'd rather just use twig the way it does it So the the decision of whether we would use twig or like token template or something We had a sprint that Jen helped organize last march Was it so less than a year ago? And we we spent like three days just like going over all the different problems and you know, that's where the slides were What are the problems? What are how can we solve all those problems? And then we started looking at systems that could help us solve those systems when we looked at twig. We're like, okay Yeah, check check check check. It's like, okay Interesting thing is that that normally what the way this has been done in Drupal world is a bunch of developers sit down in the room and decide something great in developer land and then a year and a half later they give that to front-end land and The peasants will rise and again scream at the developers and we did it another way around We had a conference in in Amsterdam at that same way the same weekend front end the first front end united where we basically had no I was expecting three people to show up to the code spend and we had About 80 people showing up all in all and 15 to 20 people actually sitting down and just say, okay Let's identify what our real problem is. We then sent that to San Francisco.  And So I I immediately did not like render system at all But it was just me and all these developers and there wasn't any other Theme people who are sort of in the queue and active and it was like it was way too late by the time it already was in Drupal 7 like So this time we decided okay, let's get developers and front end developers in the same room So we had we had chx. We had effulgencia on skype like 24 hours. Um, we had Chris van der water who's the blocks and layouts initiative lead myself gen And and then we actually opened up Google plus hangout or Oh, yeah, it was way back So when we had all these other front end developers who who joined in remotely And so all of us together came up with the twig solution When we talked about the first day we actually had a demo of a dude who did actually a version of my theme The mothership Renamed it to the mother trick and actually implemented trick into it and shows us the demo of it because people are like No, we don't need anything new. We just need something clean. And then we saw that especially the block things.  When can we get that john john? Can I get that? Um, no, so what actually happened on the last day of this conference We kind of saw what was coming out of san francisco and like Okay, let's just figure out if people actually likes this So we should actually push forward with it or should we just like hide in the hole and it was kind of a room this size of people There was actually interesting sessions going on at this point It was just kind of hey We're gonna brief you about what they did in san francisco and The kind of feeling got already at that point so early on the process that this was exactly what people have been Waiting for and which kind of made me feel happy because I just thought it was me who was being a little bit for six years It wasn't That would have been perfect So this was in munich where we had this session and we're like did people actually want this like is what we want and everyone Wanted it and it was like oh Well, we can do that too So so that's another thing, right? We haven't mentioned that yet But like we can't have like some people use wordpress right and there's like these editors where you can like open up like Here's your style sheet. Here's your template and you can like actually edit them in your browser We can't do that in php template because it's horribly insecure to expose php code in the browser But twig code is safe. We can do that It won't we want to in core but in contrib someone can write a module that gives you a ui that lets you edit all your stuff Does anybody remember the contemplate module? Yeah, don't use that But if it got converted to be twig based it would be perfectly acceptable solution you can install it into blade So contemplate can get this It can come back. Yeah Yeah, so there's a bunch of really stuff you can you can use twig for email templates. There's also like a java script Uh framework like twig js, I guess so that you can use your node template Whether that knows node is rendered like in php on your server or whether it's rendered like client side In some kind of external thing. So there's a lot of really awesome places where twig can be recycled everywhere What do you say? Feel are there is so is there any big change to field for matters? Well, I mean the biggest change is that there's no theme functions anymore, right? So all of your formatters will be using template files I mean we're doing a lot of work on field templates anyway because they're so bad, but So, um, it's a really great question field for matters. Um, I know a little bit about them But why don't you come to the sprint and you and I can talk and We'll figure that out the answer. Okay All right, so speaking of how people can help us um, we've got a lot of uh Stuff that we've completed right like we've got a bunch of template files that need to be converted to twig Which is in our done in our sandbox, but we need to move that to core Um, we've got to convert some more theme functions. I think there's like 20 left or something There's not very many um into template files and there's some pretty good documentation on how to do that Um, we've got to create and test patches against core So we're trying to take all of the work that we've already done and just put it into core Really fast because we've got two weeks to do it Um, and we can use a lot of help with that so if you can write patches We need you in that room um on saturday and then we also have uh, A bunch of people want to clean up the markup that's in core John is going to be sprinting on cleaning up the css So it may be really good to have people want to clean up the markup working with people want to clean up the css We don't break everything at the same time, which is good. Um, and we have uh issues where you can just write html You don't need to write a patch don't need an install dribble. You just want to show me the html You want tell us what you want and then we can fix it We are actually trying to figure out What is it? What kind of markup is it that we as Knowledge of people who knows the front end and how browsers Interact with it. What is it that we need instead of going the other way around? I know it's kind of in Drupal and it's against everything that we have always thought that were And it's kind of a revolution and we can see the red flags and how the people storm towards the castle We kind of need people to do that. I mean, it's I mean We are like four or five people and I got hit by all kinds of stuff the last two months So I didn't have the time to do it and we A lot of this is just sitting down and actually just No walking through the templates and figure out. What is it that I want to have here? How is there how is that my menu should look how should this list thing looks how should that thing look? I mean, it's just defining it so we can actually pass it Further down to people who know how to get this thing into code That's kind of one of the most Important things at this point and and the problem is that Well, I pretty much have hackled John for a couple of years because he was responsible for the evilness in Drupal 7 and John has now passed the torch down to me because apparently I have been the Loudest about everything that's been wrong. So apparently now everything that's going to be wrong in Drupal 8 is going to be my fault, right? So I know I think myself are being brilliant, but I'm pretty sure I'm not that clever So I need some people to help me take the fall down Which means We need more than one face to look at the marker or look at the code and look at the css. I mean John has an excellent post right now Waiting around the hole. How do we name css if he makes any mistakes right now and that stuff gets into core We're gonna be burned down with that crap for years I mean that's I mean that's that's the problem. You make one tiny mistake now And we're gonna have a lot of fun with that each and every day for the next couple of years So is this sprint tomorrow gonna be titled responsibility shared? No Yeah, it's actually it's um actually I am I have a session later today that's kind of tried to wrap up, you know Everything why stuff started out as it did and why we've ended up in this kind of it's not a nightmare Maybe because we have no learned to work around with it, but this kind of Maybe I've just been here so long. So it's not a nightmare for me anymore because I'm from from scandinavia. So it's just always dark Maybe that's the thing and being down here in the sun is kind of like That yellow thing out there. I'm getting a little bit frightened of anyways We the thing is that right now we have for the first time actually an idea of Holy crap developers are listening to funding developers.  Okay, so what we need to do is get all the front-end developers Yeah, he's got sessions after So if any of you are front-end developers and have opinions on what we should be doing in Drupal We need your input. Tell us what you want and we can try to make some changes Um, we've got to configure how to consolidate more of our template files We've got issues against almost everything in core, but we need people to write patches and people to test patches We need people to log on and just say I agree with this whatever Just so the core people know it's important. Um, and then we also need to be able to rethink the template suggestion process There's a really complicated issue So if you're a super developer and want to figure out how to solve some really hard problems There's some issues around that as well And then we want to make it really easy to change your template files in different places There's a patch for that too and then the last thing is trying to figure out how to to redo preprocess Which this is not urgent But we need people to start thinking about it because there's a lot of work to do once we figure out what we're going to do And then we've got to start converting things all into twig format too. So there's a lot of stuff We're going to be doing at the sprint on saturday So everybody put your hand up if you've written html or css or javascript before Keep them up everybody keep them up.  Okay, everybody with their hand up come along to that one so the the html 5 initiative is basically finished up already and I'm I'm pretty sure aria is in the templophiles already Um, so they just came along for the ride when they got converted to twig So we're doing a subset of the list. We just talked about tomorrow the sprint. So if you want to come out We need you Um, and we've got maybe like five minutes for questions. I think we did that already We're trying to get away from that right, but but yeah, so the the the problem so The thing that the magic that happens in the background is basically it is a new syntax, right? It's this twig syntax, which has been around for a while a lot of other projects are developing or using the same Syntax even though they're not using the twig syntax or they're not using the twig system. They still have the same syntax um But the the magic in the background for the twig system is that it takes that syntax. Um, and it actually Converts it it it compiles it from that into an actual php snippet of code and then caches that Right, so when you're actually loading a page, you're not even looking at the twig files anymore You're just pulling up these php snippets that are So So Yeah, and I would just say that that as a templating language php sucks I don't believe I I don't think that it prevents anything. Um, it has all the control structures that actually So it provides all the regular control structures that you would expect loops If condition statements and all that and you can also go one step further and actually tell twig Which of those control control structures you want it to be able to give the front end developers access to so you can modify that Yeah, a template engine. We can just use php php is a template language and back then I I think it was like seven or eight years ago. There were there were template engines around, you know, there was smarty and others um What do you say to that? How is it different today? Why is twig a better option? um Why did we decide php was the template language for us and now a template language is the template language for us? Yeah Yeah, so I've been doing dribble for eight years now and I remember this is adrian russo who came up with the php template language And if you look at the alternatives at the time smarty Was not the smarty it is today, right? It was really Well, yeah You know that it wasn't until like three or four years later that another template language. It was developed called Oh, what the heck was it? It was the opposite. It had an opposite name of smarty. Does anybody remember this? It wasn't dummy. It was like um Yeah, it was something similar to that It was it was called dummy because it was like i'm trying to not do all the stupid stuff that smarty is doing um They weren't written in a way that was actually particularly fast They were very slow because they were trying to interpret their own syntax on the fly every time you requested them So php template was a really good alternative to those templating languages at the time But A lot of really new stuff in php, right? Where we couldn't have used it in dribble six because dribble six didn't support a new enough version of php To do all the stuff that twig does so now we have cool new toys and someone wrote a template language that uses the cool New toys and makes it perform it twig is object oriented. It's it's really fast There's like a bunch of stuff that we can do with swig that we can't do in php template We can sanitize everything automatically we can run functions like t so developers don't have to we can No one has to understand data structures like there's just a lot of places where We come out on top So it was one of these things where like yeah, we solved this problem years ago But technology advances fast So let's reevaluate this problem and the solutions that are out there and think about it again This is the perfect end solution for everything. It's kind of Chicks kind of came up with twig first and tried to hunt people down and then we're doing the code sprint where Agents theme system pretty much got killed over a table And the reason that chicks wanted to have in because this whole sandboxing thing and No, other of us just want to have an easy way to draw down to variable So it's kind of a match made of as much other technology got. Hey, I get my little thing in I get my little thing and I get my little thing and you have this bastard child But then suddenly we figured the bastard child here is actually Somebody voted for us and we can use it and everybody seems to be happy at this point in three years We will probably be angry as hell So I actually I didn't want twig I thought php was much better and we should just all sanitize our own variables and do whatever in php But it turns out that everybody else wanted twig and I was like well if everyone is happy with this solution Then that's obviously the way we should move forward Yeah And I would just like to add that I was also not a fan of twig when we went into that sprint deciding what we were going to do I was like, okay I don't I don't think we want to go to another scripting language, right? and When we went through the problem space and went through the possible solutions then twig just became an obvious choice Scott Yeah, just a really quick question. Um, I've never used twig before but I have used liquid Are they like is liquid based on twig? Those who are familiar with yeah liquid syntax and things like Shopify and Um, it looks really familiar like very much to say are they in the same family? So you're using jekyll or something like that with liquid layouts or Right, okay, so yeah, I don't know which one came first. I think they were actually um in conjunction because um, so jekyll's off a um ruby Platform and they both have shared from Django. I think the Django heritage. So yeah similar heritage I think one of the things that Is really important about this is actually Really from outside the Drupal world and I think that's something that sometimes we forget but if you look at Happy cog if you look at clear left if you look at some of the the very best thinkers in the wider web world The reasons they've stayed away from something like Drupal is because it doesn't give them the control over What's coming out of it? And this is finally a chance to actually use Something similar to expression engine or some of these other platforms that do do a very good job of it While still keeping what's important about Drupal with the flexibility of the content modeling and everything else so I mean, I don't I'm not enough of a developer to have that great an opinion of the technical merits But just in order to put it on a level playing field and make it the platform that someone like Jeremy Keith would pick up And use I think that's an admirable goal and it's worth it One thing I just want to kind of keep in perspective is that we keep talking about like twig exists elsewhere in the world But there are less front-end developers that know twig than there are front-end developers that know Drupal So we do kind of need to keep that in check and be like, oh, it exists, but it's like, yeah, you know But It's I mean, it's probably the easiest language I've ever written ever ever it's it's like Oh, let me just get this loop right.  Yeah, so it's you know, it's I mean It's going to be I don't think we're going to have any problem with that That was actually one of the ground rules the thing about not dumbing it down that this whole I mean It might go we might going to have some menu tpl files It's going to be hellish to look at but instead of trying to drag that variable out of thing there and figure out Where does that come from we kind of can see it now or drill down through it or print it out on the page instead of the way Wouldn't it be nice of core? Was your good base theme? You guys can work on dribble nine I already have a dribble nine module out so Where it was the kind of thing where like I was writing something and someone's like, hey, have you heard of this now? I was like, no So it definitely wasn't in the front of our mind But it's the kind of thing where it's like I can totally see that as a contrib thing for someone comes out with a module And it's like ta-da everything works the way you wanted to So it's definitely like this is one of these things where when we first decided on twig we had a very limited Set of requirements and then as we've been working with it. It's like, oh, we also get this we also get this We also get this we also get this and there's just this all the stuff that you can do that We didn't even think about it. Yeah, and I mean this is exactly what's great about open source Of course, right? So because the more people who are contributing to it the more solutions that you end up with so Instead of just Drupal developers working on the twig system We have all these like other people who are also using the twig system and we end up with a better More, you know more robust more flexible system than we could have come up with ourselves The thing that we came up with by ourselves was Drupal 7th's theme system, right? It's probably going to be the same issue I mean, so there's a bunch of like licensing inclusion stuff that we haven't quite figured out where like Drupal has a set of Rules but likely break them when we feel like it Um, I think that what's going to happen is Drupal 7th's going to ship with whatever version of twig ships with and then there's going to be At some point a new version of twig and then there's going to be a contrib module that'll help update it It's a little harder because it's so ingrained in everything that Drupal does Like when you get a new version of jQuery, you have to provide all of the new functions that rewrite It's going to be the same thing only a lot more work Um, so we'll we'll see I mean it could be that you know Drupal 7th's around for two year or Drupal 8th's around for two years And we've got to deal with it for two years, but I don't know if someone gets angry enough. They'll write something I I think that's an excellent question because it makes me think of something that I hadn't thought of before So the problem with jQuery the reason why we couldn't update to jQuery was because we'd written our you know Our libraries built on top of jQuery In a way that wasn't really the best practices and so they were really tied to that specific version of jQuery And when you had the new version of jQuery, then we would have essentially would have to rewrite all of our jQuery stuff So, uh, I think that we need to be really careful with the way we write our filters Because those are the things that we're tying heavily to the way twig works right now and if that you know system changes so, um This would be an excellent question to like ask trees or ask the other initiative leads at the drupal 8 Core conversation later this afternoon Because it's not just twig. It's all these other symphony components that that complies to Sorry, there's a little extension on that. Um, the symphony community is really aware about how these components are being integrated into other projects So backwards compatibility and making sure upgrades don't break. What's what how people are using them is a really High priority for the community Okay, we're we're out of time. It's lunchtime now though So if you want to grab these guys before you leave and force them to not have lunch otherwise thank our team For a great conversation and please do consider coming to the code sprint tomorrow or the how to Contribute session tomorrow


From theCUBE Studios in Palo Alto in Boston, bringing you data-driven insights from theCUBE and ETR. This is Breaking Analysis with Dave Vellante. If it weren't for Pat Gelsinger, Intel's future would be a disaster. Even with his clear vision, fantastic leadership, deep technical and business acumen, and amazing positivity, the company's future is in serious jeopardy. It's the same story we've been telling for years. Volume is king in the semiconductor industry and Intel no longer is the volume leader. Despite Intel's efforts to change that dynamic with several recent moves, including making another go in its foundry business, the company is years away from reversing its lagging position relative to today's leading foundries and design shops. Intel's best chance to survive as a leader in our view will come from a combination of a massive market, continued supply constraints, government money and luck, perhaps in the form of a deal with Apple in the midterm. Hello and welcome to this week's Wikibon Cube Insights powered by ETR. In this Breaking Analysis, we'll update you on our latest assessment of Intel's competitive position and unpack nuggets from the company's February investor conference. Let's go back in history a bit and review what we said in the early 2010s. If you follow this program, you know that our David Floyer sounded the alarm for Intel as far back as 2012, the year after PC volumes peaked. Yes, they've ticked up a bit in the past couple of years, but they pale in comparison to the volumes that the ARM ecosystem is producing. The world has changed from people entering data into machines and now it's machines that are driving all the data. Data volumes in Web 1.0 were largely driven by keystrokes and clicks. Web 3.0 is going to be driven by machines entering data into sensors, cameras, other edge devices are going to drive enormous data volumes and processing power to boot. Every windmill, every factory device, every consumer device, every car will require processing at the edge to run AI, facial recognition, inference and data intensive workloads. And the volume of this space compared to PCs and even the iPhone itself is about to be dwarfed with an explosion of devices. Intel is not well positioned for this new world in our view. Intel has to catch up on process, Intel has to catch up on architecture, Intel has to play catch up on security, Intel has to play catch up on volume. The ARM ecosystem has cumulatively shipped 200 billion chips to date and is shipping 10x Intel's wafer volume. Intel has to have an architecture that accommodates much more diversity and while it's working on that, it's years behind. Now all that said, Pat Gelsinger is doing everything he can and more to close the gap. Here's a partial list of the moves that Pat is making. A year ago he announced IDM 2.0, a new integrated device manufacturing strategy that opened up its world to partners for manufacturing and other innovation. Intel has restructured, reorganized and many executives are boomeranged back in, many previous Intel execs. They understand the business and have a deep passion to help the company regain its prominence. As part of the IDM 2.0 announcement, Intel created, recreated if you will, a foundry division and recently acquired tower, semiconductor, an Israeli firm that is going to help it in that mission. It's opening up partnerships with alternative processor manufacturers and designers and the company has announced major investments in CAPEX to build out foundry capacity. Intel is going to spin out Mobileye, a company that acquired for $15 billion in 2017. Where does they're trying to get a $50 billion evaluation? Mobileye has about a $1.4 billion in revenue and it's likely going to be worth more around $25 to $30 billion, we'll see. But Intel is going to maybe get $10 billion in cash from that, that spin out that IPO and it can use that to fund more fabs and more equipment. Intel is leveraging its 19,000 software engineers to move up the stack and sell more subscriptions and high margin software, you got to sell what you got.  Again, there's no doubt that Pat is moving fast and doing the right things. Here's Pat at his investor event in a T-shirt that says Torrid, bringing back the Torrid pace and discipline that Intel is used to. And on the right is Pat at the State of the Union address looking sharp in shirt and tie and suit. And he has said, a bet on Intel is a hedge against geopolitical instability in the world. That's just so good. To that statement, he showed this chart at his investor meeting, basically it shows that Western semiconductor manufacturing capacity has gone from 80% of the world's volume to 20%. He wants to get it back to 50% by 2030 and reset supply chains in a market that has become important as oil. Again, just brilliant positioning and pushing all the right hot buttons. Here's a slide underscoring that commitment showing manufacturing facilities around the world with new capacity coming online in the next years in Ohio and the EU. Mentioning the CHIPS Act in his presentation in the US and Europe as part of a public-private partnership, no doubt he's gonna need all the help he can get. Now we couldn't resist, the chart on the left here shows the way for starts and transistor capacity growth for Intel over time speaks to its volume aspirations but we couldn't help notice that the shape of the curve is somewhat misleading because it shows a two-year comparison and then widens the aperture to three years to make the curve look steeper, fun with numbers. Okay, maybe a little nitpick but these are some of the telling nuggets we pulled from the investor day and they're important. Another nitpick is in our view, we would be a better measure of volume than transistors. It's like a company saying we ship 20% more exabytes or MIPS this year than last year. Of course you did and your revenue shrank. Anyway, Pat went through a detailed analysis of the various Intel businesses and promised mid to high double-digit growth by 2026. Half of which will come from Intel's traditional PC, a center and network edge businesses and the rest from advanced graphics, HPC, Mobileye and Foundry. Okay, that sounds pretty good but it has to be taken into context of the balance of the semiconductor industry and this would be a pretty competitive growth rate in our view, especially for a 70 plus billion dollar company. So kudos to Pat for sticking his neck out on this one but again, the promise is several years away, at least four years away. Now we want to focus on Foundry because that's the only way Intel is going to get back into the volume game and the volume necessary for the company to compete. Pat built this slide showing the baby blue for today's Foundry business at just under a billion dollars adding in another 1.5 billion dollars for the Israeli firm that it just acquired. So a few billion dollars in the near-term future for the Foundry business and then by 2026 this really fuzzy blue bar. Now remember TSM is the new volume leader and is a 50 billion dollar company growing. So there's definitely a market there that it can go after and adding in arm processes to the mix and opening up and partnering with the ecosystems out there can only help volume if Intel can win that business. It should be able to given the likelihood of long-term supply constraints. But we remain skeptical. This is another chart Pat showed which makes the case that Foundry and IDM 2.0 will allow expensive assets to have a longer useful life, okay that's cool. And we'll also solve the cumulative output problem highlighted in the bottom right. We've talked at length about Wright's Law that is for every cumulative doubling of units manufactured cost will fall by a constant percentage. You know let's say around 15% in the semiconductor world which is vitally important to accommodate next generation chips which are always more expensive at the start of the cycle. So you need that 15% cost buffer to jump curves and make any money. So let's unpack this a bit. You know does this chart at the bottom right address our Wright's Law concerns i.e. that Intel can't take advantage of Wright's Law cause it can't double cumulative output. Fast enough. Now note the decline in wafer starts and then the slight uptick and then the flattening. It's hard to tell what years we're talking about here. Intel's not going to share the sausage making because it's probably not pretty but you can see on the bottom left the flattening of the cumulative output curve in IDM 1.0 otherwise known as the death spiral. Okay back to the power of Wright's Law. Now assume for a second that wafer density doesn't grow. It does but just work with us for a second. Let's say you produce 50 million units per year just making a number up. That gets you cumulative output to $100 million in you sorry 100 million units in the second year. So it takes you two years to get to that 100 million. So in other words it takes two years to lower your manufacturing costs by let's say roughly 15%. Now assuming you can get wafer volumes to be flat which that chart showed with good yields you're at 150 now in year three, 200 in year four, 250 in year five, 300 in year six. Now that's four years before you can take advantage of Wright's Law. You keep going at that flat wafer start and that simplifying assumption we made at the start and $50 million units a year. And well you get to the point. You get the point. It's now eight years before you can get to Wright's Law to kick in and by then you're cooked. But now you can grow the density of transistors on a chip, right? Yes of course. So let's come back to Moore's Law. The graphic on the left says that all the growth is in the new stuff. Totally agree with that. Huge tam that Pat presented. Now he also said that until we exhaust the periodic table of elements, Moore's Law is alive and well. And Intel is the steward of Moore's Law. Okay that's cool. The chart on the right shows Intel going from 100 billion transistors today to a trillion by 2030. Hold that thought. So Intel is assuming that we'll keep up with Moore's Law meaning a doubling of transistors every let's say two years. And I believe it. So bring that back to Wright's Law in the previous chart. It means with IDM 2.0, Intel can get back to enjoying the benefits of Wright's Law every two years. Let's say versus IDM 1.0 where they were failing to keep up. Okay so Intel is saved, yeah? Well let's bring into this discussion one of our favorite examples. Apple's M1 ARM based chip. The M1 Ultra is a new architecture. And you can see the stats here. 114 billion transistors on a five nanometer process and all the other stats. The M1 Ultra has two chips. They're bonded together. And Apple put an interposer between the two chips. An interposer is a pathway that allows electrical signals to pass through it onto another chip. It's a super fast connection. You can see 2.5 terabytes per second. But the brilliance is the two chips act as a single chip. So you don't have to change the software at all. The way Intel's architecture works is it takes two different chips on a substrate and then each has its own memory. The memory's not shared. Apple shares the memory for the CPU, the NPU, the GPU. All of it is shared meaning it needs no change in software unlike Intel. Now Intel is working on a new architecture but Apple and others are way ahead. Now let's make this really straightforward. The original Apple M1 had 16 billion transistors per chip. And you could see in that diagram the recently launched M1 Ultra has $114 billion per chip. Now if you take into account the size of the chips which are increasing and the increase in the number of transistors per chip that transistor density, that's a factor of around six X growth in transistor density per chip in 18 months. Remember Intel assuming the results in the two previous charts that we showed, assuming they're achievable, is running at two X every two years versus six X for the competition. And AMD and Nvidia are close to that as well because they could take advantage of TSM's learning curve. So in the previous chart with Moore's law alive and well Intel gets to a trillion transistors by 2030. The Apple, ARM and Nvidia ecosystems will arrive at that point years ahead of Intel. That means lower costs and significantly better competitive advantage. Okay, so where does that leave Intel? The story is really not resonating with investors and hasn't for a while. On February 18th, the day after its investor meeting the stock was off, it's rebounded a little bit and investors are, you know, they're probably prudent to wait unless they have really a long-term view and you can see Intel's performance relative to some of the major competitors. You know, Pat talked about five nodes in four years. He made a big deal out of that and he shared proof points with Alder Lake and Meteor Lake and other nodes but Intel just delayed Granite Rapids last month that pushed it out from 2023 to 2024. And it told investors that we're going to have to boost spending to turn this ship around which is absolutely the case and that delay in chips, I feel like the first disappointment won't be the last but as we've said many times, it's very difficult. Actually, it's impossible to quickly catch up in semiconductors and Intel will never catch up without volume. So we'll leave you with biiterating our scenario that could save Intel and that's if its foundry business can eventually win back Apple to supercharge its volume story. It's going to be tough to wrestle that business away from TSM especially as TSM is setting up shop in Arizona with U.S. manufacturing, that's going to placate the U.S. government. Look, maybe the government cuts a deal with Apple. It says, maybe we'll back off with the DOJ and FTC as part of the and as part of the Chips Act, you'll have to throw some business at Intel. Would that be enough when combined with other foundry opportunities Intel could theoretically produce? Maybe, but from this vantage point, it's very unlikely Intel will gain back its true number one leadership position. If it were really paranoid back when David Floyer sounded the alarm 10 years ago, yeah, that might have made a pretty big difference but honestly, the best we can hope for is Intel's strategy and execution allows it to get competitive volumes by the end of the decade and this national treasure survives to fight for its leadership position in the 2030s because it would take a miracle for that to happen in the 2020s. Okay, that's it for today. Thanks to David Floyer for his contributions to this research, always a pleasure working with David. Stephanie Chan helps me do much of the background research for breaking analysis and works with our CUBE editorial team, Kristen Martin and Cheryl Knight to get the word out and thanks to Silicon Angles editor and chief Rob Hoth who comes up with a lot of the great titles that we have for breaking analysis and gets the word out to the Silicon Angle audience. Thanks guys, great teamwork. Remember, these episodes are all available as podcasts wherever you listen, just search breaking analysis podcast. You'll want to check out ETR's website at ETR.ai. We also publish a full report every week on wikibon.com and siliconangle.com. You can always get in touch with me and email David.Valante at siliconangle.com or DM me at dvalante comment on my LinkedIn post. This is Dave Valante for theCUBE Insights powered by ETR. Have a great week, stay safe, be well and we'll see you next time.