Dave and Chris talk about recent pandemic purchases, publishing video on the web, more sharing of convoluted processes, some menu bar app ideas, reinvigorating HTML, and writing good git commit messages.
Time Jump Links
- 00:57:00 Pandemic purchases
- 13:27:00 Publishing video on the web
- 18:17:08 Sponsor: Equinox Metal
- 20:14:18 Convoluted process
- 23:29:18 Menubar ideas
- 27:10:18 How can we re-invigorate the initiatives proposed for new HTML custom elements that ship with browsers?
- 41:41:12 Sponsor: Netlify
- 52:31:24 Am I the only one that has a hard time making good git commit messages?
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave--right in 2021. Please help me, God--Rupert. [Laughter] With me is Chris--in the neon booth today--Coyier.
Chris Coyier: Yeah.
Dave: Chris, you upgraded your booth and it looks--
Chris: A little bit.
Chris: Yep. I did the thing where I was on Instagram and there was a beautiful photo of this lamp in the corner that shot rainbows out of it and I was a little faded at the time. I think it was New Year's Eve, and I was showing it to everybody. I was like, "Look!" We're drinking champagne. I'm like, "Should I buy that? Should I buy that?" You know?
Chris: They're like, "Sleep on it, dude. Just think about it."
Dave: You're like, note it.
Chris: Yeah! [Loud laughter]
Dave: Chris Coyier pushes that button. Chris Coyier knows how to push that button.
Chris: I do push that button, but I did sleep on it, god bless myself. Then I still bought them because I think they're cool.
Dave: Oh, good.
Chris: Then I tried them in the corner, and I was like, "You know what? I'm going to mount these damn things on the roof of my booth - the roof of the booth."
Dave: The roof of the booth. Nice.
Chris: They like beautiful, and they have cool modes. They literally shoot rainbows, so enjoy.
Dave: See, I think, here in the pandemic, if you could spend--whatever--$5, $10, $100, $200, $2,000--
Dave: --just to get a little piece of happiness, it's entirely worth it. Did the Ruperts move a couch to look at the Christmas tree and decide we need to buy a whole new couch? Yeah.
Dave: We did.
Chris: That's great.
Dave: We now have two living rooms. Surprise!
Chris: Everybody is going to have kick-ass houses when this pandemic is over. You know?
Dave: Yeah, so like, "Dave, where did you get this weird bronze horse sculpture?"
Dave: Oh, well, do you remember 2020? [Laughter]
Chris: Yeah. [Laughter] Yeah. We kind of invested internally. I don't know if you know what I mean there.
Dave: Yeah. Yeah, a few upgrades.
Chris: That's cool. I saw a beautiful photo. I didn't even know it snowed in Austin, ever, but apparently, it did. You have more snow in your yard than I did in mine - for a minute there.
Dave: Two inches of snow in Austin, Texas. I don't talk about the weather too much. It's pretty-- [laughter]
Chris: No, but it's about your shed, which is a beautiful thing. It looked like it was out of a field in Japan - just beautiful.
Dave: Yeah, I know. My shed, they're putting a roof on it as we speak, which means they can put stuff inside of it after there's a roof on there. I think we're moving forward and it could be next week or, for sure, I think next week.
Dave: I might be moving into the shed.
Chris: Did you run fiber out to it?
Dave: The fiber is going to get run out to it or they're going to run an ethernet to it and then drop a line into my house.
Dave: I may just have them wire up my house while they're in here because - I don't know.
Chris: Maybe. Yeah.
Dave: Might as well, so I don't know. I wish I had a master plan for whatever ethernet in the house, but I really just need something out of there. But I could probably extend the wi-fi out there.
Dave: Maybe get bad wi-fi at first, but--
Chris: I'd get ethernet if you could.
Dave: No, it's all wired. There's a jack on every wall, so that's good. It's going to be good. Hopefully, I'll be fast.
Chris: There's a downgrade for my booth. I have one in this office that I'm in. There's one place where the Internet comes in, and it's in an office on a wall.
Chris: The only way to get ethernet to this booth would be to fricken' dangle it across the floor or some crap. You know?
Dave: Yeah. You could tack it up through your roof, maybe. But still--
Chris: Yeah, you'll have to see the roof in here. It's 50 feet in the air. It's crazy.
Dave: Yeah. You know what I do? [Laughter] I bought them on Amazon - speaking of impulse purchases. I bought this -- it's a reel. It's like - you know those things you put your--?
Chris: Yeah, like Van Halen rolls into town and is wiring up the thing and there are guys running across the field with the spool of wire.
Dave: Yeah, with a big wheel--
Dave: --of ethernet. That's what I have.
Dave: It's like 50 feet of ethernet.
Dave: I can just -- when my whole family goes to sleep, I can go plug in my ethernet cord and get super-fast games.
Chris: Oh, that's great. Then you wheel it back up? That's great.
Dave: Yeah, I wheel it back up.
Chris: The last time I saw one of those was this guy, Brad, I used to work with at the old office from Kraft. We were wiring up that office, which was just a site to behold. The old office, as much as I'm much more happier at the new office, we wired the walls with ethernet and had a big server rack that could just dish out -- because we had fiber over there, too. In this new building, no fiber, and the ethernet is a pain in the ass.
Chris: I have it at my desk because I literally just draped it across the floor and bought that carpet covering stuff to cover it.
Dave: Yep. Yep. Good.
Chris: It's fine. It's fine, but he always had the ethernet. He was like the ethernet guy. Not only did he have the spool, but he had the chops to be able to cut it and then add the ethernet.
Dave: Like crimp and wire and all that?
Chris: Yeah, in two seconds, he could make you an ethernet cord of any length and he knew he could. He would just walk into people's offices and be like, "Do you need an ethernet cord? How long? Two feet? Six feet?" [Laughter]
Dave: Two for four? Two for five?
Chris: "What do you need? I can do it." It is kind of a superpower to make ethernet of any length.
Dave: No, I mean that's -- I have done this. In my house in college, we ran -- we stapled.
Dave: We drilled holes in the wall.
Chris: Yeah, you did.
Dave: We stapled on the outside, like, 10,000 feet of ethernet cable. I did it and there were all these weird rules, too. You have to do what's called a cross-wire, like you flip two wires if you're doing it in a jack or something.
Chris: What?! I don't know about that.
Dave: But it was like a cross-cable is what it's called. But yeah, we ended up wiring all this stuff. We destroyed that house. I'm surprised they let us do it. [Laughter]
Chris: Is there a point, Dave, where the wi-fi--?
Chris: Because it evolves. Every time I look at a router, it's A and then B and then AB, then N, then N+, then N to the triple plus. All those are wrong, but you know what I'm talking about. Is there a point at which wi-fi technology is absolutely not the bottleneck anymore and that it's count-on-able just as much as ethernet is?
Dave: You know, I don't know. That's a good question. I mean I think a wire -- it's a wire. A wire can get cut. That's a huge liability. Ideally, you don't cut wires. But I think, with wi-fi, the issue is radio frequencies. You get this with, too, wi-fi and blue-tooth sometimes don't get along. They kind of fight over the same available bandwidth. It's like radios. It's microwaves.
Behind my current desk is a fireplace. We didn't know that when we bought the house. We discovered it about a month into it, "Hey, we have a fireplace."
Chris: What?! They just papered over it or whatever?
Dave: Yeah, it's just walled over, but I didn't know that that was there. We may open it up again.
Chris: Oh, my god. There are a hundred rats in there, I'm sure.
Dave: Yeah, but good rats.
Chris: [Laughter] They probably have tea parties.
Dave: Yeah. But anyway, there's a big fireplace. I think just the reflection of the beams or whatever going off this brick is not great. I had all these wi-fi problems in my old shed at my old house. I ran an ethernet. I ended up finding somebody who would run an ethernet cable out there.
Dave: That helped a lot, but I think that -- I think part of the reason was I had Hardie board on the outside of it. Do you know what Hardie board is? It's like cement planks that look like siding.
Chris: Oh, yeah. I think I've broken some of those by accident.
Dave: Yeah. You chipped them and you're like, "That's a bummer. That chipped a lot easier than I hoped." [Laughter]
Dave: Yeah, so if you think my shed was actually like a cement coffin, oh, okay, that's why I had bad wi-fi.
Dave: I don't know. It's all kind of making sense now, but I was--
Chris: Yeah, you can't beat the wire, can you?
Dave: No, you just can't. That's the same with peripherals and stuff like that. They are saying, though, like it used to be with video gaming. You had to be wired to get -- because you're talking about 300 millisecond response times. You know?
Chris: It's on our guest notes page for this podcast.
Dave: Oh, really?
Chris: Please ethernet yourself, please.
Dave: Oh -- [Laughter] Logitech has this thing called Lightspeed, but it's basically those 2.4 gigahertz little dongles that you plug in that they used to do before there was blue-tooth and everything.
Chris: What?! So, it's not wi-fi. It's dongle.
Dave: It's not wi-fi. It's not blue-tooth. It's like this kind of different bandwidth and 2.4--
Chris: Don't hate it.
Dave: Yeah. No, it's actually fast enough. It's faster.
Chris: Yeah. I mean I trust it for my mouse.
Dave: It has less latency than blue-tooth. Yeah.
Chris: Why wouldn't I trust it for my wi-fi?
Dave: I think wi-fi could very improve, but maybe it's not the 802.11 spec. It's maybe something totally different.
Dave: It focuses on--
Chris: One less wire. You know at this point I'm not down. I could see if I was rocking the minimal desk thing, which I think is very cool. That's a way to operate your life. You buy an iMac or whatever, so there's no cord even from the monitor to a machine. Blue-tooth mouse, blue-tooth keyboard, call it a day.
Chris: There's nothing on your desk. It's like Unsplash ready.
Chris: You buy one fern in the corner and you buy something from there -- what's that -- Grove Made, or something.
Dave: Yeah. Yeah.
Chris: Put your mouse on a little piece of felt or something just to really lock it in. That's one way to go. I didn't go that way. I got a hundred things on my desk, so I'm not anywhere near zero wires. If I take one wire away because of the ethernet, it's not a material improvement. But I could see if you were down to two or three, the desire for zero is very high.
Dave: Yeah. Nah. I have a rat's nest. I bought a $300 dock for my Mac just to make it all work.
Chris: Did you rock the CalDigit what'd you go?
Dave: The Elgato.
Chris: Elgato. Trust Elgato. Got a package in the mail from them the other day.
Dave: Elgato is a brand I trust.
Chris: Hell yeah, it is. They make good stuff.
Dave: Yeah, but it's one wire into the Mac, and that's what I was looking for because I was plugging in the speaker, the USB, the other USB, and I was just like, "You know what? [Laughter] How much does it cost to get out of this?"
Chris: Wow. They're making a mic now. I just popped to their site just to see because they are a good brand, right?
Chris: All of a sudden, I got their Key Light.
Dave: Key Light.
Chris: Got the light.
Chris: Then I forget what else I have from them, but my coworker Shaw, he's got a greenscreen because he does the Keyframers, a great little show.
Dave: Yeah. Yeah.
Chris: They do the talking heads in the bottom left and bottom right on YouTube.
Dave: Cool. Yeah.
Chris: Greenscreen - gotta do it. We're starting to do video at CodePen.
Dave: I saw you're pivoting your CodePen podcast to video.
Chris: Yeah, just arbitrary. Randomly, there'll just be a video instead of an audio one week.
Chris: We're sorting out the tech for it, and part because it's kind of fun. They make a greenscreen, Elgato does, and it's like, why not buy from a great company like that? So, I mounted it on my ceiling. I haven't actually done it yet. It's sitting over here.
Dave: Oh, you get a push-button?
Chris: I wish! Maybe I'll wire something up. I have been into home electronics a little bit in that way.
Dave: I don't know. I could consider that. Yeah. I think about streaming and then I think, my situation is always like -- like code streaming, specifically. I could video game--
Chris: I would watch your stream, for sure.
Dave: Well, but I'm like, "Okay, do I just open up my client's website?" Probably not.
Dave: They probably wouldn't appreciate--
Dave: --like whatever Fortune 500 company, me just operating on it in the open.
Chris: Right. Probably not.
Dave: You know they're not into that. [Laughter] It turns out they're not into that, so I'm like, "What could I do? Maybe I can make a video game in-stream or something." Just carve out an hour a day or something. I don't know, but it would have to be something. I'd have to figure that out.
Chris: Yeah, can you do it with consistency, or does it even matter anymore because life is so chopped up? Can't you just, like, if you're vibing it, just do it?
Dave: You know there are some cool people who stream when they vibe, but I think if you want to be successful, you have to do it consistent.
Chris: You stream on Thursdays at 2:00. Yeah.
Dave: Thursdays at 2:00, Monday's at 2:00.
Chris: Yeah. [Laughter]
Dave: You know, but this is way off topic for ShopTalk, but I saw this thing over the break about Instagram. Somebody basically leaked Instagram's algorithm. Did you see that?
Dave: They're asking us to do three reels a week.
Chris: Oh, I did see this.
Dave: A post every day.
Dave: Something-something, and they're like, "That's how you stay--
Chris: You've got to use all their products.
Dave: You've got to use all their products. You've got to go in and like N number of photos. You can't just be a -- you have to be a community member to get boosted in the algorithm.
Chris: Okay. To some degree, that makes sense, or were you like, "Ooh--"?
Dave: I think it's cool, but there has to be some algorithm, right? Unless you want to just do chronological, which I would actually support. [Laughter] But I think the issue is, you turn these people--
Dave: I just wanted to be a content creator. Now I've got to abide in somebody else's rules or else I get zero dollars. It's like some dollars or zero dollars. And so, it's like, I've got to be a content labor camp just to, like--
Chris: Kind of.
Dave: --show up in the Instagram algorithm, you know?
Chris: You know I made one for -- I made an Instagram for CSS-Tricks like--I don't know--a year ago, maybe, and I don't really consistently do anything, but it's kind of fun and I poke at it once in a while. I found, through setup, they have -- I don't know how the heck this works, but they have an app where I can upload video to my Instagram account from my Mac.
Dave: Oh, okay.
Chris: Which is nice because otherwise, it's a pain in the butt.
Chris: What do you produce it then put it in the cloud somewhere that your phone has access to and post it from your phone? You're like, no thanks.
Once in a while, I'll be inspired. I'll be like, "Oh, this is a good little ten seconds. I'm going to show this off." It's a video. Pictures are easy. You just post the picture, but a little video is a different ballgame. You produce the little video and then you blast it out to Instagram.
I'm like, "People should watch that. That was cool. That was cool." That's the point of this little Instagram is little educational tidbits, generally, about CSS. You know?
Chris: Then I read this post and I'm like, pfft, I will get zero. Nobody is going to see this thing because it's not also a reel and also a story and also I didn't like ten things today. Because I'm not playing the game, I'm just producing a little content, I get nothing.
Dave: Yeah, that's what I worry about some of these things, you know.
Chris: The irony -- I made a joke about it -- it's all a short-form video. A story, it's a little piece of video. You post it. What's a reel? It's a short-form video? Can you just do a post? Yeah, it's a short-form video. What's IGTV? Well, they call it long-form video, but it's short-form video.
Chris: All these different things are just little different ways to watch video. Why are there so many different ones?
Dave: Yeah. No, and I think Twitch has hoops, too, you've got to jump through. I know YouTube, you've got to do that, but you've got to get them likes. You've got to get those subs. Smash that like button. Ring the bell. You know?
Dave: As cool as that is, it's like, man, you've got to play a game. Maybe that's the old man energy talking here, like, "I ain't gonna play no games." [Laughter] "I'm about to retire."
Dave: I just don't have the energy.
Dave: Kind of like micromanage my engagement just to hit--
Chris: Algorithm threshold.
Dave: A whatever -- algorithm. Yeah.
Chris: Doesn't part of you say--? And part of it is old, but part of it is like, and this can be taken away from you at any point ever. And the rules of the game can change at any point ever.
Chris: That's true of anything, to some degree. But if you make content and you publish it at your site at a URL--old man waves at cloud--that will serve you for a long time and the rules are less apt to change on you overnight. You know?
Dave: Yeah. No, I mean that's something to be said. Is it POSSE (Publish Own Site Syndicate Elsewhere)?
Chris: Mm-hmm. Mm-hmm.
Dave: You put it on your site. You put your story on your site. It's there forever and it doesn't just disappear, but maybe you want stuff that disappears.
Chris: POSSE is a good point because then you do, to some degree, still get to be on that other platform and potentially gain some of the value of them. You're not quite playing the game as their rules, but at least it's over there. It could be over there in five places. You know?
Dave: But it does seem like it's -- there is something to be said.
Dave: If you want to be popular, start up a TikTok. Tell some goofs. Sing some sea shanties and there you go. You're on your way--
Dave: --to success.
Chris: It just seems so wispy if you do it that way.
Chris: I don't have as high of peaks, you know, like if I rock some sea shanty. Maybe you'll have your day in the sun, but I feel like, "But do you want a tenure career in it?" If you do, then you may need a different approach. If you don't, that's cool too. Who cares?
Dave: [Singing in a pirate voice] I want to be in a sea shanty. I want to be popular. I want to be heard for 15 minutes of the day.
Chris: I like the Colin Meloy tweet where he's like, "Sea shanties were so 2003." [Laughter]
Dave: Oh! Dang!
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Equinix Metal. They didn't say to say "metal" like that, but you kind of have to, I feel like, because it's pretty metal anyway as a product.
Equinix is the world's digital infrastructure company. They have this brand new product, Equinix Metal. Fully automated, bare metal as a service gives you the freedom to build any way you want, anywhere you want it.
This is digital infrastructure, as they say. You're buying servers here to run your stuff. This is something you reach for when you know you need some infrastructure to power the thing that you're building and you want something that's good and that has developers in mind for real.
They're a bunch of developers over there where they're like, "You know, I see what's happening in digital infrastructure. We're going to start over, do it better, and do it ourselves."
That's what happens here. It's a--for developers by developers--infrastructure product.
For one thing, it's info.equinix.com/shoptalkshow. Just go there, just put your name in, and they give you $100 to try it anyway. If you just want to play around, you have some incentive to do that. Thanks to them for that - $100, info.equinixmetal.com/shoptalk. It'll be in the show notes, of course, too.
"Just add metal," they say, which is awesome.
This isn't necessarily for, like, "I need a server for my personal blog," or whatever. You could probably do that if you want the world's most metal badass personal blog. But you're buying real servers to do big work.
We're talking global data centers here. They have 220 little physical data centers around the world. Pretty awesome, so this is serious digital infrastructure for your products. Check them out. Thanks for the support.
[Banjo music ends]
Dave: Last week, we asked about convoluted processes, and we got a taker. Jim Neilson writes in with his Netlify public folder part one. That's a good tip that it's going to be just a beast of a process.
Chris: Yeah. Mm-hmm.
Dave: It's a three-part thing. [Laughter] Anyway, recreating the Dropbox public folder with Netlify.
Dave: Jim does some interesting tricks with Netlify. He has a little tool that will notify him, like send a growl message if his build completes on his machine.
Chris: What's the idea? It's for your local computer. The Dropbox public folder, remember, (RIP) doesn't exist anymore. But the idea is, whatever you put in there is kind of publicly available through some UI, which was, I thought (agree) was nice.
That's not gone anymore. It doesn't mean that you can't share stuff publicly on Dropbox. You totally can. It's just a little bit more explicit.
Dave: Yeah, and so Dropbox public folder was like, "Hey, I will drop a file in here," and then I get a public URL. Then I can self-host my own GIPHY, if I want.
Dave: You know, with my own bucket. He figured out how to do that with Netlify, but Netlify has an upload a folder thing, but it's like you have to upload the same folder every time. You can't just add a file to this virtual cloud folder.
Chris: Oh, really? Well, can't you just put it in Git and Git will deal with that part?
Dave: Well, I think that's kind of the background thing that's happening here is a whole kind of Git kind of flow here.
Chris: The idea is, put a file in a folder and wipe your hands. Some magical code runs such that that file eventually will have a public URL that's guessable or whatever. I don't know if there is any UI involved here but, yeah, this does seem cool. I see where the convolution part comes in here is that, okay, well, you've got to write a little Node script. Then how are you going to run the Node script? You need a little file watcher. Then how are you going to notify yourself that it's done - and whatever? There are a lot of moving parts to this thing.
Dave: I love it.
Chris: Convolution, I can see. One of the tools involved is called BitBar. That's kind of interesting. It's a Mac thing that allows you to spin up a little menu app real quick and then put whatever you want inside the menu bar app. That's kind of appealing.
Dave: Yeah, you can write whatever script you want inside of there. That's the one he uses for his Netlify notifications workflow. It's a good post because I've actually found that out. I had three or four projects on Netlify this week. It's fine, but I don't know when people are building and committing on different branches or whatever. I may see it, but I kind of only care if it's successful or if it fails. I'm kind of like, man, maybe I need to write this up myself.
Chris: Yeah, maybe give it a shot.
Dave: I'll have to figure this out.
Chris: Speaking of menu bar apps, I think somebody suggested this to me the other day because I had a menu bar app idea. I'll share it here in case somebody wants to build it.
Chris: Have you ever gone to the command line and typed "NPM run dev" or whatever, and then it's like, oh, but port 3001 is busy right now?
Dave: Yeah. Yeah. Yeah.
Chris: You can't run it on port 3001, or 9000, or 8000, or whatever it is. You're like, 'Why?! What is running there? I don't know." Then if you Google it, it'll be like, "Just do psaux-xpipe"--
Dave: Kill all.
Chris: [Laughter] Yeah, and then you'll get the PID. Then you're like, okay, but why can't I just see where it's running and turn it off? I don't know. I just wish that was a little easier.
Sometimes, I don't even have iTerm open. There are no terminal windows running, so what the F?
Chris: Anyway, there's this app. You know these apps that are designed for responsive design where you can have the same URL open in five devices at once.
Dave: Yeah. Yeah.
Chris: Polypane is one.
Chris: Sizzy is another one.
Dave: Sizzy. Yeah, that's the one I was thinking of.
Chris: Yeah, there are some free ones, too. Whatever. But Sizzy happens to be the one that I just noticed this little feature on, and I was like, that's a nice little developer bonus thing. There's a little X icon in the header. You open up the X and you just type in the port number, click a button, and it just finds whatever is running on that port and kills it.
I was like, "That's nice! That's what I want," but I don't really want to open Sizzy. I find Sizzy a little heavy, actually, to open. It takes a minute, so I was like, "Hmm," but I still do it because I like that convenience.
I was like, "What if there's a little menu bar app that would just do that one little thing? I didn't have to actually open Sizzy."
Chris: Somebody was like, "Just use BitBar," or whatever. There are other little GitHub repos that are designed to be like you don't actually have to learn Swift.
Dave: Yeah. Yeah.
Chris: You just spin up the thing and it'll run a little Node script or whatever.
Dave: Yeah, because it can run Bash, and then you can just call Node from Bash. Yeah.
Chris: Or you could write it in Bash. I don't know. But I wouldn't know. I'm like Node only.
Dave: This is the stuff I'm excited to be back on Mac for, to be honest--
Dave: --is these just like, oh, there is Unix there and probably Node. Windows was kind of like, "I don't know what you've got."
Dave: [Laughter] "How about .net framework?" But, no, this is kind of interesting. I don't know.
Chris: Well, thanks, Jim, for sending in your flow. I would agree that it qualifies as convoluted. If anybody else has a convoluted thing, like they did at work or something, there are some great stories.
Remember that one about the email that would only travel a certain number of physical miles? That was one of the great tech stories of all time.
Chris: No? I'll send you that one.
Dave: Oh! No, I don't remember this, but it's an email that only goes ten miles?
Chris: Yeah, somehow they figured out that you could email Arizona from LA but not New York, or something like that.
Chris: It would consistently fail and they had to track it down. The reason was so incredibly convoluted but did really actually manifest as physical miles.
Dave: Man. How could you? I mean explaining that to your boss.
Dave: Like, okay, you know email, right? It's everywhere. You can email China.
Dave: We cannot email Arizona.
Chris: Yeah, I mean it took 10,000 words to explain even how they figured out the problem, but it was real. I'm sorry. This is bad podcasting. I should tell you what the solution is, but I literally don't remember. Sorry.
Dave: I don't know. I'm sure it's install some server somewhere to fix it. I don't know. But anyway, hey, Chris, we only did one question last week. Do you want to hop into some questions this week here?
Chris: Oh, I'd be happy to. Shawn Gore writes in about divitis. Remember that term?
Dave: I love divitis.
Chris: Too many divs.
Shawn Gore: Hey Dave, Chris. Thank you so much for your podcast. Love everything you guys have been doing. I've been following you guys forever.
As a long-time Web developer with decades of experience, it just seems like HTML and proper Markup have increasingly less importance in modern Web development processes. I find increasingly that libraries like React promote divitis, spewing divs all over the place and having to teach it in Canada just kind of sucks for me.
It seems like they just have no regard for using proper HTML elements like article, details, dialog. I know that probably doesn't apply to everybody in the community, but it just bothers me a lot to see that HTML just kind of get thrown to the backseat.
Furthermore, with the advent of Web components, it seems as though browser vendors have stagnated in their implementation of new HTML elements. For example, we don't see much progress happening on the dialog element and the details summary whole thing just makes it really difficult to use for accessibility.
My question to you guys: How can we promote and reinvigorate the initiatives proposed for new HTML custom elements and enforce those to get shipped with browser vendors as opposed to trying to have all these different ways of creating common functionalities? For example, why don't we have an accordion element yet?
Dave: I think it could. I will say I've even seen people say, "You only need to know div and span and you could figure out the rest later."
Chris: Mm-hmm. Mm-hmm.
Dave: That's a big "Uh-oh! No!" You know?
Dave: But to be fair, there's block element and inline element.
Chris: I'm there too. I'm like, kind of.
Dave: There are semantics and it would be good to know what they do. I think especially in inputs, I think if we all understood inputs a lot better and labels, life would be a lot better for a lot of people.
Dave: I think, too, when everything is a component and you need to style around stuff, a lot of people will be like -- and one thing that React kind of did (and Vue), the limitation is going away, I believe, in both of those. But in order to render JSX, you'd have to open it with a div tag. It has to be wrapped. It has to be one element, right?
Chris: Yeah. Right. That's usually a div because it just is.
Dave: Usually a div, and now you can do a ghost element thing.
Dave: But I think that limitation is starting to fade away.
Chris: Mm-hmm. I think so, too.
Dave: I don't know what versions or whatever.
Chris: React, you still need a fragment, I think, but it allows you to do that. But then, you know, so then, yes, it was promoting divitis because you needed the div. Even with the fragment, I mean how many people are actually using fragments? I'm sure I do here and there, but I also kind of think that kind of who cares. A div is meaningless. By using a div, you are in no way harming accessibility. Maybe there are a few extra tiny bytes of HTML that are getting shipped that don't need to be but, in the grand scheme of things, a div is not a big deal. Using a div incorrectly is a big deal, but just having a div isn't some big problem.
Dave: Yeah, and you know I mean I definitely use extra divs for styling. You know, like, if I had this, that could be a container or something. Whatever. I think there is a little bit of a contribution there and a little bit of contribution.
I think, in the last five, ten years, we've had a huge influx of people--post Web standards movement--come into the industry and maybe some of that kind of sort of knowledge transfer was lost.
Chris: I totally agree.
Dave: Good elements and everything.
Dave: This is great because more people are getting more money, so hurray on that. It's like a broader field, but also we need to make sure everybody is up to snuff on what all the features of HTML are.
Chris: Yeah. You know it's kind of a problem when somebody is like, "Oh, my god, a details element. You can click it and open and reveal something underneath of it? Oh, my god. I'm about to delete 7000 lines of code," or something. At that point you're like, "Okay. There was a little communication breakdown here." You know?
Chris: That was a little weird.
Dave: The marketing department fell asleep.
Chris: But then Shawn, at the same time, is like, "Why isn't everybody using dialog?" Well, that's a communication breakdown too because the status at the moment is, "Don't use it. It's bad." So, careful there.
Dave: It's not accessibly feature complete.
Chris: Yeah. Right. It causes more problem than it helps.
Dave: Crazy issues. Yeah. Then Web components did come out and people are just like, make your own elements. I would put React components and Vue components and everything in the same bucket. It's like, you know what? Just write your own thing.
Dave: You know, popover or whatever. If you want to get involved with that, there's a wonderful site called openui.org. You can start getting involved there and on GitHub.
Chris: I do kind of forget. Is the idea, though, that if you really knock it out of the park that the endgame is a native browser element?
Dave: Yeah. I have a post on this. I'm actually, today, going to a meeting, Open UI meeting.
The idea, at a high level, is they're going through all the design systems and they're looking at what everything is called. They're like, "Okay, accordions. What are common features in accordions?" They basically build a blueprint of the thing.
Dave: It's not a spec, but from a blueprint--
Chris: We did a whole show on this. Remember?
Dave: Yeah. You could maybe write a spec. If you have a spec, then you can maybe write a component like a Web component or something, or a browser could take that spec and adopt it. Not every component, like a badge component or something. That's not going to go into HTML.
Chris: Mm-hmm. Mm-hmm.
Dave: But something like tabs or whatever might. That's kind of what I've been working on is working on a tabs element with quite a few people. Jonathan Neil, Brian Cardell, Leonie Watson.
Chris: Yeah. That's a hell of a team.
Chris: The worst-case scenario then, though, is that there's a very good tabs component that's a Web component that will be usable kind of forever. Better would we get it in HTML, but if we don't--
Dave: Yeah, and I think the idea here, too, is we have a spec of what it probably should look like from an accessibility standpoint and whatever. We have a spec. Then with a spec, we can go talk to component authors and just say, "Hey, I know you write this component. Let's just make it match the spec." If we can all match the spec, it doesn't matter what you're using. But maybe one day we can get an actual thing in the browser.
Dave: Just to make sure we're not letting anyone down or whatever.
Chris: That's cool. That's cool.
Dave: Anyway, you could maybe write tests based on the spec too.
Dave: Those tests should maybe be universal or something like that.
Chris: Is there a story? I think there kind of is, but maybe it's complicated. If this Web component natively ships and it does everything, could somebody who has written a popular tabs in React one choose to kind of scrap their React specific implementation? It'd still make a React component for tests, but have it use the Web component under the hood?
Dave: Yeah, in theory. Web components in React have kind of a big story there.
Dave: But in theory, yeah, this could all be recycled or upcycled into the same thing.
Chris: But then it's like the assumption then is Shadow DOM. I could see somebody in React being like, "No, I'm not going to put one thing in my app in the Shadow DOM."
Chris: That's not cool.
Dave: No, and in that case it's fine. Go build your own thing.
Dave: But here's the thing that exists. You can build your own H1 with div, ARIA.
Dave: Or role=heading ARIA level=1. You can build your own H1. Should you? Probably not. Don't. [Laughter]
Dave: I think there is potential, but I think the Web components is kind of an important step. This is what my An Event Apart talk this year is about is, we have a Web component, there's maybe even a pathway where that Web component goes into the browser. That was a couple of years ago. Chrome kind of said, "Hey, we're building a toggle element called Standard Switch and Standard Toast." They were just Web components built into the machine, like native Web components, so you'd say import a standard switch, and it would be like, "Cool. I know. I'll just get it from my localhost or my local browser."
Chris: Yeah! Like native modules. That's been experimented with already. Remember the key-value storage? That was one of them that was an experiment. It's been scrapped, unfortunately.
Dave: Yeah, but I don't think that was a bad thing. I think it was a sudden thing for people. People were just like, "What's a toast? You're shipping this in the browser?"
Dave: But I think there's a pathway if we all can kind of come around a really good Web component or a really good template. We could ship that in the component and then we could ship that out to a browser or something.
Chris: Yeah. I think that developer usage story needs to be clarified a little bit. It's getting there. I think ESM is part of the story. I have millions of billions of thoughts on that, but if you could just go import, boop, and it works. I mean I know you're talking about pulling it right out of browser storage or something. That's one thing, but it could be from NPM or wherever.
Dave: Import tabs from Skypack or whatever.
Chris: Yeah. From GitHub, from a CDN, whatever. Then you just use it. The amount of lines of code that you're talking here for a developer who doesn't care about the inroads of it, really--
Chris: They just want to use good tabs--is very few lines of code. It's a pretty darn good developer story.
Dave: No, and then if you want to bundle it later, that's fine. You go bundle. Do your thing.
Dave: We're just trying to get to a good tabs that everyone can use.
Chris: Yeah. Import them and use them as a custom element, I think that story is pretty cool. It reminds me of Houdini. Una made that houdini.how or now. I forget. I think it's how.
Chris: Some of them, they show you a lot of code and it can look intimidating, but it's trying to show you all the possibility.
The real base story of Houdini can be really small. Houdini, again, being this thing that can kind of augment CSS possibilities, which is pretty mind-blowing. For example, have a behind the scenes thing that's basically using a Canvas API to paint something on the screen, but you don't ever see it. You write no Canvas code. Some author has written some stuff behind the scenes. All you do is import it ESM style. Then all of a sudden it's available to you.
The way that you call it is with this paint parentheses thing in CSS that's specific to Houdini. It can be in three lines of code. You can have rainbow sparkle backgrounds. The developer story behind Houdini, or the usage story, is good.
Chris: It's like, wow, in three lines of code I have unicorn? Shit. That's cool.
Dave: Well, and it's cool you can control with variables. It's like I want angled corners but I don't want the -- I want to -- you're writing CSS variables--
Dave: --to control the behind the scenes Canvas painting that the browser then kind of stitches together composites.
Dave: That's pretty dang cool.
Chris: That's become the story just because of the nature of those, of CSS custom properties and their penetrative nature.
Chris: They have access to that, so why not use that as the API for them, essentially? I love it. Perfect use case, I think. But that's true of lots of stuff. You can style SVG with custom properties that penetrate down into the SVG.
Web components, one of the big stories of styling Web components is just to use custom properties because they smash their way in there and then you can use them.
Dave: No, I think there's going to be a cool future of people making these Houdini things. It's just like, "Oh, you know what?" I'm looking at one from Zhen Yang. It's called houdini-leaf. It's just a bunch of leaves. You know what? I want leaves going up and down the side of my page.
Dave: I don't want some repeating GIF or whatever. I want it to be kind of fun and procedural.
Dave: Cool. This is it. I want to control it with style. This is it and they made it. It's done. Let's go.
Chris: Right, and it's probably like 1K or something.
Chris: They tend not to be particularly large.
Dave: Yeah, and I think that's just -- I think you could -- it's like drop-in styles and feelings into a page.
Chris: [Laughter] Drop-in feelings.
Dave: You know? Yeah.
Chris: Let's call it Houdini Drop-In Feelings. I love it. Oh, yeah. The tree is cool.
[Banjo music starts]
Chris: This episode of ShopTalk Show was brought to you in part by Netlify. High-five, Netlify. Thanks for the sponsorship.
They have a new product called Edge Handlers that's an early access that I think is extraordinarily cool. You know about JAMstack, right? Like static hosting and services on top of that. You can definitely think of an Edge Handler as a service on top of static hosting. But in a sense, it almost changes the nature of JAMstack, in a way, because you can (in a sense) intercept a request and manipulate it before it gets returned to a browser. It's like being able to run code at the CDN level, the edge, as they say.
Imagine you have a particular route on your website. You can say (at that particular route), "I want this Edge Handler to kick in, I want this code to be run, and I want the response to be manipulated before it goes out." All this happens just ridiculously fast, at the edge, really geographically close to people, which is really cool.
You could, for example, stop for a second, go hit a database, get some data, put that in the response, and return it, or do some auth. There's all kinds of stuff that you can do. Imagine, now you're still at the CDN level but it's not just static assets. You have the opportunity to do dynamic things but at the edge.
Extremely powerful stuff. I think this is going to be a defining thing for the Web, coming forward. Doing this type of work at the edge is a big deal.
It's worth wrapping your head around. It's worth requesting access to Netlify to play with this technology. Please do enjoy and, again, high-five, Netlify, for the support.
[Banjo music stops]
Chris: All right, so there's that. We were talking about dev experience, in a way. Love that. This is a very random one from Scott Krause. I put it in here because I just love how direct it is.
"Hi, Dave." [Laughter]
Dave: To me - just me. [Laughter]
Dave: Debounce and throttle are the two things, and I would more or less use them interchangeably.
Dave: The idea is, let's say you do a scroll, like window, on scroll, fire some event. Whatever. Change the text. Rotate the hue. Rotate one degree, or something like that.
Dave: Okay? We're going to change the color of the text one degree on every scroll. Don't do this in production. [Laughter] That would be so horrible. But now I kind of want to see it.
Chris: Yeah. [Laughter]
Dave: I might make a CodePen after this show. Anyway, so you have this text, right? Change the background; that's probably a more natural thing that people do.
When you do on scroll, that literally fires on every or tries to fire on every tick it can. Every time the browser is like, "I am scrolling, dude," which can happen--
Chris: The point is, it's going to be fast. Maybe you scroll down once, it might fire a hundred times.
Dave: Yeah, it might fire a hundred times. This is really cool for your effect because it's going to be really smooth and amazing, but what's not cool is it will turn the fans on in the computer.
Dave: It works so hard. You're measuring every--whatever--one millisecond or something like that. You're trying to ask the browser for information and change the whole page every millisecond.
Chris: Sometimes it's your fault, too, right? Just be firing it, probably might turn your fans on, but more likely it's the code that you're asking it to run when it fires.
Dave: Yeah, it has to run too much code in the timeframe, and so you end up with this stack of calls where the event has fired 17,000 times, but your first function hasn't even finished. That's where the CPU gets bottlenecked and that's where you get scroll jank and stuff like that.
If you ever resize Google Calendar, you probably know this feeling. You're just like, "Is it going to die? It is going to die on me?" Sometimes browsers do die because they're trying to do too much math and explode.
Throttling and Debouncing, basically you set a set timeout somewhere in there and you say, "Scroll, but wait 100 milliseconds before you check if we're scrolled again," or something like that. It's basically like you can set a timer on how often you're going to measure.
If you're doing this on scroll, you can do a debounce on scroll (and you probably should) but it's probably not actually going to look like the effect you're looking for. But something on resize, people don't resize the page that often, so maybe you could get away with a slower. On resize, only measure this every 100 milliseconds, or only do this every 100 milliseconds.
Chris: Yeah, I'm thinking of, like, how tall is the browser window right now? Imagine we didn't have viewport units to tell us that at CSS. In the past, we did not. You had to measure the height of the browser. You're like, "Well, I want this element to be that tall."
Chris: So, you could write code that says, "On resize of the window, calculate the height of the window and then talk to the DOM and say that element should be that high." Well, if you wrote that code and then resized the window a bunch, it's going to go, [gagging and choking].
Chris: Because it's being fired a zillion times. That's why you'd debounce it. You'd say, "Please don't try to do that every time you get the DOM event. Do it every one second. If you get a hundred of these, do it once or do it twice."
Chris: Slow down. They're different, and I think debounce means that if you just resized your browser and you just sat there doing it, just over and over.
Chris: You never stopped. It would continue to still do it. It would do chih-chih-chih. It would do it according to your debouncing rules. Whereas I think throttling would be like, "I'm going to wait until you're done and then I'm going to do it."
Dave: Yeah. Whenever you're done, then I will make this 100% tall.
Dave: Yeah. But yeah, so I think there are libraries and stuff out there. I'm sure it's even on MDN or something like that if you need code for that. But it's a pretty good performance trick if you're having the, on scroll, everything looks like a robot is barfing.
Dave: Or just not doing well.
Chris: Isn't the concept really speed? DOM events are a great use case for this, but it's not anything. Conceptually, it's just like anything that happens too quickly, you can slow down with debouncing and throttling.
Dave: Yeah. Yeah, request animation frame. Request animation frame would be something I'd probably try first, like, do this but only when you have a frame ready to draw.
Dave: I don't want you to try to sneak this in. But sometimes it's a scroll effect or sometimes it's a resize thing.
Dave: You can think of, like, if you were doing some kind of watched box or whatever, like a resize sort of--what do we call them--element queries, container query kind of thing where you change the whole element on resize. You could do that on resize.
One thing I would also consider is, you can just do a resize observer. That might be another thing. I think there was talk about scroll observer.
Chris: Oh, for resize events? Yeah, that's the way to go.
Dave: Because then you're just like, you know, this thing will detect a resize and then say, "Hey, I have resized." That happens kind of on its schedule, not on--
Chris: Yeah, observers are sweet.
Dave: Not on the browser's schedule or not on the real-time resizing.
Chris: Right. At this point, everybody knows what you're using observers for and this debouncing/throttling thing is a big deal, so I'm sure that that would be built into the API, should we get a scroll observer. That'd be cool and neat.
Chris: I would think of like an open WebSocket too. Let's say you just have an open WebSocket and you're just waiting for stuff to come at you. Let's say it's a chatroom and a thousand people come into the chatroom and start chatting. It's just crazy, the events that you're getting. You could be like, deal with that every second, or wait until you get ten messages and then do it. There are all kinds of patterns.
Dave: No, that'd be an awesome way to throttle chats. I would pay money to do that, to be honest, because I'm in Twitch chats occasionally, and I'm just like, "What is going on?! Do teenagers have super brains that they can understand this real-time stream of nonsense and pogger emojis and stuff like that?" I have no idea what's happening.
Chris: That's funny.
Dave: Children, man.
Dave: Before you--? Oh! That's a good question.
Chris: Could you go to a website that has really slow debouncing, so you could ask the whole Internet, "Hey, go to this page and type, and we will infinitely stack your debounce. We'll put one character every second onto this page"? Then there are like two billion keypresses in the stack. You could watch the entire world type infinitely. That would be badass.
Dave: That's a good one. I bet you could do it in a Google Doc. You could find out how quickly a browser can fall over.
Dave: Just put 32 people in there and just be like, "Three, two, one, type." You know?
Chris: I wonder if it's millions. Do you think it's millions? Billions?
Dave: What's the limitation? I don't know. I bet the call stack is millions, but I bet the theoretical how many people can actually happen, I bet it's -- I don't know.
Chris: Does the browser protect it? Chrome doesn't want to crash. Firefox doesn't want to crash on you. So, maybe they cap it.
Dave: Well, I think they would just kill the tab.
Dave: Yeah. Sad tab it.
Chris: Sad tab it.
Dave: What is it? [Laughter]
Chris: [Laughter] It's a new word.
Dave: [Laughter] Hopefully, that helps, Scott. Thanks for the suggestion.
Dave: Probably didn't do it justice, but hey--
Steve Polito writes in, "Am I the only one that has a hard time making a good commit?" [Stammers] I can't say it. Steve, you're not the only one.
"Am I the only one that has a hard time making a good Git commit message?" That is a tongue-twister.
Dave: "I get in the habit of committing early and often, but this means I end up writing the same vague commit message over and over again. I know the solution to the problem is to be more verbose. That's a difficult habit to break. Any advice?
Chris: I have an active, long-term project where somebody added some kind of husky pre-commit hook thing that forces it. I don't even know if it's husky. It's something. It's a pre-commit hook that is like, it yells at you if your commit message doesn't fit its concept of what a good commit message is. Have you ever had a project like that?
Dave: I haven't, but I've looked at this tool. I forget the name of it. It's like Git -- oh!
Chris: One of the rules is that it has to have prefixed in some way. It has to be "chore: " which is like upgrading a dependency or whatever.
Chris: Or it has to be like feature or design. I forget what the okayed list is. But if your commit message doesn't start with one of those okayed words colon space, it just rejects your commit. It's like, nope, not good enough. At least it's a little bit of a hand slap for, like, do a good job with your commit messages.
So far, I've just been angry at it only.
Chris: I don't like it, but if the whole team had it, if I got used to it, it'd probably be fine. But day one, I was like, "Uh, no."
Dave: Yeah. I was in the -- I got a new computer. I'm starting a new project. I just was like, you know, what are the best? Is there a "how to do Git" compendium? I think I asked on Twitter and got some responses. I can share a link to that. That tool came up.
Dave: "Here's how you do a commit message," or you can enforce how to do a commit message. I like that. I try to stick to the verb, like add -- or the present tense verb: fix, add, undo.
Dave: These action verbs, like verb foo on bar, like on the subject.
Dave: "I did this on this," and I try to figure out that. Then I relate it to the issue. Then you can -- I think best practice would be to work in a branch and squash commit and stuff like that.
Dave: Well, it is, but I'm also just like, you know, hopefully, it's micro enough that it works.
Chris: Yeah. Right. I mean if all your PRs are micro anywhere. I almost don't even care about commits. I want the PR to be clean.
Chris: I want the PR to be named well. I want there to be information in the PR about what you did. And I don't want there to be a bunch of dumb white space changes and shit like that. I want it to be clean looking PR. Chances are, that's where I'm going to look at your code. Then I'm going to not look at a commit. I'm going to look at all the commits together as one big thing.
Dave: Well, and that's a great -- like maybe your commit messages don't matter, but it might help you figure out, "What did I do here? What was I trying to do?"
Chris: Yeah. I'm not saying don't have good commit messages, but relative importance.
Dave: But if you have a good PR--
Dave: --and then you squash emerge off of the PR, now you're talking. Now that's like a really good sort of thing, so it might save you some headaches down the road. I think somebody was -- I read something and it was like, look at your -- if you type "get log," try to make it read like a book or something like that.
Dave: Like a chronology. Can you at least understand what happened?
Chris: I like that. Here's where it broke down for me recently. An example, if I'm working on some CodePen bug fix or something, 100%, good commit messages, tiny little bits, very understandable everything. Fix this on this - that type of stuff. That'll work great.
When I was redesigning CSS-Tricks, and I've been poking around with the ShopTalk Show site, as you did too. I should show it to you. It's almost ready, I think. I did your little feature request.
Chris: The way I work, anyway, is that I just open the site and I'm just generally polishing things. I'm working on a big redesign, so I might be like, "Oh, this card needs a little. I'm going to do this. I'm going to move these." I probably touched eight files, but there's not a lot of coherence to what I just did. I didn't just do one thing. I did like eight little mini things because I'm just all over the place, just polishing.
The commit message makes no sense, and I'm not going to split it into eight commits to say, "Changed border-radius to 4 from 6 on this card." I'd spend my whole day writing one-off commit messages. I'd just be like, "Did a little polish. Here are 16 files I changed." Done.
In this case, nobody cares. You might never even pull this site locally. I have no idea. Maybe you will. But it just broke down to me. When I'm doing big redesign work, I just don't care about little micro commit messages.
Dave: No. Yeah, it's definitely who is on your team, how do you care. Usually, it's the strongest voice wins. You know?
Dave: The strongest opinion wins, but it does help sort of like, you know, we're just going to write this down once and we all kind of vibe in it. If you have tooling that helps too, that's kind of cool. That tool that I think you were talking about was commitlint.
Dave: But there'll be a link in the show notes.
Chris: Was I right? Is it a pre-commit hook or does it use some other technology?
Dave: Yeah. yeah, you can make it into a pre-commit hook. It's basically just a Linter.
Dave: You can send any text to it, but then it's like, "Oh, okay. What are your--?" But then you can hook it up into your pre-commits.
Chris: I see.
Dave: But anyway, then there are another couple of side projects, but then somebody sent this, "How to write a Git commit message," from Chris Beams. I thought I got a lot from this. I kind of want the whole Git compendium, like how to do GitHub. You know? I may write this just to be like, "Here's my line in the sand," or something. I don't really care.
Dave: But here's how I'm approaching it from A to Z, from local to in production or whatever.
Chris: I see what you mean because there are a little aspects to it. It's not just commit naming. It's branch naming, issue naming, PR naming, and not just naming but what's in those things. Yeah.
Chris: There's a lot.
Dave: Like, what are your labels? How do you approach labeling? That could be a whole thing, too.
Chris: Won't fix. I just put, "Won't fix," on everything.
Dave: Won't fix. [Laughter] Won't fix. Won't fix. Well, and some people do, though. We close all issues. This is the Lodash approach. You close all issues and then you open them if they become active. Your whole backlog is just basically closed down issues. But if something comes up and you start working on it, you open the issue.
Dave: Dangerously controversial.
Chris: I've never heard of that wackiness.
Dave: Well, yeah. I don't know.
Chris: That's kind of cool. That's kind of cool.
Dave: But then there's strategy. I think Rich Smith tweeted or wrote about this, today even. Just was like, we used to do everything in GitHub issues, but now some stuff happens in Notion. Having real clear boundaries on where discussions happen.
Chris: Oh, that's just huge.
Dave: Where support happens, you know, stuff like that.
Dave: That's how I do my open-source. It's like, hey, if this is -- I can give you a one-liner and try to help you, point you in the right direction, but all help goes to Stack Overflow, and I'm not on Stack Overflow. [Laughter]
Dave: But that's where that--
Dave: If you want help, that's the website for it.
Chris: Yeah. Yeah. Yeah. The public versus not public repos changes a lot in this, too. You might want to have literally two different sets of rules depending on if it's a public repo or not.
Dave: No. Yeah because discussions is such a huge feature that I don't really have on any of my projects.
Chris: I think that's neat, too. Yeah, that's been a plague for me for years. I'm the locust in this situation. I'll be like, "You know what would be cool? We should have this in the admin screen, this button. It would be way better if we have this button." Then I'll open it as a bug - a bug!
Chris: I'm terrible! Because at least we'll look at it. It doesn't feel like it's lost. If I just write it in some Notion doc, that's fine. It's not Notion's fault. It's how you treat it and think about it, but we don't have a place that's like, "Make sure these things don't fall off the radar," whereas a bug ticket will not fall off the radar. It's still sitting there. That was the thing and you need a better solution for that.
I don't know that we have all the solutions, but one of them is that you do not do that. You need to draw that line in the sand. Issues are issues - literal bugs. Not for everybody in the world. For us.
Dave: Yeah. Yeah. Yeah.
Chris: And we're damn near zero. That's what I was going to say.
Dave: See, that's good.
Chris: I think it's really cool if you're running your ship at zero tickets. We're not yet, but we're really getting there.
It becomes a different ballgame. It becomes, if you open a ticket, then you take it really seriously. You're like, this is broken and this is a priority to get it fixed. This is not some hive of crap to just forget about or whatever - do this on the third Thursday of every month.
Dave: No. I think if you can do that. You know we have a big mix at Paravel, but we actually started a whole other GitHub, a ghost repo. No code in it, but it's just for business. You know?
Dave: Because we're doing a little--whatever--project, startup thing.
Chris: Somebody needs to call the state of Michigan to make sure our tax records there are--
Dave: Exactly. Have we talked to so-and-so, such-and-such about whatever Delaware corporation, blah-blah-blah?
Dave: It's like, you know, that sort of stuff is like, you need a paper trail. You need some sort of idea of what's going on, so anyway. Yeah.
Chris: Well, thanks. That was cathartic to yell about GitHub structure for a moment. Thanks, Steve.
Chris: Thanks, Steve.
Dave: Thanks, Steve. We should probably call it there. I think we're hitting the time zone.
Dave: We'll be back next week with more conversation and Web conversation. Thank you, dear listener, 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. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. Thank you for downloading this. This really means a lot. Celebrate 2021 and all the calamities with us. We really appreciate it.
Dave: Hey, Chris, do you got anything else you'd like to say?
Chris: Yeah. Send us more convoluted workflows again. That was fun.
Chris: Okay. See you later. ShopTalkShow.com.