 Good morning everyone How's the volume can everyone in back here me? Great well welcome to what panels can teach us about web components My name is Steve perche. I'm a senior engineer and team lead with Palantir net today. We're going to be talking about panels and the web components To do that. I think we should start by defining these terms so What are web components the Wikipedia definition? We've got here a W3C Specification that allows for the creation of reusable widgets or components in a web document and web application I like to think of web components as the next step in the history of html So if we look at an extremely abbreviated history of html Split up into before html 5 html 5 and after html 5 we can see that before html 5 we had These old reliable elements like the select element and in the select element you could use elements like option groups Options and with that we got the first era of the web. We got basic functionality basic forms I'm sure many of you have tried to style one of these and they can be incredibly difficult to style But they're also incredibly reliable with just a little bit of markup You don't have to define exactly how this works. You just say I want to be able to select something I want groups of options and with a little bit of markup. You get incredibly robust behavior That's kind of difficult to customize In the next step in html history and our extremely abbreviated history We have html 5 it took a couple of years just about a decade to get html 5 It's where it is now, but now with html 5 we get things like the audio tag the video tag a new set of semantic tags that Bring us more robust functionality Who here spent way too many hours trying to get mp3 is playing on the web before the audio element? and now with just a Little a little bit of markup Come on. Oh We can get the sound of inception Which is too hard to hear but there it is So with html 5 we get new semantic elements we get a Greater ability to customize these elements are a whole lot easier to customize than Those old elements like select lists other form elements in the next step in HTML's history after html 5 we get web components and they allow us to do us to do things like this define a tag specifically for gifts Now why do we need a tag specifically for gifts so that we can? Declare gif behavior. Here's a gif element. It's a web component available for anyone in the world to download and once you Download this web component and add it to your site then anywhere on the site You can say I want to gif and I want the ping-pong behavior that Replays the gif backwards when it gets to the end so similar to those those attributes that you have with Old school elements like the select list and options where all you need to do is use one word and say This is the selected elements. This is the selected option in my select list with web components You can do things like not worry about how this gif playback system works I don't really know how it works myself other than I've included this web component And I've said ping-pong it, please I could also have options for syncing it up with audio and make it play slower or faster So the benefit that we're getting here with web components is the ability to cleanly separate the definition of new Elements from their usage. I don't need to know that much about how this gif element works to be able to use it I just need to say the code that defines it is over there And I'm going to use it right here in one line of code. This is something that I Think is revolutionizing the web. We've we've had this concept for a while being able to use packages and components of front-end code like Everyone's favorite jQuery cycle, but that's not quite as clean as this. It's not quite as standardized as this it's not It's not as clean to be able to say Just the gif element, please So this is a relatively simple example where the only piece of data that you're passing in is a URL to a gif But of course it can get more complicated. Here's a proof of concept from The Drupal web components module, of course, there's a Drupal web components module It hasn't had much attention lately, but it allows for Drupal to do things like this. This is just the the GitHub IO demo of this web component. You define Front and back elements for this flipping card how you want it to flip and with just a tiny bit of markup You can get this behavior with a web component encapsulated front-end behavior I think I've now lost my slides. There we go so In Drupal, all you need to do is say I want the flip card element It's going to flip on this axis. This is the front of the card This is the back of the card and that's it. I've gone too far ahead We're going to ask why we care about panels, but for why we care about web components, but first what is panels? Panels is a user interface for the theme function. The theme function has been there in Drupal for a long time but it can be difficult to use and When a lot of people think of panels they first jump to that incredibly complex user interface So if this is a user interface on top of theme well, of course people are going to think of the user interface first But let's let's put aside the user interface just for a second and think about what is panels really doing under the hood? What does it need to do? What does it need to abstract to make itself a user interface on top of hook theme? Well, it needs to be able to be aware of data data like nodes user objects taxonomy terms needs to be aware of data like this node object and It needs to be able to Get that object ready for printing in a template panels Organizes its its templates in layout plugins. So this is a sample Layout plugin from panels module and really all that's happening in here is the printing of a left column and a right column Panels can send in a node object and somehow transform it into something that is ready to print in left and right and by the time these variables get to The template file. They're already stringified. They're already All set to be printed and simply left and right now How does how does panels do that in core? It takes a lot of messy pre-processing to get a node object ready to be printed in a template file Well panels does it with a lot of user-defined Configuration that this is the part that comes from that complex user interface a big dump of PHP Configuration this is where panels gets its instructions to take a node object and get it ready to be printed and simply left And right or whatever your layout plugin is So here's some radically oversimplified Panels code to to show what the basic idea of panels is if we can imagine a method that doesn't actually exist But we can imagine there's a method called Render a panel the only thing that method would need is the incoming data be it a node object to node objects Some taxonomy terms so it takes in its raw data It takes in the name of the panel's configuration that it's going to use that could be the name of a mini panel A mini panel is just going to be that big export object like a views object is a big exported list of PHP configuration, so it just needs the data. It needs the name of that thing. It's then going to ask that Regulation, what's the name of the theme hook that I need? What's the name of the layout plug-in? What's the name of that template file that we're going to end up in because all we're trying to do here is take? Raw data and get it ready to be printed in that relatively simple template. So what's the name? Oh And what are those instructions for getting this node ready to be printed in that thing? after that all it needs to do is a really really simple invocation of the theme function a lot of the times in the theme function as it's used in core what happens after you call theme is Really really complicated. It's going to go through literally ten layers of pre-processing Ten layers of processing all to get those variables ready Here just about any developer in this room literally any developer in this room could rewrite what needs to happen after this because all that's Happening is taking things that are already strings and putting them in a template file panels Abstracts all that all the other complexity into one spot and Panels can operate on multiple levels it can operate on the panels everywhere level which basically takes over what you would otherwise do in page dot tpl It can work at the page manager level which takes over what you would otherwise do in hook menu It can work at the panelizer level Taking over view modes instead of using cores view mode user interface And it can take over the block level which is which is many panels So why should we care about web components? They're they're a new thing that you might have seen on a session title just like We've heard about angular is going to revolutionize front-end web development We've heard react is going to an ember and backbone and marionette and riot J S and knockout J s and whatever JavaScript MBC was started at the beginning of this session and will be released at the end I'm talking about web components in this presentation, but I think a lot of these concepts apply to these other modern front-end tools They're all offering a new way of encapsulating our front-end work and the ability to componentize and reuse is a Measure of progress and we've seen a ton of progress in the php community and Drupal on the server side to quote our own Larry Krell Garfield from a talk called php Renaissance the way to be more productive is to write less code The way to be more productive is to reuse more code The way to be more productive is to share more code and on the php side There are a bunch of factors that have contributed to our ability to do all three of these things Larry defines the php Renaissance is coming from a couple causes class auto loading which is something we've had in in php for a while now It was really hard and then it then it got easier and class auto loading made it much easier to to share our work Get hub gave us a common place to share that work Name spaces made collisions less likely to happen the php standards group got people talking to each other Composer makes it easy to pull these things in and common interfaces tell us how to use these pieces together Multiple causes leading to a php Renaissance where now we can open up Drupal core look at that vendor directory and see That we've been able to replace big chunks of Drupal We've been able to take that infamous Drupal HTTP request function and replace it with guzzles something much more robust something much more Stable and something that we didn't have to write Which is great because the ability to be more productive is to reuse more code reuse code that you didn't even have to write We can do that with the symphony HTTP kernel we can do that With twig that was a huge help not having to write and maintain our own templating layer Makes us far more productive on the server side And we're doing well on the front end too. We've we've had jQuery for years and in Drupal 8. We're introducing Even more front-end JavaScript libraries that are making our lives a lot easier But we can go further We're playing out the ship of Theseus Paradox in real life the question of if you take a ship and replace it sales Do you still have the same ship if you replace all of the deck of the ship? Is it still the same ship if you replace the hull is it still the same ship? Well, I think I can say Drupal is still Drupal even though we've gotten Rid of our way our own way of making HTTP requests and replaced it with guzzle I think we're still Drupal even though we've gotten rid of that part I think we're still Drupal even though we've gotten rid of TPLs. We've got The fork of backdrop that that it said This is too far. This is no longer the same Drupal and I'm simply glad that they're answering that question Explicitly, I don't think there's a right or wrong answer here Now the question before us is do we have to write our own markup? To be Drupal, can we use web components that we didn't write and still be Drupal in our markup? Can we write less? We can and twig is helping us write even less that extends concept means that each different block and core Doesn't have to rewrite everything we can write less because of twig We can reuse more twig helps with that as well and stay After lunch for John's core conversation where he'll be talking about another potential model of reuse in core But can we share more we've written an amazing? Responsive toolbar in Drupal 8. I think it's great Other frameworks have similar things. There's a web component that does something like it I think ours is a lot better Can we share it with the outside world? Right now not very easily right now There's a strong coupling between the server side logic that prepares the variables For that administrative toolbar and the actual front-end rendering of that toolbar. I think it'd be great if we could share it I think it'd be great if Conceivably someone wrote a better toolbar outside of Drupal We could throw ours away and replace it with something even better and not have to rewrite everything to do that so We've gotten this benefit on the server side largely through the dependency injection container again quoting Larry a Dependency injection container is simply an easier place to wire up. What objects get past what other objects? This is something we need on the front end now the ability to wire up To objects so that they don't have to know everything About one another that the internals of core can simply say I depend on this interface That's all I need to know. I don't need to know every single detail about how it actually works Just just give me something Compatible with the the kernel interface that I know will work I think we need to be able to figure out how to do that with with the front-end world And we have a model in panels panels provides analogous wiring between markup First for the source data going to our template files The node object doesn't need to know what panels template file is going to end up in That panel's template file that simply knows left and right doesn't even need to know that a node is coming in It could be a user it could be text on each arms It could be any number of things it says all I know is left and right. That's all I can do To use web components properly we're going to need to be able to bridge data and display In a way that doesn't completely couple them to each other So individual lessons from panels that are that are going to help us as we get ready for web components In Drupal we have a tendency to treat all of our theme hooks equally quoting from The Drupal 7 module development book One of the great things about Drupal theming is it is the power of its granularity the idea that each piece Gets themed individually and is passed along I think this is is best understood through a diagram that with the power of Drupal steaming system comes a whole lot of responsibility That the same book explains the theme system like this Blocks render into a region which render into it a page TPL a node is composed of fields and a comment wrapper and even below that you have comments And this is a simplified version on a real Drupal site You're going to have dozens and dozens of theme functions called on every single page and it's hard to know Which one do you care about do you care about the theme function that's rendering views row or do you care about the thing? That's right inside of the views row. Which one are you theming? With panels you get some level of prioritization splitting up a wireframe into panels pieces you can say this box is going to Be the view mode that's going to be taken over by panelizer and I'm going to think about What happens inside of there later? If you're working in that core model where each individual slice is equally important It's hard to know when you can stop. It's hard to know when you can end the conversation It's handy to be able to say This is happening in the view mode. That's all I need to know that maps to panelizer will figure the rest out later a Good architecture allows you to defer critical decisions. This is not something we can attribute to panels But uncle Bob Martin, but it applies here the ability to defer decisions later to say We're gonna have to figure out how to render that field Sometime, but we know it's at least rendering inside of this view mode So for now it's enough to know it's going to happen inside of this layout plug-in Separation of names indicates separation of concerns Again looking at that traditional core model each of those layers is both a Drupal entity or Data structure and it's the name of the template. So what's the name of the template used by? article node teasers node Article teaser we've coupled completely the name of our template files to our internal data structures This isn't necessarily bad, but it tells us that We haven't we haven't truly separated our design from our data if they are named the same thing Panels gives you the option to say that the article teaser is going to be rendered as an Illustrated list item because that's how our design system names this thing and Illustrated list item is also used for the interview content type Tiny teaser view mode great. We can still have that illustrated list item Template file use it with a bunch of different node types use it with a bunch of different view modes as needed and not have to look at a directory with Dozens and dozens of obtusely named template files each containing near identical markup Simple mental models help. I think panels does have a simple mental model We know it doesn't have a simple user interface But the simple mental model helps me immensely knowing that at each level all I need to ask is what data is coming in and What layout plug-in is the destination? Figuring out what happens in between can be difficult But I know I'm starting at a clear place, and I'm ending at a clear place The front end world has its own mental models a lot of the front end world calls itself MBC model view controller, and you can draw a relatively simple diagram of what that looks like some of the modern front end world explicitly calls itself model view presenter like riot JS that says we have our model be at our Node object or other data domain object. We've got our view Which is little more than the printing of some variables, and we have a presenter that can pass in between this to me sounds a lot like panels and Depending on who you ask backbone is as closest to this You can also use backbone in more of an MBC fashion It gets confusing and that the people who say backbone is MVP say that the backbone view concept is actually the presenter part of MBC so Simple mental models can be quickly confused by confusing names. We know that in Drupal to be true There's also the concept of view model view model or model view view model Which is used explicitly by knockout JS and this was a concept that came up in a twig presentation on Tuesday The idea that we're still passing our full node object or user object into our template files which have all of their methods available Everything you could ever want to know about them Should we be passing a dumbed-down version instead of view model? a Version of the user object of the node object that is simplified for display rather than Something that contains all of its implementation details Wikipedia says that Drupal is presentation abstraction control. I Did not know this until I went looking Now that I know I maybe I would do some Drupal site building differently But we don't we don't tend to talk about this very often we think of the Drupal mental model as as this or Or now in Drupal 8 our render pipeline looks more like this I don't expect anyone to be to be reading this diagram just to know that our diagrams are are still relatively complicated The simplified version is the the symphony HTTP kernel so that that scary diagram We just saw was a more fleshed out version of of what we have in the symphony HTTP kernel but in women's presentation about the Drupal 8 render pipeline on Tuesday He was saying we've got a lot of ways to to get your hands dirty in this pipeline. We've got events We still have some hooks and we don't know which ones people are going to use most Within within this pipeline you can hook in in lots of places And I think we're still going to have the problem of different groups of people using the same set of tools But but with completely different models in their head about what they're doing I can use panels and think I'm doing something like model view presenter But that doesn't guarantee that my co-worker is going to be thinking in the same terms That doesn't guarantee that the client's developers will be thinking in the same terms The time it takes to for browsers to process web components is nothing compared to the time It takes our brains to understand them if we can't Understand the way we're doing rendering the way we're using web components the way we're using template files How fast they are on the server or how fast they are in the browser is near irrelevant because if we can't use them It doesn't matter how performant they are. We're not going to be able to use them. Oh My inception image file is missing nesting is still the hard part of Of working with with these tools It wasn't until I saw the movie inception that I really felt comfortable Working with panels inside of panels. I've been work. I'm serious. This is not a joke I've been working with panels in 2009 2010 and and felt like I Kind of knew what I was doing. I was getting comfortable passing data in and then I thought but It seems like I need to be able to go a level deeper and do a mini panel inside of A page manager layout. Is that even possible? Well, it is but it's it's the confusing part Simple mental models help but if our UI is so confusing It's not going to matter if we can't understand web components It doesn't matter how performant they are The next lesson Define dependencies and properties. So when you define a layout plugin and panels you say what CSS file Does this layout plugin need in order to work? What is its theme hook? You can you can even declare an alternate administrative theme hook and you declare what What its regions are what are those variables going to be that you are are sending in and that's it But that that is a good amount and it's something we have Inconsistently implemented in in Drupal core when you define a render element in Drupal core you say What JavaScript or CSS it relies on but not when you declare a theme hook When you declare a theme hook you might say all I need is an element because I know the Pre-process layer is going to dig into that element variable and figure out what it actually needs or You can do what say theme item list does and say I expect a title and I expect a list of items The inconsistency is making it a lot harder if we can standardize or on defining What do we depend on what can we do we'll be able to work with web components more easily because web components Defining these concepts as well web components are coming up with new ways of saying I'm a web component and I expect To be given a title an image a subtitle and a date That's what I expect and I'll I'll do what I want with them You don't need to know what I'm doing with them, but give me those things And panels is already a similar mental model that we can use as a reference So to quote myself as the Drupal community asks itself again how we want to do Rendering let's also ask how we want to think about rendering This is a core conversation. So I'm hoping to to get a good conversation going here feel free to to walk up to the mic and Give whatever thoughts you have but I've got a specific I've got some specific questions that I think can generate Conversation as well. Can we separate the thing that prints data at all from the thing that says how it gets printed? When you use panels now, there's still the core theme system saying Print me a node and I'm going to assume that the pre-process system will make that work sensibly And that's where panels hooks in It hooks in and says oh you're printing an article. It's a It's a teaser so I know that means this exact panels configuration and then it does Then it does what it does Ken is that separation a good thing? I think for at least the immediate future in Drupal We're going to need to keep that part the part where core can say nothing more than print me a node Please and we'll need a separate system to handle it that sensibly I don't know if that's a good thing, but I think for the immediate future We probably need it is sharing markup outside of Drupal something we even want to do I like the idea of being able to share our Responsive toolbar with the rest of the world, but maybe that's not a responsibility we want I'd love to hear opinions on that Does someone need to write a web component theme? The theme layer is a place we could hook in we could conceivably Replace the theme functions for item list or the theme function for that administrative toolbar with something that just calls a web component How many invented here parts of Drupal can we strip out and still have it be Drupal can we lose? the markup some of our Markup that we wrote and still be Drupal What patterns do you see Drupal implementing now? We've got a complex render pipeline, but how do you think about it? Which parts do you think are most important the parts that let you think of it as? MBC the parts that let you think of it as Action domain responder the parts that let you think of it as model view presenter And what pattern do you want Drupal to use maybe there's a pattern that? Really doesn't make sense at all for the tooling we have what is a pattern that we should use And what parts of the d8 render pipeline do you expect to think about? Most so there's a question that I sort of asked in whims presentation We've got these events where we can override a response But is that something I'm going to think about as a site builder in Drupal 7 I know that page manager completely depends on hook menu altar But in building a Drupal 7 site, I don't have to think about that very often What parts do you think we're going to be using all the time without thinking about it? What parts are we going to be using all the time and still have to think about it all the time? If you're using the pre-process layer, you are probably thinking about it All while you're using it All right, that's my list of questions. I'd love I'd love to hear your questions as well. Thank you anyone at all Yeah, if you can use the mic, please do so so in my company We We we we have one site where we use Drupal And so I'm a user not an agency or something that we have one major site where we use Drupal extensively Drupal 7 and and another site which is actually built with With a single page You know SPA approach at the front end mm-hmm all the user interfaces in there and then the back end It's actually ASP net Okay, so at this conference. I've been going to the headless Drupal sessions you know and thinking about you know if we could get Drupal to you know to satisfy the the Provide market for the ASP and obviously you can and you can do it by creating a RESTful API in Drupal what I wish for is is This I can articulate this is first of all a I'd like to I'd like to go further down the render pipeline and gets you know not all the way back to pure data And and gets something that that you could still consume in a richer client sure even I'm getting out I do So this is just a desire sure I don't actually have a great solution so I I Think the question you're asking is as one That I've asked as well, which is if you want headless Drupal, where is Drupal's neck? Where do you cut off the head? Do you cut off Drupal's head? before theme Do you call out cut off Drupal's head right before the template file after all the pre-processing is done? And maybe you've gotten more of that Some people have called it called it hydrated Content as as people have started to use Drupal 8 and they see what? The REST module exposes they see okay. Yes, this is the raw data, but I didn't want the image file ID. I wanted It's path. I wanted the large version. I wanted the medium version so Where do you cut off Drupal's head and there are a bunch of different answers? I strongly recommend for your for your use case going to the presentation on weather.com this afternoon because they've taken an interesting approach which is to use panels on the Drupal side for assembling a bunch of components and Panels exposes the data to angular components So the template files are angular what we looked at here was template files being PHP template files that Drupal renders on the server side Weather.com has has answered the question of we're cutting off Drupal's head right in this point of panels and I guess conceivably they could still render Those angular files server side somehow, but they're rendering them client side instead Larry Hello, so to answer a couple of the questions you asked because you had a lot of questions. Yes On the server side one thing I've been starting to say recently is Long-term like Drupal 9 vision Drupal consists of nothing but a vendor directory so third-party components even if we wrote them and forms and Just architecturally that level of separation is where we want to go and makes sense to me to do the same thing on the Client side to the extent that the technology enables it The challenge there and the core of Drupal is not the tool the core of Drupal is content management and a content management platform that's extensible for Non-engineers to be able to do something with But the challenge with that with that level of really good decoupling on Server side or client side or in the middle because it is sometimes the case is Understanding all of those moving pieces that you have nice and cleanly separated gets progressively more challenging People have a very hard time understanding decoupled components. That is a professional level concept and so the big challenge I see for us is You know, we could Technologically build a system that is all rest-based and lots of free-standing components on the server side and completely web components on the client side and You know lots of flexibility and everything's third-party and swappable Mm-hmm and now how do people who are not attending for their fourth Drupal con actually understand what they're doing? Mm-hmm because or how do we? How do we take the complexity of a modern car engine and reduce it to a steering wheel you turn left and right? That still gets good gas mileage. That's a really really hard problem and You know making web components Accessible to themers who don't understand web components is That's a really hard problem that we're gonna have to try and address. I don't have an answer for that sure So I'll try to Answer your question. I think in reverse first. I don't think we need to commit 100% to web components So I don't think we should necessarily Ask someone building a site in Drupal to understand web components I would like it. I would like to see us adopt an architecture that would make it possible to say No, I'm not going to render that Server side. I'm going to use a web component. So I could see a web component theme a web component base theme as As a possibility there where you pick and choose which parts of Drupal you want to replace and that's an advanced Usage at least in the near term is possible that in five years web components will be so dominant that Just of course Just as we use HTML five elements now, of course, we would use web components, but we're certainly not there yet I think your deeper question though about How do we address the needs of someone who may not understand this architecture? For better and worse, almost nobody understands the architecture we have now So if if the bar that we if the bar that we need to clear is keeping it as Understandable or more understandable than what we have now at least that's a low bar to clear To shake which is but which is both a good thing and a bad thing the the bar that we have now made it possible to satisfy the 80% use case really easily in 2006-2007 where the 80% use case may have been a simpler design system where the use case we wanted to satisfy was the ability to point and click together really quickly and I think that use case is still there the use case of wanting to be able to point and click something usable Quickly, that's still there But I think I think as web components and Modern front-end tools become more and more common The wider Drupal world or the wider web world who hasn't been to for Drupal cons will just assume Well, of course, I can point and click together things that involve angular or things that involve web components The architecture we have now was was designed. I think to match the expectations of the mid-2000s expectations have shifted radically and I don't think we're meeting them very well Yeah, to say that Drupal's architecture is difficult to understand is definitely an understatement so Those are really great questions. I don't think this compares with that But I think the first thing that anybody who is not a theme or and isn't even like going to even try to wrap their heads Around the architecture and figure out which way should I go or whatever? I think the first thing a point-and-clicker who's trying to build a website without actually getting into any code is the first question They're gonna ask as well If I'm gonna use web components if I actually even understand web components correctly Would I possibly be introducing any other issues like security issues? Mm-hmm like because now it's not all kind of Drupalized It's not a module that I'm installing in Drupal that is somehow vetted by the community or at least is Inmoderated in any sense is that and or do I not actually understand web components? I? Think you're I think your base assumption is correct that by moving Things that we would traditionally do server side into the client side. Absolutely. There's an increased possibility of Exposing something you don't want to expose Exposing data that you wouldn't even realize that you're exposing for instance If if you cut off Drupal's head at the raw node object Then it's possible that you'd be sending unescaped text over the wire and And now if you're theming your node you're not going to send the raw field value You're going to send the one that's passed through TPLs and and gotten escaped so absolutely Yes, I think your base concern is correct that by moving more and more things server side by definition We're moving Processes that we could just assume Would be secure because they were happening on our server. Well now we need to think about it more in general though My hope my expectation is that by adopting web components. We'd be getting even more eyes on On our tooling I'd be concerned if we were writing our own web components that were completely coupled to our architecture We I don't think we would get any benefit from that whatsoever right now if we if we replaced theme node with a Web component for node that was still completely coupled to Internal implement date internal implementation details about nodes and entity API that I don't I don't see what benefit We would get but if we could take a web component that was written by a larger community vetted by node developers vetted by Developers who are experts in JavaScript then we we don't have to become experts on everything so Yes, we'd be introducing new risks, but we'd also be Embracing a larger community that would help us negotiate those risks Well, that's sounds great I mean because the idea of it the way you describe definitely sounds really really great because having Worked on a fairly complex installation of Drupal. I can tell you that if I if it did exist boy I'd be one of the first adopters All right, great Any other questions anyone with an answered to one of the questions I asked Larry so to respond a bit to your previous answer a web component consists of effectively a Template some CSS and some JavaScript and some input variables a Theme hook in Drupal now consists of a template The input variables and it would not be that hard to let the theme hook declare some CSS and JavaScript that go with it, right? So it sounds like with one patch. We could make a theme hook be a web component. Yeah, why shouldn't we? Brought a limited browser support for the moment aside. Why shouldn't we? Because the first thing we should do is see if it works and contribute as has been our answer for most things I Think one of the first steps would be someone writing a web component based theme that replaced some number of theme hooks with web components not replacing the theme hook but replacing the thing that happens in the theme hook So rather than sending the administrative toolbar Theme hook to the administrative toolbar Twig file it would get sent to a web component Now that I think that would be difficult I would probably pick an easier theme hook to start with but one that's still worth doing Moving an item list into a web component. I I don't know what benefit we would get from that because UL is a pretty stable HTML element I don't know what benefit we would get from making that into a web component But there probably is a middle ground theme hook out there where it's Interesting enough to make it worthwhile since no one else is here One of things that you talked about with Panels that I think kind of gets glossed over is you've got the incoming data Which node or user or text on a term or whatever and you have this template that just understands strings Mm-hmm, and then you have this user configuration the middle that marshals from one to the other. Yes That object in the middle is actually where all of the hard parts are yes, so how do we make that? Less ugly and easier to understand, you know that that's the important glue piece Mm-hmm, so what do we need to do there to make it more understandable more web component friendly? You know what can we learn there or what can we what do we need to learn there in that? glued piece mm-hmm, I think we need to look at What other systems do? How do other systems make the presentation the presenter layer and MVP or the view model and model view view model How did those work within the Drupal ecosystem, I'm really interested in Amitai's restful module, which takes a different approach from Cores rest module cores rest module by default exposes nearly every property on An entity and it exposes it with its internal name So field subtitle would be exposed as field underscore subtitle Amitai's module in Drupal 7 assumes whitelisting only it assumes that there's going to be a class that gets a node object sent into it And then that class is going to determine. I want to expose Only title only field subtitle and I'm going to expose it as Subtitle instead of field subtitle so that's a model module that right now doesn't have a UI, but I think it's a Simpler implementation of the task of taking a raw node object and getting it ready for some other consumption where in The restful modules case it's consumption by some API consumer Here we're targeting for a consumer. That's a template, but it's conceivable that we could use the same tooling Thanks. I recently had to do and I don't know if it's the right approach Is I had the the theme radios you know theme function and What it does is it takes, you know an array of options and it adds a bunch of you know children to Render array, right? Mm-hmm and for each of them it it adds a theme wrapper to for for You know rendering the div tag Outside of each element. So what I did is I needed to get some HTML in there and in each of them So I swapped the theme right and that's something that that's great about Google You need something very custom and kind of do that thing Mm-hmm. How would that work with web components like a web component that takes only the initial array and Nothing else. Yeah, I think what you're talking about is a trade-off that we have to face between the power that The Drupal 7 module development book highlighted where nearly every single HTML element is coming from a separate theme function and every single one can be overridden that is Incredibly powerful and we shouldn't throw it away lightly because you're describing the use case that that benefits from it where you can do something extremely surgical and change only the part you want to change and not have to Reinvent the wheel On the other side one of the reasons I like Panels is because it makes it easier for me to open a layout plug-in and Understand all the markup that I need to understand that design component. So One example I use there is placing a node title in a panel's layout the the title Pain UI gives you a select list for do you want this to be an H1? Do you want this to be an H2 and you can very easily make the H1 or H2 come from the UI I? Use the option no wrapper Because I want that H2 or H1 coming from the template file I want to be able to open up one template file and understand everything I need to understand markup wise for this design component for this node teaser or whatever it is The the scenario you're describing is is one that's really powerful really beneficial, but takes so much training and experience to understand and and And I think we would benefit from Moving that needle from granularity to Comprehensibility so again, we're like end users of Drupal Although this is my fourth Drupal con and I do have a computer science degree from MIT But hopefully I can understand these things, but but I don't have that much time to do it right So we have another site that we're beginning work on it's really gonna be a micro site and it's kind of a low stakes thing And we need a theme for it. So before we you know commissioned the design of a theme. I thought well Let's go out and shop for you know the off-the-shelf themes, right? Well, you can go out and there's free ones and there's paid ones and they're really pretty inexpensive But all of the new ones Have an awful lot of they usually have some JavaScript framework in them You know bootstrap or or sometimes angular or something and the night all the nicer things are doing this now And I guess some people are like paying 50 bucks and you know buying these things usually they get installed with the distribution So everything kind of works right away But whatever they're doing To me is a little opaque right now. I mean I hesitate to use them because I think what are they you know How is this organized and how much time will I have to spend going into the code? Let's just an observation about what's happening You know in the Wild Yeah, and I think it highlights an unresolved question in the Drupal community of Where are you supposed to do something? Those themes come with Distributions how easy it for how easy is it for you as the person downloading a half dozen of those to understand what's happening where and I think the goal of a lot of those projects is to say you don't have to understand it just works and That works if it works if it doesn't work you are stuck trying to debug magic and I don't know how to debug Magic I know how to debug systems that I can understand and It's I don't want to discourage people from Trying to build things that simply work and do amazing things out of the box. There's absolute value in that I don't need to know Larry and I were talking about this last night I don't need to know how all of my iPhone works to use it, but I'm also not trying to Debug my iPhone very often as a Drupal site builder Understanding how it works is more important to me than out-of-the-box functionality in a lot of cases which is why I use Zen as my base theme because It doesn't do that much out of the box other than Strip a lot of things out it adds a little bit But not that much and I can understand how it works and to me that's more valuable and to quote Larry again, we need to we as a Drupal community need to establish some prioritization system for those kinds of trade-offs because There's a large community out there that wants something amazing As soon as they install it and they don't want to know how it works They don't care how it works and there's a community that wants to install the minimal installation and only add pieces that they understand and Sometimes those are in opposition Alright, well, thank you everyone