Use web components for what they’re good at with Nolan Lawson
===

. [00:00:00] Hello, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it for free at logrocket. com. I'm Noel, and with me today is Nolan Lawson. Nolan's a web developer at Salesforce who recently published an article titled Use Web Components for What They Are Good At.

He's here to... Talk about that article with us today. Welcome to the show.

Hey, thanks for having me.

Yeah, of course. I'm excited to chat. I feel like web components are one of those where they're in and out of everyone's, realm of consciousness every few months. So it's always interesting to dive back in. But before we do, can you give listeners a, an overview of who you are and your journey can into web development.

Yeah, sure. So hi, I'm Nolan Lawson. I'm a software developer at Salesforce. I've been doing software development for about 15 years. I've bounced around a bit. I've done mobile, backend, front end, but for the most part, recently I've been focused on front end and [00:01:00] JavaScript.

Nice. Well, who better to be chatting about web components with? So yeah, I guess let's just Talk through the posts and your motivation a little bit. You started out and addressing some of the I guess an existing blog posts by Dave Rupert, where he talks about why he doesn't use web components.

Why do you think a more nuanced approach is useful?

Well, so full credit to Dave, Dave's a big fan of web components and, he's been involved in the web components community group. I think it's a great post. I think people should definitely read it. I think it gives voice to a lot of developers who maybe have heard about web components, I've heard that maybe it's something they should look into, but haven't seen a compelling use case yet.

And I think he gives a good explanation for why those developers might not have been persuaded yet. It's definitely worth reading from that perspective. What I was trying to do in my post was just frame things from my perspective that I have on web components, which is that.

I don't really see it as like this war between frameworks and component and when components like, Oh, react is amazing. You should just use [00:02:00] react and web components suck or a web components are amazing. Stop using react, stop using frameworks. To me, I see it as just another tool in the toolkit.

And I was interested in answering the question of what is this tool good at? What is it not so good at? And what are the really good clear use cases for it, I see versus the ones where it's maybe not quite so applicable.

Yeah. So that, that, that makes sense to me. So . What are those use cases? What are web components particularly well suited for?

Yeah, so the first case I bring up is to me like the most clear cut case where Web Components can just be extremely useful, really almost no downsides whatsoever, which is client rendered leaf components. So what do I mean by that? Well, a component that is at the leaf of your DOM tree, so it's at the edges of your DOM tree, right?

And is fully client rendered, like doesn't need to be server side rendered. And some examples I give of this are something like a calendar widget or a rich text editor or a color picker or something like that. And what's interesting about these kind of components is, so they don't need to be [00:03:00] server rendered typically.

Usually they're going to be activated on a user input, like a click or something. So, and if you're thinking in terms of progressive enhancement, like they are the enhancement. In a sense the rich text editor is probably, if JavaScript is not running, it's going to fall back to just a regular text area, something like that.

So in those cases, I think that web components are really well suited because what they do is they give you a very. Consistent standardized basis for how to pass data down and get events back up. That's basically all they do. And so the example that I give is I wrote an emoji picker, for instance, which I think is another one of these nice client rendered leaf components.

And, to use this thing, like all you got to do is just drop in two lines of HTML, basically. You just need a script tag and then your emoji dash picker tag. And that is really revelatory, honestly, for people who are. Overwhelmed or intimidated by all the, rampant complexity we have in the front end ecosystem, people who don't want to deal with bundlers and and NPM and node and all [00:04:00] this kind of stuff and frameworks, you can just plop it onto your HTML and then go for it. But then at the same time, like I've seen this project used in very complex SPA projects, using react or using Svelte or using whatever framework people feel like using. So I think that is a really good story of how web components can run that gamut.

For different web developer use cases.

Yeah. Yeah. That makes a lot of sense. Is there, when a dev is looking at their code base and they're hoping to maybe get their feet wet a little bit or are there particular leaf nodes? Like these are the very, like the edges of these branches that are well suited to web components.

Or is there something in particular depth should be looking out for or could you make the case that like, and basically like any little independently rendered leaf that has some kind of interactability should be web

Yeah. So I would take a step back and clarify that what I'm not saying is that in your existing app right now, which is written, let's say entirely in react, I'm not saying that what you should do is you should go through and every single color picker and emoji picker, whatever else you have in there, that you should go and convert [00:05:00] that to web components today.

Like that's not really going to buy you anything. What I'm saying instead is if you're in the market for one of these things, if you're shopping around on NPM. And you're saying to yourself, I'd really like a good emoji picker. I'd really like a good rich text editor. What I would advise is to maybe not buy into the sort of what I call framework chauvinism of this idea of Oh, my app is written in solid.

I must find components that are purely written in solid. Or, Oh, I'm using Svelte. I must find components that are purely written in Svelte or Vue or React or whatever. Like it's, as I mentioned, it's like client rendered leaf component. Like all you need to worry about is how you pass those props down and how the events come back up.

Web components have a really well defined contract for that. If there's a web component out there, that is good. And, meets your criteria based on performance, accessibility, design, whatever other criteria you have. Like when I use it, regardless of whatever framework you happen to be using in your app.

That's the argument I'm making for where Web Components are just like unambiguously just a good choice in this case.

So why not? Why not go down that first path, the chauvinistic path of, just [00:06:00] googling NPM, finding the react, whatever date picker you want to use and going with that.

Well, you can certainly do that. There's nothing wrong with it. I mean, In the React ecosystem in particular, that ecosystem is huge. And you know, you're spoiled for choice when it comes to emoji pickers and date pickers and anything else you want. My point is just, I see our industry rebuilding the same things over and over again.

And, like you take my emoji picker, for instance, I think the least interesting thing about it is what framework I chose to use to implement it under the hood, I expose it as a web component. I happen to have used spell to write it, but that's almost incidental. It doesn't really matter.

Like the most interesting thing about it, I think is, I focused a lot of performance. I did some things like I use indexed TV to store emoji data offline so that it uses less memory and it's more offline friendly, like all those things have nothing to do with what framework it was authored in.

So I I think it's interesting to maybe look at. Front end development with a little bit more of a balanced perspective and a little bit of a less, a little more unbiased perspective towards frameworks, instead of asking ourselves [00:07:00] what framework was this component written in?

And, based on that, is it suitable for my use case and treating frameworks more as like an implementation detail, like in the same way that I don't care if an off the shelf MPM component was written in TypeScript like it doesn't matter, there are more important fundamental things that, that I'm going to use to evaluate that component.

Yeah that's a, that's an interesting point. So I feel the impulse there is devs like have this idea of. Like a purity maybe is the best word I can use in their front. And they're like, people see jQuery in a react app. They're like, Oh gosh, like I'm running two of these things.

, do you think that's misguided? Do you think that there really isn't much, functional utility to that kind of knee jerk reaction anymore? And if so, why do you think that is so prevalent?

So, yeah, it's funny. I have a whole separate post about this that's linked from that post. But so basically I think that feeling comes from a few different places. I think some of it comes from a good place and some of it comes from a not so defensible place. So like the good place that it might come from is let's say like you're a react developer [00:08:00] and you're really comfortable working with react code.

And then as soon as you dip down one level below, and you're dealing with the raw DOM API, suddenly you feel lost, you don't feel like you can debug. An issue if it comes up, if that's the case, then you should definitely live in react land. Like you're probably going to be much happier there.

I think that's like a reasonable argument for that kind of framework chauvinism. What's less reasonable in my opinion is the idea of Oh, this webpage has two frameworks on it. That, that's gross. Like, why is it gross? What are you worried about? Are you worried about the extra bundle size?

Because as it turns out, like most frameworks nowadays are actually pretty small. Like I think lit. Clocks in at five kilobytes, I could say it's almost nothing like, you, if you're worried about extra kilobytes on your page, like you might start looking for, I don't know, how many versions of lodash did you load?

How many versions of moment JS do you have on there? Those are much more common scenarios that I think developers run into. They can really lead to bundle bloat. Now that said, if you're working on an extremely performance sensitive e commerce site, where if it loads 10 milliseconds slower, like you're going to lose, X.

Millions of dollars or whatever, absolutely every kilobyte counts. So that, and then, [00:09:00] and in an ideal world, you would implement your entire app in only one framework, but oftentimes let's be honest, most of us are working with deadlines. Most of us are working with not perfect technology.

We're working with, teams that have strengths in different frameworks and different stacks or with legacy code bases, where we have to migrate from one to the other. And I think in that kind of real world scenario web components can be useful as this glue layer or bridge layer between these frameworks.

, I think It's an interesting approach. And I think that there's maybe devs don't really think about these abstractions when they're going to reach for they're going to find some emoji picker, for example, if we can keep, if we can keep using that, 

they don't really view it from this perspective. They just find the thing that would be easiest to integrate. So there is an interesting dichotomy there of do I go for something a little bit more agnostic that I could then move around if we ever change frameworks or it's written in a way that everyone can consume it versus it being specifically written for a specific, a given framework.

Have you noticed any trend in, in these in people who are [00:10:00] writing these little more Agnostic framework, agnostic components that can be consumed by anything. Has there been a shift that direction at all? Or do you think that kind of there's still a lot of people writing their react specific emoji picker and the spelt specific

Oh, I think there's definitely still some of the, ecosystem and specific work that's going on, especially in the big ecosystems like react I have noticed that web components are starting to get more and more popular in certain. Areas, like especially design systems. So this is something I bring up in the post, which is that, more and more big companies, especially when they're building design systems, they're choosing to build them with web components.

And when you think about it, it makes sense why they would do that. At a big company, when you're building a design system, like what's your number one goal, your number one goal is to get people to actually use your design system, right? So that everyone's on the same page. And you have consistent branding and theming and everything across the company.

And that's actually a really hard thing to do because, your company might have teams that are building front ends written in Angular and react and view, or in some [00:11:00] server rendered framework, they're not even using much JavaScript. And in those kinds of environments, like how do you write something that everyone can just pick up and use, the consistent experience across all those different stacks.

And not be tempted to just write their own and maybe, not, and then not use your design system that you're trying to get everyone on board with. And so from that perspective, web components are perfect because, many, many modern frameworks support web components. , there's a benchmark called custom elements everywhere that actually measures this.

That basically tells you how easy is it for you to take an off the shelf web component and embed it in your framework of choice. And you can, if you go visit that, you can see that frameworks like Vue and Svelte, these support web components with a hundred percent faithfulness. React is a little bit behind, but I apparently they're working on fixing that in React 19.

And even so, I've integrated React with web components before, and it's not a heck of a lot of work. You have to write a little bit of glue code between the two. There's projects out there that'll make this easier. This project out there that I linked to called Remount that will take a React component and bundle it up as a web [00:12:00] component.

So then you can take that React component and effectively use it anywhere. So I've seen web components grow in popularity for those use cases where they really prize portability.

Why do you think of that? That seems like such a useful attribute, right? And I think that most people are thinking about web components. It seems very intuitive. Yeah, this seems like an abstraction that we should be. Putting on top of everything. Like, why do you think web components haven't become more pervasive?

Like how come this isn't the standard way that everyone is pulling? Any kind of shared logic down in packages.

Well, I think part of this is a perception problem, which I mentioned in the post. So I linked to this web almanac study that said that React is used on roughly 8% of page loads. And then you compare that to the Chrome data that they provide, which puts web component usage specifically custom elements at about 20% of page loads.

So, and by the way, I'm not saying this, to try to like, gloat and say Oh, like web [00:13:00] components are so much more popular than React. This is just one metric but my point is there could be a lot of quiet usage of web components out there that developers who get all their information about budget from let's say, Twitter or Reddit and social media in general, they might not realize.

And one of the things I bring up in the post is that I think that web components are starting to become very popular in enterprise use cases. And again, at big companies. And these companies aren't necessarily going out there and talking about it all the time on Twitter and, trying to sell people on web components.

And so from that perspective, like if you're just browsing Twitter and, reading what, tech influencers on there are saying, you might get the impression that, wow, react has won or oh, it's really, it's a battle between react and. Svelte and solid and view. And then in the enterprise, in big companies, it's just, it's a totally different world.

I think it's just interesting because the conversation like, yeah, maybe the public conversation specifically does seem like it ebbs and flows so much around web components. Like I opened with, it feels every few months, it's okay, everyone's talking about web components again.

Then nobody is for a while. And like there. dead tech, nobody's [00:14:00] using them. And then everybody's Oh yeah, actually we should be using web components. And it's just it's bizarre. Like it feels like this bizarre abstraction layer in my head where everybody thinks it would be useful, but then a very low percentage of devs, just anecdotally in my perception are actually talking at least about using them day to day.

Do you think it's. Possibly the case that a lot of libraries are things that people are pulling off the shelf, have some dependency within them. That is a web component. So they end up or is abstracted via a web component. So they end up using one inadvertently without even realizing that they are, like a dev is using one.

Oh, it's quite likely. If you're pulling in third party dependencies, third party components, and you're not looking too deeply under the hood, then they could be using web components. You could be using a react component that is actually just a very lightweight wrapper around a web component. Why people aren't talking about it anecdotally, I don't know. It's anyone's guess, maybe, honestly it might sound like I'm trashing web components here, but they're not very exciting.

Yeah.

Web components are, it's a browser standard and it moves super slowly [00:15:00] and, you measure new features in terms of years, not in terms of weeks or months, right?

There's not a whole lot of news every single week of what's new in web components this week, right? It's more like what's new in web components this year, like this browser shipped this new. Feature of Web Components, maybe for that reason, it's just it's less like the talk of the town than whatever frameworks are working on, which is a lot more dynamic and, a lot more interesting day to day.

Yeah, then is your thesis that long term that it will become more of the norm that when devs are looking, going, pulling libraries off the shelf to, help them implement an emoji picker that this will just become the norm. Like this will slowly take over how we kind of piece together apps.

Yeah, I think that Web Component usage will continue to grow. And I think there's two main reasons for that. The first one is that Web Components have a unfair advantage, which is that they're just in the browser. You don't have to go and install a separate library or framework to use them.

And so for that reason, like it's just really easy to get started with them. , The second reason is that I think that web components will become more and more popular as people see them as a solution to the [00:16:00] problem of framework churn, like one of the things I bring up in the post is I think we've all had this experience as web developers where, you take your average Node NPM front end project and you leave it alone for six months.

You come back and look at it, you do npm install, and you've got, five dependencies that are out of date by at least two or three major versions. You bump one version and it breaks the other one. And you bump that version, it breaks something else. And, there's just a lot of churn in keeping up to date with a lot of front end technologies.

And you compare that to the web and the web is forever in a sense. Like browsers take backwards compatibility and stability very seriously, to the point where I, the Space Jam website from 1996 still works today in modern browsers. That is amazing. That is an amazing promise of longevity that the browser gives you.

And so I think more and more people will notice that, wow, if I write my component in a framework X, like it might become out of date when that framework releases a new major version bump, or it might be that, I have potential consumers who tell me, I'm sorry, I'm using [00:17:00] framework Y or I'm using framework Z.

Like, how do I use this thing? And if those folks just go and, package it up as a web component, it's standard interoperable format. Then they might find that not only does it have. Better longevity, but there are more people who are willing to use it because it's just easy to plug and play into their framework of choice.

Is there any fear? I haven't really thought about this much. So this is like a question I haven't considered. Is there any fear like with this abstraction layer? Say, again, say you've got a web component written in Svelte, right? So like that component is all abstracted, modularized, and wrapped.

But then I don't know. There's some major version updates happen to Svelte, like a secure, like a vulnerability or something crops up and it needs to be fixed. It seems like easier, more tangible if I'm using like npm packages that are just Svelte components and I can pull those out and use them than if there is an abstraction around it, like a membrane that is the web component standard.

May make it so I'm not quite as aware that there is possibly a vulnerability or something in a component I'm pulling down. Is that a real fear or do you [00:18:00] think that is like handled by, the community and having lots of eyes on these projects,

Oh, that's an excellent point. I think that in general, most of these security vulnerabilities are usually in our tool chains themselves and not in the code that actually runs in the browser. So I think that inherently lessens the possibility that something's going to go wrong here.

Like the most, the most likely thing that's npm ecosystem is you npm install something. It has a post install script. And it tries to read files off your local machine, right? If you're using a pre compiled web component that happened to have been implemented in Svelte, if you go look at my web component, for instance, like under the hood, like Svelte is not doing a heck of a lot.

It's calling, it's calling element dot append child. It's calling element dot set attribute. Like it's not very complicated. It, you're absolutely right. Like it is possible that. If you put too much stuff in there, right? If you rely too much on some, kitchen sink framework that is doing too many things and if people are not looking at that very closely, then yeah, you could run into a problem like that.

Yeah. Maybe security was a poor example. I don't know. I'm just thinking of. Like updates I've seen, maybe like [00:19:00] accessibility or something, just, I don't know, something that like one could audit over their code base more easily if it were more tangible, but having that membrane could isolate it a little bit.

But again, I'm not, I have never seen this in the wild as a real concern. It was just a curious occurrence to me there. But let's talk a little bit about like how SSR plays into this whole conversation. Cause I feel like that is it's been on everybody's minds for the last couple of years.

How. How do web components when one is thinking about this what is the relationship between SSR web components and how one could go about implementing, a web component with if they have a highly optimized server side rendered site, does this kind of just go back to what you started our conversation with, where you recommend only like the client rendered leafs be componentized?

Or is there some middle ground there that can be leveraged a little bit?

Well, so let me preface this by saying let me be clear, like web components can be rendered server side. And in fact, there is a new browser standard that helps out a lot with this, which is called declarative shadow DOM, which is now shipped in. Safari and Chrome and allows us to actually [00:20:00] render Shadow DOM trees from the server side in HTML rather than having to do it on the client side.

That said, I feel that the server side story for Web Components has not really been written yet. I think it's still a little bit rough out there and that's why in the post I'm saying that If something is purely client rendered, like it's just, you don't have to question is it a good idea to use Web Components or not?

Whereas as soon as you start talking about server side rendering, then the story gets a little bit more complicated. So, and the reason that is, is because there is no standard for how to render a Web Component server side, right? Unlike on the client side, where there is a standard contract that is defined by the browser that says, here's how you can compose a frame, a component written in framework A inside of a component written in framework B, or vice versa, there is a standard way to do that.

On the server that doesn't really exist and it's the same for hydration. So for SSR and hydration, every framework does it differently. And if you are using, let's say like a meta framework, like next or next, and you want to leverage web components and [00:21:00] you want to render them server side. Well, you have to basically hope that your meta framework has an adapter for that framework.

So to give an example I know that Lit has an adapter for Astro. So if you're using Astro, you can render Lit components, right? You can render them server side, you can render them client side. Does that mean that you can render Stencil? Which is, another framework that uses Web Components?

No, because it doesn't have an adapter for Sensible. Actually, maybe it does now. I'm not

Yeah.

But my point is, someone had to go out there and write a special adapter to tell the meta framework, hey, here's this framework, and here's how to... Here's how to render this component as an HTML string or a stream of HTML on the server side.

And so what that means is that if you bought into a meta framework, like if you're living in Next or Nuxt or Spellkit or one of these things, like you're in a sense already all in on a framework. Like your metaframework knows how to render that framework really well. It may or may not know how to render other frameworks.

Like I think Lib has an adapter now for Next. js, but it's a totally different story than on the client [00:22:00] side, where on the client side, like you don't even have to know what framework a component was authored and that's just an implementation detail. Just grab it off the shelf, go and don't worry about the details.

So that's why I say that the SSR story is a little bit complex. I can see this being improved. I, the standards groups are well aware of this. They're well aware that the conversation has shifted a lot more in recent years in the web dev. Ecosystem towards server side rendering. And so now in almost every standard discussion related to web components, there's the question that comes up of how is this going to be rendered server side?

Can we make this interoperable between the declarative format and the imperative format? So that is definitely a consideration that's coming up a lot recently, but I would say it's still not a fully solved problem.

Yeah, and it seems like it will be a pretty hard problem to solve. Do you see a path here where this is easier? It is easier for you as, one, as a user to like, pull web components off, have them rendered server side. Just this kind of many to many problem, right? Where it's it just depends so much [00:23:00] on how this specific meta framework is doing its server side rendering and What's being sent over the wire.

And there's I think two or three different kinds of abstractions that are trying to happen here on how server side rendering actually ends up manifesting. So having to write all these adapters, so every single framework can write render components from all the other types of frameworks seems like a massive undertaking.

Is there like some, like I don't know, is there anything there that offers some solace or looks like there may be a potential to make this a little bit easier for everybody?

Yeah, so I think that's the million dollar question. So let me be clear about what my definition of success for this would

Sure. Sure.

is that you have three different frameworks that use web components. And those three different frameworks, you can compose them on the server side and have one component inside of another component inside of another one, three different frameworks.

And then that can be server side rendered, sent down to the client, hydrated together, then run client side. That's my definition of success. And effectively why I want that is because I see [00:24:00] interoperability as the main selling point of Web Components. And we have that today on the client side. It is there.

It exists. It's great. I want that for the server side as well. Do we, is there a path to get there? I think absolutely. It's a solvable problem, and it's just a question of how we get there and there has been some discussion in the Web Component community group about, coming up with some community protocols for how to do these kinds of things that aren't being defined by.

The, by the browser vendors and W3C and and what we see in these kind of standards bodies that are interested in, browser standards, I think probably will have to be something outside of that because browsers are not going to be super interested in how Node. js works or how Deno works or these kind of things on the server side.

That's just not really their that's not really their focus. Now, one example I've seen that maybe we could draw some inspiration from is I've seen that some companies put together this winter CG which is basically like it's a few different vendors of of server side, JavaScript stacks, things like Dino and CloudFlare workers they got together [00:25:00] and they started standardizing some of the APIs used in those tools outside of.

Kind of, what the browser vendors are interested in. And I think maybe that's an example that we could learn from. Maybe we could do something like that in the web component space. I'm almost certain that this will be solved in a few years because yeah, server side rendering is just too important to ignore.

Yeah. That, that, those kind of those JavaScript engine runtime, that does feel like the same shape of problem, right? It's okay, well, how do we make it so like, all of these things can work in all of these different places with kind of this weird other ecosystem constraints going on?

But anyway, I'm glad to hear you're optimistic about it. And hopefully this will get people buying in, just to close the loop a little bit here. Do you think that the APIs of Web Components themselves, the, just the abstractions, I guess the way that one writes Web Components, do you think that's something that most devs, like front end devs, should be concerning themselves with?

Or is this really only a thing that it's like [00:26:00] if you're writing libraries or, code that's going to end up being consumed by a lot of other devs that you should have to worry about. Or do you think that those, like the web component abstractions should largely be handled by other tools that make it easier to write web components?

Yeah, I think there's two perspectives here. There's the perspective of a Web Component author and a Web Component user. So from the perspective of a Web Component author, yeah, I think that the tools are, the APIs are so low level that really it's in the domain of framework authors. And that's why Most people aren't writing vanilla web components from scratch.

There's just so many little things you have to remember. And it's so low level that piecing things together you end up just writing your own framework anyway, so you might as well use something like lit or stencil. So from that perspective, like I think using the higher level abstractions makes a lot of sense.

Or you can even use a framework that doesn't bill itself as a web component first framework, like view and Svelte, or they have modes where they can run as web components that can be built as web components. And that's perfectly fine. Now from the perspective of someone using web components, I think it makes perfect sense to learn the API [00:27:00] surface because you're, when you do that, you're basically just learning the web.

Yeah.

How do you use a, an off the shelf web component? Well, you pass. an attribute in, right? You attach an attribute to the DOM node. You maybe set a prop on it. If it's something that's more complex than a string. That's how you pass data down. And then how do you get events back up? Well, you do add event listener, like just the standard browser stuff that you would use on any element on a button or an input.

I think it's totally worth learning that stuff because those are just like the fundamentals of the web platform and like the basics of our craft, I think.

Yeah, it's very very web native feeling, right? So ah, this is very pure and simple. Like maybe not very powerful when used in conjunction with all these other things. It's oh, I understand how these are the building blocks in it. It does. It gives one that, that feeling. Cool. Well, yeah, man, we've covered a lot.

Is there anything else you want to mention Nolan or point? Point listeners towards, we'll be sure to get a link to your blog post in the show notes. Is there any other resources you recommend people check out?

Yeah, I would say just, read the blog posts, consider the [00:28:00] points I make and, if you're not convinced, like that's totally fine. I don't think that everyone needs to be using web components. If you are a react developer and your whole team knows react and you feel productive using react and you don't want to go outside of that ecosystem for whatever reason, like that's totally fine.

Like we're all building on the web. We're all building different things with different constraints and. That's wonderful. That's a marvelous thing, but I think learning how web components work and learning the shape of them, what they're good at, what they're not so good at. It's a good tool to have in the tool belt and to just think about using in certain circumstances where they might come in handy.

So I would just encourage people to maybe keep a little bit of an open mind. And yeah, like I say, use web components for what they're good at.

Nice. Awesome. Cool. Well, thank you. Thank you so much for coming online and chatting with me, Nolan. It's been a pleasure.

Yeah. Thank you. No, really appreciate it.