Do you listen at 2x? Do Chris and Dave sound weird at normal speed IRL? How searching compares to using AI, chatbots kind of suck at context, getting a designer to work with developers at an agency, what happened to content visibility, and how to best build a design system using web components.
Time Jump Links
- 00:20 2x intro
- 02:29 Are you using AI vs searching the web?
- 17:56 Chatbots suck for context
- 27:55 How do I get the designer to work with us?
- 37:08 Could you talk about content visibility?
- 44:35 When building a design system using web components, would you start from scratch or building on top of existing libraries?
Episode Sponsors 🧡
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris. How are you?
Chris Coyier: That's right. I'm doing absolutely wonderfully. Thanks, Dude. Um... yeah.
Dave: That was probably pretty fast, if you're listening to this at 2X. [Laughter] Sorry. I apologize.
Chris: Yeah. I definitely do, too, man. I can't. I'm a fast listener. I guess that makes me think of our buddy at Feedbin who has released Airplay - or something - Air Listen, Feedbin's new podcast listener tool.
Dave: Air Show.
Chris: One of the missing features of it was playback speed, which to me is so important that it's kind of a miss. I can't listen to podcasts at 1X anymore.
Chris: Maybe you ruined me. You even listen to your YouTubes that fast.
Dave: YouTube, audio books, everything, man. I'm used to it, and I can't do 1X. It doesn't make sense.
Chris: Mm-hmm. Sometimes I'll accidentally listen to something at 1X. I'm like, "Did they get dumber?"
Dave: I do. It makes you... When I hear people, people who are smart, like Wes or Scott Tolinski.
Dave: If I hear them give a 1X conference talk in real life, I'm like, "Dude, what happened to these guys?"
Dave: But it's just like, "Are they okay, man?"
Chris: Yeah, because you're used to it. [Fast rambling] Yeah, just cruising.
Dave: I'm just thinking, "Oh, man. They're just hyper-witty. Boom-pap. Boom-pow!"
Dave: It's like, "What's happened?" But it's just normal. It's like I have created this reality distortion field in my ears, basically.
I hear it in politicians, too, because I listen to a lot of political audiobooks. Then they'll just be talking very eloquently, and then my library podcast or audiobook app will flip out and go back to 1X. I'm like, "What happened?! Is this person talking so slow they're talking backwards?" This is how I feel sometimes.
Chris: Amazing. I was on a Web, Whiskey, and Whatnot recording the other day.
Dave: Ooh, fun!
Chris: Yeah, yeah. They did their 100th show, and Wes and Scott were on it, too. One of the things that came up, not to rehash it, but just to ask you kind of a similar question is, so as far as these -- and I have to put air quotes around it -- "AI tools" factor into your life, specifically the ones about chat. A couple of caveats there. There are a million different types of these, like even your spam filter is probably using some LLM stuff at this point and training.
Chris: We know that image tools are such a huge part of this new wave of AI tools. That's not what we're talking about. Specifically about the chat-like ones, meaning Bing's thing and Bard and ChatGPT.
I feel weird calling it ChatGPT, too, because they released this GPT-4 model, which is better and more interesting to use but isn't called ChatGPT. They don't use the chat thing, or do they? Is it still ChatGPT and then it just uses the GPT-4 model? Maybe that's the case.
Dave: I think so, and I think you have to pay to get the GPT-4. If you log in now in OpenAI, you're using 3.
Chris: Maybe. I used it because the demo had CodePen in it.
Dave: Hmm... Yeah, yeah.
Chris: And it had me fascinated on producing HTML, like kind of full output that way, so I paid them the money.
One of the ways that you can use it, of course, is just to go to openai.com and log in and use it. You get a fairly nice, little UI with the text box thing at the bottom, and it pushes up stuff.
What came up on the show was, are you using these chat-based interfaces instead of searching the Web? I feel like the answer I've heard not only just on this show but from people all over the place is like, "No, but it's like 50/50." I'm like, 50/50?! I'm like I use these once in a blue moon for something.
Chris: When somebody says 50/50, I guess they're dead serious, right? If they want to know how border-radius works or whatever, they don't type it into Google. They come to one of these things and type it in. Wow!
Dave: That is not me. No. I've used it. I don't find the chat interface to be compelling to me, I guess. That's maybe just me. I think GPT language completion models (or whatever these are), just the ability to predict a text, a long chain that sounds vaguely human.
Dave: I think they're cool. I think they can really help you. If you have no idea what you're writing and you're like, "Uh... Just write me a ten-page essay about whales," boom, it'll spit out a ten-page essay about whales. It might be totally incorrect. It might be somewhat right. But it'll do it.
I think that's cool because you're like, "I'm just going to start from nothing and get to the point I want to be really quickly." I think that's very cool.
I think I struggle because I'm like, "I want an outcome. I want a blog post about whales that no one has ever read before that's just very exciting and very interesting."
Do I have a red paint here? What is this?
Chris: I think you're bleeding, man.
Dave: Am I bleeding? Oh, I am. Yikes!
Chris: [laughter] Feel free to take five!
Dave: Gees. It's like a bullet wound. We'll be okay. I've got another change of shirt. What is going on, though? Sorry about that. [Laughter]
Chris: You have an outcome in mind. So, when you're using an AI tool, you want something out of it.
Dave: I want an outcome, right? I struggle with, okay, what prompt do I have to write to get the outcome I want? Or what series of prompts?
I think you have to be more improv, like, "Hey, let's just type and see what comes out." Then I'll sharpen it and hone it to what I want it to be.
I think you need that attitude whereas, for programming, for example, it's like I know what I want to code, but I don't know what to type to make the computer code that. I'd rather just code it.
I think I stumble with the idea that the prompt is the interface. The prompt is the API. The prompt is the genesis point for how to.
Chris: Yeah, right. Producing writing is a pretty niche case for these things, I think. I get that that's what a lot of the... It's about teachers being sad that you don't have to write an essay about whales anymore because it's already produced for you. That feels pretty niche.
Sure, we need to talk about that, but is that what people are actually asking these things for? I think probably not. It's probably more like I'm applying for a job or some help summarizing this thing.
Dave: Give me ten things to do in Austin, Texas.
Chris: Yeah, that's interesting. Now that's a good one because that's like, of course, you would Google that. But actually, the AI tool might do a better job because there's less crap. It's just giving you some text output of things to do and less messy and less SEO gamed and stuff. I'm fascinated by that being actually something that if you were to switch over and not use Google but use ChatGPT instead that you might get better output for.
But there are so many that I wouldn't trust. If I want to buy some new shoes or something, I'm going to stay on Google for that because, for one thing, its cut-off model date is so old. I don't want shoes from three years ago. You know? I need to know who is selling shoes right now and that type of thing.
I'm wondering what the Google search history is for someone who says they now do 50% or more of their searches have completely moved over to ChatGPT or a similar tool. What does their chat history look like? What were they googling that has made this possible? Fascinating.
Dave: This is really -- I'm just asking, like, give me ten things to do in Japan. It's giving me some pretty okay recommendations.
Dave: You know? Like, "Explore Tokyo," with some neighborhoods listed. Experience Kyoto. Go to Kinkaku-ji. Got to do that. Visit Hiroshima and Miyajima. Okay. Relax in an onsen. Heck yeah. Explore Nara. That's pretty good. I don't know. I guess I just don't think--
I remember when I was in college. I was in college and Google had just come out, so there you go - how old I am or whatever. I was like, "How does my friend Chase know all this crap? He just knows stuff. He very much could find answers very quickly." I realized he was just good at googling. Does that make sense?
Chris: Oh, he just had a skill at it? Yeah.
Dave: Yeah. And maybe he was using some of those filters like minus keyword or whatever.
Dave: There are little kung-fu secret--
Chris: In the grand scheme of things, it's a pretty simple one, but I'm sure there are lots of really advanced ones.
Dave: Yeah, but if you're just like, "Site, reddit.com, whales," and get all the latest stuff. Sort by latest - or whatever. You can get some really cool information. You can coerce Google into giving you really good results.
You learn. I think my original Google would have been whales, you know? That's going to give you just a very broad cast. But I think I learned what whales, North America, and that produced a better search result than just whales.
Anyway, that's all to say I probably just don't know. I'm not a good prompt engineer or I need to get better at it. Maybe that's why I'm not... Or I haven't been like, "Hell, yeah! I'm all in!"
Chris: Yeah, and it'd be interesting if you could talk to that person and see. Has your excellent Google-fu translated? Are you now also excellent at using chatbot tools because that's how your brain worked anyway?
Dave: I wonder. Yeah. I think he has dabbled with that stuff.
Dave: But I don't know if it's necessarily changing his life right now. Yeah.
Chris: I'm trying to look at my Google search history to see which of these probably would have been better on a chat tool.
Chris: There are so few. Some of them are clearly I'm just trying to get somewhere that I already know exists but I just want Google to just find it for me more quickly. [Laughter] Like the name of a city or a common one for me lately is a really badly misspelled Tears of the Kingdom shrine that I just need the answer for. You know?
Chris: Obviously, a chat tool isn't going to help wit that, or the name of a local business or something. I'm just looking at my own experience and being like, a chat tool is just not going to help me with almost anything that I Google. That's why I'm finding it hard to picture this transition over.
I'm not asking Google big, breathy questions about life and stuff. It's really just two-word things that I just want the most basic possible help with.
Dave: Well, and you know what gets me, too? I think the more I understand how these work--
Dave: I just gave this thing a seizure. Oh, my gosh, dude. [Laughter] Oh... Okay. So, this is a screenshot. Oh, my gosh.
I just asked is, because I was googling earlier today, like, "How many websites use JS framework, like a component-based framework?" I was trying to find out what's the ballpark of that.
Chris: That might be a good one for it. Although--
Dave: We hear a lot, right? You think a lot, but what's the number? But anyway--
Dave: I just asked it, and it gave me some examples like React, Angular, Vue, and then it's used by companies like Xiaomi, Alibaba, Xiaomi, Xiaomi, Xiaomi, Xiaomi, Xiaomi. [Laughter] It's repeating Xiaomi.
Chris: Oh, it lost itself?
Dave: It just gave up. It just had a heart attack. It's great. Good software, Chuck.
Chris: That's a funny thing, though. It's not trained on data. It's trained on a bunch of words that other people have written, right? The only way it would know is if other people had good data and other people wrote about that good data that they had.
Dave: Well, and that's what's weird to me. I feel like the way I know it works is it's just like predictive text. Then it says, "Well, instead of the best word, I'm going to choose the not-so-best word every once in a while and then kind of keep going." It's convincing to humans, but it's not accurate, so why would I put everything in? Why would I bank, run a business, which I see people do all the time, or do stuff based on it?
I saw an experiment the other day. Somebody was like, "We're just going to code an app and let GPT take the reins, you know, take the wheel." I was like, "Okay," and I think they kind of made something like -- oh, shoot. It was like a doctor care quality based on zip codes or something like that. Anyway, I guess it can do stuff if you're patient enough. I don't know.
Chris: All right, so here's a related one then is let's say you are like, "Okay, this is the perfect question for a LLM chat." Obviously, during this show, I've already struggled at what we're calling these things. It's easy just to say ChatGPT, but that's kind of what my question is. If you have one in mind and you're going to do it, that's just one of the options is to literally go to OpenAI, log in, and use their tool.
Chris: I think plenty of people do that. I've heard people say, "Ah, yeah. That's just where I go." But there are starting to be more and more ways. There might be an app that uses that as its API. There might be a different tool entirely. I find myself going to Bard just because one of the things I did is, in Arc, I just made one of my spaces a little AI space. I just have them all bookmarked in that, in there.
Dave: Oh, okay. Neat.
Chris: But the one I like about Bard is that it's your Google account, which I'm just logged into all the time. So, I'm never logged out of it. If I click on Bard, it's ready for my prompt.
I find that just a little UX important whereas OpenAI logs me out all the time. If I have to use OpenAI, there's always that little bit of friction, like, "Okay. Let me log in and then navigate myself back to where I can type in my little prompt."
That's never going to work. The point of searching is it just needs to be just one second after I have the thought, I better be searching for it. That's important to me, so I find Bard nice in that way.
But even better, I was on the show with the fellows at Web, Whiskey, and Whatnot (and a bunch of other people). Wes was like, "Oh, I use Raycast," and I've been into the Raycast thing. I think you use it, too. You can just open Raycast and type AI and pick the AI chat thing and, boom, you're going with it.
Dave: Oh, interesting.
Chris: Now that's starting to get into my muscle memory, too. The speed of getting to somewhere where I can type one in really fast is crucial to me.
Then on my phone, I have the Wavelength. It's like a chat app.
Dave: Okay. Yeah.
Chris: We should almost be friends on it. But what's kind of cool is it's a chat app, but in any chat with anybody, you can just type @ai and it will spit out an AI answer in the middle of the chat. It's kind of the first take on that I've seen. But it makes it kind of fun because it's like in the middle of a conversation you're having about something else, you can be like, "Oh, fact-check that really quick," or interject some AI content.
Dave: Yeah. Interesting.
Chris: It's kind of a nice take on it. But then I can just have a chat with just myself. Otherwise, I don't have a thing on my phone to do AI, otherwise. I guess I could log into the OpenAI website, but I'm not sure how good its mobile layout is. I'd rather just have an app quick I could do it. And so, my go-to choice has been this Wavelength app.
Dave: No, that's cool.
Chris: Okay. There's that. Also, the fact that you mentioned that chatbots suck. There have been two articles somewhat recently. One by Maggie Appleton and one by Amelia Wattenberger, two of the best bloggers in the world.
Dave: Yeah. Yeah.
Chris: They're both just crapping on chatbots as part of this AI stuff. It's not even that the idea is bad or that LOMs are bad. It's that the interface of a chatbot is just very limited and kind of annoying. I just so agree with that.
I like contextual stuff so much better than me having to use my dumb little fingers to craft exactly what needs to be input into this thing. I find almost any other interface better and more interesting.
Dave: Yeah. I would rather... like vintage Russian computers with 10,000 buttons I've got to flip in the right order.
Chris: [Laughter] Yes!
Dave: You know what I mean? Like a hallway-size computer versus using the right English words.
Chris: Phrasing. Yeah.
Chris: ...right all the time. I love using words. Words, words, words. I don't mind words, but I just feel like then I have to deliver the context. It's like, don't you just have context a lot of the time?
For example, in GitHub Copilot. I don't mind that because now what I'm doing anyway, the action of doing coding is providing all the context. Thus, there's just code being shuttled in front of me at all times. The context is just provided, and that's what I think is so powerful about this. Why can't that happen move often? Whatever I'm doing becomes the input for a model that's then suggesting things.
Dave: Yes. I think that's kind of what Amelia was saying in her article. Without it knowing exactly what you're working on or what you're doing, the context is really murky. You have to tell it everything, and that's, I think, where I struggle to type a good prompt is, why do I have to tell you to get you to do it? What words do I have to use or data do I have to seed to you? That's the stuff I don't know that well.
I've been talking to people, some big companies or whatever. But where they're seeing the value is not these large language models but basically the same tech but applied to their data set. It's like if you're looking at your Stripe data, you could be like, "In the next month, who is going to lapse? Who is going to churn based on whatever trends we're seeing in our customer data?" or something like that.
I'm sure this stuff exists, but this pre-intelligence or something. That would be useful. You could be like, "Okay, cool. Well, I'm just going to give these people a free month off and make them feel good," or whatever. I don't know. That's silly, but maybe there's--
If you had that sort of stuff, I feel like it's more powerful with your data than me like, "Hi. Give me ten ideas for reducing customer churn." It would be more better to be like, "Look at my data."
Dave: "Tell me who is about to flip off and let me catch them."
Chris: There you go.
Dave: Or ask them questions or get engaged with them or something.
Chris: It's not hard to imagine a future in which that models like this are just constantly being fed context from what you're doing and thus really are suggesting things. If you're like, "Oh, where is a good food cart around here?" and have the thing be like, "You know it's raining, right?" You're like, "Oh, really? Thanks, model." You know?
Dave: Thanks, model. Yeah. Like, "Oh, you're in Portland? Well, cool. Brunches are super popular. But you're going to have to be there by like 8:00, or else it fills up." You know? Or something. I don't know.
Chris: Yeah, "But there's one three blocks away that is totally empty." I love that.
Dave: Give me that level of stuff. That's where I like Copilot. It's in my codebase. It kind of has an idea. If I had more types, I'm sure it'd be more intelligent.
Dave: Blah! Damn it! But it's in my codebase. It kind of knows what I'm working on and it has context and it can suggest similar stuff to what I have. Sometimes it does just invent properties that are not on my objects and stuff like that - whatever. But it gets me kind of close sometimes.
That's what I like about Copilot is it's so specific to the code repo I'm working on and the language I'm working on. It's not suggesting C++ code. That's cool.
Chris: Yeah. I wonder what the opportunities for refinement are with it. I heard that from somebody. I was at the farmer's market with a guy who runs a bunch of restaurants here in town. Interesting guy, and he follows this stuff, or tries to, but from a non-tech perspective.
He's like, "Oh, yeah. I've been playing with it. I had to do a catering the other night, and I asked it to make a tapas menu for me. And it did okay," but he had already internalized the idea that you don't just type something in, you get it, and that's that, which is a little bit true of just googling something, right?
If you want different results, then you have to go back up and change stuff or whatever. But with this chat-like interface, it's one of their strengths, I think, is that you can be like, "Yeah, that's close, but I'm not that into pine nuts," or whatever, and it will give you that same menu, perhaps, and it has replaced some recipes that doesn't have pine nuts in it. You can communicate back and forth with it until it has produced this perfect tapas menu for you.
Really cool. I think that's the... If that's what you need out of a model, then that chat interface is actually a good one. I don't know where I was going with that, necessarily.
But then if I tell him, "Oh, here's how I use it," it's just built into the tools I already use as a developer. And it has a crapload of context. So, as I'm writing, it's just digesting what I'm doing and presenting me this ghost code out in front of what I'm doing. I've got to tell you, man. It's right a lot. [Laughter]
I think that's impressive to people that have otherwise been left to their own to figure out how this can be useful to them. Us developers have been shown very clearly how it's useful to us.
Dave: Yeah. Framer recently launched an AI product, Framer AI. You said, "Build me a website," and it will do it, right?
Dave: The demos they show are very high quality, very high class. You did into the page. There's no H1. Whoops. [Laughter] There are no links and stuff like that.
But it's a pretty good-looking webpage that you could fix up and tweak. That's actually kind of cool that it's doing that.
What's not clear is how they seeded or what they said to the computer to make that page. How much do I have to type to make that page happen?
I think I just have questions about that. Maybe I just need to go all in on playing with AI, but I don't know. I have a job, so I don't know how I do that. Yeah.
Chris: Yeah. I know what you mean. Yeah. Of course, I immediately saw the tweets be like, "Designers are over."
Chris: That were serious. They weren't even jokes. I'm like, "Oh, do people still think like that? Have we learned nothing?"
Chris: Yes, they do still think like that.
Dave: I think it should be said, one version of design is just get pretty pictures, but the value of a designer is not just getting pretty pictures that turn into code. It's strategy. It's knowing what works. It's having an opinion. Zigging when everyone is zagging. There are all kinds of different stuff that goes into good design.
Chris: Right. The most rote of the portion of design is what is being gobbled up.
Chris: That's true. It's not like this industry never changes. We did live through the absolute gutting of the $1,000 website, for example.
Dave: Yeah. No, that is like Squarespace, Wix, and all that have basically eaten that whole entire market. Maybe the threat is actually for those guys. There's now a $2 website and now the $10 a month website thing. Maybe that's where things are headed.
Who knows. Maybe they'll take me out, too. I don't know. [Laughter] Please, release me from this prison. At least give me universal basic income, though, so I can go farm or whatever or clean oceans. I don't give a... I don't care.
Chris: Yeah. Yeah.
Dave: Let me go do that.
Chris: We can go be Applebee's line cooks, Dave, any time.
Dave: Dude, I ain't afraid. I'll do it.
Chris: Me neither. Let's see. What else do we got kind of cooked up on our little page of glory here? Should we do a user question? That might be kind of fun.
Dave: Yeah! Listener question. Steven writes in, "I find myself the lead developer in an agency focusing on custom WordPress sites for 120 clients and growing."
Dave: Wow! Awesome. "Everything is running smoothly except our new designs. We have a designer who sees terms like "embeds" as developer speak, and they aren't interested in learning the Web rules. It's become an issue when they select a font that only lives in design tools and is not found for purchase or download anywhere.
"Communicating the rules, the dev team is not trying hard enough or taking control from design. The designs I get are usually pretty difficult and time-intensive to hit. Designs are page-by-page. Margin padding rule change drastically from page to page. I've been doing this seven years and I've struggled to get the layout correct. My junior dev finds it impossible. Okay. How do I get the designer to work with us?"
Dave: "I would love to get them design in components since that's how we build." Yeah. I don't know. There seems to be some terms like dev speak and designer doesn't do dev speak.
Chris: That's wild. There are some real disconnects happening here. Just the fonts one is funny to me. That a designer thinks that they can just pick absolutely any font on the Earth and then just assume that it's going to work.
Dave: Here you go. It's 20 House Industries' fonts.
Dave: It's like, "Ooh! Yikes."
Dave: This is a $50,000 website. Yeah.
Chris: Yeah. That one is pretty basic, and I might put that... In this day and age, I might... It just seems like one sentence can clear that up. Be like, "Oh, we have access to these type of fonts for budget reasons and because they're produced to work on the Web. Not every font is that works on a computer."
It's not a long learning process. It's a pretty clear on. You just learn that once and then hopefully that's smoothed up.
The fact that it hasn't and continues to be a problem means that there's some people stuff going on. But I do read this and think that there is some... It's not a one-sided thing. I don't read what was written here by Steven and say, "Steven is right and designers are wrong." There's certainly...
When things go wrong like this, it's wrong for two reasons. It's like every divorce is a two-sided street.
Dave: Mm-hmm. Mm-hmm.
Chris: That kind of thing. I just see that. There needs to just be more talking and planning around that stuff. You think you could show them a design and be like, "See how this one... There is very little spacing around it. But on the very next page, there's a whole bunch of space here. Which one do you prefer? Is there a good reason why they're very different? Could we middle-ground that? Could we establish that as a variable that's used over and over?"
That kind of stuff is like... I'd like to call it just easy communication. That's just something; you do a meeting. You talk about that. You agree, and you move on. If you can't agree and it continues to be a problem, then there's a human being problem happening there, not a technological problem.
Dave: Yeah. It does seem like you're in a toxic relationship.
Chris: [Laughter] There you go.
Dave: There's probably some TikToks you can watch about that. Yeah, I have been in similar situations. Not so much with my two coworkers, but just the occasional consultant or embedded person and we were the consultants - or whatever - that we kind of came around.
It's hard, man. I think you also kind of have to look at what you can do as a person. One thing you can do is try the whole, like, I'm just going to say, "Yes, and." I'm going to be full improv. You hand me this weird design, and page one and page two are different. Say, "Cool, I'm going to do it. I see some differences here. Let me outline those differences. If we don't want to fix them," like what you were saying, Chris. "If we don't want to fix this, it's just going to take extra time."
Then that "takes extra time" is a buzzword that should go up to management, and they should be looped in on these conversations. It sounds like this person is not seeding control at all. They got a job designing websites and they don't know how websites work, and that's a bad deal.
I think building in components is cool.
Dave: But they may not be there yet. They may not understand that yet.
Chris: Yeah. Wouldn't that be ideal if you could say, "Hey, we build in components around here. You like Figma, right? Figma can do components"? Build like that.
That's a lot to ask in one day be like, "Can you change the entire way you design?"
Dave: Yeah. Yeah, they can't redo that overnight, so it's going to be kind of like, what is the biggest pain point? Designing page-by-page, you said, was a big deal. I think margin padding rules changing drastically.
It seems like this person doesn't want to work. [Laughter] Or doesn't want to do the job to help development. So, you could maybe raise that as management, like, "Hey, we're in a toxic, condescending relationship with design, and so we either need your help to fix it or every project is going to take five times longer because we're doing very bespoke, non-repetitive coding."
Or have a conversation about what could we systematize. That might be a good way to start a conversation. "What about our designing process can we systematize because right now we're doing a lot of one-off work and that's really expensive and churning and leads to mistakes and bad mobile stuff or whatever?"
I would also say -- I'm a big fan of this -- write down specific events and observations, and maybe start a conversation that way. On June 7th, we did... I was asked to code this layout. It resulted in that page taking five days because it's kind of just so different than the normal page.
Chris: Yeah, that's huge, isn't it? Rather than having this emotional flinging things around about how they act and how they feel. That's too... Yeah. You need have the specifics of the events down.
Chris: If you don't have specifics, then you almost gotta wonder if you're right - in a way. I feel like it's that important.
Dave: Yeah. "Me no likey," isn't going to work. [Laughter]
Dave: And "They're being mean to me," doesn't really work either. But if you're like, "Hey, on this event, we did this."
I think I had this conversation with my coworkers recently. We end up a lot of the time in a "Porque no los dos?" why not both, situation.
Dave: Once in a while, that's great. But when a lot of decisions are hitting "Porque no los dos?" it's like, well now I have two systems, and my view files are just 10,000 if statements. The code is almost impossible to work on, or parts of it are like, "Oh, man. I don't want to work on that file," because there's so much logic kind of happening right in there.
Dave: I had to document that and bring that up. I think, whatever you can do to--
Dave: I think documenting is probably your best, like evidence-based discussions because sometimes you don't even have to say anything. You just say, "This happened on this date. This happened on this date. And this was the result." People are like, "Oh, I didn't realize." You know?
Dave: I've done that for big companies, small companies. You just kind of... It helps.
Chris: Best of luck with all that. Tricky, tricky. [Laughter]
Chris: Not my favorite.
Dave: Not my favorite.
Chris: Felix Yu has just a quick, quick topic suggestion about the CSS property content visibility. I haven't heard a lot about this recently. Perhaps you'll remember. I think it was back in 2020, about, when it was kind of becoming a thing.
I remember. I believe it was back when old Jake was at Google. He took some really super... I think, ironically, it was the--
Dave: The HTML spec.
Chris: Oh, it was the spec? I thought it was--
Chris: I was imagining it was the HTML page on Wikipedia or something. It was some extremely long HTML page. He said, "Look. If we make content visibility auto," or whatever the one is that kind of prevents it from being rendered, generally, by the browser until it's closer to being in view to most of this page, that the rendering time for this page just gets a lot faster, which kind of painted it as this tool, like it's a performance-focused tool, and you do it when you're in kind of extreme situations where the page is just so long or so big in some way that we need to give a clue to the browser, like, "Yo, chill out on these parts of the page because you can render them late." It's kind of like deferred rendering for chunks of the page.
Dave: Mm-hmm. Mm-hmm.
Chris: But it hasn't turned into a best practice in the last couple of years. I'll tell you that. I never hear about this anymore.
Dave: Yeah. It was kind of like you could be, like, section content visibility auto, and then you set a height or something. What was it? It was content--
Chris: Yeah, I think you did need to give it some kind of... Just to give it a clue. Almost like we talked about the sizes attribute last week, it's kind of like a hint for the browser to kind of know what's going on (without having to render it) because the point is, don't render it. [Laughter]
Chris: Trying to get you to not render this thing. "Contain intrinsic size" it was called.
Dave: Contain intrinsic size, yeah.
Chris: Which was a little strange. It didn't have to be perfect, anyway.
Chris: It was a clue of, like... The point is that once you get close to it, it needed to then decide, "Oh, I am going to render this." That kind of thing.
Chris: Maybe it was for scrollbars to be a little more accurate, too, despite the fact that they weren't rendered yet.
Dave: Yeah, it was almost like loading lazy for content, like you were saying.
Dave: But you could basically just be like, "Meh, paint a box. Draw a box about 1,000 pixels tall." However.
Dave: Whatever number I put here, 300 pixels. But when this is close, let's render it. I think that was kind of the idea of, like, rather than the browser having to figure out all the pixels before it even touches the page, it could just kind of do section-by-section or something like that.
Chris: Yeah. Didn't it have another prerequisite, too? You had to contain it, too.
Dave: I think you had contain inline, or something. Contain is tied to the containment spec, which again--
Chris: Yeah. I wonder if they did -- what do they call it one? Like say there's downtime on a website. Then your team gets together to talk about it. What do you call that? Post requiem?
Dave: Oh, postmortem? Yeah.
Chris: Postmortem. You did a postmortem on containment. I wonder if it would be like it had too many prerequisites or something and that's why people didn't use it. I don't know for sure that people don't use this, but it doesn't really seem like it.
But the fact that you had to contain it then remember this keyword. You had to remember to use it at all. Then it had a prerequisite. Then you had to use it. Then you had to guess at a height. There's just too much, and people were like, "No."
Dave: I tried to use it on my bookshelf, which I thought would be a really good example of it because it's in sections. It's really long. It's really slow to paint. I don't think it made it faster. I think I was running perf tests and it wasn't improving it. And so, I kind of backed out. It should have.
Dave: I think I just wasn't getting the gains from it. I think if you're in a situation where you have an ultralong page, maybe it's worth it.
Dave: Shoot. Even a homepage, it might be worth trying it to see if you can squeak out some time to - whatever - interactive or whatever it is.
Chris: Yeah. Also, it would be based on if you change that page, then you have to remember to go into the CSS and be like, "Is this still right? Are my heights still about correct? Are things named correctly?" Blah-blah-blah.
It kind of moves. You have to take care of the CSS when you take care of the HTML, which is a little hard to remember sometimes.
Dave: Mm-hmm. I don't know. I'm not totally crapping. It was kind of cool. It's nice to see performance-focused things show up in CSS, so don't hate that it exists, but I just don't think it's a hit product necessarily. [Laughter]
Dave: Yeah. Well, and it's in Firefox Nightly, but not in Safari.
Chris: Could it be part of a build step? Could you send your thing through a Puppeteer and have it decide what's off-screen on an average screen size and apply these things automatically to your build? That's the kind of stuff that excites me, not that I want that technical debt. But I just like it when things are automated and that computers are used to do things that computers can do best.
Dave: Yeah. Again, ruthlessly eliminate nuance, our theme for the show. If somebody would just be like, "Footers always, and visibility, content visibility. Don't even think about it," I'd be like, "Cool. Great. That's awesome. Now I know." But I don't know that, so now I don't know.
Chris: I haven't even heard it brought up in performance conversations. Not that I listen to a ton of them.
Dave: It's fallen out of the zeitgeist, for sure. I think if you have a very long page, it's probably worth looking at. But if that's not you, probably the gains are minimal.
Chris: Right. Right, right. There's other stuff that fell into that category, wasn't there? It's like if you're GitHub and you're trying to show a page that difs 80 files, you've got some serious DOM stuff going on, and you're going to need to deal with that in some way.
Dave: Yeah. You hit the limit of DOM nodes, basically.
Chris: But that puts you in a pretty unique situation in which the tools that you reach for you probably already know about.
Dave: I wonder if this was a prototype or a stepping stone towards virtual scroll list - or whatever - where you're scrolling through tens of thousands of items, like a contact book or something like that. Those are very bad performance for just a text or a div overflow - or whatever. I wonder if the goal was to build something like that or get something like that in a platform. I don't know.
Chris: Let's do this last one just because we've been sitting on it from Raphael Frond. I'm interested in your take on it, Dave, because he's asking about building components. When you're building a design system using Web components, would you start from scratch or would you build on top of existing libraries, extending the components that have been provided to you? He wants to know pros and cons of that.
The obvious ones being if you start from somebody else's, you start with this big, robust foundation and have a lot less work to do. An obvious con being, like, "God, I hope they designed it that allows me to do what I want to do."
Dave: The way I like it, yeah.
Dave: Yeah. Yeah. [Laughter]
Chris: That kind of thing, but why I'm asking because you were in a position where you were starting a new product. You're already a fan of Web components and that you knew that this was no small-scale thing. You were doing a startup. Did you start with anything at all on Luro, Dave?
Dave: We use Nuxt on Luro, so I should just come out and say that.
Dave: It's a Vue product. Part of the reason was because I like Vue, but I like the ecosystem, too. There are a lot of Vue modules and Nuxt modules that kind of help you do app-like things: authentication, icon scrunching, stuff like that. I just was kind of like, "I'm going to do this for the ecosystem."
I also like the meta-framework aspect of Nuxt where Vue... And there was really not a meta-framework for Web components at the time. Now you could argue Astro maybe fits the bill or something like that.
When building design systems using Web components and start from scratch, the neat thing about Web components is you don't have to. There are... Lion, ING's Lion is a good one. Salesforce has Lightening Web Components. That's a little bespoke to Salesforce, I'd probably say, for general use.
Dave: Adobe has some Web components. Those all kind of have Adobe application vibes - stuff like that. It wouldn't be wrong, though.
Another one I like is Pascal Schilp's Generic Components, which is just generic ARIA patterns and stuff like that.
Shoelace is a really good one from Cory LaViska.
Dave: Shoelace.style, and there's a next.shoelace.style. It's basically just like a big list of components and little patterns that you can use and try out. Shoelace is actually pretty cool and up on my list, so I would maybe start there.
Chris: Yeah. Especially if you're in Vue anyway, right? There's no reason you can't do both if you're in any other framework than React (is what I'm trying to say). [Laughter]
Dave: Any framework other than React, yeah. React is supposed to get better. But this is a pretty good system.
What I like about this is you can basically say, like, if you like Shoelace but you kind of want your own brand, like dave-tabs or whatever, you can say... Because it's all class-based, you can say, "Import tabs from Shoelace," and then custom element define dave-tabs as Shoelace tabs.
It's just classes, and then you can write little wrappers that give your custom-branded API, if you want to do that.
Dave: I don't hate that, to be honest. [Laughter] It's kind of a weird but cool thing you can do with Web components where you can do it in Vue. You can import and register the component as something else. But you have to register it every time. This would just be kind of like a bulk kind of setup.
Dave: I like that, so I would maybe start with something. I'm kind of... The older I get, I'm more like, "Let's just start using stuff off the shelf," but I know I would write my own.
Dave: But the nice thing about writing my own is I can have dave-tabs either be Shoelace or my own dang thing, which is kind of cool.
Dave: It doesn't matter. How I distribute it is what matters.
Chris: Yeah. I think I'd be very tempted these days. If I knew I was going into a medium to large-scale project to pull something off the shelf and use it just for the time savings of that. Not to mention the people understandability of it, to kind of know and be able to show other people who aren't necessarily designers. Be like, "Here. This is the stuff that we got."
Chris: Have them be like, "Ah, I understand. That's very clear to me."
We have a mono repo, as you know.
Chris: It's all... We're React, so we've got all that. But we have these two folders in there. Actually, there are a bunch of folders. As part of one of the things, folders in the mono repo ... packages. Those are the ones that are @codepen/ as far as importing is concerned.
Chris: And so, we have a hooks package, and those hooks can be shared across all the different things if you want. There's one for... One of them we call library, @codepen-library, but that one has some rules in it because there's a different one called @codepen-components. Imagine that. Then there are a bunch of other ones, too.
Those two are interesting, right? In order to get into library, there are some rules. You cannot query for anything. You can't put a GraphQL file (that's our data layer) into a library component. That's not allowed. If you do that, it's--
I think it's even enforced at some level. There's no way to make it work anyway, so whatever. These are presentational only.
Now, they're allowed to have props and stuff to change how they look. I think they can even digest other library components. Although, it's not super-common but they could. But then there are components, and components are more robust in that they can use library components to piece themselves together and often do. But they, for example, are allowed to ask for some data and have their own little queries attached to them.
It's making me think, like, man, if we were going to... We could potentially rip all of React out of the library if we wanted to and make all of them exclusively Web components.
Chris: And maybe use something like Lit or something because you need a little help sometimes to smooth over the experience of using it. But it doesn't need React because they're so dumb. They're just presentational only.
Dave: Yeah. No, I agree. I've been thinking about it with all of my Vue components. What percent of these can be just Web components? You can actually spit out Web components from Vue. You use a wrapper thing.
I was just kind of like... But Vue can also use Web components. What if the core of my app was actually just Web components? I thought about that. It's a big flip now. We don't have enough engineers to do that.
I would consider my next thing to be more Web component-based. But I would maybe still want to use something like Astro or Nuxt as my meta-framework.
Dave: Just kind of like... Could I just use that as kind of like my base layer? All the routing, all the page-level stuff, and all that stuff comes for free. Then I just kind of do--
Chris: That's the hardest part about all this. If you're using some other framework anyway, what's the point of the Web component?
Dave: Very little. I would probably stick with what you have.
Chris: Yeah. I'm not rushing it. I wouldn’t even... Even if I floated it, it would just get shut down. [Laughter]
Dave: Yeah. [Laughter] It would be shot down instantly.
Dave: I think it's mostly about distribution, too, like if your Web components have to go to more than just the React site.
Chris: Ah... There you go.
Dave: If your components have to go to the Drupal site to the Java site to the old Rails site to the--
Dave: And you're trying to--
Chris: They're actually portable if they're Web components.
Dave: They're portable. Hopefully, you're not giving them to different places and saying, like, "Go figure out your own build process, man. Hope that works."
Dave: Hopefully, you're giving them a distribution or something like that. And so, that's the critical part is the ability to go to multiple things makes it so much easier. You can just write. You don't have to Webpack anything or Vite or do any smooshing.
Dave: You just have an HTML API for components.
Chris: Okay. Well, that's pretty satisfying. Yeah, so it will be a slow growth. We don't see any change in the weather for Web components. They are what they are. They are supported nicely. There are plenty of reasons to use them. Their usage on the Web is probably not going to skyrocket but will slowly grow.
Dave: Yeah. I don't think it's going to skyrocket. I think when and if React puts this into, I think, 19 or something. Maybe it's going in 20 or something.
Dave: I think people will start to rethink the reality of what is possible. I think everyone or the zeitgeist of the Web is just so locked into, like, 'Web components are stupid because they don't do the one thing I like." I think once they're in React, the attitudes might change.
Dave: I get into Internet discussions, and people find the idea of a build-less Web totally unachievable.
Chris: Just abhorrent?
Dave: Like, "That's not even a real thing." It's like, no. People who are using Web components are living this life where the code you write, I can NPM or import Lit from Skypack - or whatever. Guess what. I have a build-less component system in my library and it's awesome.
Chris: Yeah. Yeah, that ESM future without a build is pretty cool. Now, I know that that's why people think, "Oh, these two guys are so old and ridiculous."
Dave: No, they think... Yeah.
Chris: Yeah. But I don't know. There are a number of quotes I associate with you over the years. You have a knack for that. But one of them is about... I almost want to look it up. But instead, I'll just paraphrase and get it wrong.
Of all the build processes I preside in or websites I've worked on over the years, it was like there are a lot of code transformation pipelines. The thing that tends to go wrong, over time, is code transformation pipelines. That's what breaks, always.
Dave: That's what breaks. You're not like, "Oh, man. The HTML in my header.php just shit the bed." You know?
Dave: That doesn't happen.
Dave: It's the, "What? Gulp can install Chokidar 4.0?"
Dave: Where am I? What universe am I in right now?
Chris: Right. Even if you can surmount that, it's like how many hours did you sink into that? You're a human person who is subject to deadlines and burnout and these types of things and being accountable for the productivity you have in the world. It's like, "Yeah, okay, you can fix that problem. But how many hours did you spend doing it?"
Dave: I don't know, man.
Chris: I spent zero. [Laughter]
Dave: Yeah. I spent zero, and I did not have turbo arch X64 binding issues. You know what I mean? [Laughter]
Dave: There's a build-less future. It exists. I think our corporate imagination is stunted by the ecosystem, and that's just the price we pay for gains, right? We're all making cool crap and stuff like that. But our imagination to imagine a better future is so stunted.
All right. We should wrap it up here. Thank you, dear listener, for downloading this in the podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show.
We are heading into summer. No announcements yet, but we don't know what's happening, so we'll just see what's going on. We'll keep you posted.
Yeah but stay with us. Be sure to stay subscribed and all that. And then, yeah, join us in the D-d-d-d-discord. We'll be there all summer, of course. Join us in the D-d-d-d-discord.
Chris, do you got anything else you'd like to say?
Chris: Yeah. Rest assured, if we miss a show, which is not planned yet but might happen in August, which happens so rarely over the years for us. It's either because Dave and I opened an Applebee's and we're busy with that or we're camping. I hope it's camping. [Laughter]
Dave: I hope. I'm going to be in San Diego.
Chris: Yeah. [Laughter] All right. Take care, everybody. ShopTalkShow.com.