 All right, we're going to do a panel now. I knew Monica mentioned earlier we're asking somebody to tweet questions at a hashtag Ask Polymer Summit. So please do that if you have questions. We've also got microphones set up there and there. I'm going to invite my panelists on stage. Please welcome Justin, a software engineer on the Polymer team. Got Wendy, a product manager on the Polymer team. Taylor, a product manager on the Polymer team. Monica, software engineer on the Polymer team. Steve Ormel, software engineer on the product team. And Matt McGnollty, director of Chrome. Please give them a hand. Oh man, there's some good Twitter questions in here. And remember, if you have questions, please just come up and line up at the microphone or something like that. We will start with a Twitter question, though. This is from a few of these that are all related, which is basically Alex just gave a good talk on the importance of HTML imports. And a lot of folks are wondering, it seems like there's disagreement across different browsers about implementing HTML imports. And we also have this question of HTML imports or ES6 modules, like where are these things going? So yeah, could you all maybe address perhaps these two issues, like where are imports headed? And also, how do we reconcile that with modules? What's the dive in on that? Yes, I can start. I mentioned this a little bit off the top yesterday. But yeah, like Rob said, all the web component specs are well along their way, already being implemented in browsers, except HTML imports is still kind of on the fence. It's on hold, is what many of the other browsers are saying. It is implemented in Chrome, but it's on hold on many of the other browsers. And really, that's just because we're waiting for the ES6 modules to land in browsers and to be implemented. And it's actually kind of a funny story the way this happened. As ES6 modules are landed, all the browsers figured, OK, you know, these specs are pretty far along. They'll be here any minute. And then we can kind of wait on how we decide to actually implement HTML imports to maybe take advantage of the same loader that ES6 modules use. So we'll wait for ES6 modules to land. Turns out, like these specs tend to sometimes do, take a little bit longer to actually settle into place with ES6 modules. And so as the ES6 module discussion was happening, at least in conversations that we've been having across browser vendors, there's been more attention focused now back on HTML imports, particularly as a performance primitive. Because with ES6 modules, you're blocking on JavaScript. With HTML imports, you get to take advantage, like Alex was saying, of all these great built-in platform browser optimizations to do background parsing of HTML, to queue up all the requests in an efficient way. And so actually, we've been seeing that HTML imports could be a performance primitive. One thing we're really optimistic about is as ES6 modules are starting to come together, there is a great opportunity to really marry HTML import mechanism, at least loading HTML with HTML that idea with ES6 modules, potentially even something along the lines of an HTML module that would interoperate perfectly with ES6 modules. So we've seen some experiments in this space, and we're really excited about it. So roughly, I think it's fair to say that everyone is generally on board with the idea of the need for a primitive to load HTML with HTML. The question is just how does it interface with ES6 modules, and we've got some pretty good ideas around that. Cool. All right. It looks like we have an audience question. Now, really quick, for all audience questions, I'm going to ask one favor of you, which is to please be considerate of the people who might want to ask a question also. So please know, like, I have a multi-part question, part 1A of seven-style questions. Having said that, OK, sir. Yes, you there. My name's Dylan. I work for Best Buy Canada. We're currently considering Polymer. We were wondering if you had any advice for transitioning your large applications in the past into modular components. I'm just going to repeat the question really quick. So do you all have any advice for transitioning your large existing application over to using something like Polymer? I'll take that one. We've seen customers do this before, where they have, inside Google, we have, I don't know, at least a dozen different frameworks that people use. And when they start using Polymer, sometimes they work from the leaves up. And they'll say, oh, I want to use the awesome material design components, because they need to be material design compliant. And they keep working up from the leaves, using buttons and inputs and stuff. And then they're like, oh, then I have this thing that uses a button and input. Now, I'm going to get Polymer. And eventually, they just don't stop. And they go all the way to the top. So I think when you get interop between whatever framework you have and web components, that's a good way to go. I think the bottom up and not stopping idea also kind of applies to a lot of the products that we've been shipping recently as the Polymer team. So particularly things like the Polymer app toolbox and the shop demo. We've got a few exciting demos that are similar to the shop app on their way. And the idea is it's a really great place to start, the Polymer CLI can download it as a template. It builds right out of the box. You've got a progressive web app in one command, which is great for prototyping and for having something up quickly within a day, within two days, three days to show an executive and really convince them that this is a great experience we can actually achieve. And similarly, we're seeing some people start there and then just kind of continue with that template until it becomes the full application. So similar idea, starting with what we've got as a starter template and then expanding from there. And with things like the purple pattern, really their scalability becomes kind of by default because purple is so, there's so much emphasis on lazy loading as you add pages to the application, there's no impact on that first load if you're constructing an application with a purple pattern with these templates that are built that way by default. So I encourage you also to kind of start in a prototype phase maybe with a new bottom-up app and then see how far you can get. All right, this is a fun question. I would like to make the panel squirm a little bit. When will Polymer 2.0 be released as production ready? I can take that one. So first off, we had this plan. It was well thought out for the last 12 minutes to bring the 360 view VR camera thing on stage. And we're going to give it its own spot and we're going to call it Blinky and we're going to throw all the hard questions to it. Last minute it didn't work out, so we came up here. I think the plan is roughly around January to have that come out with the elements and everything. It will come out when it's ready. But we had a stretch goal to try and get it done for the summit. That was sort of known tongue-in-cheek. I didn't want to tell Steve until kind of late, until they really started getting stressed out. But yeah, the idea would be the next couple of months. The holidays add at least another month to that. So that's the plan. One more thing to add is that we are in preview mode now. And I think we were in Polymer One, we got to a phase of Polymer One's development, where it became hard to change things because of the need to not break people. And based on your feedback on the preview, we're sort of in a nice period where we're still trying to maintain backward compatibility with Polymer One. But we have a little bit more wiggle room now. So I encourage you to please play with Polymer Two and give us feedback because it'll help us make it the best we can. So if Steve was like a little bit more devious, you would have realized that he could say something right now on camera about when it comes out that's much less ambitious. Hey, girl, 2017. Exactly. How may I have a computer near you? Absolutely as soon as possible. You could be a manager. OK, so I've got another question. This is one we get a lot. I would say this is like 60% of all questions are this question. What about using Polymer with Insert Framework here, OK? React, Angular, whatever. What about using Polymer with other frameworks? Rob, do you want to take that one? I'm good. I think we have to throw that one to Blinky. Oh, wait. Yes? I mean, I listened to Taylor's keynote yesterday. And what he told me was you don't have to throw out your framework. That's right. Because Polymer is based on standards, it will work with your framework. That's right. And yeah, maybe he can add more. Yes. So yeah, we do get this question a lot of the time. This is one of the big promises of web components. By having this web standard way to build a component, frameworks don't necessarily have to bring along a totally custom model to be able to get things like CSS encapsulation, like DOM encapsulation. So with Polymer 2 particularly, where all the things we've been doing to make it more interoperable, to strip away all of the Polymer-specific idiomatic things that you had to know that broke through that layer so that a Polymer 2 element is truly a custom element, it's going to be a lot, lot easier to interface Polymer 2 elements with existing frameworks. On the framework side as well, more and more frameworks have been evolving and shifting slightly to better support web components and custom elements. And I think we'll continue to see that in the near future from some of the big frameworks. And also, already there are existing kind of couplers that make it really easy to use framework X with Polymer element or framework X with web component. The bottom team was up here, they mentioned their Angular adapter, highly encourage you to check that out. That makes it pretty seamless to work with Polymer elements inside of an Angular application. So a lot of solutions that already exist, Polymer is making it easier for an opportunity to happen, frameworks are making it easier. I think this will be the continued arc of web components towards kind of seamless interoperability. So we're on our way there. OK, good. And reminder, again, we have these microphones, if you do want to get up and ask questions, don't be shy. All right, another question we have is, we heard from a number, we had partners here, we heard from a number of those partners that they ran into situations where they had too many components. So is having a MyApp element still a viable approach? When is the right time to create a component? Sorry, that's a bit of a few questions called jam together there, but it's a little. Well, yeah, sure, I can handle that, I guess. So I think this is a hard question to answer, because as with many things, there's not really one size fits all. I think it's perfectly fine to have one element that defines your application. If you're using the purple pattern and delivering a small bundle, the bundle for that is going to download and render quickly the resources. So that's pretty straightforward. I think in my talk, I emphasized that focusing on very specific, high frequency elements that you want to make as fast as you possibly can, having reasonable goals for those, and being careful in those elements. And I actually got some feedback, which was that the thing I was saying, do less and be lazy, actually sounded really hard. And so one thing I can say about that is that because we're using web components, the good news is that the hard work that anyone does is something that all of us can leverage. So that seems potentially good to me. So as long as someone figures out how to make a thing fast, we can all benefit from it. And then I think there's a lot of really specific questions that have to be answered in the context of your application. But from a performance perspective, I think just keeping in mind that the cost of the element should match the task that you're trying to have it do. So where you need to make a lot of things, make them as cheap as you can. So one thing you can think about it is that creating a custom element isn't free. You've got a tiny little bit of cost with every custom element that you have. So if you're going to just make a custom element to wrap a span, that's not really worth it. You could just put a class on that span, especially if you're going to repeat that span a lot on the page. But if it's a little bit of a sizable amount of DOM that it's hard to style and copy-pasting it in different places in your app is really annoying, that's a good place to put a custom element in there. Luckily, we never said everything is an element or anything like that, so we didn't encourage the wrong people. Yeah, we never made any DOM packages. We never did that. All right, we have a question back here, sir. This isn't exactly a Polymer question, but it's future-centric and it relates to our stuff that we do. What's with WebAssembly? When does that arrive in the real world? And what goodies do we, can we expect from that? Maybe perhaps related to Web Components and Polymer? I'm scanning the room for V8 people. There's one right behind you. There's Adam behind you. Yeah, you're sitting right next to him. I don't think we really know up here. No. WebAssembly doesn't impact Web Components that much. I mean, I don't think it really has direct access to the DOM right now, so. If you're writing a game, yeah. But he found his person, he's hunting them down. They're in the back corner. Standing up. Somebody move on. So this is a good question, because I see a lot of people, they ping me and they're like, I wanna make a thing like paper input. I don't, don't do that. As I've been doing a lot of accessibility work lately, I've realized, input gives you a lot in terms of accessibility and things like that. So the question though is, how do you leverage semantics when you're writing a component? So for instance, if you are trying to write something like input, and there are reasons to perhaps, you know, wrap some of these components. So how do I leverage existing semantics inside of a custom element that I am creating? And I think that might be a good question for Monica. Why do you mean exactly by leveraging existing semantics? If you were to redo something like paper input, how might you go about doing that? Paper input in particular is enormous. It's like a hydra with 17 heads. So it should be 17 sub elements instead. What paper input does, because it wraps an input in its shadow DOM, it has to channel all of the properties that you could set on an input and sort of expose them to the paper input itself. So we have a behavior for that, which basically defines every single property that input has as a property that paper input can have, which isn't great. But if that's the thing that you wanna do, you can do that. The reason why I'm saying paper input shouldn't be like it is is because it should be something like paper text input and paper number input. And it could only have like three or four of these existing properties that it needs to pass down to the input. I don't know if that's answering your question. Sounds correct. We also try to, this is sort of tangential, but we try to mimic in our custom elements what the platform chooses to do. So paper checkbox has a lot of the semantics that input type equals checkbox has, for example. It doesn't look like input type equals checkbox, it has a completely, like, it's called paper checkbox, but it has the same sort of, it has a checked attribute, it has a fairly quirky value where it's on or empty because that's what the input type equal checkbox element does. And ideally we like it that you could replace wherever you're using input type equal checkbox with a paper checkbox and have the same semantics without you being freaked out about that. Yeah, and that's, honestly, I feel like that's one of those things a lot of developers overlook is semantics and especially how they relate to accessibility. This is about it. A lot of people are like, well, you know, I don't even know if I have any users that need this. There's about a billion people worldwide that have some form of disability. And so if you are creating a widget that already has an existing analog in the platform, you really need to make sure that you are adding back in all of those semantics and the proper accessibility and keyboard support and stuff like that if you're not gonna be using that existing platform element. Which is why, for instance, I often tell people, just use button, okay? Like button actually, it seems so simple. It does a lot for you. And there's a lot of stuff you probably don't wanna add in that you're gonna have to do if you need to turn that into a custom element. You totally can do it. And my friend Eric Bidleman has done a talk at the PWA Dev Summit on exactly how to do that, which is a great talk that you should all go check out. But remember, the platform is trying to help you here and give you a lot of stuff. So when we say use the platform, it also means just leveraging vanilla HTML where you can. I just add one more thing. Yes. So I just wanna come back quickly to the loss of is in V1 custom elements. I just wanna get back to that because this is one way you could in the V0 custom elements leverage existing semantics here. And doing it yourself with implementing all the accessibility of yourself is hard. So I mean, we on the team basically really like this idea of is and it's still in the spec and it's probably gonna be implemented in Chrome and we're arguing for it. It may evolve kind of one of these things. This is why we're not really recommend using it going forward for now is because the support may evolve. I think there's general agreement, my sense is, there's general agreement this is incredibly valuable to be able to leverage these capabilities. But the exact way that it happens is tricky and there's some nasty things about is like the, we actually engage then directly with the old legacy built-in elements like input and like input uses a shadow root and therefore you can't add your own. There's a lot of tricky stuff there. So, I mean, this is a little bit of a, there's still I think a little bit of a growing pain here that hopefully it will evolve relatively quickly. Oh, fight for the people to get is back, don't worry. So we have two questions, but I'm gonna hold you for just a second because this question is one that we get asked. This is probably the second most popular question. I really want you all on stage to answer this. How does SEO work with custom elements? Can shadow DOM content be seen by a search engine? You actually answered one of the audience questions. Nice. Yes, so, we do get this question a lot. It's not a yes or no. The short, yes is the answer. The short answer is SEO with Polymer web components is absolutely different than any other front-end JavaScript-based framework that you work with, period. Right now, no web crawler that I know of actually natively supports shadow DOM, so it's not even a question of actual shadow roots. You need for a web crawler to see your page, you need to include the polyfill anyway, so right now it's irrelevant, and now that web components are in the spec, I highly, highly expect that anyone who might build a web crawler for search would very likely probably look inside the shadow roots as it's part of the HTML spec and something that's gonna be used cross-browser. Well, I think the most important thing to acknowledge here is that crawlers run JavaScript. I don't know if everybody knows that, but the crawler will render your page internally as it goes. Yeah, exactly. It's a blog post on the Google Webmasters blog. I don't have it like the URL top of mind, but it's from maybe about a year ago where the team said, yes, that the Google crawler at least does run JavaScript for a brief while against your page, so if you can dig up that Webmasters blog post that's in there, which would give you time to bootstrap some components. Yeah, yeah, and so for obvious reasons, I can't go into too much detail as to how these web crawlers work or indexers work, but I do highly, highly recommend, if you're skeptical about how your site is getting indexed, I highly recommend checking out the Fetch as Google tool, which is part of the Webmaster Tools set, and what you can do is go in, give it a URL of your page, and actually see how Google's crawler sees your page. So recommend you do that. You can see, make sure that it shows up the way you'd expect. Another nice little tip is the site colon query is a very valuable query to use. So if you're skeptical that, you know, Polymer-based, you know, my app, apps get picked up by the crawler, I encourage you to go Google search right now, site colon shop.polymerproject.org. If you view the source of shop, you'll just see one tag and that's it, that's the entire DOM, but if you site colon query, you'll see that everything gets picked up by the crawler. So I highly encourage using that Fetch and render as Google tool in Webmaster Tools. Okay, you have patiently been standing, so you go next. Hi, I'm Sam, I'm from Brainlap, and my question is about supporting old browsers in particular, like Explorer. Is it still in plan or feasible? We support IE 11 and Edge. We still support 10 a bit, too. Mm. Mm. I mean. So Monica made that noise, you know, audibly. Steve made a much worse noise in his head. We want to end support for 10. We do not list IE 10 as supported on the Polymer website, if you had checked it recently. So, yes, so technically. Oh, God, we have a PMG transfer list. IE 11 and up is supported, we always used to support IE 10 until Microsoft end of life, IE 10 across most Microsoft platforms. And so we decided, well, if Microsoft can do that, it's probably a good time for us to do it too. But, and the reason that being is IE 10 support, because of some flakiness and some features, it adds a lot of complexity to the polyfills. So that's why we're like on the fence here, is that for most cases, everything should work fine. You might see a touch of flakiness, which can be fixed if you drill way down. If that's worth it for your set of users that are happened to still be on IE 10. So that's the end. Please do not open issues on Polymer elements if they don't work on IE 10 though. Don't want to fix it. Thank you. Thank you. All right, over here, question. Hi, I'm coming right back from PGS Software. And I have a question about, because Polymer 2 leveraged a lot of ES6 syntax. And you have your tolling. But in my project, for example, we are using a lot of Babel and everything. So we would want to make more custom builds. So, but I saw yesterday that you were using the getter-setted syntax, and using pro, adding the service worker by magic. So if I prepare the output from Babel, so transpilot, it would be still be able to add this service worker, and it will be work on Polymer 2? Yes, I mean, there's a couple of ways that we want to integrate compilation into the workflow. One is that the Polymer build library, the reason why it's broken out the way it is, is to let you plug in things like, go Babel or something in that pipeline in the appropriate place. It turns out that the type of compilation that Babel does to output ES5, generally preserves the ability for the analyzer to recognize that there's an element there. There's some cases where that isn't true. Like if you're using TypeScript with decorators, that would output something that's very difficult for the analyzer to recognize. So our general approach is that if you want to run analysis on your program, you want to do that before you've compiled it to make sure that it's looking at your original source. We're adding a compile flag to the CLI to kind of give you like a default good compilation via Babel and we're gonna add the ability for that to pick up the Babel RC file out of your project and take out what settings you need there. But in general, it should play nice. And the service worker, the way we determine what needs to be in your service worker is by crawling the HTML import dependency graph. That's not changed by Babel. So there shouldn't be any problems there. Okay, thanks. All right, I have a question for our product managers, Wendy and Taylor. What can non-Google developers do to get better support and feedback for issues and PRs for Polymer and Polymer Elements? But basically, a filing issue, how come it's not fixed? You can email me personally, it's Taylor Savage. I don't know. Thanks, Matt. Well, first of all, I really appreciate when you guys do submit feedback. So thank you to everyone who does that already. That's a big reason why we're open source. We love getting that feedback and PRs from other people. I mean, a lot of our channels on Slack, like we have tools channels, and those are smaller generally. So if it's tools related, Justin, Fred, Peter, they're in there. We've got some other channels up there. Usually we're on general pretty frequently. So if you've got a question and you might wanna stick that in there, you can get information. Contact us on Twitter. There's a bunch of ways. If you find like it's a pretty regular thing, feel free to bug us. And we'll get back to you. We'll try to. Yeah, the best way by far to get quick response on a bug is make it a really, really good bug. Meaning detailed repro. If you can get to it, example of even a JS bin that shows us, wow, what the bug actually failing. Those help us triage because we know that there's not gonna be a ton of overhead just digging down to a root cause. It helps us also just kind of get a feel for how serious you are about getting this bug fixed, in a sense, how much it's impacting your project, if it's worth actually putting that together. So obviously we get a ton of bugs on the Polymer project across our Polymer library, our 100 plus elements, our dozens of tools. I really do wish that we had infinity engineers to fix all the bugs all the time. And we are fortunately backed by Google, which allows us to have awesome resources. But when it comes down to it, we are still a small team of just people. And we have hundreds of repositories that have issues on them. It's really, really hard to manage. Yeah, yeah, so we do our best. We really do appreciate issues that come in. We're always looking for better ways to better processes to triage and get bugs fixed. And we especially appreciate the really detailed bugs. Those help us a ton. And if you're nervous about sending us PR is we really, really like PRs. So even if you're not super confident in your fix, you can be like, I've got an idea for this. It's probably not great, but it will work with you to improve your PR because that's much easier on us rather than starting from scratch, so. You know this is recorded, right? We're gonna be able to use that again, see you later. Thanks. No, I mean, longer term there's also, I think we've been doing a lot of things as a team, having our own element catalog and things that have sort of gotten in the way of the ecosystem that might otherwise solve some of these things. So I think you're gonna see us very, very soon. I mean, step one was just the beta of webcomponents.org, getting out of the way a little bit more and allowing the community to thrive and start to respond to things a little bit better too. Yeah. So again, it's taylorsavage at gmail.com. Right here. I hope there isn't a... I know. Probably is. Sorry, dude. Docs here. Probably actually his. He probably just gave away his personal email. Did you just doc's Taylor? We know Paul Irish is, so that's the thing about that. I think it's an Irish on GitHub on our issues. It'll be great. Right here. Right, hi, my name's Thomas. As a remark for SEO first, maybe the best advice would be use schema.org for the time being. Sorry, what was the question again? Not the question, but remind us with regard to SEO. So maybe schema.org is the answer for the time being, right? But my real question is about inputs and shadow DOM within forms, because when you have fields inside shadow roots, forms doesn't work. I mean, validation breaks. So does it really work? Will it work? Or maybe I'll just have to put everything in light DOM. Yeah, so the question again is native form element. I want to put custom elements inside of it. That does not work. WTF me. Rob, do you know anyone who knows about this? Yeah. I don't know. Anyone in the middle? That's my question. Get out of the way. So this is a seven part answer. No, I'm kidding. First of all, I actually just did a polycat. The outtakes that you saw this morning were for me trying to record two polycasts about exactly that using custom elements in forms. And the punchline for now is you can either copy the value that you want to a hidden input, because the form only cares about the input tag at the moment, and that's baked in the parser. It's kind of really hard to change. So either you copy your value to an input or you put that input in the light DOM. If it's in the shadow DOM, you have to somehow copy the value to the input if you want to use a native form. We are trying very hard to work and change the spec in this, but the problem isn't that it's not a spec changing problem as much as it's literally barked baked in the parser. So the parser will see a form and then only look for input tags. And changing that isn't exactly straightforward. Blink engineers have a panic attack when you tell them about changing the parser. I am desperately trying to add spec to this to make you be able to get input functionality. And again, the is equals attribute helps a lot with this because you could be able to extend the input tag and make your custom element basically fake that input tag which would make it work with forms. All right, we have like one minute left, so we're gonna go kind of lightning round here. I do wanna try and get to some more of these audience questions, but this one question is pretty important. How long will Polymer 1.0 be maintained now that Polymer 2.0 is a thing? Yeah, what do y'all think about that? As long as it needs to be. Remember, it's Taylor Savage at Gmail. Taylor, you know this is recorded, right? And I think we've hopefully made it pretty clear throughout the conference how much we care about upgrades and upgrade paths and upgrade cycles and making it as easy as possible to upgrade. We feel that pain on the Polymer team. We feel it within Google. We see it throughout the ecosystem. So we've really taken that seriously with Polymer 2.0 and all the tooling around it and hybrid mode and all the documentation that's coming. So we hope that the upgrade from Polymer 1.0 to Polymer 2.0 is fairly straightforward, certainly not. And I know many people mentioned about being around from the 0.5 to 1.0 upgrade, which was one of the moments where we really learned this lesson hard. So should be fairly straightforward to upgrade. I encourage everyone to try to as soon as possible. That said, we expect Polymer 1.0 to it's a huge dependency inside of Google itself. So we're certainly on the hook for supporting it for at least many months, years to come. I have one tiny addendum to that. Will the V1 web component APIs be supported in Polymer 1.0? That's not currently planned. But based on feedback, we'll see. Yeah, so that's kind of more gets to when would the threshold for V0 usage get low enough in Chrome? Because Chrome has shipped it, other browsers have not shipped V0, which is what 1.0 is based on. So it's really a question of it's still baked in Chrome. Right now, V1 is also supported in Chrome side-by-side. So you can use V0 and V1 on the same page in terms of web components, totally fine. So really that won't matter unless V0 usage gets to such a low point that Chrome can take it out its report for it entirely, which would be fairly well into the future. And just a technical note, I mean, one thing just to be clear, the V0 and the V1 specs are not hugely different, but they're different enough that frankly having both in play on the same page is just not something that makes sense to really contend with. So kind of having Polymer 1.0 have that sort of mindset of having to deal with both V0 and V1. It's just a world of pain we don't wanna try. And this might also be a good reason to look into hybrid elements in Polymer 2.0 if you sort of need that transition path. Okay, we are over time, but I would like to take one last audience question because you've been standing very patiently. So sorry, everybody else. If you tweet at Ask Polymer Summit, I will go back and try and answer all of those on the Twitters. Rob, you know this is recorded, right? That's fine. Rob Dodson and everything. Shut up your mouth. All right, yes, you. Hello, I'm Maxim from Best Buy Canada and we've talked a lot about performance optimization. And I would like to know is the purple pattern meant to replace completely server-side, any server-side rendered templated? Let's talk about server-side rendering. Well, I think server-side rendering is a really interesting question. Like, we need to look at how it actually relates to, you know, pushing less for your initial render. But I was actually talking to some engineers who work on another framework, Framework X. And we were talking about server-side rendering, and I have this analogy with that, where server-side rendering is kind of like data compression, right? A component is like, you know, a compression, you know, using a component is like using a compressed format of like your component definition. And it should be cheaper to use a component than to expand that component everywhere out where you use it, right? And so server-side rendering is kind of like decompressing your data, sending the uncompressed data over the wire, and then recompressing it once it gets to the browser. And this should be bad, right? And so it should be faster to send, you know, your decompression, which is your component definitions and that, and get it all down there. And this engineer said, yeah, you know, once we split up our application so that we're only sending what was needed for the first route, it was faster than server-side rendering. I think our challenge with web components is that we don't have an existing server-side rendering solution that we can compare against. But it certainly seems likely to me with the purple pattern. And if you're rendering as soon as you possibly can with the minimal resources for that route, that it's gonna beat server-side rendering. And it's also gonna give you a less complicated, you know, setup and server. So we need to measure it to be short, but that's my hunch. Thank you for that question. All right, that is all of our time. Please give a round of applause to our lovely panelists.