[00:00:00] Welcome to Podcast. Awesome. Where we chat about icon's, design, tech, business, and Nerdery with members of the fun awesome team. I'm your host, Matt Johnson, and today my coworker Corey Laka, the Brains Behind Web. Awesome. Corey and I are chatting with. Burton Smith, a web components wizard, a tooling trailblazer, and Burton's been working on a pretty cool open source project that we wanted to let you in on.

Burton has built an entire web components toolkit that bridges the frustrating gap between the promise of web components and reality. Burton walks us through how he's aiming to make web components a first class citizen, and why he is. Rage coding for the good of the internet. We get into how the future of web development may just be headless, declarative, and wildly interoperable, interoperable.

Is that a word? Interoperable. Without further ado, here's Corey and Burton.

So Corey and Burton, I want to thank you guys for taking some time to be on podcast. Awesome. We have kind of a new rhythm going here where we have non awesome verse folks on the podcast. So Burton, I think maybe you're number three. So, uh, welcome aboard. So it just be clear though, just 'cause you're not from the universe doesn't mean you're not awesome.

Oh, shucks. Thanks, man. I mean, you're in your own universe and we respect that. So, Burton Smith, uh, you've been working on a, uh, an open source project, a web components toolkit, language server, like you were saying [00:02:00] earlier, kind of a mouthful, but, uh, Burton, we're glad that you're here. I'm glad to be here.

Thank you. Yeah. Welcome Burton. Um, man, I gotta tell you, the uh, web components toolkit stuff is, is, is something else. It's out there. It's wild. Uh, you have single-handedly produced probably more tooling for the web components community than anybody I know. And I just, I really need to ask why, like, what's the inspiration there?

And, and I also wanna talk about the language server, but like, tell us what's in it. What's the inspiration? Why did you create it and all that. Yeah. Uh, so the, the actual web components toolkit is kind of new. I, I, uh, when I started working on web components, uh, uh, full, full disclosure, Corey and I used to work together, uh, you know, at at Microsoft, and, and he's the one who wrote me in and got me to be able to deep dive onto web components a few years back.

So when I went over to Microsoft, started working with him and, and actually Connor as well, um. We were specifically working on a web components design system, and I had been playing with them as a hobbyist, and I love the idea of them. And one thing that I noticed immediately as we started working with teams is that there's a big difference between the promise of web components and what web components actually deliver, right?

So we have, uh, these reusable custom elements that we can plug and play anywhere and use them in whatever environment we want to. But when you actually go and do that, it's a very different experience than what you would expect. Like if I were writing, uh, you know, view components and using them in a view ecosystem, I would expect a certain amount of like, uh, information about those components in the editor for me.

Like, uh, what, what the component is, if there's, you know, documentation for it, if there's, uh. You know, validation for my APIs and things like that. So as I started working with that, uh, with teams on, on using those components, they came [00:04:00] back and were like, you know, this is okay, but I'd rather use my own framework, uh, components in, in this environment.

They give me a lot better feedback. And, um, I, I wanted to close that gap. I wanted to say, do you know what I, we have a lot of information about our components. We know all about the APIs for them. You know, why can't we use that information to provide better developer tooling so that when they use our components, they have just as good if not better, uh, experience using our components than they would using their framework components.

And so, um. So the process has been to, you know, find ways to integrate web components into, uh, developer experiences to provide them with that, that seamless experience. So, uh, you know, one of the big greatest tools that we have is the custom elements manifest. Um, and, and that is a, a very nerdy term for, basically it's all the metadata about our components.

And so one of the things we can do is we grab this tool, goes through and analyzes all of our components and grabs. All of the metadata about that, you know, all of the, the tag names, the property names, the attribute names, events, all of that information grabs it and serializes it into a giant JSON object.

And now that we have all that information about our components, we can do a lot of really cool stuff with it. And so that's basically what, what's been happening is a lot of my tooling is based around this custom elements manifest so that we can take that and translate that into meaningful APIs for teams to be able to use.

So. From that we've generated, uh, uh, storybook integration. So if you're using storybook to, to, uh, uh, test and document your components, there's a, a web components integration for that. Uh, react wrappers, JSX types. Uh. View types vs. Code integration, JetBrains integration, all kinds of stuff. We've been able to generate great tooling around that so that developers now have this great [00:06:00] feedback, uh, to be able to know what's happening with these components in their editor.

Now the challenge that we've had with that is that it usually requires a degree of setup. Um, usually if they want to have JSX types, the, the web component authors need to be able to generate those types and then the user needs, uh, to now go and fetch those types and wire them up to their project. Or if they want to get the VS code integration, they need to now map, uh, group.

The author needs to generate a vs code config file. Uh, and then the user needs to now grab that config file and wire it up into their environment in order to get, you know, auto complete information, inline documentation, all of that stuff. Um, and that just felt like that's been pretty painful historically, trying to get it all working.

Absolutely right. And that's a friction point, right? And that's, and anytime there's an excuse for someone not to use your tool, if they don't want to use it, they'll, they'll find an excuse, right? If there's, if there's a friction point anywhere, uh, they'll use that as an excuse as to why they can't use it.

So the more. Opportunities we can find to reduce those friction points for adoption, the, the easier it is for, for teams to be able to take advantage of them. Yeah. It's a high bar. Uh, people just expect that they, they take something off the shelf, even if it's completely free and everything just works.

And if it doesn't work exactly like the way they want it to, they don't want. Yeah. No, I'm good. And as library authors, and I'm, maybe I'm speaking just for myself here, but I don't really want. Put a lot of effort into having to maintain like JSX types for whatever, and just all these different wrappers and stuff I want provide them.

I want them to work. I just don't want to have to think about how to do that. I'd rather focus my effort on building the library and making that part of it. Great. Uh, and so you sort of bridge that gap with this tooling and it's been working splendidly. I know you had some stuff from NPM before and now it's sort of all been umbrellaed or Most of it's been umbrellaed into the, uh, the web components toolkit.[00:08:00]

So thank you for that. Um, I kind of feel we'd be doing you a disservice if we didn't let you shout out. Like, how can we support you? Do you have a sponsors page or like, what's your GitHub handle or something like that? Uh, I don't have a, uh, any kind of sponsor page or anything like that. I'm, uh. Break stuff on GitHub.

You can find me on there or on social media at, at Stuff Breaker. Um, so you can usually, uh, find me on there. But, uh, yeah, right now it's just kind of been something I'm, I've been doing for free, uh, on, on the side kind of as a hobbyist. Um. I mean, I use these, uh, tools at work, but um, that's not something that I do for work.

So this is, uh, kind of a, a side gig for me.

You know what I noticed about folks that are engineering you, engineering type, you, you techie type, but I, it's also like, you know, dudes that are like doing mach, you know. I live in Seattle where there's giant Boeing plants and like mm-hmm. Machinists, you know, a lot of machinists around here, but folks that build stuff, there's like this sort of mindset of like.

They take their work back home with them, and it's, it's a legitimately joyful hobby. You know what I mean? Mm-hmm. I noticed that with web folks that are in, um, you know, building stuff on the web as well as, you know, in the physical world too, where it's like, there's like so much love around building things and creating tools and sharing knowledge.

Um, it's been a really cool thing to sort of break into this. I don't know, subculture in a way as like a, you know, a, a creative person and sort of an outsider looking in. It's pretty, it's pretty great to watch. So, uh, a shout out to all those open sourcers that are putting a lot of time and energy and love into, uh, all of this volunteer work.

So, just, just an outsider [00:10:00] perspective. Yeah. Addiction kills, man. Yeah. It's like, sure does addiction. Yeah. Um, it's also occasionally a rage coding, right? I'm like, oh, I, I know this could be better. I know I could fix this, and so I rage code something out so I could make it better. Yeah, well there's an element to that too, where you might be at work and you're like, you got an objective and you have to meet that objective and there's usually, you know, a deadline or some sort of timeline you have to.

Follow, and you don't have time to do it the way you wanna do it, and that feeling doesn't go away. And then you end up taking it home, Matt, like you said, and you're like, oh, I just, if I could only you spend a few more hours here and then, you know, next thing you know, it's a few more days or weeks and, and, but you did it.

Uh, and yeah. And then you give it away. But yeah. Right. Yeah, for sure. You mentioned CEMS earlier though. Burton and I had a question because in the past, uh, so we have these as library authors, we have these tools, um, that generate these manifest files. And we currently use the one by, it's by Pascal. Um, and I'm really bad with names, but.

Is that part of modern web? Modern web components? Yeah. Or yeah. Open wc. Yeah, open wc. Okay. I get the orgs a little mixed up there, but like, and we've had really good luck with that. But I noticed recently, um, uh, Benny, uh, he's well known in the open source, uh, in lit community. He's working on his own CEM generator and then there was another one that the lit team.

Maybe, maybe kind of adopted that was by somebody from even before that. And I guess my question is, um, your tooling works really well with what we're using, but like, will it work with all these cems? Like, is that, is, is the CM kind of standardized or do you expect rough edges going from one generator to another?

That's a good question. So. One of the things. So there's really, I think three or four kind of big ones out there right now. Uh, and I think the one that we use that, that you're also using is probably the most [00:12:00] popular that I've seen. Um, and I think one of the reasons why that one is the most popular is that it has such a great, uh, plugin.

Architecture so you can create all kinds of great plugins and just, you know, inject code and behavior at certain life cycles of the, the analyzer. So you could say, you know, as you're going through and analyzing this file and you're looking at types, let's grab some TypeScript types and parse those out.

Or, you know, as I, I want you to reformat it this way, if I'm using custom JS doc tags or whatever, right? So, so that, that kind of, uh. I guess it was more of like a platform. Uh, ma making the analyzer a platform is really powerful and it makes it really nice to be able to create custom behavior. Yeah. Now with that being said, oh, go ahead.

I was gonna say, I, I wrote plugins that were just a few lines, so it's, it's like a plugin, but it's so pluggable and it's so elegant that you can just write a few lines and then the thing you needed to do is done. You don't have to think about, well, now I have to create this whole robust plugin. It's actually just like hooks.

The nice thing about it is that because it's, you know, so pluggable, you can do a lot more things with it. You have more access to. The lifecycle of the, of the manifest. The other manifest generators that I've seen or analyzers, uh, don't, don't have that as much. Um, with that being said, I've tried to build it so that, um, a lot of the tooling that I have is not necessarily dependent on those lifecycle hooks.

So they have, uh, a plugin feature and then a standalone feature. So if you want to be able to use, uh, if you have an existing manifest. And you wanna be able to modify that content in a specific way. Um, I try to, if, if it's possible, make my, my, uh, libraries. Function in that capacity as well, so that you're not dependent on a specific technology to be able to, uh, customize your manifests to make them useful for you.

Got it. Yeah. And those ASTs that, that they generate are just wild. And the one thing I really, really feel like [00:14:00] I want, and I, and I'm not asking this of you 'cause I, I would never ask more from an open source maintainer, but like, if we had sort of a jQuery to. Hunt and peck through the a ST because right now there's some logic that I'm not proud of and it works, but, um, I have to, it doesn't make sense why it works sometimes looking at that stuff.

And fortunately this isn't like runtime code, it's build time code. But that's the one thing I'm like, man, this is so much data. Um, but it's almost, you know, daunting to get in there and actually use the data. It really is. Yeah. And luckily, TypeScript helps with that a little bit, and that that gives you a little more of a roadmap.

But yeah, it's, it's, uh, I, I still, I mean, I've been doing it for a little while now, but I still am constantly confused and surprised with what's going on in there. So, yeah, it's, yeah, it's pretty, pretty gnar. Well, thanks for all that stuff, man. I, you continue to use it and if there's any way we could ever support you, please reach out.

Um, we'd love to do that, whether it's through tweeting or even financial contributions to help support this stuff. 'cause I feel like in the next year or two, your stuff's probably gonna be used by more and more and more people. Probably in 10 years it's might even be like the defacto because nobody else is doing this stuff yet.

And you know, why do it again if it's working really well. So I feel like you got, you're on the something. Um, yeah, but I, I did want to answer some questions from the community. I felt were really good for you to kind of, to talk about because like, you're, you're, you know, knee deep in this stuff. We're, we've been building web components for years and, um.

One of the questions, it was from Alejandro Martinez Sanchez. He asked, what are the latest proposals in the web component standard? And you know, if we've used them, what was the experience been like? Um, and there's a lot, but I kind of broke a few of them down, so. Mm-hmm. Maybe we can start with form associated custom elements.

Yeah. Because if you remember, like from the days of shoe. That wasn't a thing. And you had to make your forms, your form controls, work with native forms by hacking and by being tricky. And there was always like rough edges. So, [00:16:00] you know, form associated custom elements. The idea is now we have APIs so we can do it the right way.

Um, and we've made a big adaptation in web. Awesome. Coming from Shoelace to where all the form con components do that. Um, but I'm curious, like what, what's your experience been with that and uh, just using them in general, any rough edges or, uh, so. I think overall the a p is really nice in terms of like really quieting the noise that we used to have to, uh, create to be able to, you know, associate our internal, if we had an internal element, or even if we were doing, you know, diviv as a, as an input, you know, that kind of approach where we're we're.

Basically recreating, uh, an input. Um, it's nice because it's, uh, it's very, it's simplified that quite a bit and it's given us a standard so that we can rally around in terms of, uh, how our, uh, our custom elements should behave, uh, with within forms. Um, the other thing that's nice is that it just kind of works right where there's, there's not a ton of wire up for it.

Uh, the API is very clear, pretty easy to understand. So, uh, to be able to get in there and just. Start building your components in a more meaningful way that that work with the rest of the, uh, web ecosystem in forms and things like that. It's just really nice to smooth that out, that experience. Now where I think there's, oh yeah, go ahead.

No, I, I think, I think you might be onto the same thing. So I'm, I'm kind of curious to hear, 'cause there's a, there's a little gap that it kind of bothers me a little bit 'cause there's one piece of hackery that we still have to do and I wanna see if this is about, if this is what you're gonna say. Well, for me, the, one of the things that I am.

Surprised at is that we have the ability to create custom elements as, uh, form controls, but we don't have the ability to create custom elements as forms. So I don't you have to use a form element. To wrap your custom elements in, but I can't have a custom element be my form element. And [00:18:00] so I wish there was a, a proposal or a spec where we could now create forms as custom elements so that we can now cr you know, attach our own custom behavior and logic around what forms are doing and how they should behave.

You know, everyone has a form and then they, they have a, a submit action and most of the time the behavior is prevent. Default behavior, right? They don't want it to post to the server. Well, it'd be nice if I had a custom element that, uh, I, the default behavior was to not to post to the server unless I explicitly asked to and be able to, right.

You know, have specific feedback and things and methods and, uh, events from, from my form element. That'd be really awesome. Right. Because one of the things, like if I'm using vanilla, one of the things I, I typically reach for is this. Um, and it started years ago as a jQuery plugin, but it would basically hook into the forms.

Prevent default. Don't do anything that you're supposed to do. Um, let me decide where to go. And so you use, you know, the action attribute to determine where the end point is and then the method. And so you sort of reuse those, but you do different things with 'em. And it would be nice to not have to layer that on on top.

Um, that's not where I was going with it. That's a pretty good gap that I haven't really considered 'cause form. I'm just so used to doing it that way that I never thought maybe we could make form better, but I was going with it. Uh, like buttons, you can't say I'm a resetter or submit button, and it's like.

So I have to create this hidden button, attach, and then the submitter's not correct, right? So there's still a few gaps there, but for most of what we're doing, it's worked really, really well. So, yeah. Yeah, I definitely felt that pain point as well.

So what, what about custom states though? Now this is the ability to, on your, on your custom element, to add whatever state you want. Like the platform has like valid and invalid, but you can add custom states. So it's like colon and in parentheses, uh, colon state, and then in parentheses like the name of it.

So you could have like a custom disabled state or a custom whatever. Um, we've started using them [00:20:00] more extensively. I'm curious, like, are you doing that now or like, there's been a little bit of friction from users who just aren't used to these new selectors and, and why they would need to use them. So I'm curious what your experience has been.

Yeah, we, we haven't used 'em that much and I think partly because of, uh, browser adoption. I don't, I don't think we have a hundred percent support across browsers right now. Or, or do we, do you know, that changed? It? It's, it's pretty close. I mean, I, okay. I wanna say it's baseline 2024 maybe. I'd have to check that.

So it, it is fairly recent. I think that's been our biggest deterrent, uh, from using it right now. And actually another reason why we don't use 'em is 'cause most people, um, aren't customizing, uh, styles and behaviors based on state. They're using the just components out of the box the way they are. So it's not, it's not something that they're, they're often reaching for to be able to customize.

'cause we have a very strict predefined design system that they should be following. So. We manage that stuff internally. But in terms of a reusable library, uh, where it's highly teamable, uh, I love the idea of states, uh, and being able to use custom states to modify, uh, you know, not only just. CSS custom properties, but also you can chain 'em.

So you could say, in this state, I want this part internals to have a specific style. So, uh, to be able to get that kind of granular detail on specific component actions and behaviors, uh, is pretty cool. I love the idea of that. Yeah, absolutely. Um, I'm gonna dive into one that I love talking about, which is declarative shadow dom.

So how do you server side? Server side render, uh, web components and, uh, we've, we started an experimental, Connor largely led this effort. Um. We got SSR working with Web Awesome. And generated with 11 D using lits SSR plugin. [00:22:00] And we were dogfooding it for a while. We actually found a, a much simpler, much more lightweight approach to do it that we're now dogfooding, um, on the client side with like a cloak utility.

Uh, and it's working really well. So it really. Cuts back the need for SSR in in many cases, but there's still that need and it's always been a weird story. Uh, we started with, you know, web components, can't SSR, and then, you know, now we do have this declarative shadow dom and all browsers have it, and it's, you know, we can, we can use it.

Um. I'm curious, you know, I can talk about what we've done and what we've tried to do and where the rough edges were, but are you, are you guys dabbling in that at all? Uh, so I'm gonna throw out some hot takes here for a minute, and I hope, I hope, uh, you don't get too many angry replies. Turn the fan on the first.

Yeah. Right. The, the first one is, is I, I honestly think most people who are using web components don't need to server side render their web components. Mostly because they're super performant. They are pretty close to the browser metal in terms of being able to render and execute. Um, so most of the time I would make the argument that you probably don't need to server side render your components, um, and just let the browser do its thing.

There are some, some nice things if you're worried about, uh, flash of un style content, things like that, that are simple things you can do to make that, uh, not be an issue. Um. Uh, and it's, I I have an article on that that you guys can, uh, we could share in the notes or whatever that, that kind of illustrate how to do that.

Um, but I don't, again, I don't think it's necessary all the time. But in terms of, uh, declarative shadow dom being the solution for server side rendering, my other hot take is I feel like it's a bandaid. I don't feel like it's the true solution for server side rendering and making our our, uh, uh. Custom elements immediately, uh, rendered nicely, uh, and, and behaving nicely.

Um, I think I agree with that Burton, because it, it does feel like how can we get web components to do what framework components to do today? Mm-hmm. [00:24:00] And that maybe not, maybe that wasn't the right question to even ask, um, but I'm curious what you think the right answer might look like. Yeah. And so I actually think declarative custom elements is the next step, um, in terms of being able to create reusable, uh, custom elements and reusable, uh.

Dom basically for, for, to be able to immediately get the initial render executed nicely. Um, it, and it sounds a little bit like what Justin Ani, creator of lits, uh, new project is kind of maybe doing, I believe declarative custom elements. He, yeah, his is, um, uh, what is that one? Starts with an HI can't remember right now, but yeah, it's the, his is, uh, basically a declarative way to render, uh.

Content. So if like creating loops and things like that, using template tags. Um, and I think that that definitely is a, a cow path worth paving, uh, in the dom. But, um, yeah, I think so one of the things that, that I've been, um, talking with some, some other, uh, uh, browser engineers about is. The kind of the initial step would be basically like a, uh, a reusable declarative shadow do where basically you could define a declarative custom element once, um, and register with a browser.

And then anytime it sees that custom element, uh, will automatically provide the correct rendering for it. And then once your JavaScript kicks in, it can upgrade and have all kinds of cool, interactive, uh, behaviors and things like that. Uh, if you need to enhance the components in those scenarios. Okay, so I was in a web components community group meeting at one point, and this was meant when Mason Freed was proposing, uh, declarative shadow dom.

So a few years back. And the, I remember the number one concern in the room was around that, like, why do we have to [00:26:00] output, you know, stamp out the full declarative thing every single time that's gonna create more bandwidth issues. But, and, and I think that to his point, um. Yeah. It it, or to their point? It, it would, but I, if I'm, I'm trying to remember.

I think the idea was we'll get, we'll just circle back to that later. Mm-hmm. Unfortunately, later doesn't, didn't seem to happen yet. But yeah, as with many things. Yeah, so that's, I I'm actually hoping to, to put out an article here in a little bit about that and how I think that, um, declarative shadow do, could, could be a reasonable solution for us to help solve a lot of these pain points that, that teams are having around, you know, initial renders and, and server side rendering.

So hopefully we'll have that. Yeah. I don't know if you're seeing this pattern here, but I, I knew you from Kickstand ui. This is a long time ago. Going back to, uh, early shoelace days even. And I was like, oh, this guy, web component guy. Cool. Uh, so you used to be at that level. Now you're at this tooling level, and now you're talking about getting down into the spec level.

Are we gonna see you at like W three? Uh, it would be fun to go to that, but I'll be honest, those, those, uh, engineers intimidate me. They're so smart and they know so much more than I do. So it's fun talking with them. 'cause I'm kind of like the little kid in the room, like, Hey guys, what about this? And they're like, nice try.

That's, that's cute. You know? But it's, it's uh, um. I love, I love being able to get more and more, uh, granular with this stuff and seeing how we can, uh, improve the, the overall system and eco and experience for everyone. Yeah, I hear you. Um, I've had some conversations and throwing out suggestions and it kind of scared me away because I, I, I think, I think at a, maybe a little bit of a higher level than they do.

Mm-hmm. But they also seem to operate with so many constraints that I would never think of. Like, if you change this little thing, then. Five other little seemingly unrelated things would be affected, or it would be, you know, not the same pattern as this other thing. Uh, and [00:28:00] that to me, it was a little disenchanting not gonna lie, uh, it was just my experience, but I also didn't give it like a full on effort to become one of them, uh, and learn their ways, so to speak.

But, um, definitely a, definitely a different crowd with a, with a very big focus. And they have to look at every single thing with such, you know, fine detail, um, before it gets in there. So. Props to them for keeping it all running. It seems like a house of cards to me at this point.

I, I might be, um, picking up on something. You guys might be on a, a train of thought that's different than what I'm, what I'm picking up, but I seem to remember in months past, maybe it's been in the last year or so, and I know that these sort of, these debates come and go, that it's like this ongoing thing or whatever.

B, but I've sensed that there are some folks that there's sort of like this gatekeeping, like web components are nice, but we need to do things X, Y, Z. And there are folks that are sort of naysay on web components as a feeling that I get, and they say that it's limited and that we shouldn't really encourage folks to really try and build really robust stuff with it because we need to stick to.

A language that is well established or whatever. I don't mean this to like throw shade or whatever, but it's a conversation that's happening, right? Like, um, do you guys have thoughts on that time? Yeah, yeah, of course, of course. Well, so here's the thing, right? Web components came out and there's this V zero spec and you know, it's, it kind of got.

Forced a little bit by Google and it didn't work out very well. Um, and then, you know, fast forward the V one spec comes out, you know, there's more people at the table looking at it, and we, what we need is an interoperable model to build components with, to, you know, it's just dumb to keep building the same things over and over because the flavor of the week changed.

And so that was the, so that was the problem that, that they went in the room to solve and when they came out, they had a solution and it wasn't a fully. I mean, how could [00:30:00] you basically invent the equivalent of a framework component model in the platform and get it right the first time? But you gotta award the effort that they, that they put in to try to get us there.

And what I've seen is a lot of folks in framework Land, they look at it once and they're like, it just doesn't do everything that framework ones already do. It's not established yet. What we're looking for is not to sell you on it today. Come over to this side and start doing this. Throw all that away.

What we're trying to do is say like, what else do we need? How can we make this better? Like, 'cause you gotta create a path. You can't just jump from here and be there, right? Everyone is working really hard on these things from declarative shadow Dom. All the way down to like the element internal states.

We didn't have custom states two years ago to use. Now we do. Um, so when you're looking at web components, you know, when they first emerged, it wasn't a very great feeling and I get that from that perspective. But, um, sort of some of the pioneers coming out here to. To pave that path and, and start asking those questions and just say, look, this is where we wanna be.

Um, it would be nice if we could get more folks adopting it, but like, what else is missing? Can you just give it a good look? That's been a huge problem. Um, right. I'll let Burton kinda give his opinion on it, but, um. It, you know, it's, it's been a weird conversation because I feel like we're at a point where adoption is really being held back by things like meta frameworks.

Uh, first of all, frameworks now react 19, finally shipped with better support. So we're there, you know, for the most part. But like the meta frameworks now are the ones that are holding us back from being able to say, can we get hooks to render declarative shadow down? Because all the next users want, you know, uh, SSR.

And we're not able to do that because like we've, I've personally reached out, uh, Michael Warren, he's personally reached out to the next team and we, we got some responses, but then everything just went silent and nobody really seems to wanna work with the, the folks who are sort of championing the platform.

They just kind of want it. I mean, I don't know what their intentions are. Maybe they're just, they don't have the time, but it feels like there's just not a lot of care in that direction. Mm-hmm. [00:32:00] Yeah. It's, it's, it's sort of like. Wouldn't you want to get tools in the hands of people to make their work easier or to get from step A to step B, um, in a, in a simpler way?

Um. I mean, having the options for lots of different tools to do, to do your work, uh, and giving a lower, kind of a lower the barrier to entry, right? For folks that wanna build things. And then it seems like there's folks that are like, sort of gatekeeping this stuff mm-hmm. To where it's like, look man, we want this to be democratic for.

People from all kinds of backgrounds and, and, uh, and knowledge to be able to start building something. But it feels like it's sort of like, no, we, you know, these are the proper way of doing things. And just as an outsider perspective, it's, I don't know, it's sort of, uh. Seems a little controlling. Yeah. You get the folks that come in and, uh, they, they basically look at it, they shit all over it.

And then as it evolves, they, they look at it again and they're like, well, I wouldn't have done that. It's like, well, you weren't there to give the feedback. You just basically turned away and, and didn't care. It's like, it's hard to feel bad for that, but um, right. I didn't mean to interrupt Burton earlier.

I want to really hear what you have to say. I get a little passionate about this stuff though, man. I've fought this fight for so long. Oh, no, I hear you. I'm. I'm right there with you and, and the interesting thing is that, you know, so many times people are like, Hey, it's either. X framework or web components and that that's not the reality, right?

Reality is, is it's usually web components and your framework you're usually building within this environment, and that's something that we've seen over the last couple years, especially, I wanna say the last three or four years we've seen this hockey stick effect of people adopting web components because they solve a problem that framework components do not, right?

They provide interoperability that that. That allows us to reuse, especially primitives across any [00:34:00] ecosystem. And so being able to. To now adopt those, especially in the enterprise environment where your portfolio is, is multifaceted. You have.net, angular, react, view, whatever, and you're like, okay, well why do we keep rewriting all of these components for each of these ecosystems?

Why can't we just write it once and reuse it everywhere? And so that's, I think. The community is starting to lean that way. They're realizing the benefits of this and the, the, the APIs are standardizing enough and stabilizing enough that, that everyone feels comfortable moving to them. And so, um, I think.

Th hopefully the conversations open up more now to say, Hey, clearly we need this. We, you know, people need this, they want this. They, you know, they're moving towards it. How do we now start working together to smooth out this path and make it much easier for teams to use? I mean, react, I applaud the React team for, for standardizing in 19, uh, you know, that was.

Everyone was like, oh, react, uh, you know, they're, they're not, they're the problem child with web components. And all the way up until 18 there was, it was, we had to create wrappers and things to be able to integrate well in those environments. And, uh, thankfully in 19, they, they, they came through and said, Hey, we, we've got standard, uh, we've, we've built standards in so that we can accommodate web components, which is great.

So, um. You know, we're starting to see the needle move on, on a lot of these environments and, and these ecosystems, which is, uh, very, very exciting. Yeah, I'm, I'm super happy to see 19 react 19 having support, although it, it had been promised since 16, but, um, we don't talk about that. Shh.

That, that's a great segue into, um, what Zix had asked us on our, on our web Awesome Discord, which, which is, um, he wanted to, he links to Chris ER's post, uh, which was entitled, thoughts on a Global Design System. And maybe we can put a link in the notes, Matt, but, [00:36:00] um, the, to summarize that post for folks who aren't familiar with it.

Basically at one point, Brad Frost had proposed a global design system, um, and he did that on episode 6 0 1 of Shop Talk. Shop talk show. Um, and so they, these are sort of like universal, like to oversimplify, these are like universal web components that would effectively eliminate the need for us to keep building buttons and things.

Um, they would just work across organizations or anywhere they'd be highly customizable. Um, but Chris kind of worried in, in his rebuttal to that, that making it universally appealing might actually make the design system way too generic to actually be useful. So I'm curious what you think about that. Oh, so this is something that we have been working on at Microsoft.

We have an internal global design system that we've been building that is generic. Uh, it is intentionally ugly, internal and global at the same time. Like in the same title. Yeah. It's, it's global, but only, only internally. Only internally. It's Microsoft global. Right. Uh, so it's, uh, yeah, it's, it's generic and it's ugly on purpose.

Right. It is uns styled and, um. You know, just, just kind of like the regular, uh, the DOM itself, HTML. When you start running with HTML, it's, it's not very sexy, right? It's just kind of generic looking. Um, but the idea is that you can style it and customize it and theme it. Most importantly, extend it, right?

The, the one thing that I love about web components is that because of its class-based architecture, you can literally extend components and, uh, for example, web Awesome has a button and maybe you're like, oh man, I absolutely love that web awesome button. It does 99% of what I need to do, but I need to do just this one thing and then it would be perfect.

So what you can do is you can take, create a custom element. Ex you just extend the web awesome element to create your own, uh, additional behavior to make your own web awesomer [00:38:00] button if you wanted to, right? So that now it has everything that web awesome provided, plus your additional features that you wanted to.

So that extensibility model is very compelling, especially if you wanna be able to take. A base foundation that you know every component is gonna need every time, and you're like, okay. I just, I don't wanna have to rewrite it. I just wanna write the fun stuff. I wanna write the a, the special stuff for my design system.

Cool. Get that boilerplate into its own isolated base. Component and then extend it and add your fancy stuff on top of that. So I think, I think it's really compelling and I think web components are definitely the tool to enable that in terms of a, a global design system. I'll add an asterisk to that, and that is if you.

If you've developed the components in such a way that you intend for them to be extended. Um, and I say that 'cause what we have not exactly done that, um, probably a 4.0 type thing where we, uh, backpedal a little bit on that. But, uh, yeah, so you can extend it. But like certain ones, like what we do right now is we have the problem of hard coding, um, certain tag names into selectors, um mm-hmm.

Or, you know, query selectors, things like that. So there's, there's not a lot of, you know, reason why we can't enable that. We just, we weren't being thoughtful initially on that. Um, and that, I think that actually carries over from Shoelace. Um, surprised anyone even uses this stuff personally, Burton, like, so when you say un styled components, are you talking like headless?

Uh, essentially like, they, they would render, like you can have 'em render, uh, and, and be usable. However they are, you know, the way they are right now. But, um. Yeah, I guess that's a good way to think about it, right? It's a way they're, they're designed to be extended. They're not necessarily designed to be used outta the box the way they are right now.

Do you provide any, like, at all base styles to kind of give it an initial like, well, this should at least be positioned here? Yes. Yes. That, that initial base functional styling is in place so that [00:40:00] you know. You know, dropdowns are, are showing up correctly. Popovers and popups are, are positioned correctly and all, a lot of that base functionality exists.

But in terms of like, you know, border radiuses and, uh, padding and spacing and all those things that, that, you know, are kind of context specific to a design system, um, that's, we leave that out because those, those are decisions that are, that need to happen at the design system level. Sort of the approach that lion from, um, ING, uh, started out with, I think maybe they still use that approach.

Um, my, my big concern with headless is that you end up with components that, um, if you don't have enough of a base style, uh, you end up with too much room for error. And I've written a post about that before that maybe we can link to, but. Headless components are not usually what people actually want, or at least not true headless ones.

They, they want ones that provide a good baseline and are easily, like, I can go and add to it. I don't have to do it all from scratch. I think that's my, mm-hmm. My big point I try to make about it. It sounds like you've got that perfect balance that, that I would look for if I were looking for a, uh, quote headless component library.

Yeah. Yeah. I, I, our, our, our good friend Wes Westbrook, uh, tweeted the other day. He said, uh, um, hell is being in someone else's components, uh, working in someone else's components. Like, it's just, it's frustrating when you're like having to like now work in somebody else's design decisions and, and things like that.

So, so. You know, it's nice to be able to make those decisions on your own. Like, what, what are the, my button variants? What, you know, should they have, you know, a hollow or a border or a whatever, like it, you just, you wanna be able to make those decisions, um, and not have them made for you, uh, in, in a meaningful way to, to match your design needs.

So, so I like the idea of having the flexibility, but I also, you know, there's a lot of teams that that want just. A certain amount of customizability, right? There's [00:42:00] certainly a spectrum there where, I mean, we saw it on the, uh, the Windows side. The Windows app store rewrote their UI in Shoelace and they said, Hey, uh, we we're gonna use Shoelace, but we're just gonna tweak some of the styles so that it has a microsofty field to it.

And that was enough for them. And, you know, and, and definitely they, that was a lot less rewrite, um, than starting from a headless perspective. So, yeah, for sure. Yeah, I think there's lots of opportunity there. I think that, um, Chris is probably right in that a universal design system wouldn't actually pan out because that kind of is what HTML is.

Uh, but at the end of the day, it's people have too many opinions and you're either gonna make it so, so capable, it can do everything and it doesn't do anything well or the inverse of that. So I think he's got a good point there. Um, but let's, Hey dude, thanks for coming on. This is amazing. It's been so good to talk to you.

Um, we should, we should catch up more, man. I agree, man, it's been a little while. I mean, I, we text and everything, but, uh, we gotta jump on more calls together. We do. Well, thanks for coming on, man. Yeah, yeah. Appreciate it. Corey, what would you say to folks, why should they check out this project and, uh, how has it benefited your guys' work?

It just makes it so much easier to use this stuff. Uh, you just, it just works. I love it when you just plug it in and it works and, uh, yeah, it's, it's. It's just a tooling that nobody wants to write. So Burton, bless your heart, man. You are, you're doing God's work here. Appreciate that. Yeah. Awesome. Burton.

For folks that are just jumping in right now on this part of the conversation, where can they check out your project and find you online? Yeah, so it's uh, wc toolkit.com. So web components toolkit.com is, uh, is what that stands for. So, uh, yeah, they, I, I've been trying to migrate all of my tooling into that one place, uh, and, and standardize all the tools around that.

So, uh, that's probably one of the best places to look to start out. Awesome. [00:44:00] So great. Thanks so much for taking some time again, Burton Smith, ladies and gentlemen, and, uh, make sure to check out his project. Appreciate it. Thanks for having me. This is awesome. Whew. If your brain isn't spinning like a dorm tree in a recursive loop, were you even listening?

A big thanks to Burton Smith and you can find him at Stuff Breaker on the interwebs. And thanks Burton for being the open source powerhouse that we didn't deserve, but totally needed. And thanks to all you open sourcers out there. You guys call yourselves. Open sourcers. Anyway, thanks for volunteering your time to make the web a better place.

Burton's web components toolkit may just be the missing link between you and a friction free dx. Alright, so I'd say that pretty much wraps our episode podcast. Awesome. Is produced and edited by this guy right here, Matt Johnson. I get a little extra help with the video episodes from Isaac Chase. The fun awesome theme song was composed by Ronnie Martin.

The music interstitials were done by Zach Mom, and if you found podcast awesome to be helpful, informative. Funny. I don't know. Uh, why don't you copy the URL and send it on to a buddy right now. All right. Until next time, go make something awesome.