Brian Kardell: Okay, so I'm Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer, also a developer advocate at Igalia.
Brian Kardell: And today we have a guest.
Brad Frost: Is that my cue?
Brian Kardell: That's your cue.
Brad Frost: I'm Brad Frost. I am a design system consultant and web developer based in Pittsburgh, Pennsylvania.
Brian Kardell: I don't know how interesting this will be to anybody, but I think that this is interesting for me at least, I think this is the most geographically close episode I've ever done. We're all within about two hours of each other and Brad and I both live in Pittsburgh.
Eric Meyer: And I live in Cleveland. I guess the two of you are supposed to gang up on me now or...
Brian Kardell: It's interesting. I grew up here in Pittsburgh. I don't know if you grew up in Pittsburgh, Brad?
Brad Frost: I grew up north of Pittsburgh, a town called Oil City, Pennsylvania. More Northwestern. Northwestern, the birthplace of the oil industry.
Brian Kardell: I grew up here and then I moved away around middle school and I was gone until about eight years ago when I moved back. One of the first things I did when I moved back here was go to this event, Abstractions. That was a big event that was here. I saw Brad there. At the time, we were working on web components. A lot of people wanted to talk to Brad after the event and I was one of the people in line trying to talk to him because I was like, I think that Brad would be really interested in web components. It seems really related to his stuff. It would be great to have somebody like Brad's input on a lot of these things. It's great to have you on the show and to have you here also to in part talk about web components. That's awesome.
Brad Frost: Yeah. Yeah, that's great. I mean, your instinct was right. I would be interested in web components.
Brian Kardell: It seems really, really useful for the sorts of things that you do. Also, there's lots of things in web components that I think are aimed to help with some of the problems that you also have developed your own ways to look at it and to solve over the years. I'm not sure we've always gotten them right. It's very difficult without wide input from a lot of people. Also, just some time to live with it and understand what the pains are. By this I mean things like Shadow Down and things like that.
Brad Frost: Yeah, happy to get into all of that. For the past, coming up on decade, I will say closer to 10 years ago was like a, 'Hey, could you build us a responsive website?' Now it's kind of the gig, but over the course of the last decade, it's kind of morphed into, 'Hey, can you help us build and evolve our design systems?' As such, we sort of duck our heads into all these big companies and large, or large and small, but especially large companies. We get to see all manner of different sort of tech stacks and different sort of implementations of front end code and stuff like that. We've built design systems and seven, eight years ago it was more of a bootstrap style. Here's a front end specification and a CSS file that you could publish and match the classes and get it right and then you get the desired look and feel and then the reacts of the world came in into the picture.Learned React and learned Angular and learned View and all of those things. Again, whatever our clients are wielding and basically building these component libraries using these technologies that... And these component libraries consist of your meat and potatoes UI components, the things that we all know and love for your tabs and accordions and form fields and buttons and cards and heroes and all of that jazz. Across all of these different sort of tech stacks and implementations, it's really the same crap, different day. That's it.
Brian Kardell: Right.
Brad Frost: Very elegantly there, but there's a lot of commonality. The implementation of what I call this front of the front end code, meaning the markup, the styles, and the sort of presentational JavaScript. The JavaScript required to, you click on the accordion, it opens, you click on it again and it closes, right? That's kind of what we're talking about. Three and a half, four years ago, we finally had the opportunity to build things in web components.At this stage, we had already had a couple React based libraries under our belts and a few other things. It was kind of fun to take that into the world of web components. For the past three and a half, four years, we've had a number of client engagements where we come in, do an assessment, take a lay of the land of their ecosystem, and help make recommendations around how to tackle that ecosystem with technology. As such, we've been advocating for increasingly, not all the time, but increasingly looking to web components as a delivery vehicle for these design systems that are able to travel to Angular apps and View apps and React apps, but also Drupal sites and WordPress sites and other sort of just things. Increasingly that is the case, especially the larger the company, the more of a footprint and the more diversity of technology they have.The more it makes sense to just... And the aim of design systems is we want to deliver these high quality, cohesive, good looking experiences to all of them. Our users don't care if your marketing website is powered by WordPress and you log in and you hit a dashboard and that dashboard is built in React, your users don't care about that, but they do see the buttons and they see the user interface and they want that experience to be cohesive. That's why increasingly we're like, okay, web components are a great way of solving that problem of, well I don't want to have to code the button CSS twice because we have a WordPress site and a React app.
Brian Kardell: Yeah, right.
Brad Frost: That's the big wind up. That's what kind of led us to web components and it's been quite the ride.
Brian Kardell: Yeah. You recently wrote a blog post about this. In fact, let's talk about web components. It was good. It was a good post. Encourage everybody listening to go read about it. I've written several posts about different aspects of web components over the years and one of them also had to do with a lot of the controversies, which are honestly still going on. People are like, 'Web components are the best thing in the whole world. They will solve everything,' and other people are like, 'What a bunch of garbage.' I think the truth is probably somewhere in between those two extremes.
Brad Frost: Of course. Like most things in life.
Brian Kardell: Like most things in life. Right. It has some rough edges and there are some places where it's really, really, really good. I think that the two benefits to custom elements, really the primary ones are that first, they exist, which sounds kind of a silly thing to say, but people wanted custom elements in HTML about 0.3 seconds after Tim announced HTML. Literally, this has been on the radar since the very, very early times and we have had many attempts at this and all of them spent years and ultimately did not get implemented in all the browsers and this one did. That's not nothing, right?
Eric Meyer: I remember when everyone was telling us that XML was going to solve this problem.
Brian Kardell: It is a really huge hurdle to overcome and web components made it.
Brad Frost: They made it, but I think it also sort of... That history unlike, we'll say the doc type curiosity, that is more of just a historical footnote now. I think that a lot of web components fits and starts in history, plays into the current conversation around how people feel about things like web components because they've seen these different sort of generational efforts and these different sort of manifestations of them over the years and seeing the rough edges and seeing that things kind of evolve and it's just a fundamentally different beast than a proprietary JavaScript framework, or something like that. It's just this kind of platform level stuff. As you know way better than I do, just needs to take a lot more into account and do more consensus building and do more sort of things in the open that I think a lot of other places don't need to wrestle with.
Brian Kardell: Yeah, there's definitely a tension here where there will be fits and starts in anything. It's necessary growing pains and a lot of this happen and people have some impressions. You're absolutely right about that. Also, it means that a lot of people will want different things.
Brad Frost: Sure.
Brian Kardell: Web components isn't currently, maybe it never will be, all of those things. We'll have to see. We'll keep trying to get it to be what people need from it. Like I was saying, I think the big thing is that it exists and even if it is useful for let's say one out of 10 use cases.
Brad Frost: Better than zero.
Brian Kardell: Well, that's huge actually, because given the size of the web, the diversity of the web, that is a huge, huge, huge number. I think that the capability and the potential is there for something to get really widely used and maybe it's not super huge, but the other part about it that is really I think interesting is it gives us a means to create slang for the web. We have this dictionary of HTML elements, but we can say... We can start using these new terms declaratively, and if they get really popular, it suddenly gets potentially really easy to write them down because they're not bound up in some other framework or library. We can just look at what everybody is doing and say, 'Gee, everybody thinks that this custom element is the bees knees.' Right?
Eric Meyer: Right.
Brian Kardell: Maybe we should have an element like that.
Eric Meyer: Yeah, it is kind of the SaaS pattern for CSS, or pre-process in general where the working group, what it started had to just come up with things that they thought that web developers and authors would want. Now that SaaS is super popular, they're able to shift much more to a, 'Well, lots of people use variables.' We should probably have a way to do that in native CSS. Well, lots of people mix colors with dark and or light and or tint or whatever. We should probably have a way to do that. Expanding a little more, lots of people use JavaScript frameworks, so they can have parent selectors. Maybe we should have a HaaS tutor class, stuff like that. The thing is, I think the advantage of the SaaS to CSS pattern is that there really are one or two popular pre-processors for CSS. You know what I mean?
Brian Kardell: Yeah.
Eric Meyer: SaaS-less. There are large communities around those and I'm not... Do you see communities forming around custom elements?
Brad Frost: Should be. There should be. Let me paint a picture here, if I may?
Eric Meyer: Okay. Oh, please do.Be our Bob Ross.
Brad Frost: Hard degree that I think that these things really are the test kitchens for what ought to be an HTML proper. I duck my head into so many different organizations and at some point in time it, and I'll just kind of blur this together. It really does boil down to the same, again, when we're talking about design systems, it's like between 50 and 100 common [inaudible] components. Now, not all of those ought to be their own sort of custom elements, meaning future HTML elements. I don't know if it's valuable to have a card HTML element proper, but at the same time I see all of this stuff and I'm just like, 'My God.' The just sheer amount of human energy that's going into just creating and recreating and recreating and recreating and recreating this stuff again and again and again and again. I'm like, if I had my magic wand, half of this stuff, at least half of this stuff is going to end up in HTML proper.I like that web components is kind of this stepping stone, or test kitchen, or however you want to frame that to a pathway to making this stuff and getting this stuff into HTML proper and looking at the work. Brian, I know you're involved in this as the Open UI stuff, which I'm on the outside of, but it's like I'm aware of this work to take these kind of common patterns and try to put pen to paper to get them into more of a state where it can hopefully be implemented in the browser because let's just be frank, people shouldn't be creating their own custom date pickers. People shouldn't be creating their own UI widgets. People shouldn't be creating tabs and accordions and accessibility. We like to just pile on developers and oh, 98% of websites are inaccessible and all... Fix it. These are not unsolvable problems and we should solve them at lower levels, so that individuals can just pick up the right thing and just get a bunch of stuff for free.What I feel is this wasted human potential and wasted just sort of developer time multiplied thousands if not millions of times all over the world recreating the same freaking custom dropdown and it's like let's just... Can we not do that?
Brian Kardell: Yeah. Actually, I'm glad you mentioned Open UI because if you haven't seen it, I guess it was 2018 or 2019, you can look it up. Greg Whitworth and Nicole Sullivan gave a talk at a chromium event, Chrome Developer Summit called HTML isn't done! In it they talked about Open UI and one of the things that Open UI is trying to do is to be sort of that test kitchen for incubating the ideas. Even lower than that though is just this thing that Brad is saying, which is like, wow, there are, I don't know, roughly an infinite number of design systems and component libraries and they have so much in common, but they also differ in all different kinds of ways.Some amount of that commonality should not be just start from scratch. How can we catalog those things and try to build some kind of at least collaboration between organizations that build those things and give them a minimal spec that's like, this is what it means to be this. This is what you all have in common and then here's a way that we can make it easier to extend that if you have the rare case where you need to go outside of that.That is probably necessary because none of these things are fixed in time. If I asked you way back in the green screen computer days about tabs, you might have seen some primitive asky tabs thing and you had been like, 'Oh, well yeah, they're just like file folders, they're on the top.' Maybe Lotus puts them on the bottom and they're actually kind of different things. One of them is managing almost independent files and the other is just managing sorts of sections of the same file. Then, Microsoft came along and said, 'We're going to put them on the side, let the world burn.'They're not wrong. I mean, over the years these things kind of change. Today, if you play video games, you'll see radial interfaces, which a bunch of them are effectively tabs. It's okay, we can innovate, we can change. We just need to find ways to say that radial thing is tabs and here's how it maps those parts. Maybe most of the time that's just styling, but all the parts should be the same and you should be able to explain it to your accessible interface and everything. Having some agreed pattern or skeleton there that you start from that is the unspoken, the unwritten down, not W3C standard, but sort of an industry agreement that we've collaborated would be a huge step.
Brad Frost: Yeah. That's right. I think that really is just it like right now. So much of what the landscape is right now is a little bit of a microcosm of what I see in my design system consulting work. I'll go into a big old company with a bunch of different products and a bunch of different silos and a bunch of different scrum teams and everybody's kind of got their headphones on, their horse blinders on, and they're all kind of inventing and reinventing their own sort of solutions. They're doing that not because they're trying to stick it to the man or anything like that, or because they think that their ideas are superior. It's really just a lack of coordination and visibility than anything else. A lot of my job is to provide that visibility and provide that coordination and here's what that looks like to all sort of be marching to the beat of the same drum and let's all do this and contribute to this stuff so that we're, again, putting our smart brains together to make this happen.At an industry level, the world over it is in my view, just again, an utter and complete tragedy that we have all of these independent teams, the world over creating and recreating and recreating things like tabs and accordions and date pickers and what have you. That becomes the open question as, what is that, Brian? That contract or that sort of specification or that shared thing that everyone can just start... What does it look like to open the door to let's all just work on the same accordion pattern?We don't have to do our... And it's challenging because I could tell you that with design systems, one of the big draws and the benefits is that they are meant to be consistent within themselves. One of the biggest things that we do and spend a lot of time on and have iterated a lot over the past, again eight, nine years, is API design. The actual words that we use for attributes.Button text equals click me variant equals primary size equals large, all of those things, all of those constructs are super hard earned. One of the benefits and one of the things that I will say is one of our bits of secret sauce is that we help implement that stuff consistently when most of the time, whenever we look at an existing component library developer one used text equals click me on this component, but developer two used label equals click me or whatever on a different component. There's just some of that just naming things stuff, which is of course hard and hard to accomplish, but it's not insurmountable. It's not insurmountable. I honestly don't know what it looks like to have a global component library, but Lord knows I want one.
Eric Meyer: I mean, it is really weird. I think a lot of this probably comes to the relative youth of the industry. I know Brad, that you do a fair amount of woodworking and that sort of thing, and Brian does that. I do that. Where web components and stuff like that is in the era of before standardized tools, where everybody has to make their own saw and everybody has to make their own chisel and their own whatever. Each person builds it a little differently. Your chiseling hammer, you have to put together from wood and some people make it this way and some people make it this slightly different way and there're pluses and minuses. Now, we're in an area where you buy a chisel, right?
Brad Frost: Yeah, right.
Eric Meyer: You can buy a chiseling hammer. Again, there are maybe different chiseling hammers for different needs, but they're standardized and the web just isn't to that point yet really.
Brad Frost: No, that's right. That's right. I think it's important to paint that vision and this is I think why... This conversation, while it's almost a little esoteric, is ultimately where my head is increasingly at, which is I am not particularly interested in building the best tabs component. That has lost its luster and I'm now at a more existential place of what are we even doing here?
Eric Meyer: Right.
Brad Frost: It is important to paint this picture of like let's go down the road 10 years and what does that standardization look like? What does HTML having a more comprehensive set of components look like? And sure, Brian, to your point that there's going to be new interface patterns that emerge and continue emerging. The world of user interfaces is only freaking 50 years old or a little over 50 years old. We got a ways to go for sure, but at the same time it's like I would love to see more of a way... This is just not new in the whole of human history, but the potential to actually harness the brain power and talents of a global community of developers to all be kind of orchestrated and working on stuff and making each other's stuff better, it's like holy crap.There's the promise of the web right there and right now it just feels so middle school and feels so juvenile when you just see these different factions kind of just clutching pearls and it is total just schoolyard junk. It's like, can we just not? Can we get to the part where we're actually solving real things for the world and actually trying to work together?
Brian Kardell: I think that's well stated in every other instances of can we all just work together? There seems to be a number of challenges with it.
Brad Frost: Yeah. Yeah.
Brian Kardell: I don't know, I think maybe we're young in this as a concept, but we don't have a really good model for how standards should work. Actually, I gave a talk, a number of talks where I say there are an alarming number of standards bodies once you start learning about this stuff. They do things like slightly differently. Each one of them is also constantly changing. The answer to the question, why are there so many standards bodies and why do things keep changing is we have no idea what the hell we're doing. You also wrote a talk called, 'I Have No Idea What The Hell I'm Doing.' I just went back and watched it again and it's a really good talk and I think part of this has to be like, it's okay to a degree, but we should be trying to figure it out a little bit.
Brad Frost: That's great. Let's at least have the vision of... Let's at least plant that flag out in the distance and start working towards it. I think that that's the issue. Really, the world over expand the circle to politics or whatever it is. Things like that. In absence of a shared vision and this is why I think that that sort of values and principles are so incredibly important because if we have a shared principle or a shared value in a... We ought to be collaborating with one another, we ought to be not reinventing things just for the hell of it and get people to agree to that. Wouldn't it be nice if we could all use the same accordion component for instance, and to just get people going? Yeah, that sounds good. Great, okay. Now, we have that flag in the distance that we can start working towards.My frustration arises just in witnessing conversations the world over is when there isn't that sense of shared purpose or values or just objective and people are preoccupied with the tactics or the implementation and all of that stuff. I'm like, these things are beside the point. If we step back and just say, 'What are we actually doing here? What are we working towards?' Then, get into tactics and sure there's going to be differences in tactics and implementations and standards and whatever, and that's totally fine, but let's at least have this sort of vision right and agree to the vision. Some of these things is... I promise I won't get totally into politics, but things like politics, the vision should be we should make things better.Do we agree with that? I somehow doubt actually that there's a fair amount of people out there that would disagree with that. We'll leave that as is, but I do think that we need to just pull back a little bit and be like, what are we doing here? What are we working towards? Once we agree on that, which I think are pretty reasonable and agreeable type of values and principles, things like cooperation, things like shared effort, things like not reinventing the wheel, things like trying to help each other, then the tactics become a little bit clearer and we're able to align those tactics to the broader goals and vision.
Brian Kardell: Yeah, I think the politics thing is really interesting for two reasons. The first one is, it's a good illustration of, of course we should... I think you would find generally agreement with the statement as stated, but you would find a broad amount of disagreement over what it means to be better.
Brad Frost: Yeah, that's right.
Brian Kardell: You have to get increasingly careful about how you craft the thing that you're trying to get agreement on. The other part of this is we just take... I don't know what it's like everywhere, but in the US we run for office and that costs a lot of money. It has a lot to do with letting people know what your policies are and who you are and why they should vote for you and why maybe your opponent is a big liar. That is very, very solvable if people would be involved. I mean, the information is all there and everybody could donate a little bit of time toward that or toward having those discussions with people and going out and knocking on doors, or passing out flyers or whatever. In practice, it's hard to get that level of participation really a lot of times.
Brad Frost: Yeah, that's right. That's why it really does come down to things like the people who do have the capabilities back to the web world. It's something like Open UI, or something where there's an apparatus or there's an easy way to just up vote a bug or do all of that stuff. It's just to really reduce the level of friction that it takes to participate and stuff. I think that that stuff is really fascinating.
Brian Kardell: I had an idea a really long time ago, 2014 or something. I tried to talk to W3C specifically the [inaudible] about it and get something set up. In the end, Google had something that they were trying to do that was similar, but it kind of didn't go anywhere. Today, a need in accordion for my website. I mean, good luck. There's no wonder that people just create their own because you can have an absolute anxiety attack trying to find... There's just so many, right? It's like, well, okay, but this one doesn't work with my system or this one has... How do I even know if it's accessible? A lot of people want one because they don't want to... They don't have a capability of knowing that themselves. I thought it would be great to have a sort of almost NPM, but not exactly NPM, but some central place where you could register your web components.Then on top of that, to have something like Underwriters Labs. Do you know Underwriters Labs?
Eric Meyer: Oh, yeah.
Brian Kardell: Early in the electric industry, well, we wired houses for artificial lighting. That was the full stop. I mean, there were only the little screw in things in the wall that that's all there was. Then, once we had that, a whole bunch of people who were us for the web, but for electricity were like, 'Oh my god, I can do cool things.' They built an entire industry of toasters and refrigerators and all these things that would screw into light bulbs. All of these things made the world dangerous in new ways that nobody, not even insurance companies knew. How do I evaluate this? It started with an industry thing from insurance companies funding the work, but the idea was let's get somebody to say, this one is good. Let's get professionals to actually review them and give us some advice. That way you could say, 'You know what I want? I just want an accordion,' that five accessibility experts and some web components people all are like, 'Yeah, on all levels we think this is really good.' Then, you would not even think about it. You would just say...
Brad Frost: That's right. That's the thing. The whole throwing the baby out with the bath water thing is the thing that just really grinds my gears the most where it's just like, and you have that happening millions of times over the world over. It's like, let's just be like accordion. Let's just pick one and roll with it. If there're deficiencies in it or if there're bugs, then let's fix those and I'll be better off worded, right?
Brian Kardell: I mean, it's not good on either side of this. If you are people who do accessibility reviews for a living, it's not like there's 10, right? There's an infinite number of them. It gets really exhausting to be like, 'Oh my goodness.' Literally my career could be like the accordion bug opener. It's no wonder that sometimes things get terse and there's a level of exhaustion there.
Brad Frost: [inaudible]. Yeah, I fully understand it, but it's at the same time... This is where I think that your idea of having this more officially blessed where it's like lets at least be like this is the one that we're all going to rally around. I'll use an example, so it's for our React projects, React-datepicker is Airbnb is date picker and it became the one. If we're building React based design systems, which we do, and we need a date picker component, which we often do. Guess what we're using? We're using React-datepicker. It's the thing that one, it just had the most gravity and there are other ones that are out there, but this one is pretty damn good. Everyone in that community seems to understand and acknowledge that.It would be cool to have... Here is the thing. Here is the accordions and the tabs and the date picker and the... Whatever components that we need to... Even things like badges or whatever. We can do those things and hold them up under an official structure. If people don't like them or if they're not sort of efficient, or they have deficiencies or bugs that they aren't as accessible as they ought to be or whatever, but we just file issues and fix the things. We're all kind of working along the same grain. We're working to make the thing better rather than going, 'Oh, see there's one little tiny deficiency, so therefore I need to peel off and do my own thing and go rogue.'
Brian Kardell: Which then, your rogue thing will have its own unique issues.
Brad Frost: It happens all the time. I mean, I could tell you so much where it's just the custom dropdown... Native select versus custom dropdown is just such a brilliant example of this, but I need it to also show this little red dot next to the text label. Therefore, we need to throw that native select control with all of its keyboard navigability, with all of its accessibility features baked in. We're going to throw all of that in the trashcan because I need to put a red dot next to that option. That's literally it. Then, what you have to do is then incur all of that work that you get for free if you were to just use the native control and it's like, I see this happen again and again and again and again and you're just like, 'Oh.'
Brian Kardell: I think the big part of that is that all the work is hidden from you in the native thing and that's good. It's actually really good that it's all... You don't need to know all that. You just need to know, oh, select. That's all you really need to know. As an example, a button, it's so simple. We put a button in your page and there you go. I've seen Léonie Watson give a 45 minute talk about let's make a custom button and let's do all of the things that are necessary to make this almost an exact equivalent of a native button. It's like a lot. You don't have to know all that stuff when you use just a regular button.
Brad Frost: That's what we want to get to as it's just, again, how do we make the right thing, the easy thing? How do you make the thing or just by using the right tag? You just get the goodness out of the box. Yeah, I don't know.
Eric Meyer: Absolutely, make the right thing the easy thing and make the wrong thing the difficult thing.
Brad Frost: Yeah.
Eric Meyer: I learned that from Kathy Sierra basically. She's like, 'This is a principle of horse training and it's also a good design principle.'
Brad Frost: Yeah. It really is. I feel like in my design systems work, it's one of the most universal kind of principles of it's like this is how to make this successful is you just pick it up, you get the stuff for free and you go with it. There's another interesting thing to learn. The React community has kind of gone in this sort of direction of there's this emergence of what's kind of called headless UI stuff, which is basically here are these components and you kind of bring your own. One of the fascinating phenomenons I think is that a component's behavior and style or semantics behavior, but also the visual style travel together, which on one hand is very welcome, but on the other hand, it's not. Especially, the visual design language part of it. That's why things like material designer's such a double edged sword because it's like, oh, I am reaching for material design because I want tabs to work, but my designers want to be able to design the tabs to look how they want to look like.I don't want this weird ripple effect when I click on the buttons. That's weird. I don't like that. That's where I think that this sort of trend in what I see playing out in the React world, which is we're going to just create these primitives or these components that take care of the necessary binding of whatever... The [inaudible] stuff is stitched together in the right way, so that something are expanded true or false. It all just kind of works, but you bring your own presentational UI to the party. That's I think a really interesting thing and something that I would love to see at the platform level as well, which is just like this... Rather than this... As much as humanly possible, decouple the aesthetic presentation of something with the semantics and accessibility and behavior of it.If we were able to get that right, then that would be super cool because that way people can style things to their heart's content, but all of the necessary accessibility stuff is just baked in and you can trust that it's going to work. Those are just interesting trends that I see playing out elsewhere that I'm like, 'Huh, that's an interesting opportunity I think for HTML level stuff,' which I guess I'm kind of describing what HTML does in general I guess because that is what it's doing. How do we extend that further into things like web components?
Brian Kardell: One of the interesting things that gets really challenging is that the more flexible and fluid we make these to presentation, it's very hard to separate entirely semantics from the presentation. If you squint hard enough, these two things look really similar, but maybe they're actually really different.
Brad Frost: Yeah. No, it is challenging and Dave Rupert said it really well where it's just, what we want to do is attack something from a purely semantic or HTML level thing. As soon as something needs to sit beside the other thing, then you got to bring styling into it and that everything goes off the rails. It's like what do you do with that? What do you do with that?
Brian Kardell: Are there any pain points that you think it would be really good priority for us to address and maybe why with web components? Maybe as part of that, I would like to know your thoughts on Declarative Shadow DOM.
Brad Frost: I think right now, and I mentioned this in the article and another one that I linked to, which is the word is geist, which is where everybody's at now, these JavaScript communities have come full circle and are now like, 'Hey, we should spend HTML over the pipes,' which translates to, 'Okay, we want server side rendered experiences.' This becomes one of those web components to do that. It's like, well, they do, but also they don't. It's complicated but also... And didn't write this in my article. I don't think that a lot of people truly understand and what they actually mean by server side rendering. I think that they just see... They're treating it as this kind of very coarse definition of something when in fact it is a lot more nuanced and gets into the magical world of progressive enhancement.I think that whole big ball of wax, which is to say server side rendering web components and making that work well. The picture that I painted in the article is that it's like we want the developer experience to be one of... I want to do my dash card and then passing all the props and just have that experience, which is we've come to know and love. Which is just, oh, I'm reaching for this. I need to splat a button on the page. I'm going to do my dash button and then pass in the props and move on to the next component and do the same thing. That is a great developer experience and is one that, again, plays out syntactically different across React and Angular and View, but it's all effectively the same thing.We want that experience as developers, but then we want the browser experience, the actual thing that gets rendered to the browser to be server side rendered and progressively enhanced and elegant and work on page load, but then also enhance with superpowers once JavaScript becomes available. In that respect, I look at something like Declarative Shadow DOM and I'm just kind of like, cool I guess, if I don't have to think about it. That's how I see it. If that's the shape that needs to take in order to unlock that good SSR progressive enhancement sort of strategy plus the developer experience that we all want, I'm fine with it.I don't want to write that. That looks like garbage, so it looks bad and I wouldn't want to author it, but if that's the shape that it needs to take in order for it to work properly and that the machines can convert my stuff into that, then that's fine. That's how I see that ball of wax and I feel confident in several conversations that I've been having with different people. Zach Leatherman, the [inaudible] team and just other people. There's a lot of smart brains working on this stuff, so I feel pretty good about that being not necessarily a solved problem, but at the same time I feel like this time next year we'll have a lot more mature solutions in there.
Brian Kardell: Yeah, I don't know. I hope so. It's always tricky because any kind of engineering, there's what you feel like you might want, and that is broad and then there's a lot of steps to get there and at some point you go, 'Well, that part is shippable all by itself.' It's not the whole thing, but let's ship that part. That happens in specs all the time. Every CSS spec does that. With Declarative Shadow DOM too, is that I think that Declarative Shadow DOM is not what a lot of people are asking for. It is the sort of a minimally useful thing that I think you're right. Nobody wants to write that. It will be interesting to see how that plays into the conversations, whether people reject it because it's ugly, but also not really quite what they want yet or whether we're able to wrap some things around that. People like Zach, for example, show this can be really useful and it can be hidden from you. Here are these new ideas and those new ideas then will also then end up helping inform the standard as it develops. It's interesting. We'll see.
Brad Frost: Yeah, it is really fascinating because I just want to be like, yeah... My header, here's the source to that HTML file and just work. Then, it does get complicated as soon as you're like, 'Oh, okay. I do have some JavaScript and stuff that needs to be rendered in there.' That's what I think is really interesting because there's this... What I wrote about in my article was this, most web components don't need to be web components at all, right? It's really just an abstraction for markup. What I want to do is write product dash card title equals name of product price equals this image source image alt call to action and just write that and have the right thing render. The right markup, rather. There's no JavaScript involved, anything like that. What we want is basically to just do your old school, whatever PHP includes or Handlebars or {{mustache}} or any of those [inaudible] language, you just want to be take this web component shape and convert that into just raw HTML.That's totally fine, but then it gets weirdly complicated when you're like, 'Okay, now all of a sudden I want that product card to be exactly the same way, but I also want it to be dismissible.' Right? I want it to render an X button in the top right corner of the product card, so that the user can edit their cart or something like that and sort of remove this thing from their shopping cart. You're like, 'Oh, okay.' Now that JavaScript's involved, now it's like got to do these different back flips and it's really fascinating. At the end of the day, as developers, we want that common developer experience, which is truthfully, I just don't care. I don't care how it works at the browser level. You guys obviously care, but I'm just kind of like a... So long as we all just get to write things in this nice way and it just ends up working, then I'm fine.
Brian Kardell: Yeah/.
Brad Frost: That's, I'd say, the biggest front of mind topic. I think that there's some other stuff around Shadow DOM that's really interesting. I'll say accessibility. It's like I want to have a label web component that bakes inside of it, the required versus optional props. I want to bake in the styling, I want to have all of this just as a thing. Right now, you can't do that. The Shadow DOM is so strict that I can't create a text field, or a text input web component and a label component and then wrap both of those and into a text field component and have the label be associated with the input. It's impossible to do that right now, which feels gross.
Brian Kardell: Igalia is actually working on that.
Brad Frost: Yeah, there we go. Well, thank you.
Brian Kardell: With some financial support from Salesforce.
Brad Frost: Great, great.
Brian Kardell: So that's great.
Brad Frost: That's what I see it as. These aren't impossible problems, they just need solved. Thank you for helping solve them, but it's like that's the kind of things that I get frustrated with that. Eric, I know you've been in this dance for longer than I think any of us, but it's like you just see the things where it's just the current solution is not exactly what we want yet. People are dismissive of the entire project and that's just a really exhausting thing to see. Whatever responsive images and just crap like that. Just fix the problems. It's fine, it's fine. Sure, grumble about it, complain about it, but let's direct it in a productive direction. We'll get them smoothed out, we'll get them shipped, and then we move on with our lives. Eric's book is the second book I read as a web developer, so I knew that he's better out [inaudible].
Brian Kardell: The first one was the Cat in the Hat and then directly into the CSS Bible.
Eric Meyer: Thank you for reminding me of my age. You kids today.Your Shadow DOM and your... You kids, get off my DOM.
Brian Kardell: That's very good. You should tweet that one. Thanks Brad for coming on. This has been...
Eric Meyer: Brad, where can people find you on the inter tubes?
Brad Frost: Yeah, so bradfrost.com. That's where I blog by thoughts. It felt good to finally get a good meaty blog post out the door for... Had a lot of life getting in the way of my blog post. Brad Frost is my home base and then my drug of choice is still Twitter, so I'm Brad underscore Frost on Twitter where I share web things as well as not web things. I apologize for the not web things.
Eric Meyer: No, no, no, no apologies.
Brad Frost: All right, well hey, thank you so much for having me. This has been great, and I enjoyed the conversation, so thank you.
Brian Kardell
Eric Meyer
Brad Frost