Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--in the shed--Rupert and with me is Chris--in the office--Coyier. Hey, Chris! How ya doin' today?

Chris Coyier: Doing pretty good, Dave.

Dave: Yeah?

Chris: I heard, on the old Mastodon (which I feel pretty good about)--

Dave: [Howling] Yeah.

Chris: That's a worthy topic one of these days. But it was old Sam Cap was asking around about what's up with Web performance and is there anything going on with Web core vitals that I should know about. And you had some advice for her to look at a new one, even though I don't think it's actually graduated to become a Web core vital but is looking pretty good.

I thought we could just maybe take a little bit of the early part of the show to talk about what's happening in Web performance. There are a couple of hot links recently and some interesting stuff to talk about.

Dave: Yeah. You know it's funny. Sam had a really good question: How do you keep up with a particular topic, not just Web development as a whole?

It's kind of hard, right? You have to find the blog or the people that really do this thing, and that's not always easy to track down.

Chris: Yeah. You'd think it would be tremendously easy. You think that would be the number one thing that some publications would attempt to do for you. But as a former publisher myself and publisher in the case of a podcast, one publication can't.

I don't know. It feels like it was hard to hit that mark. It's not like because you read CSS-Tricks, you knew every possible thing coming up with CSS. Um... I don't even know if that was ever our explicit goal even.

Dave: Yeah. You caught wind of a lot, probably. Certainly, when a new feature landed.

Chris: But it wasn't like, "Ooh, there's a new feature. Here's a comprehensive guide to how it was thought about, how you should think about it, the specs, the examples."

No, we just didn't... It didn't happen that way.

Yeah, it's a little bit up to someone following the industry to kind of carve their own path there. Sam's question was really relevant. I wouldn't have known how to answer it.

But you did, and you pointed to this. There's a Web.dev article on it. There's a Calibre article on it. pretty interesting. It's called "Interaction to Next Paint (INP)."

Dave: Mm-hmm.

Chris: It feels like one of those core vital acronym things, to me, when I just look at the words or the acronym. It is almost meaningless to me. I need to spend more time understanding it and then I'll be like, "Oh, I see what they mean." Then it'll be locked in my head. Then I'll get it. But it definitely doesn't scream what it is right from the title of it.

00:03:15

Dave: Yeah. The way I sort of interpret this metric is it's interaction to next paint. If you click a button, how long does it take until the next paint happens.

Chris: I guess that is more straightforward than I thought. Is a scroll an interaction? Is a mouse move an interaction?

Dave: No. [Laughter] But I think it's almost like when your page loads, they click the first button they can find and try to figure out how long it takes until that--

Chris: Oh...

Dave: --button click changes the paint.

Chris: Doesn't it depend on what it's doing?

Dave: Sort of super, yes. But I think it's sort of like trying to... Maybe this is also one of those Web vitals that is not like, "Ooh, how is it calculated?"

This is one of their metrics. It's not really like a Lighthouse metric, like, "I'm going to test your page on load." But I think there's something like that. It's happening in there, but time to interactive is sort of replaced by this. I could be wrong there. That was my impression.

But it sounds like INP is calculated by observing all the interactions made with the page, so it's kind of like Chrome data.

Chris: Oh, so it's not the first one. It's all of them. Any time you do an interaction.

Dave: All of them.

Chris: Okay.

Dave: And then you get kind of a score based on how that goes.

Chris: How would you donk it up? What would make a bad one? Every time you click, maybe it has to do a network request to your analytic service, and you don't paint the dropdown menu until you had a callback from your analytics service to say that that was recorded. You've obviously coded that incorrectly, so that would give you a bad score or something.

00:05:08

Dave: How they score is it good is under 200 milliseconds, 200 to 500 is needs improvement, and 500 is poor. That's sort of in, you notice something is slow after 500 milliseconds, or it feels non-reactive after 400 milliseconds.

If you ever watched Halt and Catch Fire, they talked about the Daugherty Threshold, which is 400 milliseconds. You press a keyboard key. It needs to show up in your terminal in 400 milliseconds or less.

Chris: I hope so. Gees! It feels like one--

Dave: Yeah. Could you imagine? Yeah. Could you imagine if it took longer than half a second? It would just be like typing--

Chris: That would be horrible.

Dave: --on a treadmill going backwards - or something. I don't know. It'd be so bad. [Laughter] You'd make a lot of mistakes, too.

Chris: It feels also like... I mean, in CSS, you can have a transition delay or a transition duration. The default is 0.2 seconds, so that's 200 of your milliseconds right there - almost. That feels weird. You know?

Dave: Yeah. I wonder how this is going to impact. It's still experimental, we should say. Right? But if you click a button, there's a pointer. I guess pointer up happens and mouse up, and then the click event fires.

Chris: Yeah.

Dave: Then a render happens, and then a paint happens. And the user sees it.

You know we started doing a lot in that click event, right? Go hit the ad service. Go fetch data. Oh, I'm not going to load in this component until I am mousing over it - or something like that.

I'm curious what this is going to kind of do for a lot of A) performance tricks but then B) how people expect.

Chris: It's a tied up thread, too. Let's say all it does is classlist.toggle, and all it does is toggle a class. Well, that's great. That should be fast. But it depends on what your main thread is doing otherwise.

Dave: Yeah.

00:07:25

Chris: If that gets punted because it's super busy doing some other crap, then it won't paint and you'll get a lower score. It feels like in spirit of the rest of the core vitals.

The core vitals were these metrics that a little bit turn performance on their head because we used to care about things like how weighty is the page, how many kilobytes is the page. And if you can reduce 422 kilobytes to 394 kilobytes, that's a perf win.

Dave: Mm-hmm.

Chris: Core vitals said, "No, we don't care about that. That's irrelevant. That's a side effect number." They said, "We care about stuff like how long it takes to paint the page," which is what an actual user actually cares about because it shows up.

If your 400-kilobyte page renders faster than the smaller one does, who cares how big the size was? It only matters how quickly it got to your users' eyeballs. Everyone said, "Clap-clap-clap. That's nice. That's tying performance to actual reality how it uses to paint." This feels in line with that.

This is like trying to measure reality. How does it feel to use the website? Does it feel fast? Yes? Okay, you're doing a good job then. It seems cool to me.

00:08:45

Dave: Can I tell you where I see this interaction to next paint fail? I have an example that I use daily.

Chris: All right.

Dave: Do you use Slack? Do you use Slack at CodePen?

Chris: I do. Mm-hmm.

Dave: Do you use huddles at Slack?

Chris: No, but I know what you mean.

Dave: Okay. When you click the huddle button, it's like 2.5 seconds before you join the channel. And so, there's this minute there where you're like, "Do I need to click this again?" And you click it again, and it shoots you out of the channel. And so, you're like, "Oh, I have to click it again."

It's slow, and it doesn't give you the blup-blup, like, "Hey, you're doing something," or it shows you, like, "Hey, you're going," but nothing happens. You're not on the call or anything. I think that's an example.

I think what's also interesting, worth noting about this INP thing is it's pulling. It's starting to hint at Chrome usage data is showing 90% of a user's page. Time on page is spent after it loads, right? It's starting to get into that whole single-page app measurement sort of stuff.

Chris: Okay.

Dave: This is a thing like Evan You from Vue always says, "It doesn't matter how fast it loads. Users are going to be on it. It's an app not a website." That's fine, Evan. [Laughter] You're not wrong. But are they having a good time after that?

If you just say, "Loading speed doesn't matter. Bye," that's one thing. But are they having a good time after that? I think this will kind of at least start getting us in the ballpark.

I do wonder about fetch events and stuff like that, how that factors in because maybe it does factor in, but I can't really control server speed necessarily. But I guess that does matter to the user, so I don't know.

00:10:37

Chris: I know what you mean. You can't ignore... To me, it's tantamount to the cache hits matter, too.

Dave: Yeah.

Chris: I know it's more interesting and more en vogue to talk about totally uncached hits, and I would never say that doesn't matter, but there is such thing as long-running sessions. There is such thing as primed caches and stuff. Those experiences are not to be ignored.

Where I was kind of headed with some of it is that there are old-school metrics that are almost coming back to be cool again like time to first byte is not a Web core vital.

Dave: Mm-hmm.

Chris: But it's a classic one. And I've always enjoyed that one because it's like you open that network tab when you reload a website. The first request on every website is always the same. It's always the HTML that comes from the server. There might be some handshake or pre-flighting or something that happens. I don't remember the whole lifecycle of it, but always that topline is the browser needs some HTML in order to know what to do next.

Dave: Mm-hmm.

Chris: That number can be wildly variant. We got kind of used to it being really fast in the age of really good caching and Jamstack and all that stuff. But it didn't always used to be that way. You could certainly write a really slow Rails app where that would be like two seconds. [Laughter]

Dave: Mm-hmm.

Chris: Two seconds would be awful time to first byte.

Dave: Yeah.

Chris: Because it needs that HTML in order to do everything else. So, getting that really fast matters.

I just finished reading an article today about somebody that tested the time to first byte essentially across all the different services all around the world. Super narrowly, Cloudflare pages won in most regions - or something - so they switched to that just for that.

Again, not a core vital. Just kind of an interesting metric. How do you get faster at that? It does matter, and I'm trying to tie it back to an article that you just shared in the Discord recently from Tim Kadlec who was reevaluating how much does server-side stuff matter and how much does front-end stuff matter. That was interesting.

00:12:59

Dave: Yeah. I was going to go there, too. There was an old 80/20 rule from Steve Sauters Yahoo, like 20% of the time is spent waiting for the server and 80% of the time is waiting for the front-end. Part of this is servers were fast.

But Tim was like, "Hey, browsers have gotten a lot faster, so maybe this is better." And so, he looked at the top 1,000 pages or whatever, and it's not better. It's maybe worse. It's maybe a 90/10 rule. [Laughter] So, not 80/20 anymore. Ninety percent of the work is done on the front-end, the client.

Chris: Right. It's not necessarily... I don't know. I don't read it as a problem. Right? It just means that it's still true that you need to care about what's happening on the front-end more or spend more time on that if your time to first byte and, generally, network requests are still fast. If that's still in the few low hundred milliseconds - or whatever - fine.

Dave: Yeah.

Chris: Now focus your effort on front-end stuff. It is still true, though, that if that's bad, your front-end speed cannot overcome bad server speed.

Dave: Right.

Chris: It's a chain. There are still prerequisites. The server is a pre-req of that. [Laughter]

Dave: Yeah.

Chris: Even though it's 90/10, if that 10 is really bad... I don't know. That 90/10 is generally not for your website. It could be 50/50 for your website. Who knows?

00:14:44

Dave: Yeah. We have terrible performance on Luro, I should say. [Laughter] But we care about performance. We have terrible, like when we run our lighthouse. Some of that is we do un-cached loads and Nuxt pre-... We'll try to pre-fetch all the script that it doesn't use on the page. That makes Lighthouse angry, right?

We're overloading, if that makes sense. And we could probably tailor that down and only load the parts we're actually going to use and pre-fetch that or maybe defer the parsing of that script. We actually don't care. Stuff like that.

But I think what's also happening is because we've moved to server-side Nuxt, now our server (as actually like our time to first byte) is kind of lousy, and so this all gets better with Nuxt 3, but we've got to make a jump to Nuxt 3, and that's going to be forever away. [Laughter] Or at least Q4 stuff.

Anyway, jumping without re-platforming, what can we do? There are a few things we can do, you know, some slide of hand, size images correctly, stuff like that. But man, it's going to be a back-end, front-end job to get this all finished out to get hundreds across the board.

Chris: Yeah. Yeah.

Dave: I think the first step is knowing. Right? The first step is knowing how bad your situation is. The second step is coming up with a plan to manage it. Then the third step is doing it.

Chris: That's why it relates to this podcast. Every time we get some existential question from somebody about what we should do or how I should think or anything, you're like, "Okay, well, you've already taken a couple of pretty solid steps."

Dave: Yeah. Yeah.

Chris: You already care. And you care so much that you're actively seeking answers. Gosh, you're probably more than halfway there already just by caring and thinking about it.

Dave: Yeah. I was thinking about... I forget what I was... I was thinking about that just the other day.

The fact that you even care, you're just light years ahead of your competition in the workforce. [Laughter] I think that's good. I think it was something about somebody was asking about accessibility or something. it's like the fact that you care, you're just so far ahead because not everyone cares and not everyone keeps up with what the Web does.

That's fine. To each their own. But people right now, they're listening to a podcast about Web development in their spare F'ing time. That's weird, Chris. [Laughter] There's other stuff you can do. You could be listening to people playing Dungeons and Dragons or a murder mystery, but you're listening to Web development. That's a positive sign. That's a positive thing.

Chris: Yeah. Yeah.

Dave: You're career-building yourself. It's good.

00:17:56

Chris: I always thought that was almost like a cheat code I had for life. It just so happens that something I find relatively entertaining is this kind of thing. Not necessarily listening to our show, but I listen to lots of different shows and blogs and stuff. I read it and do all my RSS'ing and YouTube'ing and all that stuff.

There are some negative implications to this, too. But as a hobby almost. I actually kind of find it fun.

I say it's a cheat code because it becomes useful then. When something comes up, I'm like, "Oh, yeah. That's the HSTS list built into Chrome browsers," blah-blah-blah. The only reason I know that is because I read something about it one time almost recreationally.

Dave: Right.

Chris: Not because of my career experience but because my hobby helped me get there.

Dave: Yeah. It's like now you know HSTS. Now your company's website shows up in Chrome faster only because you listened to some dumb podcast. [Laughter] It's weird stuff, man.

Speaking of industry podcasts, congrats to Syntax on their acquisition to Sentry. Congrats to them. That's pretty amazing. I think they do a good show, so they deserve getting acquired.

00:19:22

Chris: Sounds like Scott is going to Sentry full-time. I'd love to know all the details. Just the nitty-gritty, like how many employees did you have before? Are some of them going and some of them not? Did you get any equity?

All this stuff is going to be free? That's crazy, right? I'm sure there was a big amount of revenue that was coming in for that. Are you just going to turn it off immediately? Was the deal actually worth so much money that the revenue from all those sales of courses is just having it just be gone is somehow fine? [Laughter]

I don't know. There's always you want way more data than they'll ever make public.

Dave: Oh, yeah. I'm always that way. I always - I don't know - fantasy VC - or something like that. [Laughter] I just kind of thing, like, "Hmm... What could a potential equity merger breakdown be?"

I think it's cool. It sounds like they are able to do more together than apart. It could just be straight up Sentry was like, "Hey, we've paid this much in ads. You should just be our thing." Anyway, I don't know. That's maybe overstating it. But somebody looked at a spreadsheet and made a decision that this would be worth it. I think that's pretty cool. I guess two parties looked at a spreadsheet and said, "Let's go."

Chris: Yeah. Yeah.

Dave: That's a pretty big deal.

Chris: Wes even reached out and was like - I don't know. They were giving away a bunch of swag or whatever. He gave some to me, so I took the opportunity to congratulate him on all the stuff.

I almost did the, you know... I'm also familiar with content-based acquisitions, you know. [Laughter]

Dave: Yeah. Yeah. Yeah.

Chris: I've kind of gone through it a little bit myself. There are some unfortunateness with that in that it was kind of like, "Oh, man. This company that clearly values content is going to have a whole team behind it and make more content than I ever could." That's kind of what we're hoping for happens to Syntax. It just seems really likely because they did a podcast with the guy at Sentry whose idea it was and is a founder. And they're going to that company to do that and are talking about all the ideas in which to do it. That is just different.

I didn't go to the acquiring company because I had too many other things going on and the other company wasn't acquired. Then they just didn't. They didn't put the people behind it. So, it just was unfortunate.

Dave: But I do think that says a lot. That person came on. That person tied their name to Sentry. They have created an immortal blood bond that they must forever uphold. [Laughter] I think that's good.

You know lots of people are learning on the Internet, and I think creating a learning resource takes a lot of time. It takes a lot of money. It takes a lot of effort. It takes a lot of brains and people. I see the value in saying, "Hey, let's go this way."

00:22:55

Chris: It stifles it, too, if the people that are expected to do that also have to be their HR department and all that. You've talked about that before, the amount of tasks there are to run any company. It's just outrageous. It's amazing how much work.

Dave: Yeah. I've got a blog post somewhere.

[Laughter]

Dave: I haven't posted it.

Chris: I remember it, though. It was just like the list of stuff you have to do is egregious. It's known, though.

Dave: Yeah.

Chris: That's why people go work for Wells Fargo or whatever because that entire list goes away, all of it.

Dave: Mm-hmm.

Chris: You just show up, and you put your YubiKey in, and you get on a Zoom call, and you go home.

Dave: For sure. Yeah, you just wake up, and you don't have to worry about that stuff, and it's awesome. I imagine it's awesome. I actually literally don't know. [Laughter]

I've only been in hard mode my whole damn career, so yeah. Do one day I just walk up and I don't even own a fricken' laptop or maintain it? I just open it and do work in it, and then I close it and say goodbye. That would be interesting.

Chris: Right. Yeah, I don't know. I don't know. Life is long. You know. [Laughter]

Dave: I also feel like I don't--

Chris: I don't own a jet.

Dave: Yeah, I know. A tiny, plastic robot Gundam, but I don't own a jet yet.

[Laughter]

Dave: I own lots of those. But I don't want to over-glorify founders and entrepreneurs. I am that. But I don't like over-glorifying it. But these people do a lot of work.

If you're operating, you've got a legal thing, a corporate email system, some user authentication, some user email system, privacy controls. You're managing code. You're managing hosting. You're managing some kind of deployment machinery. You're managing security and privacy, error logging. Oh, my God.

Chris: Working on your SOC 2 - whatever.

Dave: Yeah. There's so much that goes into it. But it's all people, right? People build the company. That's what we should value and reward is the people, not the CEO entrepreneur kind of whatever, the Musk or whatever. But I do know first-hand the amount of work that goes into it, and it is overwhelming and exhausting. But there is sometimes a drive to do it.

[Laughter] I'm curious about the part where you don't have to do all that stuff.

00:25:48

Chris: Right. Right. Right, right, right. Isn't that more likely that you're excited about an acquisition because you're going to do less of it? That is interesting.

We got started about this talking about Wes and Scott. It sounds like they probably will get to do some degree less of it. One thing immediately, which we dabbled in but didn't get very far, is not having to have sponsors.

Dave: Oh, well, they talk about it in their podcast. No ads. They're like, "Hallelujah. This is great." [Laughter] "This eliminates so much back and forth and so many emails."

Chris: I mean it worn on us both. I'm grateful for it. Even know, this is hopefully not too weird of a show. Don't break to an ad here, Enns.

[Laughter]

[Banjo music starts]

[record scratches]

Chris: But I'm grateful for working with Mark at Frontend Masters because I do think that they do a good product and they're just ridiculously easy to work with and realize the value in letting people say what they want to say on a podcast. All that stuff, I feel like I have to throw out that caveat.

But for every nice, good, easy person to work with, there was one that was absolutely not easy to work with that would wait for you to run the ad and then demand your male/female breakdown numbers before they paid your bill - or something. And you'd be like, "I don't even have that. Why would I have that?"

Dave: Yeah.

Chris: What are you talking about? Pay your bill.

Or something horrible like, "We didn't like the way you enunciated this word. So, even though this is already published, can you go back and edit the way that you said this word?" or something.

Dave: Yeah.

Chris: You're like, "I don't know. I guess," because if you're killing that game the best that you possibly can, you say, "Yes. Of course, I can. I would be happy to do that for you. In fact, it's already done. Listen to this new cut that's perfect now. Is that up to...? If it's not, I'll do it again."

That's customer service. That's doing it right.

Then two days later say, "Oh, we have a great opening for you in June. We have the perfect spot to put you at."

Dave: "We have high profile guests. This stuff is happening."

Chris: Oh, yeah.

Dave: Yeah. Get in.

Chris: "If you don't like that guest, just wait until the next month. We have another one, too. I'm going to hold this spot for you." That's killing it at that job.

I can't. I don't have the time for it. Dave had a list of all of the stuff. That's what I'm working on, the 500 other things, which makes me bad at all of it. [Laughter]

Dave: [Laughter] Ah, touché. Yes. At some point, yeah, it's plate spinning. I'm going to drop the one that's editing a 30-second ad spot for the next 4 hours. That's the one that's going to drop, right?

Chris: Yeah or delivering a kind of bummer email that said, "Oh, I'm sorry that episode actually already came out. Even if we were to edit it, nobody is actually going to get that edited version, so there's really no working it." That's honest, but it's also, like, meh, that's not the best answer for somebody who just gave you some money. And it's not fostering the idea that they're going to give you some more money later.

00:29:07

Dave: Yeah. I think you have some visibility into this. I think 2% of my job is emailing people back saying, "No, you cannot be on the show." That sounds terrible, but it's usually these, like, "Hey, you should have my boss." They make it sound like they're a listener, but it's just the same foreign email that happens every time.

It's like, "Hey, you should have my boss on. He's a million in revenue, man." You know? You're like, "Okay."

I just made a text expander that was just like, "Hey, appreciate you thinking of us, but we've had bad experiences with guest solicitations in the past, and we don't do this anymore." I feel like that's true, and I just was like... They said, "Oh, okay. Yeah. Sure."

Then occasionally somebody is like, "Oh, man. But have you done our guest? They might flip your mind on that." I'm like, "Nah. No. Don't."

But it's like 1% or 2% of my job is just responding with this text expander.

Chris: Yep.

Dave: Hey, that's all to say podcasts are work. It's a lot of work.

Chris: [Laughter]

Dave: Acquisitions, if they can ease some of that burden, that's great.

Chris: Yeah. Yeah. Hopefully, that wasn't too much overly nuanced there. Overall, big congrats to the Syntax boys. Good job.

Dave: Yeah. Nah, that's awesome.

Chris: ShopTalk is also for sale.

Dave: Yep.

Chris: Do you want to pick us up? Hit me up.

Dave: Pretty good price. Good price.

Chris: Good price.

Dave: Yep.

Chris: A lot of people that make stuff don't have content. We have a deep catalog of content that could come for you. Ideally, it's a barbeque sauce company.

Dave: Yep.

Chris: But I'll settle for whatever.

Dave: Roofing shingles. Lots of options.

Chris: That'd be good. Yeah.

Dave: We are available.

Chris: Yeah. Gaming beverages.

Dave: Oh, yeah.

Chris: Even more ideas.

Dave: Coder Fuel, Game Fuel. Reach out. We already got the brand established, guys. Just reach out.

[Laughter]

00:31:23

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you by Frontend Masters. There are so many courses on here, the highest possible quality courses, almost focused on maybe you're already a front-end developer and you need to learn a new technology or really level up. You definitely can be a beginner, too. Think of that.

I think a lot of people that listen to this show are kind of in that intermediate zone. This is the place for leveling up and learning new technology.

We've got courses on here about Next.js with Scott Moss. We've got Ben Hong on here, Brian Holt, Kent C. Dodds. Sarah Drasner is on here. Nobody I'd trust more than Jen Kramer to teach intermediate HTML and CSS. Just amazing. The best of the best. And Dave! [Laughter]

Dave: Hey, I've got a Web components course out there. I don't know how I slipped in, but I did. Let me tell you; it's going to teach you Web components.

Yeah, if you're interested in that, I feel like they're a hot topic this year. People should go sign up and watch it.

Chris: Yeah. Dave, you're early to the game, as usual. You know what's going to be big.

Dave: I used my code smeller, and I smelled out the next big one, baby. [Laughter]

Chris: Yeah, dude. Web components are not going anywhere, and you might as well learn them now. Check it out at frontendmasters.com.

[Banjo music stops]

00:32:44

Chris: You know what I need? Remember at one point you were going to do a Web component sommelier.

Dave: Oh...

Chris: Hopefully, I'm not ruining that.

Dave: Ooh-la-la, Chris. Yes, I am. The Web components sommelier. What are you in for tonight?

[laughter]

Dave: Do you have a flavor tickling your palate? Yes?

Chris: Yeah. I need a card component that has two variations.

Dave: Ooh... Yes. I think you would love this.

Chris: [Laughter]

Dave: Okay. This is from Scandinavia. It is the Nord Health Stack Component. It goes horizontal. It goes vertical. It does everything you want. It is just a beautiful, beautiful piece of code. This is Nord Health. It is a very popular design system.

Chris: [Laughter] What are we talking kilobytes?

Dave: Oh, I don't have the bundle on me, but it is a very good size. It's very, very few kilobytes. It's all very Flexbox-based. Yes. You will love it.

Chris: Are container queries built in?

Dave: This I do not know, but you will get notes of vanilla and notes of--

[Laughter]

Dave: --of cinnamon and cardamom. Yes. Yes.

Chris: I do want a YouTube one, though, because I feel like there are so many streamers. I guess it all starts on Twitch. Whatever. I'm a YouTube guy, so if you're producing high-quality video, I assume that you're at some point propagation that stuff to YouTube. It seems crazy if you don't. But whatever.

Dave: Yeah.

00:34:14

Chris: A video game comes along or something, and I want to watch it. The chances of it being covered by lots of different streamers is high, to me, especially if it's a relatively popular video game - or something. I need the sommelier to help me home my tastes.

I feel like the more popular they are, the more surfaced they're going to be when I search for it. Then it'll just be some kid, and it's a dark room. They have a red light behind them. it's in some impossibly wonderfully high resolution.

Then you watch them play. Then it just turns out that you just don't really like their personality. You're just like, "Oh, you're an idiot. Why am I watching you play this game?" It's all inside jokes and crap that I don't care about.

But then I'll look for the same game, and it'll say, "No commentary," one - or something, and you'll be like, "Oh, that's kind of nice because then I don't have to listen to some idiot make crude jokes or whatever. But then it's kind of boring, too. You know?

You're like, I need a sommelier to be like, "Ooh, you'll like this woman. She just plays the game and makes intellectual jokes occasionally. But for the most part, stays out of the way."

Dave: I feel like wouldn't that be a great life thing? I don't know.

I feel like I have wrecked my YouTube algorithm to the point it cannot make me recommendations anymore. [Laughter] I've one YouTube, I feel like.

I just wish... Yeah, I now need a human to be like, "Have you seen these videos?" To some degree, Kottke is my human.

Chris: Yeah.

Dave: But it's like, "Have you seen this video about Japanese manhole covers?" It's like, "Well, now you've got me!"

[Laughter]

Chris: Right, but that just comes at you live. You are just waiting to be fed stuff. But sometimes I need to guide it. Maybe there needs to be a Kottke AI bot or something.

But it would be nice for everything, just to kind of intercede in your life to make sure that you're not making a decision that's worse than it could be. Like if I'm shopping for new roof tiles or whatever, just to keep the roofing analogy going. Where is my little floating bot to make sure I don't buy the wrong roofing tiles, or that I know that at least some cool kind of European roof is possible - or something - which I wouldn't even know if I just had to make the decision by myself. I need a sommelier for everything.

Dave: Yeah. You've got to start with Web components, but no. I think there's a future where that works, especially when it's automatable.

If I type in "washing machine," another tab or side window should just go up and pull up the wire cutter for best washing machine 2023 - or whatever. [Laughter] It should just do that automatically.

Chris: Yeah.

Dave: And convert those into Amazon links or whatever it is. I feel like that's step zero. Who knows. Maybe that'll come. Maybe that's ARC's money play. ARC, if you need ideas, hit me up.

00:37:32

Chris: Hmm... Doesn't it seem like ARC--? I'm so into split panels. I literally have you open in a split panel right now.

Dave: I'm split right now.

Chris: Yeah.

Dave: I'm reading a Web.dev and a Chris Coyier.

Chris: How does not browser have split panels? It's crazy to me now, now that I just split all day. I'm just splitting it up.

Dave: Oh, no. You get a code review and the website, like the PR branch. [Laughter]

Chris: Yeah, dude. Come on.

Dave: It's the stupidest best innovation. I can look at the code that changed and the website that changed. Oh, my God.

Chris: Right. Or literally writing anything.

Dave: Oh, yeah.

Chris: I'll be writing about something and that something is in the other split.

Dave: Yeah. Yeah. I hate to fanboy about ARC too much, but there's so much.

I was doing a thing. I was doing, like admitting events to Segment, and it was like I'm clicking around my local host. Then I'm switching tabs. I was like, "No, stop this. I'll just pull it up in a split tab." I click around, and I'm seeing the events show up real-time in my test environment.

00:38:43

Chris: Dang. Segment is so cool. It was one of those products we got priced out of, kind of. It's just too expensive for us.

Dave: I got a startup credit. [Laughter]

Chris: Nice.

Dave: Kick that can down the road, but--

Chris: You can self-host it, for the record.

Dave: Oh, really? Interesting.

Chris: I just haven't gotten there yet because you kind of need to... You've got to be sending your data to at least two places for it to be worth it. You know? Then I didn't have that going for a minute, but it is a great product. I feel like people need to be using Segment. Although, isn't it similar in spirit?

I know we have a bad habit of not explaining stuff. The idea is rather than putting three different analytic services' JavaScript libraries on your website, Segment is really incentivized to be small and efficient library on your page. It goes to Segment. Then it propagates that data out to those three services, so it's way more efficient. It's like the best use of a middleman ever, right? That's the thing that you can self-host if you are so inclined. But do you actually have three places you need to send your data to?

Then there is some kind of fancy one, but I guess it was still client-side. it just happened in a Web worker. It has some really cool name.

Dave: Party Town?

Chris: Yeah, that's it, Party Town.

Dave: Yeah.

Chris: What a weird name for that. It does all that analytics sending out, but it does it as a worker, so it never blocks the main thread and all that. But I guess it's still client-side, so it's not as efficient.

Dave: Still client-side. There will still be a post message.

Chris: Network traffic.

Dave: Something. Yeah, network traffic. I mean I think Party Town is great. I think you could do both. You could put Segment in a Party Town, too.

Chris: Yeah, you could.

Dave: It's always off the main, never blocking the UI. What I think I like about it is you can use Segment, but then you can use Segment, but then you can also--

What's cool about it is you could try other things. We're not at this level at all. We are probably more on the ignorant side just because we were like, "Don't put a whole lot of value in metrics and stuff like that," but then we're being asked questions and we're trying to find some answers. It's just about, like, activation and stuff like that.

Chris: Right.

00:41:11

Dave: But anyway, we were just trying to do this as easy as possible. But if you want to try something huge, what's the big one? I have Data Dog in my brain, but that's not it. Mix Panel, that's a big one.

Chris: Yeah.

Dave: That's charts, graphs, and segmentation. The minute we hire a marketing person, I bet we've got to put a Mix Panel in there for social - or whatever it is. You know?

Without Segment, you have to retool the application. You have duplicate event codes. Let's send this to Google Analytics. Let's send this to June, which is another cool product. But let's send this to Mix Panel.

That's a lot of code overhead. But with Segment in the mix, we just sent it to Segment, and Segment sends it out. That's way more efficient. That's way better. It's all a universal API, and it's all this other stuff. We're not into this at all, so don't, but data lakes and warehouses and stuff like that where you just create so much user data.

Again, we're just trying to figure out do people like us. That's what we're trying to figure out.

There's all this stuff you can do with data that you need, in theory. If you prioritize it, you need a big warehouse for it, like a big cold storage for old user data - or whatever.

Chris: I'm really sour on that type of analytics data thing. I think there's something wrong in the industry about it if you look at just a standard grade Mix Panel integration would be for our scale, which feels like it's medium. We're not huge Google or whatever. It would just be outrageous. It'd be five figures, for sure.

Dave: Really? Yeah. Yeah.

Chris: It's like, why? So, you can store some JSON data thing? Not that it's a bad product. I just think the pricing is just whack on it.

Dave: Yeah. That's sort of the mystery meat of all of this. They track by events, which you can control by not sending as many events.

If you have X number of monthly active users, which we fall under all thresholds, and you wouldn't. If you go over 1,000 or 10,000 monthly active users, it's super-cost town.

Chris: Yeah. And they wank you. Yeah. They figure that's... My guess is that's what it is. You're either a startup and you can't afford it yet. Then as soon as you can afford it, you're doing so well that it becomes this trivial or easy-to-swallow cost.

Dave: Executive salary.

00:44:06

Chris: That's how Google Analytics works. It used to be every website in the world had that on it. Maybe it still does. It seems somehow less popular to me than it was. But it was like a no-brainer. You just sign up for Google Analytics. You get their little thing, and you put it on your website, and you get a bunch of analytics data, and it's free-free-free free-free-free-free.

Dave: Mm-hmm.

Chris: Boy, not in startup land, man.

Dave: No.

Chris: You hit some scale level at Google Analytics and it's just as bad as Mix Panel. Worse.

Dave: Yeah. No, I mean that's probably our ejection point as well. At that point, we should kind of know what's going on.

Chris: I'm sure there's something I'm missing and I'm not talking about it as intelligently as I could. Certainly, there's some.

We explored some stuff like - I don't know - just do 10% of page views then. Now your 10% is small and you still get pretty good data. It's not quite that clean. You'd probably have to do it by a cookie or something because you need--

If one user gets it, you can't just not record their next page view and record some other rando. You kind of want it to follow the user. If it's just logged-in people, you could do their user ID mod 10 or something.

For some reason, I just mentally hate that. You either have good data or you don't.

Dave: Yeah. Yeah. I agree. Yeah, it's tough, too, because I don't actually believe there is good data. I mean with content blockers and people--

I have some friends that block it with the piehole, like at their router level, they block requests and stuff like that.

Chris: Oh, so you kind of doubt the data, period. [Laughter]

Dave: I think there's a case to be made that the data we all make data-driven decisions on is incorrect or imperfect. We had a situation where--

Auth0, right? That's our auth provider that we use.

Chris: Mm-hmm.

Dave: Which is another pricing wowzer sometimes.

[Laughter]

Dave: Thank you for sponsoring the show.

[Laughter]

Dave: I don't know if they have (off the top of my head). But it's a good service, but anyway, some people log in, create an account, and then they'll come back the next time and just click the login with Google button. Well, that shows up as like two users.

While that data is true, two different email or, I guess, two accounts with the same email have logged in, it's still the same user on our side of things. Does that make sense? We could do database counts, I guess.

Chris: How do you know it's the same user and show them their stuff? Is it email-based?

Dave: Yeah, email-based.

Chris: Yeah, that's what we do, too.

Dave: Dave@gmail and then dave@gmail, it's like, "Oh, that's the same person." It comes back as the same person, but it's just they auth different.

00:47:06

Chris: Yeah. For some reason, somehow, amazingly, it hasn't bitten us in the butt. I always thought that it would because there's another way you can do it. You can do it token-based or something.

This is what I assume would happen but doesn't for some reason. Let's say you signed up for CodePen. At the moment, we make you pick a password anyway. Once in a while, we will get an email that says, "Oh, when I signed up, I signed up through GitHub Auth."

We'll be like, "Well, yeah. Maybe you did, but you still had to pick a password, so there's 100% chance that you can log in. You don't have to use GitHub Auth. You can always just use your email and log in."

But in some people's minds it's like they clicked that button, so they're forever stuck using that one - or something. Or that you have to auth some other one. You use GitHub, and now I'm going to use Facebook OAuth, too. Now I can use either of those two - or something.

But we just key it off email, as you do. Apparently, that's more common. But let's say then that you were to go into GitHub and change your email address in GitHub, which you of course can absolutely do. Then you use GitHub login again on CodePen. That's not going to work. You're going to get the wrong account or we're going to tell you, you don't have an account - or something - because we get that email from the GitHub OAuth and match it to your CodePen one.

Somehow, we just get no support about that. [Laughter]

Dave: Yeah.

Chris: Apparently, people just keep their email.

Dave: Always do it right.

Chris: Yeah.

Dave: Well, I wonder, too, what will happen if you did the plus trick, like dave+luro@gmail or whatever.

Chris: Yeah, that wouldn't work. [Laughter]

Dave: Then you sign in with... Yeah, I'm sure my server is just going to go, "I don't know, man. I tried. I don't know. I don't know who you are." [Laughter]

Websites, they're fun.

Chris: [Laughter] Yeah.

Dave: This part of the stuff is not fun for me, but I will be 100% true.

Chris: Yeah. It'd be fun to just focus on... That's what I fantasize about. Can I just focus on these little UX details all day? It's like, "Yeah, that would be nice, wouldn't it?"

00:49:11

Dave: Over on the CSS-Tricks blog, they had a post on Passkeys, like the new iOS - that came in iOS. It is not actually an iOS thing. It's an everybody thing.

Chris: Yeah, it's on Android phones, too, right? Oh, that's cool. These are so cool. I think they're cool.

Dave: It's like a fetch. You send a fetch to the browser. You just say, "Hey, authenticate this person." The browser is like, "Cool. Okay."

Your computer browser is like, "Oh, they must use their phone, so I'm just going to throw up the phone QR code that they scanned," or your phone starts buzzing because it's connected to your computer. Then you say, "Yeah, use this website."

Chris: Do they have to click a yes? It's, by nature, two-factor?

Dave: Yeah. it's only two-factor, if that makes sense. There are no passwords. It's just like you've authorized this device.

If I say you've authorized this. One of your devices, your computer or your phone, is the authorizer.

Chris: Right.

Dave: And so, I say, "Cool. I'm davatron500 on this website," and they're like, "Cool. We're going to start the authorization." This is for registering. "We're just going to figure out who you are."

Then there's a handshake. It'll say, "Log Dave in," and my phone will say, "Do you want to log into this site?" I say yes, and then the website has to store this public key credential thing - or whatever.

Chris: There'll never be a four-digit code. There'll never be any of that crap? It's just yes or no.

Dave: It's just yes or no.

Chris: See, that's awesome. Right? But you could never... If you just have a laptop only, it doesn't mean you're out, right? Can't your 1Password or whatever be the thing?

Dave: I think 1Password is going to try to get into this game is kind of what it was saying. 1Password could stand in as a passkey provider.

Chris: Is just your computer good enough? If you implemented this on Luro and the only computation device that I own in the entire world is a Mac laptop computer, am I out? Can I not use it?

Dave: I think Mac - yes, Widows - no, is my understanding.

Chris: If my laptop is the only device I own, so I cannot okay it on any other device because I don't own one, that's not multifactor auth then, really.

Dave: Oh, maybe not.

Chris: That's what I always struggled to explain it to my friend (or just any friend, a metaphorical friend). It literally came up the other night, and I was like, "Oh, passkeys. You've got to look into this. They're the coolest."

They're like, "Why?" I'm like, "You see, Matt, they're better." [Laughter]

Dave: Vis-à-vis, they're better, ergo, ipso facto.

[Laughter]

Chris: Well, I think the correct thing, like, "What's the experience like?" I'm like, "Oh, well, there just is no password," because that's part of the....

They're like, "How is that secure?" I'm like, "Well, because it is more secure."

00:52:27

Dave: Well, actually, I think the password would be the biometric on the device.

Chris: Yeah, but I always understood the biometric to be optional.

Dave: Oh, okay.

Chris: That was just bonus security, not the primary security. But maybe it could become the primary security.

Dave: I think you would have to verify your identity on the phone or, sorry, on the computer somehow. Maybe you get a system password.

Chris: There's got to be something because if somebody can just grab your computer and be logged into anything that uses a passkey, that's horrible. That's the exact opposite of security.

We know that's not the case. That's definitely not the case. Right?

Dave: No. This isn't like Dave Rupert home rolled a security system. [Laughter] This is Web Auth and FIDO security.

Chris: No, all security people agree that this is great.

Dave: Yeah.

Chris: People are saying, "This is it. We solved it. We finally did it. This is the future of auth."

Dave: Math. [Laughter]

Chris: I can't even lock in the UX of it, how it even works in my mind. This is a horrible podcast segment because either people are slamming their dashboards of their car being like, "You idiot, let me explain it to you," or "I also don't get it," which is not helpful.

Dave: You're just as confused as us. Well, and it doesn't help that the demos are like, "Hey, dude. Authenticate with us." I'm like, "No." [Laughter] I don't know who you are, you fricken' criminal. I'm not going to give Russia access to my phone or whatever.

That's my irrational brain. I know enough that that's not what it does.

Chris: Mm-hmm.

Dave: I'm just like, "I'm not going to do that." Anyway, I should just set one up. But even though, like, you know you have those projects, the little side projects, and you're just like, "Hey, this would be cool. But oh, shoot. I need them to have an account." Right?

Then you're like, "Cool. I'm never working on this idea again." I feel like this would be a perfect situation for adding Web Auth, this passkeys to your little project that you don't care what happens. Maybe you have a user in Supabase or whatever, but you just store the little credentials you need, which needs to be an array--I think that's what the blog post said--because users can have multiple devices.

Basically it's like you say, "I am dave@gmail," and they're like, "Cool. Prove it." You know?

Can somebody register as dave@gmail? Maybe. How do we validate that? Maybe there are different ways. I don't know. That's where it breaks down for me.

I don't know how you do that, but maybe you don't ever register for a website as dave@gmail. Maybe that's the trick. Maybe you only register as cool lord, or whatever.

[Laughter]

00:55:24

Chris: Yeah. I don't know. We're going to have to figure it out. Because you use OAuth, are you going to get it for "free"?

Dave: Auth0?

Chris: Auth0.

Dave: They have a biometric thing. We can do biometric challenges. I think that starts getting into their enterprise stuff.

That was part of the reason we use them. I knew they could potentially have it probably before we could roll it out. They have two-factor stuff. I don't want to code my own SMS text message infrastructure, so I just was like, "I'm just going to let them let me know when it comes out."

I think we're kind of facing all that if they get the passkeys. I've asked, and no one really seemed to know. But I was probably talking to the wrong people. My big bet, I think, was that I should use this service so I can get these new authentication pathways faster than I can code them. That was my thought there.

Chris: Yeah. Right? Yeah, if all you wanted was social auth, I'd say that's really not that difficult. You can hand-roll that pretty easily. But as soon as now you're adding--

The question is, do you only have social auth or do you have your own auth thing, too, and you're combining them together and now passkeys? It does feel like a pretty nice thing to just outsource. That's why people use Cloudinary for their images or whatever. Outsourcing any particular part of your stack is just awesome. [Laughter]

Dave: Yeah.

Chris: Please. You deal with this instead. That would be great. I don't want to think about how to turn on HTTP 3. Oh, it's just a toggle in Cloudflare. [Tongue roll] Done. Sick. Thanks.

Dave: Yeah. Yeah.

Chris: [Laughter]

Dave: I'm looking at my things. It's like one-time password. Bloop.

Chris: Yeah.

Dave: Web Auth N with Fido devices is a thing, but I think that's all biometric.

Chris: Yeah.

Dave: That's not the new passkeys. But that's the bet.

00:57:40

Chris: Jealous of looking at websites that just use every single DX thing that Stripe provides. You're like, "Oh, when you checkout, it pops up the Stripe payment form," so nobody had to code that. Then when you ask for an invoice, it just pops up a little Stripe default invoice. I'm like, "Oh, my God. You don't even know how much time you saved. That's amazing." And it looks great.

Dave: We're doing it. [Laughter]

Chris: It looks trustful. Yeah. Nice.

Dave: No, I mean it was just even to the point where it was like, "Do we need to save any of this data on the system, like transactions?"

Chris: Very little.

Dave: It was like, "No, I think all we need is a customer or a subscription ID or something."

Chris: You're better off not.

Dave: I don't want it, and that's why I used Auth0. I don't want your password, dude. Could somebody else do that? I literally don't want it. That's a liability for me.

The same with your credit cards. I literally don't want it.

Chris: It's more than a liability. It's a data synching problem and a drift problem.

Dave: Yeah.

Chris: Your data can be wrong. You know whose data will never be wrong? Stripe's.

Dave: Right. Right. If a user falls off of the Mailchimp list, oops. But if a user falls off of the stinkin' authentication list, that's a problem. That's a big one.

Chris: Startup talk with Chris and Dave.

Dave: Man, we're a startup podcast here. Look at us.

00:59:11

Chris: I was going to get into... We don't even have time now, but there was a pretty fun Robin Rendle post from back in February about Vibe-driven development that I just loved. Robin has a habit once in a while of saying things that people are feeling. [Laughter]

Nobody says. There are not a lot of blog posts that are like, "Forget data. That is stupid. Just Vibe it out." [Laughter]

He means it, which I love that because I've always kind of been that way myself. Like, "Yes, yes, data. I know."

Once in a while, I'm kind of happy that we have the data that we have and stuff. But, ugh, some part of me is like, "Yes, but I know what I want to do anyway. I don't really care what the data says."

Dave: I agree. I like Vibes, but also, to me, an honest answer is like a kiss on the lips. If you tell me, if the data is saying this is bad and no one uses it, I'm like, "That's cool." I like data more than I like my feelings. [Laughter] You just tell me data.

Chris: Exactly. That I don't disagree with that in some way because you don't know. Right? If literally the chart is telling you that nobody clicks that button, that's fine. But there's nuance to it.

If you use it or you can demonstrably show that clicking that button is actually awesome, it could be an education problem or a design problem or something. I don't know.

That's just it. Sometimes you just have to be like, "Cool. No one clicked it. What do we do now? What levers do we have? Do we need to email? Do we need to make the logo bigger or whatever? What do we do if no one clicks it?"

Then sometimes you just need to believe in yourself, too. I think that's the other thing. It's like, "No, we make okay decisions, so this is probably useful," and users told us they wanted this. That's another way. Don't just make something. Make sure somebody needs something.

Yeah. If somebody tells you they want something, then at least you know somebody wants it. They just aren't using it.

Chris: All right, man. Next week, more unanswerable questions.

Dave: More questions. Send us your questions and we will attempt to answer them. And then we'll just circle around the drain and not answer them.

[Laughter]

Dave: Thank you, dear listener--

[Laughter]

Dave: --for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show.

If you want to know more about Web components, I would love to show you some beautiful ones. I know very many.

Then follow us or join us in the D-d-d-d-discord, patreon.com/shoptalkshow.

Chris, do you got anything else you'd like to say?

Chris: Hmm... ShopTalkShow.com.