Web Awesome with Konnor Rogers + Cory LaViska

Yeah. So let let me tell the the story of of how this episode came about, because I think it's kinda interesting. So we just dropped our huge episode on UI components, UI frameworks, kind of like we talked about everything from headless to some styles to, you just drop them in. You can you can work with them. And, that show did really well, and there was lots of really good conversation around it. And, like, one thing I said during the episode, I was like, I mentioned probably a 1000 different libraries, but I'm probably not hitting them all. And I even told a bunch of people, like, please, like, pull request them to the show notes because it's it's interesting to see them all. And one of the ones that we had talked about was was Shoelace, and Shoelace is a web component based UI framework that gives you everything from alert, badge, breadcrumb, dialog Bos, details, date picker.

And and then, like, the next day, I was just talking about, like, the century has this really cool date picker where you can instead of having to select a range of dates, you can just say, like, five days. And and and Connor was like, yeah. Like, that's a very hard thing to do well accessibly. And, we'd we kinda talk back and forth about, the frustrations around it and whatnot. And then I realized that he was the one working on shoelace, and I didn't even realize that Fawn Awesome has sort of taken I guess Wes can get the story from these guys, but Fawn Awesome has taken shoelace under its wing or or joined or I'm not sure what the the whole story is. I I kinda waited till the podcast to get it, and it was raised $600,000, Canadian at least, for this new framework thing. So pretty this is this is awesome. So I think there's there's a lot to talk about here. So, like, first of all, Connor, Corey, you wanna introduce who you are and and what you do?

So, yeah, again, thanks for having us. My name JS Corey Laviska. I created Shoelace a number of years ago, and it's been quite a wild ride. And more recently, as you said, we've joined Fauna Awesome to build it out into a sustainable open source project with a, you know, pro offer on top of that. And there's there's a ton of awesome stuff that we're doing over here. I originally created shoelace back in 2017, and it was sort of an alternative to bootstrap. Shoelace is actually a play on the name bootstrap, if that's not too too too too obvious. I didn't know that. No. It's not.

Cool. So, yeah. And and it was basically I didn't get to know that, to be honest.

That's the first I knew about that.

It's a CSS framework, where, this is back where we still had IE 11 to worry about, and custom properties were they were a thing, but they weren't really widespread at the time. And what I noticed was everyone was using Bootstrap, and Bootstrap was awesome because you could configure, like, 1 SaaS variable and just everything would update, but nobody was doing that. Everyone was was using it from the CDN, so all these websites had bootstrap.min., you know,js and CSS.

But the problem was they were they they there'd be, like, 400 line CSS files to customize all these things, and it's like, why why are we doing this? We have CSS custom properties. Shoelace was a very bleeding edge thing at first where, you know, you could set 1 CSS custom property, and all of a sudden, your brand color was everywhere. And and that was sort of how it kicked off.

And so it's always been a bit bleeding edge.

Fast forward to about 2020, web components were a thing now, and and browsers were supporting them more widely.

And I thought, you know what? Let's do 2 ESLint o. Let's just make it more than a CSS framework. Let's make it a web component framework because then then it can just work everywhere. We'll take all this bleeding edge stuff that we we can't really use in production yet, which we can nowadays, but we couldn't then. And we'll we'll continue that bleeding edge thing. Let's just see what the browsers can do. And so it was reinvented as a web component library, and we're we're now sort of transitioning it into a framework. But at the time, it was like, can I build all these components? Can I let people just load them all on a CDN, set a couple custom properties, get all their colors and everything else, and then still style them if they wanna do overrides with CSS, if they wanna you Node? What can the browser do? That's really what it's always been about. And so that's where we kinda landed, and it got kinda popular JS browsers more modern and evergreen. We we just kinda started seeing more people use them and and and like the the library. And, yeah, that's Scott how it all kinda kicked off.

Yeah. So it's kind of an interesting story how I got here. I'll I'll give a little background of, like, how I even got into web dev in the 1st place. So, fully self taught. I don't have any degrees to my Node, so I, you know, I I worked as a paramedic for 8 years. So, like, I'd I'd be, like, in fire houses or, like, you know, at at base. I'd be coding away.

And I still reme I don't know exactly how I got started with shoelace, but I remember everyone was mentioning it, and I was like, wow. This looks really cool. This looks really nice. Everything is awesome. And this is probably around 2020, like, probably around September, around that area.

And, I still remember I wrote the, the Rails docs for Shoelace and how to integrate it with Webpacker, which is like a special, like, wrapper on top of Webpack for Rails.

I wrote it in the Brookline Fire Department Firehouse on my birthday. I still remember it. Oh, that's true. It clearly.

Oh, that's true. A month later, I got hired from my 1st job, and, like, I backed off a little bit using it. But I still really enjoyed it for, like, personal projects. So I made PRs. I I never really got into the whole React hype train. It just never, like, clicked with me. It really never was my thing, but I really enjoyed working with web components. And then, you know, I was making PRs, but, like, I was busy with my full time job in rails at this point. And then after that, my the startup I was working for shut down about 9 months later.

Stars aligned. Long story short, I ended up getting hired at Microsoft working with Corey, and, like, that really and we work on an internal design system using web components similar to shoelace.

So that's how I got started in it, which, like, I just got I just got pulled along with Corey, and I was like, I'm I'm sticking to the to the, bootstraps here and just hanging along the coattails.

Nice.

That's awesome. And so where you are today JS that Fawn Awesome, which is, like, I think probably everybody unless Wes Node what it is, but they Fawn Awesome absolutely changed the game for Scott, I don't know, probably 10 years ago, where you load the, script into your or some CSS into your page, and then you just have an I tag with the class of f a and then f a dash whatever, and you get all these Scott. And it was just so much faster than everything. And and quite honestly, I I would I tweeted the other day. I'm like like, nothing has come close to the ease of fun awesome is today. And I know a lot of people are Node don't necessarily use that anymore, but Funhausen, incredibly successful project. I think incredibly successful business.

What's the story with them trying to now get into the web component and UI Kit game?

Yeah. That that's an interesting story. The the thing I really love about being here is Font Awesome folks are very platform oriented. Right? We see frameworks come and go. We see things come and go. Trends come and go. And and there's just a fundamental need for stability out there that we just haven't had in the front end. Everyone's fatigued. And and when you look at, you know I mean, I mean, React is a little sticky. I'll give it that. It's it's a it does a lot of awesome things. It's very sticky. But even React sort of has its its issues with, like well, you know, we started with class based components. Now we moved to Hooks. Now we have this React Vercel components. What are all these things? So there's even a little bit of with certainty is that the platform does that. Right? I mean, ESLint tags, they're deprecated. I think, they still work in certain browsers. Marquee actually still works even though that's been deprecated. But Yeah. My point is, you know, 20, 30 years ago, your HTML still will render in a browser today. And so the platform to me was something that, it just made a lot of sense. Right? And that's where web components came in because, I'll be honest. I I created an app. I created a SaaS, and and I wrote in Vue 2.

And it was just an unfortunate timing because about 6 to 8 months later, Vue 3 came out. Mhmm. And it was enough of a breaking change for me that it was very frustrating.

Yeah. But not just that. There was a component library built into Vue 2 that used Vue 2. It was great. And when Vue 3 came out, that broke too. So not only did I have to up upgrade my framework, I had to upgrade the component library. And, oh, whoops. I wanna be bleeding edge. I couldn't the new version of that wasn't out yet. They didn't have a vue three Vercel, so I was kinda stuck on this. And I was like, how do we fix this problem? Yeah. I I I think framework churn is something that we're gonna have to deal with, and I think that's maybe okay.

But what if we start taking some of the lower level things like UI components and moving those off to the platform? Like, if the component model shifts from Vue, React, Angular shifts over to the platform and we can start relying on that more, then when frameworks upgrade, which is natural like, frameworks are sort of a test of what can we do. Like, you know, the platform takes time. Frameworks are are cutting edge.

What if we had a way to reuse a lot of the fundamental stuff? Like, that makes upgrading frameworks a lot easier. Right? Why do we have to rebuild buttons every 2 or 3 years? Yeah. To me, that didn't make sense, and that's that's sort of where the inspiration came from. How do we solve that problem?

Yeah. So we like to coin Wes Awesome as the, like, the 3 point o version of shoelace.

Part of that is that there's a there's a tiny bit of concern because, I I mean, I named this project thinking, like, it's just gonna be me and a couple random people on the Internet using it. There there happens to be a company that's involved in technology that is named shoelace. So there's a little bit of worry there. But, also, when we joined Font Awesome, it it kinda made sense to be a little bit more on brand. So so there was a little bit of a double edged thing there. But Bos Awesome is a continuation of the project. We we're doing the next major version.

Longevity is something we care a lot about. We don't like to break things, but for this Node release, we're gonna be breaking some tag names, s l to w a for our prefix of our HTML tags.

But that but that's really what it is. It's no different. It's the same project. It's the same people behind it. Actually, we have more people behind it. We have brilliant designers. We have the full resources of a very talented company that cares a lot about design and a lot about development, which is something that you know, WebAuSOME is is taking shoelace from a component library to a design system that you can pick up and customize by turning a few knobs and just start using. Just start building right away. Just pop it right in. So, like,

Scott and I, after this, are recording a project on just getting up and running and doing a demo as quick as you possibly can. Right? Because Scott and I, all all day long, we're testing new APIs and, like, to the to the point where, like, we want a nice dev experience, but we also wanna get up and running as fast as we possibly can. And, like, part of me misses that, like, the days of Angular. You put a script in and you you you put some tags in the page, and it it it picks it right on up. Fun Awesome was the same way. So is the idea with the web components is that you can just pop it into of course, you can import them and and npm install them and whatnot. But is that the idea? Is that, like, if I want a good date picker for a quick demo that I'm doing, I could just pop this thing in and and I'm up and running?

I wanna let Connor answer that. But before before I do, I wanna say that we're still working on that date picker. That is that is the, like, the holy grail of web components. Oh, yeah. Is, isn't it? Yeah. It it is a little bit tricky, but we are we are working on that. And I think we're we're committed to getting that in there soon.

Okay. That is a that is a a tough shouldn't have used that as the example because there's what? How many other components that you have? Yeah. I I think we're over I think we're technically just about 50 ish right now. I've lost count. It's it's

there's a lot. A particular favorite of mine is the drawer the drawer component. I love that one. Yeah. It's a good one. A drop down like, do do you have, like, a filter drop down? That that's a Node that is commonly used. Is that coming?

I think we will soon.

Yeah. That's a combo box at that point. Okay. But, yeah, the filtering as possible while still being easy to use. But the other thing is, like, getting started. We understand that. Right? People wanna, like, get started quickly. People wanna move. Like, that's why the default installation method is a script tag to JS deliver, then a link tag with our CSS custom properties, and then you're off and running. That's, like, the goal of the project, get you up and running. Then if you wanna, like, you know, come back and get, like, only the components you want. Because right now with the autoloader, it will like, the autoloader is gonna be the default in 3 ESLint o. Spoiler alert, by the way. Like, right now, the default will load every component.

With the autoloader, it loads components as it detects the tags.

But, like, the the goal is you're still gonna incur some Scott of importing every component, but it's not gonna register everyone right away. But the goal is really how quickly can you get this set up. And then afterwards, you can optimize. Right? Only import the components you want, import pieces here, there. But, like, at the end of the day, we want people to get a prototype up quickly, and then they can move from there, optimize from their benchmark, whatever the case may be.

Yeah. So the the auto loader is basically like if you have a mutation observer on the page that just listens for any time a new element is added or whenever the page is loaded, it will run a query selector for all possible shoelace components. And then if it detects a shoelace component, it will register it with the custom elements dot define API. That's in its simplest form. It's really just a, you know, beefed up mutation observer.

In theory.

Yeah. I'm curious about where Wes Awesome fits in the, like, the categories that we talked about on that last episode. You Node, like, you on on one side of it, you have, like, the React ARIA functions, which is simply just a set of hooks, bring your own divs.

And then all the on the other side, it's, like, full components that look awesome, and and they're they're up and running. Where does Wes does this fit?

I could take that one. So, shoelace Wes. I'm sorry.

Name changes are hard. Right? And the goal is to be a full design system similar to, like, the, I would say, React Spectrum is the implementation of React Aria.

Okay. Cool. The goal is to be the whole design system implementation.

We don't really offer too many, like, low level hooks to, like, build your own. Some people do. There's a few design systems that have straight up fork shoelace and, you know, are using the internals of our stuff. But, like, as a whole, the goal is when you use shoelace, you have a full design system at your disposal.

And with Wes Awesome, now we're gonna be getting theming and other things coming along to make the process of customizing a site a lot easier so you don't end up with bootstrap syndrome where everything looks the same.

That's good. Because that's always the the frustration JS that you put all this work, especially, like, if you're putting all this work into accessibility, that was the one thing. It's like, there's not a React ARIA for everything else. You know? Like, there are components here and there, but there's not an implementation that is that good in other frameworks. So if Wes awesome can be that and give us these primitives, but still give us the flexibility of, like, being able to style it. And maybe that's my next question is, like, what does the styling game look like? Because, like, one of the frustrations that people have with web components is that web components is a separate dom. And if you wanna be able to reach in there and, a, modify the output at HTML or b, be able to add classes and and style it a little bit differently, it can be a little bit limiting. So what does that look like? This goes back to that bleeding edge concept.

When we say web components, I always thought that it was a bad name because everyone thought, oh, it's a web component. Must be like a React review component.

It's not really the case. I like custom elements better because it is just a custom HTML element.

The thing about the shadow DOM JS, like, yeah, there's a little black box in there, and it's it's it's it's a blessing and a curse because JS authors of Custom Elements, we can expose certain things. We can do parts. We can do custom properties, and we can we call that our public API.

You wanna style these things, use that.

And I think people have gotten so accustomed to just taking a component, and then they can manipulate the HTML however they want. And they like that freedom.

And and it feels good sometimes, but the problem with that freedom is you can also break things, and you can also mess up accessibility really easy. So the black box, where it becomes a blessing, is we handle all that hard stuff for you. If you stick to the public APIs, it's a little different from what you're used to, but it's still fully capable of doing all the customizations that you're looking for. You just have to do it a little bit differently, like the CSS part selector that most people seem to not really be aware of yet.

And over time, as as these become more and more ubiquitous, that's gonna become a lot more common. Like, that's just gonna be something that you learn from CSS. Oh, it's a part selector. Which parts are available? Oh, here's the docs. That's how I style that. It's just it's there's been a lot of friction there. And so one of the things that we're doing because because shoelace was traditionally very, like, okay. Use the parts. Target the parts. Style those things however you want. And now we're moving to something because there's been so much friction that we're exposing more custom properties. It's something that people are a lot more comfortable with these days. Mhmm. You know? They know how those work. They feel good about it. They didn't maybe 5, 6 years ago, but they do now. And I think in another 5 to 6 years, parts are gonna be just like that. And so you can have your cake and eat it too. We're gonna make it easier because that that has been a little bit of a pain ESLint, but it it doesn't mean you can't do it. It just means it's different from how you're how you're used to doing it.

Yeah. So so it's it's it's quite fascinating.

When I when I say Shadow DOM, you know, a a custom element is what we like to call a host element. Right? And everything inside of that host element, if it uses Shadow DOM, that's that little black box.

And we can control the structure as authors of that, and we can expose certain things and hide certain things from our consumers.

And so the things that we expose, that's called our public API. That that's the stuff that we're not gonna break, right, from version for whatever version. We're not gonna break that. You can rely on that just like a right just like semantic versioning. Right? A major version, we may change it, but minors and patch Vercel, it you can rely on that. And so parts are where we have a certain structure inside a custom element that we say, hey. This particular div or this particular header or this particular thing inside here, this element JS called, you know, part equals whatever. And it's just an attribute. We give it a name. And in CSS, you can use a, you know, colon colon part parentheses, but but then you target it that way, and then you just use regular CSS properties. Right? So with a custom property, you can expose those those those go right through Shadow DOM. They're they're designed to just kinda penetrate that. But with parts, we actually give you a specific element inside I

I I think Node more thing we should probably say to the audience as well, especially if they didn't listen to the episode with Brad Frost on design system.

The reason why we are so stoked about web components is that we don't need a React version of we do, actually. React is one of the few frameworks where you do Node, an Node for every single one. And Shoelace does make it work with with React, but the idea that if you have a large company I have a friend who works at a local bank. They have a 1,000 developers. They got 3 Angular apps, 6 React apps, 3 View apps, and they have a design system that needs to work across the board. And either you're doing a whole bunch of work reimplementing that in every single one, and you gotta make sure the accessibility is bang on and the it looks exactly the same, and the same thing happens when you hit escape twice ESLint all the components.

That's a ton of work. Or you can just do that once in web components, and you can very easily use web components in these different frameworks or or write adapters that will sort of handle them. And that's that's huge for, amongst the other benefits we talked about. That's huge for companies that want to be able to port things from framework to framework or design system to, different projects that they're working on.

Yeah. And a big reason why I like DOM first frameworks. Right? Frameworks that use the DOM is the reason why. You have that that's a good idea. You know? Yeah. Wes, it's it's interesting that you mentioned design systems and how all this fits in because custom elements are are like a natural progression of where people wanna be. I I actually got into this whole thing, and and the reason that shoelace 2.0 with web components came about was because I was working at a company where we had a problem. We had Angular. We had a little bit of React. We had some folks that were just rogue doing vanilla everything.

And they had 3 to 4 implementations of different journey into web components was. How do we solve this problem? How do we make all these things consistent? And that's where it all kinda started. And, you know, back then, it was very early.

We were using polyfills left and right. IE 11 was still a concern. Mhmm. But that's that's where it all kinda kicked off, and and it and it clicked to me, like but why why do this at every single company? Maybe we could do this at a much higher level in an open source way and let people just kinda take these components and run with them just like their HTML elements.

One one question I have while we're talking about, like, HTML elements as well is, like, what are your thoughts on the Scott of the new stuff that's happening with the Open UI, initiative? So anyone listening, Open UI is a working group that's got together, and they've been researching and writing proposals for new inputs. Like, there's a reason why nobody uses input type of date in the browser because it sucks. You know? Like, it doesn't look good. You have no control over it. So a lot of the new ones pop over API. We already saw there was an initial implementation of combo box and select box.

It's being revised right now due to some feedback from from WebKit.

So, like, these APIs are so much more flexible where, like, they allow you to use multiple parts together, and you can build your own custom filterable multi select combo box.

And it's just it's awesome seeing that type of thing.

And, like, obviously, those are 2. You guys have, what, 50 and are still working on on new ones. We're a long ways from from that type of thing. But will you use these browser APIs or maybe the polyfills when it comes time to using these types of things?

Yeah. So this JS actually the thing I'm most excited for about Wes Awesome. The 3 point o version is we get to move a lot of this stuff that we were doing with bespoke implementations. We have this focus trap API that I have had many headaches and nightmares about for our dialogue.

And it is familiar.

It's a monster. Right? And, like, we get to move over to a dialogue element now that just handles it for us. And whatever they do, we can be like, this is what the browser does. Right? It lets us offload a lot of complexity and a lot of issues with cross browser support and everything. New popover API means we get to remove hopefully, once it becomes more stable and we get anchored regions in CSS too. That's the other thing too. So we get all the benefits of CSS and HTML. So, like, we the new anchored region stuff coming out means we get to get rid of floating UI, which awesome library, by the way. Floating UI, if you're building any drop downs, combo boxes, whatever the anything that is not absolutely positioned somewhere, floating UI is absolutely the best. But we get to get rid of that and let the browser do it for us. So, like, I'm actually most excited about the things where we're moving in Wes Awesome because we get to use browser APIs that, you know, maybe we didn't get around to in two point o because it result in breaking changes and other things. So that's what really excites me JS as these advances come along, we just get to plug them in, and we get the benefits from it. Yeah. Imagine that you can spend your time

more fun components than having to worry about implementation details and an API that sucks in the browser. Yeah. Awesome. Here I have a question that I posed last, episode about this as well, and I'm curious what your thoughts are. So you have a you have a pop over, like a dialog box that pops up. And in that, you have a form, element. Oh, yeah. And as you Yarn typing in an input, you hit the escape key. What happens? Does it clear the suggestion, or should it close the,

entire modal box? What are your thoughts? I I I can tell you right now what we do. We we do we clear the suggestion because we check the path of the events when it's, an escape key like that, and we check if you're inside of, like, a Gosh. Wes. Of a input button text area.

I think there's a couple of it. Content editable. Exact code. Yes. Yeah. Yeah. It and we use compose path too, so it also checks, like, if it's in a shadow DOM somewhere too. So it it just does a quick find to make sure you're not on any of these, like, tags that you shouldn't be that has its own escape key functionality.

So that's so to me, you don't close the dialogue if you're inside of a interactive field.

but Well, we actually take it a step further. And and this the cool thing about it is the platform is always evolving. And so, normally, you have to do all these checks. And and we're very early, but there is an API for handling exactly that calls called Close Watcher API.

And Woah. We this has already been implemented. And it's it's I don't think it's in any of the evergreen, like, live browsers, but I think it might be in some of the canaries at this point. But we're ready for that. Like so we're looking for these new things. Like, can we get rid of all this extra code to do all these checks and just use the browser's APIs? And that's that's a huge part of what we believe in is, like, can we get rid of more code and just focus more on, like, what we said earlier, just the components, just the styles? How do we make this your design system and get rid of the cruft and just give you all the good stuff and let you focus on that?

VPN. It well, we're like I said, bleeding edge. This was a PR. I don't know if you guys know Luke Warlow. He does a lot of platform work for Agalia.

Like a they do, like, open source. They're they're, like, big proponents behind, like, the open UI stuff.

He's the one who did the PR for Closed Watcher for us, and that's how I found out about it. So he's the one who actually showed us. Yeah. Luke is, like, my go to for, like, all these strange bizarre browser behavior stuff. I just I'm just like, Luke, is this supposed to happen?

Yeah. He's a high quality Twitter follow. Luke underscore warp, w a r l o w.

Big fan.

That's awesome. Because, like, on I think yesterday, I found a bug in the syntax website. We have a share dialogue, and we use is it dialogue or popover that we use, Scott?

Okay.

We've had For that in particular, I think it's dialogue. I think it was dialogue. So we Wes opened it, and we have a a boolean of if it's open or not. And if you click the x, it sets a boolean and and hides it. But then if you hit the escape key, it actually closes the dialog box. So I was finding out that if you hit the x, it hit it visually but didn't actually close it. So I had to write a little bit of Node. Like, I just moved it over to the, the on close ESLint.

And I was like, oh, browser standards. You know? Like, we you take code out of the code base. There's no you don't need the Boolean of it if it's open or not. You simply just use the browser methods to open, close, check if it's open, all that good stuff. Let's talk about Kickstarter really quick because,

You know, that decision goes back to the Font Awesome 5 Kickstarter, I think, where, you know, it that's that's the Kickstarter, like, record for software. That's the most earned. There's there's 2 records, and I'm I'm not as good at off the top of my head here, but it's the most amount funded, I think, and maybe maybe it's the most number of backers or something like that. Yeah. That's what we're saying. Records. Yeah. That's what I Wes. There's some records to be had there, and and that's that's just phenomenal. Like, I think, you know, that that kicks that Fauna Awesome five video was just awesome.

And so we we actually we just kinda wanted to relive that, I guess.

And I'm really glad to be part of it because we actually got to go out to Los Angeles back in August, film this whole new video that, you know, that's on there, and and it's it's just a heck of a time. Right? But the cool thing about that is you're you're telling a story.

You know? We're we're we're yes. It's a presale. We're selling product, but we're telling a story about how we turn how we turn this free thing into something that's still free and even better, but also we add a lot more to it, and how you could be part of that. So it's really I think it's one of the best platforms. Maybe not for software, but it works for Fawn Awesome, apparently. But for most software, I I don't think it works as as well for for whatever reason.

Yeah. I I don't know why exactly.

But it's it's just something that we we we seem to connect with and vibe with. And, our our followers seem to kinda appreciate that, and, you know, we could add swag. We could add all sorts of things to it. So just kinda works for some reason for us. Yeah. Do you think that the success of the Font Awesome

I absolutely think it helps. Yeah. Right? Because people are familiar.

Another piece of that that helps is is Font Awesome was this open source thing. Right? And then they they how do we how do we keep the lights on? That's always a common story in open source, and that was how that that was what made it all possible. You know? Now there's a company. Now we have, you know, employees. We have all these things that that we could do with it, and keep making it better. And, you know, open source has been a struggle. I've launched a number of open source things that fizzled out, and it's like, you give away a lot of free time, a lot of effort.

And when you when you try to put a price tag on, you're immediately like a sellout. And we didn't wanna send that message. I very particularly didn't wanna send the message of, like, hey. I just I want your money now. Like, I'm flipping switches off. Give me money. That's crappy. I wanna give stuff away, but I also wanna eat. I wanna feed my family. I think we all kinda share that in open source.

And this this is was a path that has been proven.

And my decision to join Fawn Awesome Wes when, you know, we started talking about this and how how things would work, they they have a good track record of open source. Right? Like, they've added tons and tie I think it's been, like, thousands of icons to the to the free version of Font Awesome.

And we plan on doing something similar with, Web Awesome where, you know, Shoelace is now Web Awesome, where we're gonna be adding a lot more of the free stuff. But to keep us being able to do that, we need to start offering other things that are above and beyond that. So it's it's, you know, it's a replay of that. I don't know how else we would do it. I think it's clearly, it's working. So that's the good news.

Yeah. Yeah.

Man, do you do you have any idea of what the, like, I don't know if it's called a premium inputs are going to be or premium components are going to be. But like, there's been many times where I'm happy to shell some money out to stop the pain of certain areas of dev.

Yeah. One thing we don't wanna do is lock away, like, the best stuff.

Because, like, you know, if if we lock away the best stuff, nobody's gonna use it. We're just giving away garbage. We wanna give away some of the best stuff, but then some of the really complex stuff, like I'm gonna I'm gonna toss it over to Connor here to talk about that stuff. But, like, some of the more complex components, those are the things that we're putting in pro. Some of the stuff where there are companies dedicated to selling, like, these specific components. These are things that we're adding pro. So we're not trying to just put a price tag on everything. We're trying to put a price tag on the things that you'd probably be paying for anyways.

Yeah. Connor, you should you should talk about the rich text editor stuff. Yep. I knew that was coming. Yep. The rich text editor. That's a big one. That one wants to build a rich text editor. Yeah.

And if and if you look at rich text editors out there, they have awful licenses. They are exorbitantly expensive. It's like Mhmm. You're either an enterprise and paying for this or you're just not getting a rich text editor. And the licenses are like you can't even modify source. It's not even, like, copy left. It's just like what you what we give you is what you get. This is all you get. Nothing more and pay us a lot of money every year.

So I actually have built a reg text editor for Rails using TipTap, which is built on top of ProseMirror, which is, like, pretty much, like, probably the best text editor library out there. It's great. There's also some new ones. I can't it's from Facebook. I think it's Lexical. It's a new one. It's a lot smaller than ProseMirror. It's probably about a third of the size.

So, like, there's a lot of libraries out there, but it's really hard to get it all together well. And the UI is really where Oh, yeah. Rich text editors are so hard. There's so many icons and, like, how many of you have used the rich text editor with just an awful table editor inside of it? It's Oh, yeah. Yeah. Or the pay just the paste alone. You know? And I I don't Yep. I've I've seen code that, like, a paste does, like tiny MCE or something like that.

I do not envy anyone working on that. That's hard stuff.

Yeah. It's rough too because browsers actually all handle paste slightly differently.

Like, depending on the age of the browser, you only get certain things with paste. And then on top of it, like, Safari is a lot more security focused when you paste, so you only you don't always get all the information. So you have to have a bunch of, like, try catches and, like, backfills and, like, you know, you just progressively work your way down from what you get from the browser, which may not always be the same in Chrome versus Safari versus Firefox. So it's it's really tough to get right, and there's a reason why

there's not tons of these out there. Yeah. Yeah. Man, even, like, I know people that make a living on, like, file image file upload, you know, upload the file, resize it, whatever, Yarn it up, and then send it along its way. There's just so many little I was just looking at which Node was is the was the big one back in the day. I just looking up how much it JS. $800 per developer per year.

It's a big business. And, like, data grids are huge.

Where Yep. Data grid. A huge stock trading company needs to build a filter, a list of stocks and have it update every 6 milliseconds. And that's a wild world that these businesses are out there. And I'm glad to see it because they obviously like fun. Awesome. Can sell, like, icons. They sold $1,000,000 of the icons on Kickstarter alone,

and they're able to, like, hire you guys to to work on this type of stuff. Like, that's beautiful. Mhmm. I mean, the thing is Wes you look at it, like Corey said, some of these components that we have planned for pro, like, they're pro because these are legitimately full business components. Right? Like, data visualization.

Right? Like, who here has paid for what's it? Highcharts is the big one. Right? Yeah. Highcharts and every exactly. Right? Like, you know, that's $100,000 a year depending on your size. Right? Like, Right? Like, these the fact that these are all in 1 component set and they're all using the same style, some same consistency, that's, like, the big sell of, like we can't legitimately give away some of these for free because there's so much time, effort, and everything spent into these. And we're happy to give you primitives. Right? Like, you know, the selects and the even date picker is a little iffy, but, like, the thing is these more complex ones, data grid, data visualization, rich text editors, like, that's just really hard to give away for free because of the fact that these are full businesses alone.

Yeah. You're you're not wrong. We've we've had some internal discussion about that.

And I I I don't know if it if it was that we're just crazy or if we think that we're maybe we didn't think we were gonna get this Yarn. And I think it's inevitable. We're we're we're looking like we're we're gonna be building some charts soon. Nice.

Yeah.

And and and that's that's that's the thing, though. Like like Connor said, like, we're building the more complex things, and those are the things we're charging for. But there's another curious thing about Font Awesome that I always personally thought. Like, they are a little bit underpriced for what they offer.

And so if I'm gonna take an open source project and join a company and and sell out JS a lot of people would say, I I wanna make sure that they have you know, we're doing this in good faith and that we're not gonna be charging people ridiculous prices. We don't want to box people out. Like, if you're paying for something, you know, make it very reasonable, almost stupidly reasonable to where you can't not pay for it. Like, you can't justify trying to build any of this stuff yourself. Yeah. But when Wes it comes to charts, yeah, we're we're gonna be busy.

Yeah. We are.

Yeah. I I see it more as a as a presale, and I I don't wanna sound very market y here. That that's Scott the intent even though that's what we're talking about. But one thing that Fun Awesome did and that we're we're continuing that pattern here is if you if you're an early backer and you do this, you you get that price for life. Right? We're not gonna we're not gonna be, like, oh, 1st year, and then you pay full price. So so we really appreciate the people that are out there that that believe in us, that say, hey. We're gonna put our money here and and trust in you to to bring us all this awesome stuff. Right? Because we have a lot built.

Wes don't have it all built yet. That's you know, we're still doing some of this stuff. Mhmm. So there's a lot of trust there. So that's our way of saying thanks. Like, if you get in now, we're gonna we're gonna honor that for the life of your subscription. So the rewards are are pretty much that. You Node? You're you're you're an early backer. You're gonna get a price that no one else is is ever gonna get. Bragging rights, I guess, is a good one there.

That's great. Have have you guys ever dipped into to drag and drop? I've been following Alex Reardon.

He I think he wrote React Drag and Drop, and and then he just released Pragmatic Drag and Drop. And it's just I watched the whole talk of him. I was like, this guy probably knows the most about drag and drop in the entire world.

I don't I don't know that we have anything planned for it, but I've been following for a while. I it was React Beautiful DND, I think it it's called. Okay. React Beautiful Drag and Drop. And it's all under Atlassian Atlas kit. I forget what what the package scope is. Yeah. Kit. And it's called Pragmatic Drag and Drop now. Yeah. And and so the original, obviously, React Beautiful D Node was under it was only React. Right? And this pragmatic one is the, like, latest. This is, like, brand new. This is, like, a week ago he released it. Yeah. Yeah. I don't know when this is gonna air, but, like, this is, like, fresh off the press. And I've seen some of the demos of it, like, dragging across iframes and stuff, and you have to, like, change the opacity while you're dragging to be able drag across iframe or drag from 1 browser to another, and then you get, like, a, a data transfer event. Like, it's there's a lot there. And, you know, I think if we ever do anything with drag and drop, we're probably just gonna pull that package in and wrap it in some Yeah. Nice way because it is challenging.

I'm curious how how that do you know how that works? Because it works with React's Felt Vue, Angular, and so on. So is that is it web components, or is it just a bunch of DOM code that has to be surfaced?

I haven't looked into it. I'm assuming it is DOM code that has to be surfaced because I haven't seen anything that points to anything else. My best guess is they probably do something with, like, the draggable attribute or something and then have, like, a mutation observer with, like, a attribute filter for it. That'd be my best guess. I don't know a 100%. I haven't I haven't even had time to look into it yet. And, like Yeah. This package has excited me for so long, but, like, it's so new. I haven't even looked in. And there's it's a big package because it it has wrappers for, like you said, it's felt Vue React. So it's like there's it's a big code base, but, like, the core of it is pretty tiny as well.

Cool. We can talk about the layout component at the $1,000,000 mark that spend, you know, my my living misery for the last year of my

life. Yeah. What's the layout component?

Yeah. So the layout component JS, like, a culmination of me staring at tons of websites and seeing what, like, the general layout of most of these websites are. Mhmm. And I originally built 1 at Microsoft on their original design system, but it was very, like, stripped down. It Wes, this is the way we're gonna do it. There's no other permutations of this. This is it. And even that took me, like, a solid 4 months of, like, how do I get this right? How do I make this extensible? How do I make this in a way that, like, if somebody needs to break out, they can break out? And then I got hired into Web Awesome after I had been they pulled me off of the design system working with web components to do a bunch of AI stuff because this is like, you know, sometime had to have been around June or so. I think June is when I actually joined. So it would have been before then. So, like, at the start of the new year, they're like, oh, yeah. You're gonna work entirely with AI now and do lang chain. So I came over to web web awesome. Yeah. It was not my cup of tea. I I just didn't enjoy the work. Right? Like, I enjoyed building with web components. So I I came over to Web Awesome, and I'm like, alright. Cool. And then they're like, alright. We have this layout component to build. And I was like, well, I've done that before, but now it's a lot more challenging where anyone can put whatever layout they want. Right? Like, I'm no longer restricted to this is the Microsoft way of layout.

So it was really challenging. And even the docs on it are challenging because it's abstract enough to where you know, we we have a bunch of at at its core, it's simply a couple resize observers and some slots that let you slot into certain places, and, you know, it's pretty stripped down in that sense. You have sticky sidebars if you do, like, the holy grail layout Wes you have, like, the 3 column center and then a header above, footer below. Like, that's, like, the ideal scenario for it. But, like, there's other things we wanna do. Like, you write your navigation once, and it can, like, move into bold Scott. And you don't have to write your navigation.

Like, all you all your top header links can then move into a drawer or flying panel that comes in from the left once you get to certain breakpoint.

And so that's really, like, the challenge of it was supporting all these different ways to build, having the ejection mechanisms for most layouts and, like, seeing what most sites did. And, like, there's even challenging things around. Like, you have to calculate the height of the header, and then you want, like, the the 2 sides of the main content. So, like, if you have that 3 column, the 2 side columns, you want those to be sticky because you don't want those moving with, like, the main page as you're scrolling down like in a doc site. Right? Like, it's the worst when you're in a documentation site and you have to scroll down to be able to scroll the sidebar, so you lose, like, your main content area and, like, you're trying to find where you want in the Node navigation menu.

Like, it's it's challenging because then you need to, like with the sticky, you need to calculate, like, how big JS our header and make sure that you're, like, sitting below that so you know, like, the amount of, like, I I think it's margin effort or the top is what you said on it. So it was really hard to build.

I think the point Connor's trying to make is layouts are really hard.

And and a lot of the components that we're building are Yarn just as hard.

And and I like to think of it like from a design system engineer perspective. It's easy to build a component for a specific use, but it's really hard to build a component that can just work in as many places as possible and maintain the ability to customize, maintain the ability to do exactly what you need with it.

You gotta give me a sec. I what I'm not even sure what my favorite is. What's been the one that you're excited to

work on or build?

I'm I'm excited to work on ComboBox. I've started it, in some free time, but, like, ComboBox is, like, a really hard one to get right, but everyone uses them. Everyone loves them. Yeah. So ComboBox really excites me.

As for my favorite, I feel like my favorite may be I would say probably drawer is my favorite because I feel like I use that all the time for, like, small like, once you get down to the small viewport sizes, it's great to just be able to have all your links come in with it. I think that one is fantastic.

For me, it would probably be dialogue.

Weird because dialogues on the web are kinda, but there's a good purpose if you use them right. And and and it's not the version that you see in shoelace today. It's the version you're gonna see in Wes awesome, which is where we actually move to the actual dialogue element, and we get to scrap all that code we talked about earlier because it visually looks the same.

But every time I click that button, I and I see that dialogue, I know that we've we've been able to remove so much garbage code that we don't wanna have put in there for focus trapping and everything else. Mhmm. And and it just comes natural. So, you know, it's it's sort of that appreciative.

We we appreciate the platform for what it what it continues to let us remove from our library.

Let's get into the next section, which is, shameless plugs and sick picks.

Did you guys come prepared with a sick pick?

We did. What do you got for us? Yeah. I'll go first. So I don't know if you guys know about the enhanced Scott dev, by Brian Larew and his team over there, and begin. I I don't know. Oh, yeah. So there's a lot more to it. We've had Brian on the show. He's probably one of our

we've had very few guests on more than once, and I think we've had Brian on 3 times now. Big deal. Yeah.

So they just released their SSR module to be able to run across any server. So, like, you if you have, like, a PHP server or you have a Bos server, whatever the k Ruby, whatever the case may be, they released their SSR module.

And I was diving in yesterday. I was so excited. It was just released yesterday, and I was so excited to dive in. I was like, what are they doing here? And there JS a fantastic package underneath that's powering it all called Extism.

And Extism is like a WASM library that allows you to package up a library that you're using written in, like, Rust or something, Rust c, whatever the case may be, and then run it in these other run times like a JavaScript, Ruby, etcetera. So ecstism.org, fantastic. It's a super exciting project for Blossom.

That's cool. So, basically, if you have an app that needs JavaScript to run but you are using a Python server, it's pretty common use case, right? Like somebody in Ruby or someone in Python, someone in Pnpm world, you still need sometimes you need JavaScript server tools because that's what most tools are built in.

So you can bundle it up for WASM, but then Exxism will allow you to run it on

these different platforms. That's sweet. Yep. Exactly. Nailed it. I'm so excited about all this WASM stuff. Like, every time we talk about it, I'm just, like, giddy. So I've been I've been thinking about how to do SSR with web components forever. Right? And, like, the the thought I'd always come to was, like, you need, like, a static template. You need, like, a universal templating language. And I'm like, once I see WASM, I was like, wow. This makes so much sense. Like, it it's just string in, string out end of the day, add some data and, you know, some context essentially. Right? And Wow. You string in, string out. Right? Like, that's the the easy goal.

String in, string out. I like that.

Yeah. It's a it's a common theme with with the SSR story and web components that you hear from, especially, like, the React crowd where, you know, they just plug in next, and everything just works for them. You Node, somebody's done that hard work already.

And with the platform, things take longer. And, you know, we're are we there yet? Are we there yet with the SSR story? It's, like, that's the last remaining thing that people seem to be like, I don't wanna use them because SSR. Well, we're so close to having that solved. And and I feel like after yesterday's announcement with that package and and with the work that we're doing on our side to make this happen, like, we're we're gonna disprove all of that. I mean, SSR is gonna be a nonissue, and there's just at that point, there's really no reason why you wouldn't wanna start thinking about custom elements.

Corey, sick pick. So my sick pick is is is gonna be ESLint. And and and the reason is not just because we use it. There's a reason why I used it. Shoelace didn't start with lid. It started with stencil.

And then, eventually, I was like, how can I make this slimmer? Like, you know, I wanna I wanna make it as thin and close to the platform as possible. Started rolling my own library. Yeah. That was kinda dumb. But I did. And I realized that I was kinda just building lit, and and the size almost matched up too once I added all features that I wanted.

And so, I really appreciate the work that they've done over there. Justin Fagnani and the team over there at lit that has just made this the, like, de facto. I mean, there's a lot of great libraries out there, not to take away from them, but, for me, Lit has been, like, the de facto. If I'm gonna roll, especially, a collection of web components, it it's gonna be with lit because I I tried, and I cannot make a smaller library Mhmm. Than what that does to create these with with the tools and and the, abstractions that I prefer to have. So, lit.dev.

Definitely check it out. Yeah. I'd I'd love to add on to that too.

So Yeah. There's also so it's actually broken up inside of lit. There's lit element, which is like the web component wrapper, and then there's lit html. And lit html is such a fantastic way to write tag template literals.

I know front end master uses it. Like, you don't need lit for web components because you have lit HTML if you wanna just write some JS HTML. You Node, it's such a fantastic library. So much of it is it just feels like you're writing HTML. It doesn't feel like, you know, you're writing some bespoke dialect.

And maybe now we're gonna get signals. Actually, that that's 1 question I didn't even ask you. It's like, what are you I don't care. It's my podcast. We can we can ask it. What are you doing for, like, internal state? Right? You gotta, like, you gotta sometimes you have to hold data in turn inside of these components, I assume.

What do you use for that?

I can answer this. So, so we just use Litt's Bos wrapper. So Lit has this idea of properties. Right? So these properties, at the end of the day, they're really, like, rappers with getters and setters.

So, like, if lit ends up using signals under the hood, then we get that benefit for free. But lit kinda has its own, like, state management in a way, and it had it keeps track of what properties change as Wes. So you have, like, this will update hook and to see, like, what properties are changing so you can update certain things. So we largely just use what lit gives us. Sweet. Nice.

Yeah. That's for low level stuff. Right? As as things start to grow and and I don't think custom elements are there. Like, web components are there as a community where you have, like, a web component based framework. Right? You you start talking about state management. You're talking about actually building apps right now. Yeah. We're building lower levels lower level stuff where that's not quite as relevant. But I do see JS people start to realize this is a really good component model. It's interoperable. It works everywhere.

How can we make that better? I what my theory is frameworks are gonna pick up on that. In in enough years, we're gonna start seeing a pivot to where they're yeah. You Node, it might be the Svelte. It might be the Preact. It might be the whatever version of custom elements that you're building. But at the end of the day, they're custom elements. Now the frameworks start to focus less on component models and more on things like routing and state management and stuff, the things that we're really gonna shine. So I think that's where we're gonna go with it. But, I do wanna Sanity, I think Lit has an experimental the Lit Labs, I I do believe they have an experimental signals package Wow. Largely influenced by Preact already that's out there. Pretty sure I've seen that. Preact Wes is influential for sure.

picked, like, 9 things.

So Oh, I hate that.

No. I I what I would say is if you're listening to this today and and if this comes out before the Kickstarter ends, that's that's awesome. Go to web awesome.com.

It's gonna bring you straight to the Kickstarter. You can get those lifetime prices that are they're they're never gonna be you know, with inflation, with everything else, they're never gonna be lower than this price. But if you're listening to this later on and you end up going to Wes awesome.com, and if we've not released yet, if we've not launched the final product yet, we're still gonna have an early ish backer price. So it might might not be the same price, but I've I've been told that we're gonna have still some sort of discount for those folks. And once we launch, that's you know, the price is gonna be the price. So, that's my plug. You know? Node I've I've devoted years of my life to building these low level components. And, I do wanna say, not necessarily plug any product, but plug in all the folks that are out there backing us that have been sharing us on this whole time.

We appreciate that. It's awesome. Yeah. Thank you. Wicked.

I I forgot to tell the Node hilarious story of, Connor on Twitter was replied to the show that we did, and about shoelace. And I was like, yeah, shoelace is a good fit because it's built on web components.

And he very nicely told me, I know I work on shoelace.

Yeah. That's my full time job.

And it's not the first time I did that. I I was explaining to the product manager of Shopify Hydrogen what Shopify Hydrogen was. He's like, I know.

I I feel like it is I always I always click that profile.

Yeah. I always click that profile and be like, who is this person? Yeah. What is

Could I could I plug one last thing as well? I didn't get to to plug here. Connor plug away.

Yeah. So, obviously, Wes Awesome. Wanna plug that that go check it out. But the other thing is everyone doing all the UI work. We talked about it. Open UI, go check them out. They're doing awesome work. Igalia, they do a lot of open source work.

Some of the people from there, Brian Cardell, he has, like, a library for working with Shadow DOM exposing it. Luke Morlow, like, everyone who has answered all the bugs that I filed on Chromium, WebKit, whatever. Like, everyone doing work for the browsers. Like, I just wanna plug them because they're awesome, and they help us a lot to be able to make better things.

Sick. Alright. That's it.

Alright. Thanks, Scott. Thanks, Wes. We do appreciate the help you guys for having us. Later.