Web components. Isn't just one thing. It's really a collection of technologies that are part of the native web now. A collection of web standards. So for example, in HTML, now we have the ability to create new HTML tags, new custom elements, and there's an API for that, that lets us define the tag name and provide a class.

You're listening to episode number 14 of 20 minute JavaScript where we discuss everything JavaScript related.. Like I always say these episode is hosted by OpenReplay, an open-source session replay suite for developers, stop guessing your production issues and check out openreplay.com, like now, or maybe after the show, check it out. I'm Fernando Doglio, your host and favorite cat owner for the next 20 or so minutes. And today we're going to be talking about web components with two very special guests, but be warned though. We have so many things to cover about web components that this is just part one of a two part episode. You have to wait until next week to listen to the second half that said, this is a great introductory episode for the topic. So without further ado, I want to introduce you to Chris Colt UX engineering manager at Microsoft and Rob Eisenberg UX architect also from Microsoft. But why don't I let them tell you a little bit more about themselves Chris, Rob welcome. Thank you for being here and please introduce yourselves.

Um, my name is Chris Holt. I'm a UX engineering manager at Microsoft, and a maintainer of fast

and I'm Rob Eisenberg. I'm a UX architect at Microsoft and also a maintainer of FAST. Fernando Doglio: Awesome. I guess we'll soon learn what is fast. Uh, but, but before we get there, uh, thank you both for joining today to talk about web components I wanted to learn more about it. So I guess kind of, that's why I also started looking for people who would come and speak about it, you know, not just for the listeners, but also for me. So. Let's start with the beginning and go from there because I know a lot of people never heard of web components, so so can you give us a, like a small introduction as to what, web components are? Yeah. Um, so web components is I usually refer to it as an umbrella term because web proponents, isn't just one thing. It's really a collection of technologies that are part of the native web. A collection of web standards. So for example, in HTML, now we have the ability to create new HTML tags, new custom elements. And there's an API for that, that lets us define the tag name and provide a class that will provide the behavior for that element and hook into the elements lifecycle and do all those sorts of things. Um, so custom elements is one thing that's under this umbrella of. Web components. Another thing is shadow Dom, um, shadown DOM is an API, we have that we can use to kind of create, um, a sub Dom tree that encapsulates it's HTML and it's, and it's CSS. This can be used in combination, uh, with custom elements, um, and it can actually be used on its own as well. You can actually create a shadow Dom on a div and, uh, and, and. And give that div new rendering capabilities, uh, and encapsulated CSS as well. But typically it's used with custom elements. So that's kind of under that umbrella term, uh, other things that come under there as well, uh, CSS properties, again, it's a technology that we can use in CSS in general, but it turns out to be a very key part of how we tend to do. Um, theming of web components. So you can say that, uh, that that's kind of part of the web components, uh, under that umbrella as well. And even JavaScript language features like classes and, uh, static fields and getters, and even future features, um, like decorators and different things like this are, are all kind of part of the web components story. So it's really a collection of standards. An HTML, CSS and JavaScript that come together to give us a robust component model for the web.

Wow. All right. So definitely more complex than I thought it was, but that kind of robust API, like you said, uh, that's not something that comes out that is created or developed quickly. So, um, from what I've seen from what I've read, web components have been around since 2011, something like that. Uh, so Why are we not all using what components? And I know that kind of question was going towards, um, why are we using React or Vue? And I know these libraries and frameworks are not exactly like web components. They, the, I, from what you tell me, web components seems like, the building blocks, you will use to create something like that, but why are they not the actual building blocks for React or Vue or, or any other libraries? You know, built on top of them instead, uh, they go on a completely different direction. What what's missing or, you know, what's the problem or what has been the historic problem with the components. Put it that way.

Well, I think one thing is while there's a history that may go back to 2011, it wasn't till 2020, that all the major browsers had implemented the standards. So prior to, um, the chromium based edge lunch Uh, in January of 2020, you had to poly fill a large number of these standards, um, uh, on, on edge or I E different, you know, different things like that. So, uh, and I think, you know, a lot of people weren't willing to sort of pay the polyfill cost in order to adopt those standards for those number of years. Now, if you go back even farther than that, Uh, in the early days of web components, the specifications are actually quite different and where, um, largely, uh, the work of Google and there was not agreement in the beginning, uh, on those API APIs. And so, you know, part of that process, just, it just took time to work out. It took time for all the different browser vendors to kind of weigh in with their concerns and to define. The version of the standards that we have today. So like back in 2011, or I, I started working with them, I think around 2013, um, those versions of the specs were what we would call like the V zero web component, uh, specs at the time. And they're a good bit different than what we have today. And so it was a number of years that it really just took to stabilize, um, what those standards were. To get agreement. And then, and then there was a period of time where that implementation had to happen and where there were only polyfills. And it was really quite recently, like I said, um, in 2020 where we have finally, every browser has now implemented these, and now you can build these components without any sort of polyfill whatsoever. Uh, and I think since then there's been a huge uptick. Uh, in web components, that was kind of the edge was kind of the final piece of the puzzle when edge shipped, that really changed the landscape in terms of web components. And we've seen huge growth. Uh, obviously we're working at Microsoft and there's a ton of web components stuff happening at Microsoft. But if you look across the industry as well, Google heavily invested. I mean, they were from the beginning, but they're continuing their investment, their Adobe massive, uh, investment from Adobe. There are new photos. Uh, for the browser is being built with web components, Salesforce, their entire platform is basically web components base. They've been in this for awhile and on and on. So there's a lot of, a lot of companies that are, uh, that are shifting this way. And it's much more viable solution since 2020 than, than it was prior to that. And so I think that combination of factors was the reason why we didn't really see huge adoption. Until that point in time and all the other libraries and frameworks that you mentioned, uh, you know, we're all sort of created prior to that point in time, really, to feel, to feel what was a gap. Because there, for so many years on the web, there was no standard for building components. There was a, there was a, there was just no way to do it. Right. And so we had what we call user land solutions. Um, for many years and, you know, you can go back to the early days of even Scriptaculous and prototype and MooTools and jQuery all these different widget libraries and they evolved then angular JS, and then you got your reacts and your views and in different things like this, but all of them were trying to kind of fill this gap in the platform. Um, and finally that gap has been filled by the, by the platform, but it's actually very, very recent. Um, that it's natively implemented everywhere

and it takes time too. You can't blame, you can't blame all 11 years or whatnot on, on standards, but standards take time to evolve. Right? And it's not just getting agreement on broad strokes. You're talking about like the nitty gritty, how these things will work and how they will scale. You know well beyond what we can consider and see. So, you know, I think that's one thing that tends to get forgotten as well, is that, you know, the sheer volume of working on the standard side, you're not creating something that a subset of people will use. You're creating something that lives in the browser and that is the, the model. Um, and so I think it's taken time for that to evolve. And in that time, yeah, there's been a lot of awesome solution and innovation that I think has led to even better innovation on the browser.

All right. So let me turn the question around, uh, because as you say, there are a lot of companies, big companies that are investing a lot of money and time on, on these, call it new to English now because it's somebody said, why are they what's the, um, upside of what components that is making them invest so much time and money when these other solutions came and feel that. Years ago.

I

think there's so, as Rob mentioned, like there's a lot of universal application for this, right? There's a lot of conversation that's taking place more recently on different social media sites with web components, can't scale, which, you know, um, Adobe has proven outright that that's not true by building Photoshop 100% using, you know, not just web tech or web components. Um, and they did a fantastic job on it. I think out of, out of the gate. If I were to say, um, you know, what did I offer that nothing else can, I think that they solve a problem that none of these other frameworks can, which is interoperability with any of those frameworks. And so, you know, the place that I would say there is immediate application solving a problem that others can't is component libraries at scale. Right. Um, especially at large companies, right? As you said, one of the reasons that you're starting to see more adoption. You know, large companies can't really, or don't often centralize on a single tech stack. I mean, it's very, very hard to do. Requirements. Just tend not to line up that way across business groups. Uh, and so you have a universal design language for instance, and you want a universal component library and you want to have reuse for a number of reasons, but mostly so that our users get consistency. They get, you know, the same experience, no matter where they're at and what product they're in. Up until now. Like if you pick to build your component library on react or on angular, right. It is a high cost to try and create interoperability on there. There's a high cost performance wise. There's a high cost in terms of engineering efforts. Uh, and then there's what do you do when you need to pivot or change web components solves that problem. Like, like nothing that's come before. Because it is, it is part of the platform you are creating essentially native elements that work and act and behave like native elements. And so at this point now I think we have every major framework that is offering, whether it's behind a flag or natively support for that interoperability. There's no more framework lock-in when it comes to leaf nodes. Uh, and truthfully from, from a performance standpoint, I think that. You know, pick whatever framework you want. You know, I, I'm a big fan of pick the right tools for the job at this point in time, I cannot see why anybody would be building like their UI layer, their, their component library on anything about web components, because as far as scale goes, like it's, it's really what it really brings to the table in my mind.

Yeah. And I think there's a couple of other really interesting things as well. You touched a little bit on performance. Um, you know, this stuff is implemented in C plus plus, you know, literally web components that are implemented into the HTML parsing layer. Right. Um, so there's fantastic performance you can get, you know, from there there's the inter-operability, there's something else that a lot of people don't think about. Um, especially if you're a serious engineer, if coding is your main thing, which is that web components really open up the possibilities to people who don't write a lot of JavaScript who don't know how to write Java script or who aren't comfortable with JavaScript because. Um, web components are just HTML elements in the end. So for, for the community of people that are maybe more skilled with HTML and CSS, but less with JavaScript, they can put a script tag on their page. And all of a sudden they have new HTML elements they can use, they don't need to write any JavaScript. They just use the HTML elements and set the attributes, just like any, um, any, you know, just like a div or a span, an input or anything like that. And so I think. Web components really opens up the, the landscape to a whole other world of people who have been actively part of the web for a long time, but have maybe, you know, and during the rise of JavaScript frameworks, you know, have maybe not been able to contribute as much as they potentially would be able to, uh, Because of this, uh, sort of Uber JavaScript focus of those technologies. But with web components, web components are JavaScript, HTML and CSS. You know, you do need to know JavaScript typically to implement a web component. You do not need to use you don't, you don't need to use our no JavaScript at all. And in order to use web components. Uh, so that's, that's a whole other advantage as well. And you can just start to think about, well, what does that mean for content creation tools? Um, there's all kinds of different parts of the industry and in our web ecosystem, um, that cater to folks that are just content creators, uh, and, and so web components opens up a lot of opportunities. You know, for that. I also think, you know, aside from the interoperability side of things, there's another kind of offshoot of interoperability, which is just modularity, uh, modular systems and plug in, plug in systems. So if you're building, if you're building larger apps and you need third parties to plug into your app, Web components is, is great to use as your sort of plugin API, if you will, because now you can have your third parties and you don't have to say, Hey, third-party to, you know, to plug into my app and my ecosystem, you have to use react, or you have to use angular, or you have to use vue you can say, well, we're using web components and you can put whatever you want inside of the web component and use the web components, whatever framework you want. It doesn't matter. And so you don't force your, um, your ecosystem down a particular framework path. And so then you, don't sort of, you know, push people out that maybe, you know, maybe they have more of an angular background and less, and not so much a react background. If you choose react, you know, as your sort of plug and model, you. You know, made it hard on those people. And when you're trying to build and grow a business, you want it to be as easy as possible for people to plug into your ecosystem and contribute. And so web components just, you know, because of that interoperability side, there's this other side as well, which is building ecosystems and pluggable apps and things like that, where you have third parties plugging in, um, it can really help a lot in those, uh, those scenario.

Interesting. Um, and, uh, are they up to that point already? Uh, the web components where you say, because I've seen like what components.org marketplaces, where you can just browse whatever you need. And in theory, you download it added to your app and then it just works. But are they at that level that. Plugin, and plug&play, let's put it that way.

Certainly some of them it's going to depend on the author of the component. I think web components.org is sort of an interesting thing. We should talk about that website very briefly. Um, the history of that site is that it, it started, you know, uh, as something that Google made and it was very, very much. In the early days, very polymer centric and polymer was sort of like the first web components framework. And it was sort of all woven together with the standards and the polyfills and all kind of mixed up together. The website today hasn't really been updated in a while. And in fact, one of the things that's happening right now that we're doing in the W3C is we're looking to kind of reclaim that website and repurpose it. Um, as a better resource for teaching people about web components and getting them connected into communities like our community, the fast, uh, community and different things like that. They, the website, you know, and its current states sort of has maybe a little bit of a confused purpose because it, it has this marketplace of components in there, but, and it also sort of has a little bit of. Documentation, but not great. And the design isn't fantastic and it's kind of mixed together and it doesn't end up doing either of them too well. Um, so, uh, from that the perspective of that website, that's something actually that we're looking, uh, to have the W3C, our web components community group actually kind of take over and make a better home for web components in general, and eventually. Uh, hopefully we can kind of refresh that marketplace and make it a lot more usable and nice. I think it's a little bit difficult now there, because, um, you know, the web components can obviously vary in their quality, just like any, you know, open source library or a piece of code that somebody writes. And so some web components are, are very much plug and play. You know, and some are not. And in the marketplace that is upon web components.org right now. Uh, there's not, um, uh, a ton of consistency and even submitting to that marketplace is, uh, a little bit, uh, problematic for certain types of libraries. So you won't even find like you won't find fast our stuff up there, uh, because the way we ship it is different than what the marketplace assumes. So, um, So, I just want to say a little bit about the site. That site has kind of a longer history going back. Uh, you know, when web components were quite different and we're looking to, uh, through W3C group to kind of fix that. Um, but certainly, um, like setting that aside, um, like if you take fast for the most part, uh, we haven't talked about fast yet, but you know, we, we ship, uh, Well, our team builds. Maybe I should say this way. We build tech for building web components and also building design systems. I think we should probably come back around to that topic. Um, but one of the things that our team works on is the fluent UI web components. So, which is Microsoft's design language and it's all built on web components. So in terms of plug and play, basically you NPM install the fluent UI web components package and, um, No, it was this tiny little bit of setup, you know, JavaScript that you write. And then after that you've got 30 ish new HTML elements. You can just use, you just use them like any other HTML element, if you want switches or selects or combo box or tabs or tree view or data grid or whatever you've got, you've got them. Uh, Uh, it can be very much, uh, uh, pretty close to a plug and play experience. But again, it depends on, you know, like I said, who, who wrote the components and how much care they put into that side of it? What

the, what the goal is, right. I mean, I'm a, my hammer is, you know, like what are the requirements? Right. Build to the requirements. And so sometimes, you know, sometimes it is that somebody wants something like super customizable for a reason. Um, For the most part. Yeah. I mean, I think if, if you want to build something that is out of the box plug and play, it's absolutely doable. Um, You know, there's, there's several libraries or individual components that folks that built and publish out there, um, to, to play with. And, uh, you know, anyone listening, who's interested, I'd encourage you to, to go and grab something and play with it and look at trying to build something, you know.

Interesting. All right. I didn't know about web components. It's definitely sad that that's the case because when you don't know better and you start Googling for it. That's one of the first results that you get? Uh, it has a great SEO. Yeah.

And that's why the group is looking very much into making that a better place to land. In fact, I think we have a meeting, uh, either this week or next week to circle back around on, on that.

Well, and not only do you get that, I'm sure that you get a number of blogs from, you know, the mid 2010s with, you know, opinion. And that certainly doesn't help either.

Yeah. Yeah. When I, when I started research for these, uh, I had to like filter because anything that was like 15, 12, 13, it was"why I are web components bad?". Well, you know, what's the problem with web components and, uh, up to 2021 is when you start seeing. People actually mentioning good things about them and, and, and use cases. And so on uh, it, yeah, it's not easy to find information about them.

Well, I think this comes back to something very interesting about the web and the web versus libraries and frameworks, which is. Libraries and frameworks typically tend to have sort of their own little marketing engines around them. Right. There's hype people get out there at the conferences. There's branding, there's a cultural personality around various frameworks and libraries. And what, what does the web have? You know, the web doesn't really have its own marketing engine and it doesn't really have, uh, quite the same thing. So I think. Uh, you know, it's quite interesting that sometimes there's more hype around something non-standard than, than something standard, which is, which may be technically better. Um, and it's simply just because of, you know, how people in communities and, uh, you know, conferences and hype and Twitter and all these other things work. Um, the web doesn't really have, you know, a have a PR firm that's out there, you know, you know, I'm doing all this cool stuff to get people excited about the actual standards that, you know, that gets shipped. And so hopefully web components that org is something that we can kind of repurpose reinvent to start to help with that side of things. A little bit, at least for web components, because I think we, everyone that's invested in web components, we see the. Transformative power for the entire web, I think, for this technology. And so we want to help people to, uh, you know, to see that and understand it and to be able to leverage, uh, those capabilities.

Right. All right. Before we get into the, the brushes that you've been mentioning, I want to get a little bit, a little bit more technical, uh, because we don't have a lot of time to cause, and I guess we could spend hours talking about this, but you mentioned Rob, uh, at the start, when you say. Well components being an umbrella term. Uh, you said custom elements, a CSS attribute. I think you said, and shadow DOM. Can you elaborate a bit more on each, on these and what kind of capabilities they give you? I mean, cause some elements, I guess is the common one and most people. That have read anything about what components would identify them, but, um, what are the other two?

Sure. Uh, well, I'll just recap custom elements. Cause I think it's a super important. So literally in the browser now you have a browser global called custom elements and it has an API for defining an element. And so it gives you this opportunity to create a new tag name you provide, uh, Th the name that you want, and then you provide a class that inherits from HTML element. Um, so this is an important technical aspect of web components. They literally are HTML elements, every web component inherits from the HTML element based class, the same base class that div inherits from and span and all the elements in inherit from HTML element. So you create a new class, you extend information to mail. And then you have a number of methods that you can optionally implement in your class to hook into the life cycle of an element. So if you're familiar with JavaScript frameworks, a lot of them have some sort of lifecycle component life cycle, and it's the same for a web component. So you have the connected call back and the disconnected callback. And of course the constructor, those are kind of the most common callbacks that that folks use. And so the constructor. Obviously called when it's constructed, either constructed through HTML by the parser or constructed through a call to create element, document dot, create element. However it's constructed. Obviously your constructor gets called and then you got your connected call back. That is called when the element is connected into the Dom, uh, into the document to the tree and disconnected when it's disconnected. Right? So you have those basic. Uh, into the life cycle of what's actually happening in HTML. Um, and so you, yeah, you write code, uh, to do things, uh, in these various callbacks, uh, you know, just like any HTML element, a custom element can have its own attributes. So you can declare properties and attributes, you know, properties on the class effectively, and you can make those function as attributes. So one of the other callbacks you have is the attribute change call. And the browser will call that method. Anytime one of your attributes is changed, regardless of whether it's changed, uh, you know, through JavaScript or through HTML in our HTML. However, the attribute value changes through debug tools and the browser. You'll get that call back automatically whenever that attribute changes. And you're able to declare, um, as part of your web component, which Africans. You want the browser to observe and automatically call you back on? Um, so there's a bunch of kind of, uh, you know, callbacks and things around how you define your class. And even there's some new capabilities called element internals, which you can get access to from inside of a web component and element internals gives you additional capabilities around, uh, creating, uh, uh, form components. Uh, so there's a whole bunch of kind of new API APIs around making components participate in forums and supporting validation the same way that native validation works through element internals. And there's a lot of accessibility, API APIs that are coming through element internals as well. I'm not sure if those have shipped yet. Chris might know if those have shipped, but I don't think so.

Yeah. That's the ones that you're thinking of.

Yeah. So there's there's and I guess this is an important point to make about web components. Like any web. Uh, we continue to evolve these standards, adding new features. So there's a lot of interesting stuff with the element internals capabilities that's coming with. Like I was just saying new, um, accessibility, API APIs, but also, um, things like, um, custom pseudo selectors and things like this. So you can give states to your components, um, just like native elements do. And this is, there's a whole bunch of new features that are coming there. So there's basically, there's a bunch of API. That are around the element itself. Um, but when it comes down to it, it's basically a class that inherits from HTML element. You pick some of the, uh, the hooks that you want to implement the, the lifecycle methods. Uh, you implement those on your class and then you call an API to define that element, you know, with the tag name and with, um, with the class basically, um, next, I guess, a shadow Dom and shattered. Is this way to create a, uh, a sub Dom tree that's completely isolated from the main tree and the main reason you would want to do this? Well, there's a couple of reasons. One, you might want to hide away. The HTML you're actually using to render the component. Uh, but the big, uh, two advantages I'd say are composition and a capsulation of styles because inside of shattered arm, you can use special elements called slack. And slots are sort of like little placeholders within your shadow, Dom, that, uh, the content of your element gets rendered into. So, you know, HTML is a tree, right? And every HTML element can have child elements. So if the HTML element is rendering something, what do you do with the child elements? Where do they get rendered? Well, they get rendered into the slots. And so you can have these slots in your shadow. Dom, you can have a default slot where all the children are running. Or you can have named slots and then you can have a different children rendering into different slotted locations, uh, within that. And so it's extremely powerful composition system, even slots can redirect to other slots inside of other elements within the shattered arm and so on and so forth. So there's a very powerful composition engine that you get access to through shadow Dom. And the other really big thing is encapsulation of stocks. Uh, and so any CSS that you put into the shattered arm doesn't leak to the outside and, and likewise, any CSS sort of outside of that shadow Dom doesn't leak into it, affecting the internals. So you can truly create a component whose styles are encapsulated that can, that is safe to use on any web. And you'll know that it will render correctly regardless of what CSS exists on that webpage, uh, because the existing CSS won't be able to break through that shattered on barrier and then the CSS inside of your component, won't break out and mess up that, that page in other ways as well. So this is, um, this is really, really huge, uh, from sort of the safety of being able to use these things. We talked about interoperability, we talked about modular systems, these, these sort of things that are. Guaranteed by the platform are really powerful and really helpful in those scenarios. The other thing that folks don't realize about shadow Dom on the performance side of CSS is really important when you start to build a larger app that where you have a lot of CSS, the cost of the browser to evaluate that CSS, uh, it can be, could be very harmful to the performance of your application. What shattered on, lets you do is it lets you break your app down into these small pieces of Dom and small style sheets where the browser can effectively reason better about what styles affect. Because within a shattered arm, typically you don't have a huge amount of HTML and you don't have a huge amount of CSS. And so the browser can be a much more efficient and rendering the contents of that shouted off because it only has a very few, um, you know, selectors to evaluate. Typically your selectors are very simple as well, because you don't have to worry about the cascade because you know, you're basically only affecting. You know, very, very simple, very simple selectors and much, much less of them. And so, um, there's a lot of scenarios and larger apps where shattered on can really help with performance because it, it lightens the load on the browser and lets it makes his job much simpler. It doesn't have to consider the entire universe if you will, of CSS. For every HTML element, it can have these little isolated islands and, um, be much more efficient there. So that's shattered. Um, that's a little bit more about shattered on and, you know, essentially decreed shadow them, you just call attached shadow and, uh, on an element and it gives you back a shadow root, and then you can put whatever HTML you want in that shatter root and, and shattered arm has an open mode and a closed mode. We tend to favor open mode, uh, just because that's kind of part of the culture of the web. Uh, you know, a lot of us that started doing the web in the early days, we learned by doing view source and plunking around in the DVD debug tools and figuring things out. And so open shadow mode really sort of embodies that spirit where, um, when you create the shattered arm, um, people that are looking into bug tools can actually still see what's in there. And different things like that. Um, there are legitimate cases for closing the shattered arm as well. So you have that option as the implementer, uh, but it's pretty straightforward. You attach, shadow, decide open or closed mode. You get back, uh, a root node and you can just add HTML into it using our HTML or apend nodes are all the normal API APIs that, that you would know from HTML. Uh, And so what a web component will typically do is in its constructor or, and it's attached call our connected call back, um, it'll attach shadow and it will, uh, create that route, which it will hang onto and then I'll use to render itself into that, that route. Um, so those that's just a little bit more detail, I guess, technical detail on a couple of the key. Standards, but there's quite a few different pieces. Like I said, CSS properties come into play for theming. Um, there's the element internal stuff. There's a form associated custom elements, um, because we're continuing to grow and evolve and enrich the component model for the web. And so, you know, the. We like everything to kind of work with everything as much as possible. So everything you know about HTML still applies, you know, to web components and everything, you know about CSS still applies. Anytime somebody adds some really cool new features, you know, we've got, um, I think we've got the container query CSS container query is coming up. I mean, that's going to be huge for web components because now you'll be able to use. These selectors to say, like when my web component only has this much space render it this way or when my web component has that much space a render it that way. So now that's just a general CSS feature that can be used for any other. But the, um, combination of that with web components is very, very nice. And so it really fits under that same sort of componentization story for the web, um, making the styles, even that much more, um, modular and component oriented. Um, so, uh, there's lots of different, lots of different little pieces and cool stuff. And so I usually just encourage people to just, uh, get out there and explore and learn. Uh, learn the native web and the web standards that are out there are, I'll get a little bit on my soap box. Here is like, I think we've been as a community too dependent on, on lots of third-party libraries and we've invested ourselves too heavily and learning the react way or the angular way or the Vue way or whatever framework dejour way at the cost of actually learning how the web itself works.. Uh, and. You know, the lifetime of the web is much, much longer than any particular library and framework. And so your investment there is, uh, has, uh, quite a long longterm return on it. And, uh, so there's really a lot of cool stuff in the web platform these days. Uh, so, you know, spend some time just playing around with this stuff and it's not the same web as it was a few years ago and the experience of building modern apps on the web, using all these technologies we're talking about is quite different and quite, quite nice. I, I mean, I'm a sort of builder of frameworks. I've built these JavaScript frameworks prior to web components. And, um, I don't, I don't want to go back. I really love, uh, the new model, uh, based around web components and a lot of the new web stems that we're able to use now. And it's. Very much like, like, you know, just as good as native development, frankly, and even better on a number of cases. I think.

And that's it for today's episode tune in next week to listen to the second and final part of our web components conversation. I'll leave you with a preview though, catch you next week.

I have conversations with junior developers or folks who are looking to break into the tech industry, just because of my background. Often a lot of times, you know, based on whatever folks are hiring for, that's what they lean towards. They're like, oh, I got to go learn this framework, or I'm going to go learn that you will not become a better. X framework developer by focusing.