Transcript

[Banjo music]

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 Rupert and with me is Chris Coyier. Hey, Chris. How ya doin'?

Chris Coyier: Hey, man. Doing pretty good.

Dave: What's--

Chris: Doing pretty good.

Dave: What's life like here? We're cruising into -- I guess this is August something, so yeah. It's getting kind of wild. I'm trying to wrap up. Me, I'm trying to wrap up a big initiative here on Luro, trying to get this all kind of ready for users to get into it and all that.

Chris: Yeah, because you have a waiting list, right? You've got to be ready to start inviting.

Dave: Yeah. Yeah, the strategy there - not to get too behind the scenes. You don't want to put that up too early and then, all of a sudden, you're not -- you know. [Laughter] You're not getting people inside and they have to wait around.

I have an app I signed up for two years ago, and I'm still in the waiting list. I'm like, "You all ever--?"

Chris: Yeah.

Dave: What's going on?

Chris: I have a little policy with email where if you send me an email about your product and I don't immediately know what it is, that I just hit unsubscribe on the thing because I'm like, "Obviously, I don't use it that much." If I have to query my brain for details about what your thing does - or whatever - I definitely don't care.

It's not like mean. It's not like, blah, bad. I'm just like, oh, no, that's one of the ways that I curate my email.

Dave: Mm-hmm.

Chris: It's a fairly telling thing if I have to dredge up what your thing even does. It's like, "Well, whatever."

Dave: Yeah, it's like I'm not sure. Yeah, you know, I signed up for this Austin Business email because my friend was hyped on it.

Chris: Yeah?

Dave: He was like, "You know it's a really great way to get an idea of what's happening in Austin, investments coming in, and companies moving in, and all that stuff." It is cool. It's great, but it's like three or four emails a week. [Laughter] I'm just like, "You know what? I might--"

Chris: Whoa! It's poppin'.

Dave: I might not do this anymore. But, yeah, you know. I don't know. There are different ones. There's a "Let's Just Talk" email, and then there's a "Here's Actual News" email. Kind of different brands of emails there.

Chris: It's interesting that local is the tie that binds there. You know? Because a lot of people in tech, the geographic nature of what you're doing is almost irrelevant.

Dave: I could totally see that. Yeah. It mostly is for us, how we're operating, but I think (in a big enough city) it's--

Chris: ...to feel connected to a scene? Is that it?

Dave: In a big enough city, I think it impacts hiring and location. You know? If you're fully remote, it totally doesn't. But in a city like Austin, if we wanted to hire something, it helps to have good friends and support, somebody I can walk up to and be like, "Here's my laptop. What's going wrong with my website?" Or talking to friends about it and stuff like that.

Chris: Yeah. That requires physicalness. Yeah.

Dave: Yeah. Yeah. Just good people. It really just requires good people, but one way to have good people -- like you were saying, I think, before the show. You have your little Ben.js group.

Chris: Yeah.

Dave: You kind of go and hang out and co-work and do stuff. We have that kind of in Austin.

Chris: Yeah, we did that today. It was kind of neat, and it was fun to have some face-to-face thing.

Isn't there something? What do they call that? I feel embarrassed that I can't remember it now where you feel more comfortable or safe or something working, even if you don't say a word. You're just together, and you're doing it. You can even do it virtually. There's some term for it. I can't remember.

Dave: Oh... um... What is it?

Chris: It's not just coworking. It's like--

Dave: Like--

Chris: --co-body something or something.

Dave: Oh, okay. Yeah. Like co-sleeping [laughter] with babies. [Laughter]

Chris: Yeah. Yeah, I don't know if it makes people -- it just makes people feel good somehow. I think there's more to it and I'm misrepresenting it. But there's certainly a desire to do it. Whether you know exactly why you like it or not, certainly people show up to these things sometimes.

Dave: Mm-hmm.

Chris: There was a little bit of chatter and then some silence of just like, we're all just typing on keyboards, but we all know we have kind of similar jobs.

Dave: Yeah.

Chris: You look over and see somebody's VS Code, you know.

00:04:50

Dave: Yeah. Yeah. Do you--? Working from a coffee shop, can you do it? Can you?

Chris: Can I do it? Oh--

Dave: Yeah.

Chris: Oh, I'm amazing at it.

Dave: You're amazing.

Chris: I prefer to do it. Yeah.

Dave: From a coffee shop? You prefer to work from a coffee shop?

Chris: Well, it comes and goes in waves. Pre-pandemic, I just loved it. There was something that I just LOVED about going to work for a little while, and then I'd be, like, "Oh, I've got to stand up, do my sun salutations - or whatever - and then hit it." Change of scenery. Bring the laptop over somewhere. And it just felt fun.

Maybe it's this town. I'm in downtown Bend, and there is ten choices, you know.

Dave: Oh, yeah, yeah, yeah.

Chris: So, it's not just the same thing exactly, like, "Do I feel like going to the one with the cute little bench that you can sit on that's a ski lift, or do I want the cute little one with the river view, or the one with lots of plants?"

Dave: Yeah.

Chris: Or do I like the one with the best coffee? Or do I like the one that's really a yarn store too, or do I want to do--? You know?

I've already logged into the wi-fi at all of them, so I sit down. But you know what? It was like thick CSS-Tricks time when I had context shifting that was like, okay, I'm working on some code. But I needed to write a blog post today.

Dave: Right.

Chris: So, if I could sit down and write a blog post. And I feel like I almost needed less screen real estate to do that.

Dave: Right. Focused. Okay. Yeah.

Chris: Yeah. But these days, gosh, I'm doing so much of Go, API work, and stuff where I need the terminal open or multiple of them, maybe, and a graphical thing because I'm doing API stuff that I need to be testing GraphQL queries and the codebase and maybe another codebase that I'm referencing and maybe a browser window. When you're at your most productive, you've got five, six things open.

Dave: Yeah. Yeah.

Chris: Which I feel like, blogging, you need one or two.

Dave: Right. You need either the preview or the reference and the editor. Right?

Chris: Yeah, so it depends on the work you're doing. Were you going? Was I sensing that you hate, don't like doing it?

00:07:01

Dave: Well, I actually found myself in a lot of coffee shops this week. I had car problems. I think I had mentioned that on the other week. It was like a flat tire. Oh, no. I thought I saw a staple in my tire, and I thought for sure that's in the tread it. Pulled it. Pshhh...

Chris: Uh... yeah.

Dave: Fully deflated. Wicked. Awesome. Cool. Now I'm at -- I was at Discount Tire on a Saturday, which is the worst. Everyone knows that. [Laughter]

Chris: Hmm.

Dave: I'm like, "Here it is." I went up there on Friday, and they were like, "We'll order your tire." They didn't. But then it came in late that night.

Then I went, and I said, "Okay. Can you replace the tire now?" They were like, "Yes. It will be two hours." You know, for like a four-minute job, but whatever - two hours.

So, I go to the Starbucks across the street, and I wrote some blog posts or edited up, spruced them up.

Then two days later, I had to go take the truck in for an oil change. Go there. They're like, "It's going to be two hours to get the oil changed."

So, I go, and I walk over to the Starbucks nearby. I sit down, and I just write some blog posts. It was actually super effective, and I felt like I finally was ahead on my blog.

Chris: Nice.

Dave: So, like, that's cool.

Chris: Do you bring your main machine?

Dave: I bring my main machine, and I feel like that was great. I think there is something about the coffee shop that it's very limiting in what I can do there.

Chris: Yeah.

Dave: I can only look at this and type.

Chris: Right.

Dave: Maybe that was a secret to the power focus. But I'm also -- I think we were talking about it before the show -- sensing RSI has picked up a bit, and I think that's from using the keyboard, the pinch in the wrists.

Chris: Yeah, it might be. It's surprising to me. I get why keyboards are the way they are on a laptop. That's fine. But to have a company that makes computers, like Apple does, and make external keyboards and totally shun the idea that people ergonomic keyboards.

Dave: Yeah.

Chris: It feels like, "Screw you."

Dave: Yeah. Well, it's a weird, like, you have mastered the experience of the hardware and the design, the look, but then the people who are using your stuff all day are like, "Ow! My wrists hurt! Ow, my thumbs!"

Chris: Yeah.

Dave: You know.

Chris: Don't get me started on the mice. I would never.

Dave: Never. Oh, no. That's big problems. I'm using the trackpad, and it's kind of big and dumb.

00:09:49

Chris: Yeah! That's a great question. Do you rock the trackpad even at your desk?

Dave: I do. I have a trackpad, and then I built this tent out of Legos.

Chris: Oh!

Dave: It's like a kickstand out of Legos that kicks it up to where it's a little bit more of a natural, like - I don't know - 15-degree wrist incline.

Chris: Interesting. So, no mouse at all. Or is there a mouse too?

Dave: No mouse at all. I have a gaming mouse that I could use, in theory.

Chris: Yeah.

Dave: I really don't like how Macs scroll, do mouse scroll.

Chris: Yeah.

Dave: I know somebody is going to be like, "Well, you can install a tool," but that's not what I want to do. I want a mouse to work on my $3,000 laptop. That's all I'm asking.

Chris: [Laughter]

Dave: So...

Chris: I don't know how this happened to me but, at home, which was a desk I didn't use all that much, somehow it got set up at one point where all it had was the trackpad.

Dave: Mm-hmm.

Chris: And so, whenever I worked, I just would use the trackpad. And I noticed myself -- I noticed myself not noticing. [Laughter] You know what I mean?

Dave: Okay.

Chris: I was like, wow, that really just doesn't bother me. I could rock a trackpad all the time. So, I tried doing it at work. Then I was like, "But if I do it all the time, that's also a little RSI trigger for me."

Dave: Yeah. Yeah. Yeah.

Chris: But I liked having it because it can do some stuff that the mouse can't do. If I ever flip over to Figma (in a tab or whatever), I have to trackpad.

Dave: Yeah.

Chris: I have to be able to scroll around and zoom and pan and all that stuff with the trackpad. I cannot deal with it with the mouse.

Dave: Yeah. Yeah.

Chris: Now I'm in the situation where I generally prefer the mouse. And I upgraded, by the way, to the LX Master Mouse 3S.

Dave: Oh... Okay. Okay.

Chris: Instead of just the 3. It has one additional feature. It's just not loud. [Laughter] The 3 was just like, "Click!"

Dave: [Laughter] Silent, S is for Silent? Okay.

Chris: Yeah because I was like, oh, you know, this is starting to bug me because I feel like, you know, I'm just -- it feels weird to say out loud because maybe people I work with listen, but sometimes during meetings, I'm clicking around a little bit. You know?

Dave: Hey. Hey.

Chris: It's just going to happen.

Dave: Hey, a little ADHD.

Chris: [Laughter]

Dave: God gave me this chemistry. You can't really deny it. Yeah. No, I'm clicking around.

Chris: And I feel like, very honestly, probably what I'm doing is looking at PRs and stuff. It's not even that I'm on YouTube or something. It's just that I'm just like, "Ugh! There's not enough hours in the day," so I'd like to almost be multitasking here.

Anyway, I feel like people notice if you have a loud mouse and you're in a meeting with somebody. First of all, they're not staring right into the camera. You can tell they're looking at their screen. And they click 10,000 times with a loud mouse. It's just not a good look.

I don't know. Maybe I should just increase my behavior, but instead, I bought a quieter mouse. [Laughter]

Dave: [Laughter] Yeah.

Chris: I started to Google them. I'm like, "Can you make--?" because I frickin' love the MX Master. It's just such a good mouse. I was like, is there a way to make it quiet? Of course, there are all these YouTube videos. They're like, "Yeah. Totally. Just take the entire thing apart, do some light soldering."

Dave: Yeah.

Chris: I'm like, no.

Dave: Yeah. Yeah. Remove all the bushings.

Chris: Then I look up the 3S, and they're like, "New, quiet click." I'm like, "Hell yeah. Buy."

Dave: Yeah. Buy, buy, buy.

Chris: And it's beautiful. I love it. Now I have both. I set them right next to each other. I've got the frickin' pad.

Dave: Loud boy and -- oh, the trackpad and the mouse? Yeah.

Chris: And the mouse. Yeah, right next to each other.

Dave: I should probably. I had the Logitech Vertical, and I really liked it. But it was so bad for mousing, but I think if I do more designing. I don't know. I kind of have the opposite problem.

Selecting layers in Figma is not my favorite thing to do. I don't think it works good, just in general. But it's like I always feel kind of dumb about how it works. Anyway...

00:13:42

Chris: Well, we've got some questions people wrote in with.

Dave: Hey! Sweet.

Chris: We might as well get to those. It looks like Mr. Niles here -- let's see if I can cut down to what he's kind of saying here towards the bottom of what he writes. There's a lot of context, which it's easier to see than to read.

He's like, "When do you know it's time to leave a working but shaking system behind and start from scratch?" Here's the context from what he was tasked to do is that he has this basically a client website that the only thing that he was able to influence on it was the CSS with the job of improving how it looks.

He sends us these kind of before and after looks. One of them looks very - I don't know. It looks almost like somebody took material design and did a bad job implementing it, essentially.

Dave: Sure. Yeah, yeah.

Chris: Another one is cleaned it up quite a bit, but you can kind of tell that they didn't have--

Like he said, you can't even add a class to the HTML, essentially. And so, the question is, do you keep going down that path or at what point do you have to just literally wipe your hands and be like, "We can do no more here until we have access to do more of a deeper rewrite"?

Dave: Um... Yeah. Good question. Well, first of all, I just want to say he's done a really good job. It's hard to convey this before and after, but it's basically just good and bad. Bad was the before. Or just rough, like out of the box, something you installed off of NPM, like Angular table or something.

Chris: Yeah.

Dave: Then he has made it into this cool, card-looking thing. It's just really refreshing. It's got some different color palettes and stuff like that. I think that's awesome.

You're only able to do CSS, right? That's the limitation?

Chris: That's what it sounds like. Doesn't part of you feel like, "Wow, that sounds a little fun," [laughter] because you get to flex your muscles, in a way.

Dave: Yeah.

Chris: But also that I think I would just say no right out of the gate and say, like, you're only giving me this one tool. What's with the hamstringing, y'all? I don't know that I'm comfortable working in situations where you don't trust me to have more control over the system.

If you're saying, "You can't change that. It's going to stay the way it is," it means that if I write my CSS, somebody else could change the HTML, totally breaking my work. There's no connection anymore between the HTML and CSS. I'm like, "No!" I don't know if I ever do design where I don't have control over both of those things.

It just feels like you could get hamstrung. They could come along and screw up your work. Then they'll say, "What's wrong with your work, bro?!" I'll be like, "You only gave us half the power! You broke it!"

00:16:43

Dave: Yeah, so it looks like it's an e-learning system and through a third party or through a vendor. They buy this e-learning system, and then they are able to--

The only thing the e-learning system offers is adding some flexibility. Man, I would--

This is tough. I think you need to maybe work with the vendor. As wild as this sounds, like threatening to leave, suddenly unlocks a bunch of features.

[Laughter]

Dave: We've seen -- I've seen that before. A company was using a proprietary CMS. They were like, "We're going to switch." They were like, "Oh, by the way, we have a new CMS that does--" You know?

Chris: [Laughter]

Dave: They footed the bill to upgrade them because they still wanted the money. You know? I don't know what the situation is here. If you're only paying them $10 a month, then maybe it doesn't work like that. You know?

Dave: Yeah.

Dave: I mean, it may--

Chris: Switching entire -- they call them LMS in this case. It must be a learning management system.

Dave: Yeah, learning management system. Yeah.

Chris: Also, just because you - I don't know. Look. The decision to change LMSes probably as a lot--

The CSS selectors is a tiny pebble in the ocean of deciding whether you're going to switch an entire thing like that.

Dave: Right.

Chris: Don't listen to me and be like, [growls] "I'm mad!"

Dave: What I would maybe try -- the second step I would maybe try to figure out, I mean you're doing an incredible job with CSS. Maybe you can upstream that to them and be like, "Here's what I have." Write a manifesto.

I've done this a lot in my work is write a manifesto. Be like, "Here are the shortcomings. Ideally, we could change the look of the player. Ideally, we could customize the look of the episode list," stuff like that. I think that would be a big--

They want to hear from their customers. Anyone who is writing software wants to hear from their customers. If you can just provide them a bulleted list of actionable items, I think that's going to go super far in their organization, a bulleted list of actionable items. Do that.

The third thing I think you could do is maybe see if there's an API of some kind to this learning system and maybe some of those views you can own. You know? Like the latest courses look or something like that. Maybe there are pieces of it that you can own (through some URL hacking or something). Maybe they have a way for you to have a big, empty block that you can style, or something like that.

There are maybe -- or if you can put a script tag on the page, you can actually do whatever you want. Maybe you need, like, we need a script tag on the page to do our custom tracking. Surprise! You're hacking the website. [Laughter] Maybe that's something else, too.

There are a few ways around it but, in general, I think re-platforming is pretty risky. It sounds like you re-platformed from a Google Spreadsheet before. So, I would be hesitant to re-platform unless you knew the costs and the benefits and did some prototyping around what would be a next better system. Definitely do that. Good luck!

00:20:24

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Deque, the makers of aXe. I feel like we've talked about aXe lots of times on ShopTalk Show. It's kind of an industry standard accessibility testing tool that's super powerful.

Do you know how accessible your website is right this minute? Can people with disabilities access it? If you aren't sure, you can get started in minutes with the free aXe DevTools browser extension.

That's right. It's installable in Chrome, Edge, or in Firefox. And you're already developers. You already use DevTools. It's a part of DevTools. It's like a new tab in there, so you tab over to it, hit the "scan all my page" button and, within milliseconds, you'll get a list of accessibility issues with details and guidance on how to go about fixing them.

Think of all the low-hanging fruit is so easy and represents a bulk of accessibility issues on websites, in general. That's really powerful. Anybody can do this, by the way. You don't have to be a developer. It's so easy to use, and it'll be like there are color contrast problems here. There are some form problems here. There are all kinds of stuff it can go through.

I would point out, even though they didn't put it in these notes directly, that they have these walk-through things, too, that are a part of Pro that are really cool for sussing out more complex accessibility issues that need a little bit more of a walk-through to find. That's almost my favorite part of aXe. I think it's cool.

Let aXe tools do the heavy lifting for you. Try it for free today. That's deque.com/shoptalk to get started.

[Banjo music stops]

00:22:11

Chris: Nicholas Skimas writes in about the misleading outline algorithm in the HTML spec. Did you see this going around the other day?

Dave: Yeah.

Chris: They yanked it from the spec, and it was both controversial and not controversial, in a way, in that it was removed from the spec, which felt weird. But then it turns out the reason was kind of that literally no browser ever implemented it. It was kind like, "Yeah." It was almost like a white flag kind of throwing in the towel on that.

It had to do with basically the header elements and stuff, right? The way that it was spec'd was like, "Oh, when you start a new section element, you kind of start over with H1, H2, H3," or something. That made some kind of more logical sense, but that never really lived up to be anything browsers ever implemented. So, bye-bye. Not going to be a thing.

Dave: Yeah. Yeah, it's gone. The whole idea, "It doesn't matter what headings you use," is not true now. You have to have a document outline. You kind of did, in general, but now it's like you definitely do.

Chris: You definitely do.

Dave: You can't point at the spec and say, "But the spec says," you know? So, yeah. I don't know, man. This is great, I guess, that it's clear.

I love removing nuance from ARIA accessibility land. Let's get rid of nuance. I love that. But in a component-driven world, that's a lot. It's a lot of work to be like, "Okay. When this component is in here, it's actually an H4." You know? I wish we had generic heading elements that managed all this, but that's going to be on my tombstone, probably. [Laughter]

Chris: Yeah. [Laughter] Right. Right. No, you do gotta get thinking about it. It's tricky because it's hard enough, even on (let's call it) a simple -- even though it's an overused word -- blog kind of thing.

Dave: Mm-hmm.

Chris: What's the H1? What's the H2? What's the H3? Do you have to be cognizant of the entire page while you're thinking about the headers you use in the content? Well, yes, you do. And it's a little unfortunate that you have to be like, "What's the sidebar doing? I guess I better not step on toes inside the content of my blog post because of something else totally somewhere else on the page." But it's kind of always been the case that you've had to, and now you really have to. So, suck it. [Laughter]

00:24:58

Dave: Yeah. Yeah. Now it's just hard. You know. I don't know. It's hard in practice. It's not super hard. It's just hard in practice.

Chris: [Laughter] Sure.

Dave: You know? Because if I'm writing a component, I'm not immediately like, "Oh, this will always be an H3." I have zero, I guess, guarantees that that will be true.

There are some tricks you can do with hidden headings and stuff like that. Maybe that just needs to be blogged about, and when to use this and when not to.

Your cards could be H3, or something. Maybe they don't even need to be. They're just links. But--

Chris: That's the H2, H3 conundrum is the hardest one because you can always be like, there's going to be one H1 on the whole page.

Dave: And that's going to stay like....

Chris: That's almost an SEO concern.

Dave: Yeah.

Chris: Unfortunately, that has to factor in, too. Then what's the H2? It's never the site title or anything like that, except for maybe on the homepage might be the site title. But for the most part, I think subpage is going to have some kind of H1 that's the title of whatever if happening on that page.

Even page, I realize, is a little -- when it comes to Web apps, for lack of a better word, "What's a page?" Then what? Let's say you have a weather widget, and it says "Weather." Is that an H2 or is it an H3? I could see it being an H2 if it's pretty high-up content there. I could see it being an H3 because it's tucked in a sidebar or something. You know?

Dave: But what if it says "Omaha" really big and "47 degrees" even bigger? Which one?

Chris: Yeah. You'd almost think--

Dave: The vertical rules fall out the window. You know what I mean?

Chris: That's true.

Dave: The sizing rules go away. Yeah. I don't know.

Chris: Yeah.

Dave: There are so many--

Chris: Here's the real truth. We've been winging it, and we're going to just keep winging it.

[Laughter]

00:27:04

Dave: I will get by. Yes! I've been thinking. There's a really good tool. Microsoft Accessibility Insights is a good tool, a good extension for this.

I mention it just because it'll tell you your heading levels pretty good. I found it to be pretty awesome from that perspective, like, okay, I can at least get the headings kind of sorted out without embarrassing myself. That's a plus, maybe.

Chris: Yeah. Here's a funny one is that, on CSS-Tricks, the head -- I think, in the very early days of the site, did make CSS-Tricks the H1 in some context. Then I was like, well, okay. Well, then the title of posts is always in H2. So, in the content of posts, I only -- the highest level heading I would use was H3. I've been known to use H4, too, and an H5 very rarely but sometimes.

Dave: Mm-hmm.

Chris: Good because that's much as you've got anyway, or is there an H6? I guess there's H6 too. I don't think I've ever used that.

But that meant, though -- isn't that weird that there was very rarely H2s used. It would go -- because eventually, I learned, oh, for SEO reasons, on a post called -- I'll just go to your site -- "Before I go, what I know about putting on a rock show." When you go to that page, that's got to be the H1. Otherwise, you're really strewing yourself from an SEO perspective.

Dave: SEO, yeah.

Chris: On CSS-Tricks, though, that would be the H1. Then in the content of the article, the first header level would be an H3 just for historical reasons. I just rolled with it. Instead of fixing the underlying issues, I just did that for 15 years.

The problem is, what if you're on an archive page? Then the archive says, "post from August." That's the H1. The H2 is the title of the post, then. It makes sense then that the subs are H3. It works on that page. It just doesn't work then on the--

It's almost like they need to be dynamically generated depending on the context they're in. [Groans]

Dave: Yeah. Nah, that stuff is hard, man. They don't - I don't know.

Chris: Back to your generic header.

Dave: Generic header element. Please, please, please. Then that's the tool. Rather than H1, H2, H3, just H is our generic algorithm. If you nested it in sections and articles, it'll try to--

If you messed that up? Great. You messed it up.

Chris: Hmm...

Dave: You look stupid. [Laughter] That's the -- I would just love that to be like, I know this is a heading, but what level it'll be can actually change. That's what I'm trying to express with the H element.

Chris: That's exactly what I'm trying to express, too. That's a great idea. If you want to nest them, just use a parent element of some kind.

Dave: Right. Right. Yeah. It's just like, okay, well, cool. This one is in an article inside a section. Therefore, make it like that.

Although, I'm not sure you can do that. But anyway... [Laughter]

Chris: Yeah. I'm sure there are caveats all day long.

Dave: Right. Hey, I'm using very generic terms. I'll let you generate an outline. Then wouldn't it be cool if we had tooling -- here we go -- in DevTools that just showed you what that outline showed up as? Then you're just like, "Oh, okay. That does look bad. That is incorrect."

We have tooling, I guess. But it's kind of just here and there.

Chris: Yeah. There's a thing right in ( at least Chrome dev tools) that'll show you the document outline, won't it?

Dave: Oh, man. Really? I would love to know. I know there's the accessibility tab there, and it gives you what everything reads as. But I didn't know if it would give you a heading outline. But maybe there's something in there.

Chris: Yeah. Maybe it doesn't do heading. Oh, gosh. Now I'm talking out of my butt. It shows you how often I use it, huh? But it'll show you the accessibility tree, which is kind of like that. Isn't it?

Dave: Yeah, sort of. Yeah. It gives you, like, here is sort of what the AT is going to get.

Chris: Yeah, but it's not as clear as just headings only. Like your headings are in there.

Dave: No full page accessibility tree. Whoa! We just enabled full page accessibility tree. Let's see what's going on.

Chris: But you can't -- after you do that, you can't filter it to just headings (I don't think).

Dave: Oh, yeah. Yeah. But that is actually pretty cool that you can see that. That's actually a cool feature. There is, at least in my dev tools, a little accessibility man shows up, and you can click accessibility man, and you just get the A11y tree view. That's actually cool. I'm going to actually test this out.... Why not?

Accessibility man, go!

Chris: [Laughter] Go!

Dave: Accessibility man, go!

Chris: Really, but you can always kick the aXe tab, too, and that's probably the more correct thing to do because it will actually have actionable advice and such.

Dave: True, true, true.

00:32:15

Chris: Adam Beck, a few episodes back, we talked about checking in your node modules, essentially, which 1% or less or people do, right?

Dave: Mm-hmm.

Chris: It seems a little insanity, especially because the joke around node modules is always like, "I'm on a plane and I did node modules, and the airplane crashed, essentially." You know? Because it's so bandwidth-intensive, and it's amazing how many files there are. You know.

You'll hear somebody run some terminal command to remove all the node modules on your computer and have their computer come back to life. There's basically node modules is a beast of a folder, and that's just the way it is in our industry (for now).

So, there's that. But checking in them is silly because then every Git commit that changes it might be sending up 16,000 files, and everybody that pulls your commit pulls down 16,000 files. A little much, you know? It was designed almost not to do that.

I feel like industry advice is, "Don't do that. It doesn't need to do that. That's why there's a package-lock."

The person that pulls it can do their own install, and that's much more efficient and the correct way to do it. That's why there are lock files. That's what ensures that you all get the same thing. You know?

Dave: Yep.

Chris: Which is cool. Package.json alone doesn't absolutely guarantee that everybody has the same thing. The reason they don't is because there's a special syntax inside of the package.json thing that says what package are you using and then a semver string that describes what you want. So, it's not just--

Imagine it says 5.2.1. If it says that, you're going to get version 5.2.1. But a lot of people don't do that on purpose. They put little up arrow ticky thing 5.2.1. That means if it just so happens that 5.2.2 becomes available, it ain't even going to ask you. It's just going to pull 5.2.2. It will even pull 5.3.0 if that's out. But it won't pull version 6.

Dave: Right. Yeah.

Chris: Some people just like that. They like to just not derp around with little, minor updates knowing that they can just NPM install and get, generally, the latest stuff from that. Hence why that little uptick is pretty important. But there's also the little tilde thing that behaves a little differently, and there are all sorts of different syntax in there.

It gets weird. I don't think anybody has it super-duper memorized. The problem is that it's an honor system - totally honor system.

Dave: Right. Well, and it's like putting so much faith in a library author to obey semver. You know?

Chris: Yeah.

Dave: Which maybe did get shouted down.

Chris: That's what I mean.

Dave: But you're just like, okay, let's all hope that wasn't a breaking change. The whatever pack RegEx exploit 9520 for blah-blah-blah. Hopefully, that's not a big deal in my application. You know?

Chris: Well, it literally causes problems, doesn't it?

Dave: Yeah, it does. It does. I would say testing has got a little bit better, but I think, as testing has got better, I have a lot more faith in other libraries have tested their stuff and they probably aren't going to ship a fully breaking feature, like capitalized first letter, or something like that. Lodash capitalize probably isn't going to break if a minor version shows up.

Chris: No, it generally doesn't. It only causes a problem once in a while. Usually, it's intentionally nefarious and then gets fixed up because of that intentionality - or whatever.

But it's interesting to me that lock files aren't more a bigger part of this conversation, right? If you commit the package.lock or yarn.lock - whatever you use - then that's the trump card. That's what gets honored first.

Dave: Yeah.

Chris: Even if there is a minor patch difference, you're not going to get it because the lock files lock to the certain thing so that everybody who works on your app gets exactly the same stuff. That's pretty huge. That will save you a little bit.

Dave: Yeah. Lock files, though, have their problems. It's more about resolutions. Can I use Lodash Capitalize 2 and Lodash Capitalize 3 at the same time, sort of, you know? Or will it, can it, resolve it to the same version of Lodash or whatever? It'll try to do that.

It's like a resolution of modules, but then a lot of services -- Netlify or whoever -- will just do an NPM install and kind of ignore the lock file. Maybe. I don't want to speak for Netlify. I don't actually know. But a lot of services will ignore the lock file because you just kind of can't guarantee because it puts a lot of architecture information, like bind it for whatever M1 Mac and stuff like that. So, they kind of have to ignore it in reinstall.

Chris: Hmm.

Dave: Even that lock file isn't guaranteed to be perfect.

Chris: That's unfortunate, isn't it? Yeah. I don't have a full set of understanding of all of this, but it's one of those, like, every once in a while there's a problem. People talk about it. And it causes you. You know people go do a little audit on their package.json files and just see what's appropriate to have what syntax and what isn't.

Dave: Yeah.

Chris: I wonder if we'll converge on not allowing those variable syntaxes at all in package.json. Just say the frickin' version you want and leave it at that. Then make it more of an intentional quarterly thing or something to upgrade versions.

00:38:40

Dave: Yeah, I've kind of had -- at Luro, at least -- a small company, a very small company. One thing I'm trying to do is, before we hire anyone new or whatever, we make sure to go through and update all the package.json so that when somebody shows up for the first day of work, we're on the latest and greatest and there's not NPM install problems because they pulled some package that's four years out of date or something like that. It's kind of like, just set that as a maintenance milestone. Whenever we hire somebody, we'll just make sure everything is up to date or something like that. We'll see if it worked. Sometimes you hire people because you've got too much work, and then updating all your modules is even more work. You know. If you find yourself with down cycles, it's good to at least take part of it, right? Take a chunk.

Chris: Yeah. Good question, though. Sorry for the half-unsatisfactory answer. Listen to Dave, not me. We did have an episode recently all about security, particularly in the JavaScript ecosystem, with Feross, 524, so that was pretty interesting stuff.

Dave: Yeah, that was eye-opening. I'm just, even now, like, "Oh, man. I need to figure a lot of this stuff out." I've looked at forking repos that have bad dependency problems that aren't updating and stuff like that. I'm in it, man. [Laughter]

Chris: What do you think, though? If we boil this back down to the thing, is there some advantage strong enough that would convince you to check in your node module?

Dave: Um...

Chris: Or is that whack-a-doo?

Dave: Oh, like to check in NPM node modules?

Chris: Don't ignore them. Put them in there. That way when somebody pulls your repo, they don't even have to NPM install. They just got it. You know?

Dave: There's nothing I would do that did that. In my situation, we use Puppeteer and stuff, so we'd be checking in whole versions of Chrome.

Chris: [Laughter] No, it seems--

Dave: So, I'm probably not going to. I don't think I'd recommend it. It would be--

Let me just see, in Luro, how big my node modules folder is. This should be a fun game that'll crash my computer.

Chris: Let's see. I might be able to play this. I'm on my booth computer, but I'll try to play too.

Dave: [Laughter] We'll see. It might take 25 minutes to figure out.

Chris: To calculate? Yeah. Are you just going to open the get info window?

Dave: 1.2Gs was its first guess, but it's going to keep going up. 1.21 gigabytes is where we're at right now. I think the fans are about to kick on.

Chris: [Laughter]

Dave: You know on that alone, it's like checking in--

Chris: But you only have to pull it once. It won't -- it'll just do difs from there on out. Right?

Dave: Yeah.

Chris: I mean if I'm going to argue devil's advocate, it's a one-time pull, right?

Dave: It's a one-time hit. Then every time it updates. Yeah, I guess that's not super bad.

Chris: I remember the argument was, let's say you use Netlify. Even that, your deployments are faster because it doesn't have to--

Dave: It doesn't have to install it. It just does it.

Chris: --do an NPM install. Yeah, it's already got the files.

Dave: Just pulls. Maybe.

Chris: I don't know, man.

00:42:10

Dave: You know what would be kind of a cool trick? Can I tell you? Here's an idea. You have some kind of computer or repository that pulls this repository, runs NPM install, and then commits all the things. It's not your working one. It's like this preproduction repository. Then that's the thing that goes out. Maybe that's a weird compromise.

You could probably come up with a machine that forks your repo and then always pulls the latest and then always reinstalls node through some GitHub action, commits those files back, and then that's the deploy machine. You always know what got put on the server. That would maybe be useful.

Chris: I think the security angle is a secondary benefit to it. Let's say you put your Gerry McGovern hat on, though, and were concerned about the electricity costs one way or the other. Is it actually less to commit your node modules because people aren't pulling them fresh from NPM each time, or is it the same, or more? I guess it would be the same, right?

Dave: It'd be about the same, assuming you have to do clean environments. Less HTTP traffic. It's only coming from one domain or one source.

Chris: Yeah. Only one person pulls the new dependencies. Then it's ... from then on out.

Dave: Less lookups. It might be more green.

Chris: Less lookups? [Laughter]

Dave: That's a tough question. That's a tough one to go down, but it is -- I don't know - maybe something we have to think about.

Chris: [Laughter] Maybe. Yeah. I'm not convinced. I like my Git Lite says the guy who commits his five-megabyte JPEGs to repos regularly. You know?

Dave: Yeah. Yeah, same.

Chris: [Laughter]

Dave: Well, actually, I minify. I squoosh my images before.

Chris: [Laughter] Still -- it's still -- what do you call it? Binary data, you know.

Dave: Yeah. Yeah. Yeah. I need a media server of some kind. One day, I'll have it. But I'm too lazy.

Chris: [Laughter]

Dave: I want to do the Jim Nielsen Netlify files thing.

Chris: Yeah.

Dave: I just want a bucket of files on Netlify. That's what I want.

00:44:30

Chris: Here. Let's add this. Let's spend five minutes plus just fantasizing about what a full-featured app media server would be. It sounds like number one is that you never put any binary data into get because it's all separately handled by this media service. Right?

Dave: Yeah. It's all in the media service, and then it's just in a, like, S3 bucket, basically. But I put a file in there. Probably the biggest, highest fidelity I want or can, you know, that makes sense. Right?

Chris: Yeah.

Dave: I don't need a 7,000-pixel wide picture of space for my blog. I need, at most, 2,400.

Chris: No, but you should probably upload that one, right? The media server -- if we're dreaming about all possibilities, you might as well give it the biggest one possible, right?

Dave: Yeah. I think it would be almost like Lorem Picsum, you know?

Chris: There you go. Yeah.

Dave: Or the Phil Murray where I can just say, "Give me the height and width in the attributes," right?

Chris: Or Cloudinary is the extreme example because then you can tell it how optimized you want it. Not just the size but what format. You want URL parameters and/or stuff inside the URL to control what it's giving you.

Dave: Yeah, and I want AVIF by default, AVIF, WebP, and then whatever PNG or JPEG that app located.

Chris: Yeah.

Dave: Because that's something I don't have right now.

Chris: Okay, so we'll do that. Okay.

Dave: SVG, OMG.

Chris: Yeah, do the optimizing.

Dave: To an acceptable extend. I feel like it always overdoes it, so I'd want SVG OMG. Video is a big one, and I'd probably -- dream machine does all these VPA and all the new codex because they can--

Chris: Yeah, then it wouldn't just be streaming, or it wouldn't do just format. It would have that special HTTP special server that would deliver it.

Dave: Code chunking, yeah.

Chris: Yeah, chunking stuff. Yeah. Okay. That's a pretty good dream. Would you build a whole UI for it?

Dave: I could see a UI or I could see a native app or an electron app that just visits the folder. [Laughter] You know?

Chris: Hmm... Mm-hmm.

Dave: That does that.

Chris: Remember, back in the day, if you so pleased, I think it was maybe a third-party app, but you could mount a server as a native volume.

Dave: Yeah, like a transmit. That was Panic's transmit.

Chris: Yeah. Could it do that?

Dave: Yeah.

Chris: Yeah.

Dave: That's what I want. That's what I want. Yeah. Like an FTP.

00:47:17

Chris: Yeah. That's a lot like Jim's thing where you just throw stuff in a folder and it just eventually syncs up to the server.

Here's another question, though. This is what I would want mine to do is that it wouldn't--

Yeah, sure. There's a URL format. But I can't just know and use the URL because that doesn't have good cache-busting. It would have to be like e-tag spaced. I'd need cache busting in the HTML with that string, and I'd want it to automatically break when I adjust that image (if I need to). Meaning that I can't just use the URL directly. What I want from my service is, like, a JSON dictionary of all the assets it has. That way I can import that, like at the top of a JavaScript file or whatever I need to, which is tree shakable. I don't want to ship every URL as a constant - or whatever. I want to just import just the URL that I need. And that gets updated.

If I update the picture of my ninjawarrior.jpeg, I'm not directly using the URL. I'm importing the URL as a string constant from my media server, which knows when to append a cache-busting string. [Laughter] You know what I mean?

Dave: Yeah.

Chris: It's a little elaborate, but if I can--

Dave: Well, yeah. Well, and if it could, maybe that thing, that URL is obviously a proxy to a real file. You know what I mean? Maybe instead of - whatever - media.chriscoyier.net/images/file1.

Chris: Yes.

Dave: It might be just something like get images/file1 -- or something. Maybe there's some intelligence there where you can be like, bus cache file 1, or something, through some CLI or something. I don't know. I'm just riffing here.

Chris: Yeah.

Dave: But you're just kind of like, bust the cache here. This has changed. Maybe that's just reset e-tags on all files in this directory - or something like that.

Chris: Yeah. Yeah. I definitely wouldn't want to rely on e-tags all the time.

Dave: Yeah.

Chris: I almost prefer I could call a function or something and be like, "Give me the file named ninja warrior," and it would return the URL that I'm supposed to use.

Dave: Right. Right. Right. Okay. Yeah, sort of like -- mm-hmm.

Chris: Like an API for my images - in a way. But I can't be -- I don't want to actually make an API request on the client. The API request would happen either during the build or -- yeah, during the build.

Dave: Mm-hmm. Yeah. Yeah. Yeah.

Chris: Eventually... But maybe not during the build either. That's not perfect because how does a build know to be triggered when my media server uploads and image? You know?

Dave: Right. Yeah, WordPress isn't going to be like, "Oh, he rebuilt. Let's do it again." You know? Yeah.

Chris: Yeah. Unless you do a webhooks thing and be like, "Oh, trigger a rebuild on the pages that use that particular asset by hitting a webhook," or something like that. I feel like you're in spider town there or something. It's bad news.

00:50:36

Dave: I'm going to just preemptively say somebody is going to say Thumboard does this, Thumboard, and I'm sure it does. But I don't know how to do it, and it's not set up for me.

Chris: [Laughter]

Dave: And so, I would maybe even pay you to set it up.

Chris: You know what it does make me think about, though, is how stuff like Bun - or whatever - that people are talking about putting your JavaScript, a little lightweight but fast JavaScript, runtimes.

Dave: Yeah. Bun is powered by Zig.

Chris: Yeah. Duh. Of course, Zig.

Dave: Duh. Bun is powered by Zig. [Laughter]

Chris: I definitely never heard of Zig until Bun was out, but now I love Zig. It's amazing.

Dave: Yeah.

Chris: Right, but we know how -- because this has been building for years. Companies competed over that weird acronym that static incremental regeneration - or whatever. Then there are two variations of it. I can't even remember what they are, but there was a little battle for a minute between Vercel, Netlify, and maybe Gatsby invented their own too.

Dave: Yeah.

Chris: But the point was we'll build the pages. We don't have to run your whole build to deploy. The first request that comes, then we'll build it. One was stale while revalidate - or whatever. In that version of it, it would serve the stale page. But behind the scenes, it'd be building the new page, or something.

There's something to that. It was in the water for a while. But I think that's kind of cool knowing that you have this. If you think of your SSG, your statically built site, let's say there are 1,000 pages on it, which is probably somewhere in the ballpark of even daverupert.com. When you ship a new version of it, maybe it doesn't build all 1,000 pages. You just let it do that kind of on-demand build.

When you ship a new version, all it does is invalidate the cache. Then the first time somebody visits a blog post or something, it rebuilds just that one page. Then it's cached from then on out. There's a mental model to that that makes sense to me.

Whereas your media service then -- because we're still dreaming about this -- it knows somehow (through magic) which pages of that site use which pieces of media. Then if you upload a new version of an image that the media service uses, it knows to just invalidate the cache on just those few pages. That would be frickin' fancy to me.

A little too much magic, maybe, but I like it.

Dave: Again, this is -- well, not again, but this -- caching is one of the hardest problems in computer science. What is it? Naming and caching are the two things.

I don't know that that's super easy to solve, but there's something there. I feel like there's such a common use case. The common use cases are like: I put the wrong logo.

Chris: Because the answer to having troubles with cache is clearing it more than you should. But the answer to make anything fast is caching more than you think you should. It's very at odds.

Dave: At odds, right? Yeah, so what's the perfect? You know I will say -- I don't know. Netlify ... sponsors the show.

I feel like Netlify does a pretty good job of the balance of cache and edge and all that stuff.

Chris: They do. You know what they do? Frickin' e-tags.

Dave: E-tags, there you go.

Chris: As much as I just talked poop about them, it might be a pretty good solution, ultimately.

Dave: It might be a good solution just for this. I don't know. Hey, well, that's probably a good place to stop, huh?

Chris: Probably.

Dave: All right. Yeah.

Chris: We're recording on a Friday. We're frickin' tired.

Dave: It's a Friday. It's almost Margaritaville, so we're just wrapping up the week here.

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 ten tweets a month. And join us in the D-d-d-d-discord, patreon.com/shoptalkshow.

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

Chris: Oh... ShopTalkShow.com.