 Yeah, twig is dead long live web components. I just named it that so that I control Morton You know because you've been working so hard at getting twig into into Drupal 8 and I Actually think that you know adding web components to like Drupal 9 maybe would be Not something that would necessarily replace twig. It would be more like augmented. I would think of somehow But that That's what I'm gonna have I want to have like a big conversation with people about stuff because I don't actually have like a lot Of really good answers. I have a lot of really good questions, right? so I Know that there are a bunch of people who are not able to tend Austin and want to see videos of all the core conversations Those people are gonna be really disappointed with this recording because About five minutes into it. I'm gonna stop talking into the mic and just talking with everybody You don't need to line up to have the conversation with me and talking to the mic. We're just gonna be Talking all at once. That's what I vision sort of old-school core conversation Well, that's really annoying that Let me stop it doing that, okay But yeah So I told people that I would give a super brief intro to web components Just so we're all on the same page. Even if you don't know anything about web components, right? So The I've got these some resources here CSS tricks, there's an article you can read. This is a great article It really gave a really good overview of everything that goes web components.org is probably the best place you can go right now to Keep current with things that are going on with web components and then the mark sonam I'm told me about this thing called React that Facebook just recently did and it's not web components in fact is sort of explicitly trying to Be an alternative to web components because they're not quite sure that web components make sense because of the DOM heavy nature of Doing web components requires use of the DOM and the DOM is very sort of heavy heavy system compared to a very lightweight JavaScript system which they built with react. I think Mark is gonna come back He was you had to go to barbecue for lunch. So he's gonna be late And then like if you guys have more resources, I'll just like add them to this slide and then post the slides later But so Here's web components.org If you went to my talk yesterday about design components, I basically just described web components as This back author sort of getting together and saying hey, you know Web developers really like templating systems, you know, there's handlebars and there's php and you know, even ASP whatever They like templating systems and we we should really add that natively to the HTML spec itself so that you can basically specify a You know a sort of snippet of HTML instead of a page of HTML Which is kind of what's required around now as far as the spec goes You have these like snippets of HTML and JavaScript and CSS are sort of combined into this thing Called a web component and then you can use those as templates to You know insert your actual data into those Those web components those those templating system and it's it's built sort of natively into the the HTML spec So Web component is that or gives a really good high-level overview of the different specs of this because Like a lot like the CSS spec is now like eight specs, right? They're doing the same thing with with web components. So there's these different parts of it Custom elements is the way that you specify a web component And then you actually tell the system that you're going to name it this tag and then you can use that tag name, you know Oh god, oh god, why didn't the client listen to me about carousels tag, right to to encapsulate your carousel, right? HTML imports are basically A way and it's that particular spec is like not implemented at all in the browsers You can sort of see on the left here. HTML imports. Not so much but it's a way to specify like an external resource external to the current page that hey, that's where my my templates are right and Then the shadow DOM this thing of course is is already implemented in and all the browsers and is Like the way the video tag and a lot of other widgets are actually implemented Inside the browser so Yeah Like that's my entire talk about web components right now and In in Drupal we've we've come a long way from just the beginning of the system We had a dot theme file that Had raw PHP and it basically to insert HTML into the system Then we went to a system called X template and finally PHP template and now twig and I I really I'm interested in in What people think about how do we get? this new technology this new tech Templating system that's in HTML and integrate that into Maybe you know, how would we integrate that into contrib into Drupal 8? How would we integrate that into Drupal 9? Is that even feasible? I mean some the question of whether it's feasible for Drupal 9 is sort of up in the air because we just have to see How far the spec comes with the release cycle of of Drupal 9 and Larry wins Drupal 9 coming out Yeah So I'm gonna move over there What a use case Well, I mean the We use templates throughout Drupal all over the place and the the idea is basically that that Having a sort of nativational implementation of it would be much faster Just a better way, but it's basically it would work identical to you know, whether we Are going to be using twig we're you know that we are currently using PHP template where we just We You can actually I Saw a really interesting demo last week where Chris Weber is he in here? He showed me how he got Drupal 8's Rest API and he built a web component that pulled out data Jason data out of the the rest API or something like that and Then used a web component to actually display a node, you know, so he like he was editing the node Yeah, yeah a custom element that was like a node web component Yeah Yeah, I think that there are is namespacing in web components Does anybody know the spec a little bit better and knows definitively that that's true? I can't imagine that there wouldn't be namespacing Yeah One thing I should point out is it, you know, they have partial implementation of this in some of the like the chrome Canary or whatever, but then there's a bunch of libraries here Polymer and x tag is sort of the better one. I've never even seen this one until today bow sonic But these are JavaScript polyfills that allow you to start playing with Web components right now in the browser using it this JavaScript polyfill as long as we don't have like PSR one style Name spaces for our tags. I think we'll be fine. I like to troll Larry sometimes too, by the way I don't know why it works like it is and JavaScript fails They would see like exactly What happened Well, I mean it's hard to non-dial a text that the HTML spec has been good about that If a browser does not recognize the tag, it will still render this content and it will just relate I think it's like a spanner I think it's like a spanner I think it's like a spanner It's no sound at all Okay, we're getting away. I'm not talking I'm going to be very clear. I was scrolling more than when I came up with the trigger tag I think that we will be working on it Actually, I don't mean I don't think we're using it before right now Probably Yeah, we are Not much A little bit A little bit, right But I think it's really good for like people suggesting sorts of stuff Where you have like the The same nodes to example it and then Say you only want to override that like one line of code So you use the trigger block and then You can incite your people to do that You don't have to use the entire node grid file again Say, this is a part of it Okay, those kind of things Definitely getting that better integrated into the trigger There's something that we will be doing I mean, I don't see what's going on with those types of things So when I When I started thinking about, okay What would Google line actually do with what? Theoretically, if what's going to be expected Solid enough by that time I think we would have We would improve our twig template Because right now we just did a straightforward Feed-by-template situation So like, we still have a really odd grid template So we'd like to A major refactoring to reduce the number of grid templates Down to better, simpler, more reusable Grid template files And once we do that We could, you know, it How would we have web components We'd probably have like a Complimentary library of web components Like Boston And I'm not sure exactly how that would work together But I see the more complementary part Of what you're saying I think there's a bridge to form Between the way Drupal names its template Which is specific to Drupal's understanding Of the data structure And the way web components Name themselves Which is specific to Drupal's understanding It was an idea that Jeff Eason was talking about yesterday And it's going to be rejected There's a reason that Drupal Or any server-side system should know What its own name for something And that might be a node And the Parasol example It's probably a node Or a Parasol or a gallery That's what Drupal thinks of it The browser seems to have something else Maybe web components With a gallery tag Maybe it's there with a class gallery But there's a bridge to be formed between What Drupal thinks something is And what a browser thinks something is I think what you're saying is honest Perhaps there's an extent Of that grid between Drupal understands this as Node-hyphen-hyphen-gallery Web components Or something And understands Either it's a gallery element Or a class gallery So that bridge can be formed there Either with a good sense Maybe it's more direct But yes, there is a bridge to be formed Between Drupal knows this as a node Or a type gallery The browser doesn't care If it's a node type gallery It cares if it's a class gallery Or something else But he's built that And he's built It's not like stable or anything But he has He has He has He has the Operate interacting with other things And you play it like Object Dora and his rendering guy Is just in the top And that's what he's built So you And then you're like Exposing those gages You know you're like Trapped to rendering Gages and structures You should look at it Because it sounds exactly like The stuff that You're just describing And that's something that You know when you presented it It's not something that We're really going to Drupal necessarily It's like it's going to think Right, it's going to set a Process It's going to kind of Framework for having Objects on it And render it And check it out The other thing I wanted to say About what component here is like As a core conversation This to me seems like Very much still the future Like it's a polyfill And it's a chair Like in the discussion around this There's a chance to say Maybe taking Drupal from being Known for being Eight years behind Industry standards Or like practices To being like We're going to put some weight Into like less than four Web components Because so many frameworks Use templates like And that's why this whole Web component Of course you can exist Because it's like We are all re-creating Sections of HTML And HTML5 is even more Like in the article In the discussion It's already Heading in that direction But we move it further From part-menalizing And make it component So like This conversation You know If you are interested in that You can think this is where The web is heading For some web component It's a chance for Drupal's tremendous Community And it's a way to Working on that Just getting it In browsers And HTML5 And standardizing And moving it out of Policy And I feel like If you follow The picture element All about Like that's what it's And the responsibility Is working with All of that stuff Like Years Of work And back and forth And different teams Saying like Which way to do it And like Those are people Who have a stake In the conversation And those are people Who are shaping The function And Drupal has an opportunity To do that How to decide About community And So it's an opportunity To think about You know It is hard to be like Going to jail Sort of a twig And you know Direct conversations But I think they're Separate Yeah Yeah I I I I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with I agree with that was great. It was kind of like chrome and like this fall, on the September it's going to have an actual short set and size of implementation so you're able to have native responsive images of that chrome and the others probably are just talking about what's the thing about it. People here it's not just a type of thing, it can really happen, it can help with the core of these communities. But there are two current ways that electric components can interact with the data and one is through regional attributes if you have a custom tag, you basically have some method elements or method attributes that contain your data and then the component is able to review that stuff to it. You have to mark up where you have to say it inside the website and that's how it fits the data in the website. The other way is through JavaScript. And of course, those two methods are not DAT. So, yeah, I mean if you're trying to, I mean currently right now if you look at like, oh I'm just going to build everything in JavaScript and then have the web browser who has JavaScript and pull in the data through JSON and render it all like that but at the time it's low, you want to have a really half of a, you want to be able to build all the data, you know, like back to 10 and then send it and then it's going to come to that super fast right now, right. And the way that we would do that is the way you would do that in with Twitch right now when I said they were separate, I meant more like the conversations. I mean you need to render an HTML, right. Like I'm not like hardcore front-end or like headless Google. That's not really where my expertise lies. But just as a conversation is different, I just wanted to throw that out there and shape things while we're talking about that. It should be able to, it's progressive enhancement. It should be built with the idea of progressive enhancement right there. I feel like that builds the rest of the process. I mean I think it's very possible that that will definitely have to do with the tool and do the stuff. But like the custom tag things go back to like a bigger conversation about the nature of the web and how browsers handle tags and how you need to find all sorts of great articles and posts about how it's a good thing that it just falls through, you know. And it renders when people do stupid crap like it still works. As opposed to it works, it might be something. So that's a bigger conversation about our approach to what the web is and like what? What the web is versus what native is, right. It's like native you would never expect that to happen. But in the web it's kind of share what you know. Like you want to be as open as possible kind of an approach to the web. How does it work? Actually I'm going to put it this way. It's part of the thing when you come up with custom tags, they're not just like coming up with like some new thing that... You are coming up with a new thing, but it's an encapsulation of existing defined markups, right. It's taking the sort of tag soup of like this markup that's like all that giant, cruffy markup that we have to do in order to do like an image player, right. And you encapsulate it so there's just like one tag, sort of tag soup of known and understood markup, but a lot of it make it simpler. So I think that because of that the browser can hopefully the accessibility software will be able to see the actual that old DOM real life defined HTML5 elements that are there. It all sounds wonderful, but as you're talking about really all it is is browser native template engine. Because everything is still filing down to the same HTML5 markup which means your expressiveness is limited to what you can back to existing markup with JavaScript, with the other bits and pieces. It's not a way to reinvent XML and the power you get with completely custom tags, you get short hands for processing something back into HTML. And I think we should try to not think it as something more revolutionary than it actually is. You can't have properly rigid users, but it's really just a temporary engine. I mean give a better example of something like this. Right now there's the new HTML5 tags and form elements that allow you to select a data picker, right. That uses the shadow DOM and if you do whatever canary flag that you have to in order to see the shadow DOM, you inspect one of those data pickers, native HTML5 data pickers, you'll actually see the giant markup. Who here is seeing the markup that's output by the calendar module? It's a lot for a calendar because it requires that much. So all of that gets encapsulated by the shadow DOM. So if you right click and inspect that data picker element, you'll see all of that. And then it's just the attribute on one input. So it's encapsulated this very complex set of markup inside a very simple wrapper. If you might be, sorry, can you just hand it up a bunch? The problem with one is, is that written by Google? Yeah. So I mean they're definitely thinking about that, right? And that's also a reason for you to have a distinctive spot of using things to talk about like what things about what to want to say or say versus what to react to. If you've actually seen the video and I haven't, you can. So, and I haven't said that much time with it, but the first thing I'd like to mention is that the criticism of this chart is pretty good to react to. The second thing I'd like to mention is that instead of like the Google Angular web component, I'd be able to get more into the browser and then just tell, they're going for the app directory where they're working with the person that's on it. There's a very similar idea, like the language that you use for that. It looks sort of, the idea is like they can do that. M, V, R, and C, there's the app directory layer. There's a lot of sense. I don't know that that concept can really apply to what we're going back into. Yeah, of course. But just to point out, it's interesting. Well, there's one other thing, is there, there's a lot of stuff. I don't know, I can't remember. There's something to think about. Yeah. I did a little thing that a research app right by the time I was marked. And the thing that makes Dom so happy about it is if you ever create an HTML element in the DOM and then immediately, in fact, there's like 300 properties on it and you know, anytime you do anything, it's got to create all this stuff that requires from like HTML 1.0 and so on. Yeah, I think that, I think that's a good one. Yeah, I think that's a good one. Yeah, I think that's a good one. Yeah, I think that's a good one. Yeah, I think that's a good one. Yeah, I think that's a good one. And so, but if you did, at the end of the day, we would have been quick to do this and talk to not everybody but to be happy as you can come into the floor and we would have it if everybody could go to the actual. Well, that makes it back to the other question in the way of setting it up. Are we just, you know, I mean quick, I actually think that we should, we try to have an art. If we can't, if we have a, exactly the old pthim, that would be quick, and you build them out of actual components encapsulated, you know, reusable, independent components. Doing that in trick now will definitely help us to be on the right path for, or, you know, even react sound like it's coming off the same idea, the same methodology, even if it's different technologies. So really, backering our grid templates to be more of a part of that would be a huge win for us. So we've got doing that theoretically in 8.1. I don't know if I understand what you're saying, but yeah. So we can actually do that tomorrow. We'll start on it tomorrow. Changing template files is probably going to be a guide for us. That's what we're going to do. That's what we're going to do. That's what we're going to do. That's a lot of the stuff. I feel it's very exciting. Yeah. There was a kind of a Google blog yesterday. And I wasn't able to go through it, but from what I understand, that it would be possible to do it. It's really difficult with a lot of people of all different assumed HTML rendering that it has to do. Do you want to say how much for it? Yeah, yeah. So, like, one of the things here is that I actually had a little bit of an echo. I feel it's not as great as I think it is. In terms of even agnostic, it's not accurate. And when I brought that up, it actually was. But there's a lot of you who want to do it. The big issue here is models and the shifting. So once you've ran through that, if you instead of model it into a template, it should look like it's coming back. And if you need to get it, this is true. But again, if you get something out of models, that's one, two, three, four, that's probably a good thing to do. Yeah, I was just saying that that was not hard. Because I mean, you can use it to make it simple to just actually build something. I mean, either way, you're going to have to develop something to do with something. Even if you're doing a normal, simple HTML, you have to style it. You have to have one interactive, you have to write it down to it. You're going to have to do something. So, I mean, if you put it in this configuration to be a field or a text on there, however you want to categorize it, you just have to read the text on the front end. You still don't have to write the text on the front end It's really simple. You just have to think about the paradigms you have. I hope that I need to send along with my normal HTML or anything I'm going to send. I need to send some information to the front end of all of these pages. And I like, obviously, the 400-60-60 most of them are like an auditory and there is an event or an end. And I talk to that. And I talk down to some of the software studies. But that gives us the big issue with the intention. And I guess it's really important and I guess it's talking about this in that, you know, what you want to be able to get on the front end is the intention of the content that's created on the back end. What do they want this content to be like on the front end? And the decorator thing is a big plus because that gives you the ability to have modules inject what they want to do with it. But you can also still get the original unlimited content. And then also, the fact that you can't make structure as part of what the JSON is coming to that. So if you get an individual node, it was all grouped by where it would live if you had pushed stuff into the people structure of, you know, regions and all that sort of thing. It came through that way. So even though you, you know, you had to go through the pieces of what you were doing with the stuff, you could just have structured as part of it. So you could then use that if you built up an elaborate system that would render the page and still be all dynamic. You could really be coupled into what I'm doing now. And it's awesome because it's so fast. I mean, you know how many of the group is running the stuff? You just have to go back and do it for free. And then on the front end, you have Angular or whatever your Amber or, you know, the space of things is still on reading about the contrasts between the two. I mean, either way, the idea is that you get all that power from everyone depending on the new stuff that's on fun and relevant. And I mean, it's just it's a win-win. Because Drupal's excellent at structured data. As long as you separate content, data, so you know what that makes it because it takes better fits and we're trying to do a good job of it. But I want to give back briefly to your point about how to handle people or the frequency of all that. I really feel like they're complementary that you can do both in a way that you don't have to do one or the other. As long as we can do both as well. Right. With the auditory and the system that you just wanted to, you can do everything in front of you or you can also integrate your MTC stuff on the fly. I mean, I'm looking at the left and then double-times just like, okay, this is just exactly what you want to do with the box. You don't need to deal with the module, you can load Angular and then you can say, okay, I want to get this case on screen and I want to pop this box with this stuff and encapsulate different functionalities for you. You don't have to include anything you want to add and it all goes in and you fed data from a positive and this does work with them. What I just thought of because I was thinking about what you were talking about and I was going to talk about what they tried to start doing that but then because of the project requirements and deadlines and more and more features that were required by their clients, it became too easy to display and install a module that does that thing and because of the Google module it output dates and all. So it became there was a small layer of Angular on it and then they type that in because we've already done except for some CSS we have to try to figure out how to re-implement it. How do you use fewer modules? Well, yeah, I was thinking you would have to use fewer modules but there's no modules and in front of these you're Angular and it's super too long. What I was thinking of so we've got these features down Google 7 that are modules what would it look like as far as trying to create functional I don't think modules are the right word some package front-end component web component functionality how would that look like is there Google integration that's required for that or would it be pure web component distributed package that would have a certain functionality? What would it come from? I don't know There's a JavaScript implementation in Twig so I want to put this idea that there's a choice between Twig or front-end rendering I think an ideal would be our Twig templates are written in a way so that the Twig template itself doesn't know or care if anything you render through a Twig template that's easy for me to say how we actually ensure that our Twig template the only bit about that is custom filter type I think it's in-function in-function today I'm writing a PHP Twig function to view entities of it well that's PHP size that's a great template with the entity and that function were rendered on JavaScript JavaScript would have no idea what to do with that so yes there is work to be done to ensure that JavaScript and PHP both know how to handle the same with their functions but that is one way we can get to the place of this module which either ships with this or that's under this happening server side or client side just from what I'm seeing at our job and a lot of other jobs I know of this is happening the front end back end where the split is is happening and it's not necessarily hard to have it happen we don't actually always have control of the site of it so I think it's just because it enforces it correctly we accept that and we just take some ownership otherwise we've just got to be dragged along pretty much in terms of where we're in the process you're asking about complex and runs you might see a shift where people do write those complex and runs they take responsibility for writing and expose control of that from the front end because you can write complex you can just make any guide and provide an interactive just like you have an interesting on any guide or action for sale or they're happy to people to get into writing that so it's huge how we think about those sort of things but then if you build an API you can also make people interact with it that's why we got left we got a standard if you look from the technical side of the author I think if you are kind of kind of , in both things what are we actually I know