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 about websites.

Chris Coyier: Yeah.

Dave: Ha! Look. I changed it. Ha!

Chris: You did change it.

Dave: I'm Dave--migraine is your gain--Rupert and with me is Chris--looking good in the both--Coyier. Hey, Chris. How are you?

Chris: I'm doing all right. I'm doing all right. Sorry about the headache. Yeah, sometimes life gets you.

Dave: You know sometimes you show up and you're like, "Guess what. I have a splitting migraine. I don't know what happened. And a flat tire," but I'm going to eat some tacos here and try to power through, so that's what's happening behind the scenes here of our nine thousandth episode of the ShopTalk here.

Chris: Yeah.

Dave: I don't eat on the show very often, but this is going to be one where I do. [Laughter]

Chris: Oh, yeah. No. We'll fix it in post. Yeah, yeah.

I've got one. This feels so silly to me, and I feel like everybody and their brother and sister has a solution for this in their own way, but it's fun to talk about, I think. It's cache-busting, essentially.

Dave: Bust!

00:01:25

Chris: You've got a style sheet or a script tag, and I'm kind of thinking more about "basic sites." Something like an 11ty site or maybe just a site that you don't use any processors on. Just an index.html file and some stuff. Okay? Because if you're using a whole build system kind of thing and it's getting run through Vite, or it's a Ruby on Rails site and it's using the asset pipeline and stuff, that asset-busting is a part of those technologies. It's such a well-known thing on the Web that you need cache busting of some kind for your assets because they're served with headers that say, "This expires in the year 3000," or something because what you don't want is a browser ever requesting the same static file from the server again. It might as well just tuck it in cache and be fast about it.

Dave: Mm-hmm.

Chris: That's kind of what makes the Web fast. If you had to ask for every single asset on every single page when you refresh, the Web would suck a lot more. It's like a big part of the equation of the speed of the Web.

Dave: It would. I mean I would guess that's part of how -- because the browser fetches the file, right? Like a JavaScript file comes down, parses it. Even image data and stuff like that will parse it and kind of build a tree that it needs to render it. I wonder if, if we did not have caching, any kind of like, "This expires later," if it would just be -- like it would have to re-parse everything every time, or if it could be like--

Chris: Yeah.

Dave: "Oh, that's the same file. I don't need to do anything. I already have that."

00:03:07

Chris: Or if you just click over one page and it's not a single page app. You click over to another page and caching just didn't exist as a concept on the Internet, it would be so slow. The Web would be so bad.

I know we always test our un-cached stuff, which is important, right? Because if you improve that, you improve the whole website. But really, the Web is at its normalist and fastest when it's dealing with fully or partially cached pages. That's the Web you mostly experience. So, it's just a big deal. It's a big fricken' deal, right? You can't just ignore cache.

But if you say, "Okay, I'm going to cache the crap out of all my assets," you're also saying, "When they change, it's something's responsibility to break that cache." This image has changed, this JavaScript has changed, this style sheet has changed. It needs to break the cache so that browsers request the new version. It has to be done. It's not optional.

Dave: Right.

Chris: So, like if you're Netlify, I think they've kind of skirted the issue in a way, and I think it works fine, essentially. They use E-tags, right?

Dave: Yeah.

Chris: The file doesn't actually change. The browser is just like, "Hey, is the e-tag of this file changed?" "Yes, okay, well, I'll download a new copy of it."

Not as efficient as changing the file name or the query parameter because it has to do this little extra round trip, but it's pretty much fine. And Netlify is so fast anyway, it's kind of like, "Who cares?"

But not every site in the world is that, so I'm thinking of sites that aren't Next.js or Nuxt.js that have some build process already that's handling this, and they're not hosted on Netlify, Vercel, or something that's handling it for you. So, what does that leave?

Well, it leaves a hell of a lot of WordPress sites. That's for one thing. And other sites in that category where you're not processing the HTML, but you need to bust assets. And I have a lot of WordPress sites in this category.

And it's not the only thing. It could just be like 11ty hosted on your Linode server or something, which is fine.

00:05:07

Dave: Like a lot of times you do. I mean whether it's, "Oh, we -- I put the wrong logo file up there, but I want the thing to be called logo.png. I just don't want it to be logo1finalfinal," because you can change the name of any file and that'll bust the cache.

Chris: It will.

Dave: Then I think you were saying the query string parameter hack is kind of--

Chris: That works, generally.

Dave: Generally works.

Chris: There's something that's stuck in a lot of developers heads that some weird, old -- you know it was called, like Sea Monkey or something. I forget what it was, but it was some Web server that I think is long dead. I could be wrong about this, but it just doesn't seem to be a big deal anymore. That query string parameter busting didn't work.

Dave: Ooh...

Chris: But I haven't run across that a long time. But that's kind of why everybody was like, "Well, we'll just change the file name," and then that edge case is handled.

Dave: Mm-hmm.

Chris: Okay. Anyway. You've got to bust it. One of the things you can just do is do it by hand. I've done this. I think, on the ShopTalk Show, I do it by hand. I go into the header.php file, and I change the stupid--

Mostly for the style sheet is mostly what I'm thinking of changing. I don't do it for all the individual logo assets or anything like that. But it's annoying and it's error-prone. And if you ship a bunch of HTML changes that do change and the CSS doesn't change because of caching, you can get into annoying situations.

One of the things I've done in the past -- and everybody has got their own little way. That's why I preface this. I use Gulp because I'm like, "Ah, well, we're going to process Sass anyway."

Gulp has a little find-replace-node thing you can chuck in there and say, "Hey. Look through this file. Find this string," and I've always just used something like the words capital cache underscore bust - or something.

Dave: Yep.

Chris: And replace that with data.time or something.

Dave: Mm-hmm.

Chris: Just come up with a random number and chuck it in there.

Dave: Every deploy gets a new--

Chris: Totally.

Dave: --cache bust. Yep.

Chris: And you can write in the Gulp file, like, "Do it only if it changes," so at least you've got that going for you.

But then you're in Gulp town. You know? What was it? Probably a year ago, I had the Gulp fellow on, and it was like, "Gulp is not dead," but we all were like, "Yeah, but it's not widely used." You know?

Dave: Yeah. Yeah.

Chris: It's a little weird, and it's quite the dependency to just chuck on a site just for that one thing, I think.

Dave: Oh, I mean I've done it just for CSS and it feels like overkill. You know? And even that is like what its bread and butter is. You know? Yeah, so do you--?

00:07:48

Chris: Well, I got a new one.

Dave: You got a new one. Okay.

Chris: Yeah, only because I was really trying to be like, "Okay, I'm actively working on a WordPress thing. It's not important. It's important to me, but it's not a big thing worth talking about. But I'm working on a WordPress site, and it involves shipping a new style sheet all the time.

When I'm really actively working on it, and I'm wanting to look in production and see what's going on and stuff, I'm doing this three, four times a day. I'm really sick of changing the query string parameter manually on the style sheet. I'm done. I can't do it anymore. I'll reach for Gulp if I have to, but I'm going to solve this. Right?

But I got to think, "There's got to be a better way. Why can't some of the other technologies that I use help with this?"

Dave: Mm-hmm.

Chris: The way that this particular site is deployed is with Buddy. We've talked about Buddy. You've used it before. That's the thing I generally use.

Dave: Yeah. Buddy.

Chris: It's the thing I generally use to deploy websites that are in this category because it's just like, "Okay, here's my FTP credentials. Get the files off GitHub. Cool. Thanks."

It can do lots of other fancy stuff, but I feel like it's a decent choice for that to kind of help me do deployment thing.

Dave: Yeah.

Chris: It'll run your CI. It'll do all kinds of fancy stuff. Right? It's a little bit like Zapier that has all these -- you're like, "What do you want to do in the world? Browse through our epic directory of stuff."

Dave: Yeah.

Chris: You're like, "Ooh!" You know?

00:09:14

Dave: I used Zapier for the first time last week or something.

Chris: Oh, for the first time.

Dave: For honest Go. I kind of knew what it was.

Chris: Yeah, right.

Dave: It's fancy Yahoo pipes.

[Laughter]

Dave: But used it for the first time. It's really cool and intuitive. They're not sponsoring the show, are they?

Chris: Uh-uh.

Dave: I did find the pricing a little tough to choke down.

Chris: Yeah.

Dave: So, we ended up going a different way.

Chris: I think their pricing model is actually pretty interesting. I think they have, through data, analyzed what some of the juiciest, hard--

Dave: Integration?

Chris: Yeah, and just been like, "Oh, yeah, those are premium."

Dave: Oh, wow. Yeah.

Chris: It's stuff like Google Docs to WordPress, or something.

Dave: Yeah.

Chris: The two most juicy ones to integrate, and then just chuck the premium label on those suckers, which I don't blame them, of course.

Dave: I don't blame them. It makes sense to me because a lot of them are like, "Hey, you want to integrate with Notion? Cool. you can create." That's it. You can create a page. You can't create a block.

Chris: Oh, or update.

Dave: There are just these -- it's like I think a lot of the APIs are just very slim pickings on what you can do with it. You know? I would pay for premium API integration. So, if they were like, "We built out all the endpoints, so you can literally do anything with these two," this would be great.

Chris: Hmm.

Dave: That's just something I noticed.

Chris: So, you're browsing Zapier, and you're like, "Look at this and this and this! Oh, cool! Cool!" It can be a little bit like that with Buddy. I don't think there are quite as many, and it's not really integrations-focused, but you build pipelines for your deployment in Buddy and it evokes that same kind of feeling like, "Oh, there's a Cloudflare thingy. Maybe I should look at that."

"Oh, I see. You can just tell my pipeline to clear the cache in Cloudflare when I deploy." That's cool. You should have that in there anyway, but that's not quite where I'm going with this. I don't think--

You've still got to bust the file name cache in Cloudflare anyway. It's like whatever. I'm sure there's a way you could trust Cloudflare more in this scenario, but here's where I'm going with this.

One of the things I just happened to notice in there while I was plucking around, like, maybe Buddy has a cache buster machine built into it. I don't know. Maybe.

They don't, but they have find replace. They just have that same Node-based find replace thing. I don't know if it's Node-based. I think it's just Bash-based.

Dave: Yeah.

00:12:04

Chris: It's just a really simple -- yeah, that's just sitting there. They just put a UI around find replace for files, and they made it nice because Buddy does nice things, and so you open up the little ... browser, and you said, "This file, I want you to -- when this pipeline runs, look for this text and replace it with this." And the replace mechanism will use environment variables, which is kind of neat. Imagine that being useful, right? Keep your environment variables or be able to sprinkle them into stuff depending on where the deployment is going. Pretty clever.

But it has a couple of magical ones, and one of the magical ones is just like, "What number deployment is this?" So, it's guaranteed to be unique. So, you can say, "Find this and replace it with the number of deployment," which works for busting cache.

I'm like, "Oh, finally. I don't need Gulp or anything. I'll put it in my WordPress header file. At the end of the style sheet, I'll just put some string that's unique," and I chose triple brackets just like an HTML templating language with triple curlies and, in the middle, it just said, "VERSION," in all caps.

And then in my buddy, I said, "When the style sheet changes," because it can be a different file that is watching for changes and then is doing a replace on, "When the style sheet changes, go to the header.php file and replace that text that says VERSION with the build number," and it's done.

Dave: There you go.

Chris: That's all I needed. So, I don't need any additional technology aside from what I was already using to have cache busting. And I could use that same thing in other -- you know, if I wanted it in the footer or in other template files, you could use that kind of same strategy. I just thought it was nice.

I'm pleased to have found it because now I can use that same technique on other sites and not have to be like, "Ugh! I guess I'll wire up Gulp again." And it's no shade on Gulp. I just don't want.

00:13:58

Dave: No, that's great. I meant that's awesome. You know where I had to do this recently was a service worker. I updated the service worker on my site.

Chris: Mm-hmm.

Dave: The application was, I wanted to get rid of Twitter embeds because they just bring down all of God's earth. You know?

Chris: Yeah.

Dave: They're just violent, and I have all these tweets and all these old blog posts, and I just was like, "You know what? I'm going to make the service worker intercept the request for widget.js and just kill it.

Chris: [Gasps]

Dave: Just nude the request.

Chris: Yes. Yeah.

Dave: So, my own service worker is now--

Chris: Send back and ASCII flower.

Dave: Yeah, and so somebody is going to get whatever. Their service worker setup might not catch this or whatever, but anyway, I just was like, "Awesome," and my UI will have to respond to that if a whole tweet embed happens. But I kind of wanted to keep it just in case I wanted to go back to tweets. I didn't want to just go rip out all the script tags for every tweet because then I'd never be able to add them back. You know? So, anyway, that's what's there. I did it.

Chris: I like that idea. Remember how somebody--? I think Paul Irish did it once and then other people took it up and ran with it, that YouTube lite Web component.

Dave: I love it. Yeah.

Chris: Or it might have--

Dave: My embed.

Chris: Was it a Web component, though? I guess it was.

Dave: Yeah.

Chris: Don't we use that on--? We use that on ShopTalk Show.

Dave: We use it on ShopTalk. Yeah. Yeah.

Chris: But it's so clever because you don't need a lot of, like, the way to integrate it is so light. And what I really like about it is that the UX of it is identical to what a real YouTube embed is.

Dave: Yeah.

Chris: Because a real YouTube embed shows you a still photo and the name of the video, and there's a play button, and you click the play button, and it plays. That's everything that the really heavy God's green earth fricken' YouTube embed does. [Laughter]

Then the YouTube Lite is just, "Oh, it's a photo and an anchor link to play the video in an iFrame."

Dave: Yeah.

Chris: It's amazing. It's so clever.

Dave: No. I mean that's I need to do that, too, because I did find pages that were slow on my site just from just having YouTubes.

Chris: Yeah.

Dave: So, yeah. It's just simple stuff like that.

Chris: But do it for Twitter. Okay, fine. Have it be a block quote. I don't hate the block quote idea, but it's not the same. You know? When you're embedding a tweet, it almost should have that cool embedded tweet look.

Dave: It should. Maybe just the ship has sailed for them. You know what I mean?

Chris: Yeah, maybe.

Dave: But it should be like twitter-embed or something - you know - like a full Web component.

00:16:42

Chris: I swear to God. I just argued with a guy at Twitter. I swear to God at one point you shipped a Web component.

Dave: Yeah.

Chris: They finally did look back through history, and they really did for a minute and then bailed on it for some reason. But it was there. It was there. No iFrame because iFrames such for performance. It's a way to avoid. Yeah, so cool.

Dave: Yeah. You avoided this whole flash of a layout.

Chris: Yeah.

Dave: And then there's maybe some session stuff and hearting and liking and stuff gets a little weird or whatever. But I just -- man, just right there on the page is a little interactive widget totally scoped, isolated, no style bleeds. Bing, bong, bing, bong. It seems like what you want.

Chris: Now that you got me thinking about this, do you remember that they changed this? I just caught wind of the drama after it happened, but if you embedded a tweet and the owner of it deleted the tweet, for a long time the behavior was Twitter's JavaScript was kind of like a board, and it would just show you the block quote styled as text on your website because the HTML they give you is a block quote, which is smart. That's a good choice they made.

But then all of a sudden, it started not aborting, and it would show you the skeleton screen of the tweet and basically say this tweet was deleted, which is unfortunate because, all of a sudden, your article changed, like any website on earth.

Dave: Yeah.

Chris: The vibe changed--

Dave: Yeah.

Chris: --because you couldn't see what they wrote anymore.

Dave: Yeah.

Chris: Even if they really did originally write it. They did revert it because I think that the drama was you're changing the public record, which is one of their stated little principles, isn't it? Like, "Twitter is the world's town hall," or whatever. I'm like, "Well, if it's the world's town hall, stop fricken' with people's websites then."

Dave: Yeah. Yeah, I mean no. I feel like they should offer both. Does that make sense? Just like embed the real thing with the actual number of likes and blah-blah-blah. And then just embed a historical document. You know what I mean? That's kind of like--

Chris: Sure.

Dave: --some styles that ship over.

00:18:51

Chris: Or can you do it in, call it, 30K? Even that seems like more than enough to style a little fricken' block quote with some like buttons on it.

Dave: Yeah.

Chris: Could we call it 30K? I'll take it. But not 350K. I don't even know what the exact numbers are.

Dave: No, it's a lot. I mean it's like 20 requests and stuff. It's so much going on. And then they did this thing like threaded conversations got weird. You'd try to link one and it would try to show context, you know, the reply, which sometimes I want it and sometimes I don't.

Chris: Yeah, and that was kind of hard to control. Then it depended on what the integration was because, if I do that on WordPress, it requires WordPress to have additional UI to have a checkbox or something to have that or not, and they didn't have it, so it was kind of like you're just stuck with it one way. Blah. That sucked.

Dave: Yeah.

00:19:45

Chris: Let's do some actual user questions, though. What do you think?

Dave: Let's go!

Chris: Here's some advice ones. Eric M. writes in that he's working with a client that's suffering basically from poor CSS hygiene, lack of methodology. They're in a state where they have some bootstrap CSS, not even Sass, just linked up bootstrap. They've manually modified it so they can't really quite upgrade it.

Some other library CSS. There are roughly two dozen CSS files per page with all kinds of random selectors with no rhyme or reason to their organization. It's all used on an SPA, so there's no individual routes that you can hit. There's just no front-end build tooling at all on the thing, but two dozen CSS files.

Eric's task here is to bring some maturity to this, like fix up the mess and do a full rewrite of some kind of the CSS. What an interesting position to be in to fix the CSS on a site. Probably not even necessarily improve the look or restyle anything, but just bring some maturity to the practice. Very interesting.

Dave: Yeah. Well, welcome to the hard stuff. You've leveled up into your job. This is exciting.

I was going to try to find some stats I had. I've had this situation. I went to a client and, literally, they were sending down one megabyte of CSS down the pipe.

Chris: Juicy.

Dave: There are some cool tools. Does he say he's using Sass? It looks like it's just some CSS.

Chris: Yeah. Just CSS, it looks like. No build tooling whatsoever.

Dave: Well, okay. I'm going to give you step one. [Laughter]

Chris: Step one. Yeah.

Dave: Sorry. If you've got suggestions, Chris, I want to hear them.

Chris: No, I want yours first, but I do, of course.

00:21:43

Dave: Step one: convert this to Sass. That's going to seem like an extra thing. But when Sass happens, you get source maps. Right? With the source maps, there's this cool tool -- sic pics -- we're syntax now -- there's a cool tool called Source Map Explorer, and it's kind of like Webpack bundle analyzer, if you've ever used that.

Chris: Hmm.

Dave: That shows you a tree map of your thing. This will basically, if you have all these CSS files in one Sass file importing, and you get the source maps working right, then that's big, wavy hands.

Chris: Oh, so you can smash it down to one CSS file. That'll be an improvement already.

Dave: So, get it down to one CSS file. You immediately saved a bunch of requests.

Chris: Yep.

Dave: Okay?

Chris: Yep. Okay.

Dave: Now you're going to see, in large, what these files are, like how big they are, and then what are they trying to do. That's sort of -- bootstrap may even have its own whole CSS. It may include a dozen different partials and stuff like that, but what you basically want to do is get a size and get an idea of how it's chunked, whether manually or systematically, but these are kind of like manual organization techniques.

I would do that first and then try to find your bloat. Don't spend 70 hours on the 2-kilobyte file. Spend 70 hours on the 100-megabyte file. You know?

00:23:24

Chris: Right. If it's all of bootstrap and bootstrap includes - I don't know - tabs or modals or some kind of design pattern and you do a find in project and see that that string appears nowhere in it, you can probably drag your mouse and select a big chunk of bootstrap and just delete it.

Dave: Yeah.

Chris: Because you've proved via find in project that it's not there. I mean it's not 100% foolproof because maybe you have weird third-party JavaScript that pulls down some HTML that you didn't know about that gets injected onto the page and that's where that string appeared. That's what always worries me about CSS is that it styles things in weird states that are hard to explore.

Dave: Mm-hmm.

Chris: Find in project is pretty good, though. You know? And it also doesn't account for string concatenation in JavaScript if somebody decided to put the class name on a div by concatenating TA with BS to make tabs. Now all of a sudden you didn't find class name tabs, and now you've deleted CSS that you needed. That's what's hard.

I'd say I really like Dave's idea. Get the request out and be able to analyze it better. Then you can start using variables and stuff anyway, which is a version of maturity for CSS. But one thing I'd recommend, the very first thing that you do (if you possibly can, and I hope that you can) is use something like Percy, which is visual regression testing so that every PR is just making sure that you're not ruining the site. Be like, "Go to these five crucial pages of the site," take a screenshot of it is what Percy does, "and compare it to what's on master so that when you delete that big chunk of CSS, is it a surprise to you that the look of the file is different? If there is no difference -- and it's hard to be comprehensive, but at least you can be watching yourself for big, gnarly ones.

Dave: That's sort of like the barstool in a different bar falling down problem. It's trying to solve that. Trying to. Yeah.

Chris: Yeah. What worries me there is that the barstool tends to not be like the homepage. The barstool is like three modals deep on a page that you forgot about. That's what fell over.

Dave: Yeah. It's the gluten-free ingredients table.

Chris: Yeah.

[Laughter]

Dave: You know?

Chris: Absolutely.

Dave: Four websites over. Yeah.

Chris: But that should help a little bit. Another thing he says, "This is all used on an SPA," and I'm thinking if it's an SPA, it's probably using a modern JavaScript framework of some kind. Usually, those modern JavaScript frameworks offer some kind of component-based styling. If it's a Vue site, there is a way to put the CSS right in the component itself. Chances are this site is built from components. I'd be more apt to start moving styles into component-based styles as you're deleting them from elsewhere than anything else.

00:26:15

Dave: That's what I've been trying to do. Not like it's overly wild, but if you say, "Oh, this is a component style, not a global style," like here's a global style we have is meta text. It's a little fainter. It's a little smaller, you know, 15 pixels instead of 16 - or something.

That's a global style. We're going to use that in 10, 20 different places. But something like tabs style, that's in your tabs control, so put it in your tabs component. Move whatever you can into the component.

Chris: Yeah.

Dave: Even just in a directory next to your component would save you all the mental load, cognitive load of what's happening in the file. Why does this exist and where is it? Just put it next to the component and name it the same thing as the component. That's going to change your life, I think.

Chris: Yeah. Yeah, nice. Good luck, Eric. It sounds fun.

Dave: Yeah, I mean I think those three things, if you can just try to understand your CSS. You may even have to spend a few days just reading it, like read through the CSS, and make notes.

Comment the CSS. That's probably another problem with it is there are no comments in it. Chuck some comments in and be like, "Okay, this controls blah-blah-blah." I've done that before. It's great. Great practice.

Chris: Mm-hmm.

00:27:50

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you by another podcast. Whiskey Web and Whatnot, a fantastic podcast from Robbie and Chuck over there. They run their own agency as well, so come at it from a long career in tech and lots of different technologies that they use.

You know I found that Dave and I (on this show) have a certain set of technologies we have the most experience with, and then end up talking about that. And being a guest over on Whiskey Web and Whatnot was so fresh because they definitely have a totally different setup. I mean we're all Web people, but they have a different perspective on things because of the different technology choices they've made and had experience with throughout their career.

They obviously talk about Whiskey. That's great. The beginning small chunk of the show, everybody enjoys a little whiskey. They talk about, so there's that aspect to it. But it's largely about Web stuff, but lighthearted. You know? Not super-duper heavy on tech all the time.

They have guests from all kinds of different areas of Web development. Lots of variety there, which is kind of fun.

Web 3 and NFTs are fairly frequent topics - and stuff. I think it's just worth a subscribe. If you like this show, there's a good chance you'll like that show. I certainly enjoy it. They do a good job over there. Can't have enough Web podcasts. Right?

Go check out WhiskeyWebandWhatnot.fm. If you just spell it all out .fm, you'll get there. And it'll be in the show notes, of course, too. Thanks, bye.

[Banjo music stops]

00:29:32

Chris: Right before we started, I asked in the Discord if anybody wanted to bring up any particular topics or something. Andrew was wondering about previews on CMS-driven sites, meaning literally any site that uses a CMS. Awful lot of sites out there.

Let's say you're producing or editing some content. Isn't it nice to be able to see what the heck you're doing before maybe you hit that publisher update button?

It is a weird thing on the Internet. This is a huge rabbit hole, of course. But something like WordPress, I just got done talking about, is a no-brainer.

For a long time, this was kind of like, "Obviously, you can do this. You just look. [Laughter] Or you hit the preview button first." It's baked into the technology. But there's an awful lot of, like, the second you choose that you're going to use a headless CMS, now there's a separation between where that content lives and where the site gets built. Previews are just a lot harder. It just kind of depends, I guess. You know?

It's one thing to be like, "I'm going to change the background color of the sidebar and ship it." Let's say you're using a cool thing like Vercel or Netlify. You can look at the deploy preview and see that the background color is now the nice lavender purple that you're asking for. But that's not content. You know what I mean?

If you go to Contentful or Sanity and change the value of some content, that's not triggering a development build on your build server. How do you see what your content changes are going to look like? It's a fricken' thing. [Laughter] You know?

If your content is in your repo, it's a lot easier. If your content is in a headless CMS, it's a lot harder.

Dave: Yeah. That's for sure. I mean I think there's, too -- I think, as developers, we build trust with our tools that we use and we're pretty confident. If I type this out and hit save, I can just push commit without ever starting on my local host. Boom, it's up there. You know?

I'm pretty confident. I know how my Markdown machine to text -- Markdown to website works. You know? So, I think this -- but I think not everyone works that way or not everyone has that level of trust built up.

Even with WordPress, it's like, I could just type it and hit save, and then just have pretty good feeling that that thing that I authored went out in the style I expected. But not everyone has that trust, so I think it's about that. I think some people want more verification about what they're going to hit publish on, and some people are completely visual.

That's another thing I've learned is they just want it to look a certain way. That's where we get into accessibility problems. They want everything to be in H2, or whatever. But they just want it to look a certain way before they hit publish. It's kind of the--

Chris: Yeah.

Dave: --old - I don't know - I'm going to tinker with my Word document before I submit it to class. You know?

Chris: Mm-hmm.

Dave: But I think us who are more Web-native are very much like, "Oh, whatever. If it's messed up, I'll just do it again," whereas I think people who -- I don't know. Their life is kind of on the you get one shot to present yourself. You know?

Chris: Mm-hmm.

Dave: Maybe they're in the whole, I want to make sure it looks right before I hit save.

Chris: Yeah. Yep.

Dave: That's just what I've noticed over years of - whatever - client services. And then some people will say they want the previews, and they're going to totally do it. Then they don't actually use that stuff.

00:33:26

Chris: Right. So, if this is hitting really hard for you, this kind of like, "Oh, yeah. We have this kind of -- we have our exotic front-end stack that's built from some kind of static site generator," or something, "but our content is in probably Contentful or Sanity," I don't know, maybe Fauna, I don't know, but those two are pretty big names.

I should mention that there's this company, stackbit.com, that I feel like pretty much specializes in this. They made this really fancy content studio thing.

Dave: Yeah.

Chris: That allows you to kind of edit the content right on the page visually, which is impressive enough. But then you save that, and it--

Dave: Yeah, it shoots out to your headless CMS, right?

Chris: Yeah, but only when you're ready. You know?

Dave: Oh, wow. Okay.

Chris: You're previewing it exactly how it looks on the page, and it makes this kind of temporary build of the site with the updated content on it. Then you're like, "Okay, I'm happy with that. I'll hit publish," and then it kind of makes its way over to the actual data store kind of thing. So, it's a little bit of a middleman.

I would say that this has been thought about and messed with. I'm not sure how Tina works into this, but if you've seen tina.io, the Tina CMS. It's a little similar to that.

Dave: It used to be Forestry.

Chris: I think Forestry probably still exists. This is their second product.

Dave: Okay.

Chris: But in a similar vein, for sure. As much as I like them both, I think Stack Bit is a little more fancy with how it integrates with headless CMSs, whereas I think the assumption in Tina is that the content is in your repo, essentially. But I could be wrong about that. Sorry if I am.

Dave: Well, and--

Chris: You both do a good job. Love you both. [Laughter]

00:35:08

Dave: [Laughter] Everyone is doing great.

I think, too, there's a slight distinction. When I want previews in my dream CMS--

Chris: Yeah.

Dave: --I really kind of just want a vibe. I want it to be close to what I'm seeing. I don't actually need one-to-one, header footer, email sign-up at the bottom. I don't need all that stuff, but I'm not everybody. I think some people do need the full picture of what this is going to chuck out when you hit save.

Craft CMS does this pretty well, too. I know Andrew has worked with Netlify and Nuxt kind of integration stuff, like the Nuxt content API and stuff like that. I think there's some really awesome stuff you can do. But yeah, it's a hard problem. If it was easy, it would just be solved. Right? [Laughter] But it's a hard problem.

00:36:16

Chris: Yeah. You did a post not super terribly long ago about analytics, I think, kind of comparing the details of that. I have a question here from Magnus who is wondering. He wants to pull off Google Analytics from a site. Then it's like, okay, well, but I still want some data. Fathom, plausible, search.

Dave: Mm-hmm.

Chris: Netlify has got a thing. What did you go with, Dave? Magnus is wondering (topic-wise) what's a good alternative to Google Analytics, which of course you can't answer until we know your requirements and stuff. But what was your journey like?

Dave: Yeah, so I was on Google Analytics, and I got off of it. I just think I was like I don't need this. And it was probably in some kind of privacy surge or something. You know?

Chris: Right.

Dave: But I was kind of even more interested in just owning that, so I got Fathom spun up on my own server. This was the community edition that they used to offer. I put it up on my own server.

I just took it off, and I wrote this post, "Server Side versus Client Side Analytics," and Jim has a post. Basically, it's the same post, and I dragged my feet on the post because we both had the same kind of outlook. But it's basically comparing Netlify Analytics and Google Analytics, or I'm comparing Netlify and Fathom.

Dramatically different, like 10x different in some points, or 18.5x different page views. For me, I think I just don't use analytics that much, but I think it really helps to maybe even have both, like a server-side and a client-side (if you're going to do it) because you need this bicameral, I'd say, or bifocal approach to what's your kind of raw log data and what's your client-side analytics script data saying, because they can be very different.

I think you just -- I don't know. Fathom is great, I will say, and they have a paid product that's even better than the community product I was using. So, I could totally recommend it. I think it is. There's some vanity there, but I think it's fun to just know how your thing is doing.

Chris: Didn't you find, though, that it was real different, like the numbers were not only 10% different but 400% different?

00:39:02

Dave: No, it's like my top posts were different. So, if I was doing the whole growth hacking thing where I, like, "Oh, man. That got 87 hits. I'm going to go write more about that one," if I went full growth hacker, I would have gone in two different directions based on if I followed the data.

Chris: Right.

Dave: And so, my unique visitors in Fathom were 1,200 a month, yeah, for one month. In Netlify, my unique visitors were 26,000 in one month.

Chris: [Laughter]

Dave: So, 2x, right?

Chris: Mm-hmm.

Dave: Page views, 18,000 in Fathom and 333,000 in Netlify.

Chris: Three hundred and thirty-three, so like - I don't know.

Dave: It's 18x, 20x.

Chris: Twenty times? Yeah.

Dave: Yeah. It's like 2x and 20x different, and so--

Chris: So, in your brain you've got to be like, "These numbers are all garbage. The only thing that could be interesting is relatively speaking," like if I track next month and had 340,000, I can see that page views went up a little bit.

Dave: Yeah.

Chris: But the actual number is bullshit, basically.

Dave: I mean, kind of. Yeah. I mean what am I supposed to gain here? You know? I don't think there's really much I can really kind of--

It just tells me some bot is hitting my server a whole bunch and Netlify's stats are super skewed. That's all it really was telling me. But it was also just telling me, "Hey, there's a lot of bot traffic. There's a lot."

But I think just seeing the trend lines, too, I was kind of comparing those over the two months. Man, it was like on one of them I have more page views and less unique (or something like that) over a year and, on the other one, I had more page views and more unique over a quarter, a month, or whatever. So, even just the basic stats, KPIs you'd be tracking, are different.

Netlify showed a 25% drop in page views over the month and a 41% drop in unique. But Fathom was showing the opposite.

Chris: Oh, it went up?

Dave: If I believe Netlify, I'm in crisis mode. I lost 25% of my traffic. Chris, 41% of my visitors are gone. Ah, Christ. Head on fire. Everyone is fired from Dave Rupert, LLC billionaire mega corp.

So, I've just fired hundreds, thousands of people from Dave Rupert, LLC over this gross misconduct, mistrust.

Chris: Yeah.

Dave: But Fathom is telling me, "Hey, we're doing good. The numbers are up, guy. We're up 25%."

[Laughter]

Dave: Who do you believe? That's ultimately what it comes down to.

00:41:59

Chris: I would say that, well, comparing across tools, it's just different. That's why only relative matters. But you're saying that the relative trends can be opposite, which that's even more just damning to the whole thing.

Dave: Alarming! And then I would tweet about it, and then got a bunch of tweets. Old people. [Laughter] "Yeah, we learned about this in the '90s. The numbers are just BS," or whatever. It's like, if you learned about it in the '90s, why are we still using it? [Laughter]

Chris: Yeah. You didn't evangelize the problem very well then.

Dave: And has it gotten not better since the '90s? I would think we're a smidge better than the '90s.

Chris: I would hope. There should be some kind of shared, collaborated upon blacklist or something for analytics tools.

Dave: Like a Kismet for analytics?

Chris: Because Google Analytics clearly filters bots, right? That just seems to be the vibe. I think they say they do.

Dave: Yeah.

Chris: And the numbers indicate that that would be the case. Well, could they share what they're filtering so that all analytics tools can use it and contribute their own, like, "Well, we've noticed that this isn't a real person either," and contribute to that. That would be an ideal kind of world if what gets filtered from analytics was shared between the analytics tools.

Dave: Yeah. I mean I think Google Analytics is probably pretty good at what it does, so I think you just have to figure out what are you looking for, who do you trust, what do you believe, and then how much trust are you going to put into it?

Chris: Right.

Dave: I find data incredibly interesting, and I want it, and I'll always have it in some fashion. But I think what I'm feeling is that there's just really no telling. You know? Right now, there's really no way to know or trust the machine. So, I think, for me, there are other metrics I could maybe invest in like likes and tweets and retweets (if I wanted to know my content performance), and so maybe something like Web Mentions is maybe even a better deal. You know? But, yeah, that's kind of my issue is, like, if you can't trust your data, who can you trust? And what's good data? What's a good signal, is kind of it. You know?

There's somebody tweeting about GitHub stars versus NPM installs and stuff like that. It's like a GitHub star means, hey, somebody went to the site and said, "Yes, I like it," but a download, an NPM download is like, "Hey, somebody has actually used this and installed this." However, a lot of the NPM installs are all CI driven and stuff like that, so those big hockey stick charts, that's just teams adopting it with no choice and CI is installing it. It's really not like a signal of, like, "Yeah, people are using this."

I guess it's like, "Machines have installed this," is sort of the -- you know. But it's not like, "Oh, man. Somebody is using this because they really love it." It's usually a sign that something got picked up by a big project.

00:45:28

Chris: Hmm. Magnus also asks. He says, "Chris, I remember you writing, mouth blogging, about not sharing page views with advertisers."

That's wrong, actually. I think that's reasonable. Back when I ran CSS-Tricks, that an advertiser would run a post and then they'd want to know how much traffic that post got. I would just tell them because I had Google Analytics on the site, and just look up how many visits it got and share that because it just seems like a reasonable request. It's all anonymized data. I'm not breaking any user trust I didn't feel) by doing that, and I think that's a reasonable request for somebody giving you money.

I also said that they could use a linx when they link out with tracking params on it so that their own analytics on their site, they could see the clicks that came from my site with that kind of situation because, again, that's just click on a link. Whatever. It's just how the Web works with a query parameter. I'm not sending a long data, secret data from their logged in database. I don't have any information I'm trying to share, so there was that, but isn't that interesting?

If advertisers care about me reporting that data to them, I should probably switch to Netlify Analytics, huh? The number would be a lot bigger. [Laughter]

Dave: Ka-ching, ka-ching. Yeah, I mean if I'm looking at Netlify data, I should just retire. I should go full-time blogger. Dude.

Chris: Yeah, so it depends on what you need this data for. What does it matter? Is it for internal decision-making, or is it more like people are getting paid based on those numbers?

Dave: Yeah.

Chris: Very different things.

Dave: I am in the camp like I think people should be able to get good data. It's just that the fallout is the second we allow cookies and third-party and tracking and stuff like that, people use it for bad, and that's just where it gets rough, so I'm not even sure you can trust any of it.

Anyway, good luck. Yeah.

Chris: Josh from -- yeah. Yeah. Good luck, for sure.

Another one from our Discord. Josh was--

Dave: D-d-d-d-discord.

00:47:50

Chris: He's a little -- sounds a little bummed about basically React and job hunting. I think Josh probably knows React fine. Although, I don't know for sure. I think he's kind of a Vue guy. Aren't you, Josh? I forget. Svelte?

Dave: Svelte? What's his games written in?

Chris: Oh, yes. Svelte. Svelte. Svelte. He's a Svelte guy.

Dave: He's writing games in Svelte. He's got a new one, by the way. We got a sneak peek in the D-d-d-d-discord. It's really good.

Chris: Yeah.

Dave: It's like a Wordle A-game.

Chris: He's quite the games maker.

Dave: Yeah. Yeah.

Chris: Yeah, so he's thinking about how Ubiquitous is everywhere. That you'd be irresponsible, he says, not to focus on React if your goal is getting a job. He's saying 90+% of companies hiring front-end devs seems to be using React in some way, and it makes him wonder are we are the peak of that. Is the peak going to stick around for a while. Is there anything looking to dethrone React?

I think it's important to distinguish when it comes to job boards and getting hired because it's easy to refute that React is king by looking at global usage data and be like, "Oh, look. Only this tiny slice of websites actually use React, but jQuery is on 75% of websites," or whatever. I've always kind of rolled my eyes at that because it's like, "Yeah, dude. jQuery ships with WordPress, and most of those websites are not -- developers aren't actively writing jQuery on those websites." Right? But in React, they probably are. You know?

Dave: Yeah. Yeah. Yeah.

Chris: And React, there are a lot of new projects in it, and new startups, and stuff like that. The picture is very different when it comes to getting a job.

Dave: For real, and you can follow the money. I think you can chase money and definitely be in a situation where you need money. Lots of people need money. [Laughter] Most people need money.

Chris: Hell, yeah.

Dave: I think knowing React is probably something you should do or have some kind of fluency in it. I wish I had more, to be honest.

Chris: Doesn't it sound silly? It's like, yeah, they're paying you because they want this particular thing. It's like if a railroad was hiring, and you're like, "Ugh. I only think planes are good." They'd be like, "That's fine. Then don't work at the railroad company."

Dave: Yeah.

Chris: Gees.

Dave: Yeah. I mean I will say -- this is anecdotal -- you look at the job market and stuff like that. But I do think if you're good at Vue, if you're good at Svelte, and if you're good at Web components, I think there are jobs out there.

I've tried to find contract Vue people, and it's kind of hard. To find people who are quality, trustworthy, have an Internet presence, and stuff like, it's hard to find those people.

I can't just hire somebody who is like, "Oh, yeah. I'm a Vue professional," and then I go to their site and it's just a bunch of Tailwind clones. I can't evaluate are they actually good at Vue - or something like that. But I think there are companies, very big enterprise companies, that are using Web components, and they'd probably love to have somebody who really kind of knew the ins and outs of Web components kind of straight up.

I think if you just look at the big list, it's like a lot of companies bought in on React because it really did have the best component model for a very long time. And it had a lot of backing, and I've even heard people say React won the framework war, so why would you choose anything different?

I've heard this fatalist viewpoint, too. It's just like, "React won. It's probably what you should use."

A lot of companies are just following into that same not trap but just like mental kind of like front-end is complicated. We're just choosing React because that seems like something that solves a lot of people's problems.

00:52:08

Chris: I don't know. It seems -- [laughter]. I use it and don't regret it.

Dave: See. There you go. Right?

Chris: I don't see what the big problem is, really. You know?

Dave: CodePen is not switching to Svelte? No?

Chris: No. There would be literally no advantages.

Dave: [Laughter]

Chris: Nothing against either one. It's already written. Leave it alone. It's fine. We'll do one more user one, and then we'll call it here. Right?

Rory Hendrickson is curious about CSS Houdini, which I don't think either of us have any real secret inside knowledge on or anything. It seems to me that they had a lot of traction, a lot of talk going around it, a lot of excitement and stuff. You know? Then all the excitement now is kind of focused on container queries, cascade layers, and other new CSS features have kind of overshadowed it.

I feel like I heard people talking just the other day. I can't remember who was talking about it, but they were kind of like, "Uh... It's kind of dead." You know?

Dave: Oh, man. That's bad news. I just put it on my website.

[Laughter]

Chris: Not dead like it's going to stop, but I get the vibe that the Web got out of Houdini what it's going to get out of Houdini.

Dave: Mm-hmm.

Chris: We got the typed stuff in CSS values, and we got the paint module. Maybe that's it. [Laughter] Tiny little other things. I think our typed custom properties, were they born out of Houdini?

Dave: Yes, CSS OM.

Chris: Yeah.

Dave: Yeah.

Chris: Maybe that's just what we'll get. Are we going to really get the layout mechanism thing? Probably not. Maybe not. You know? I don't know.

It doesn't seem like there are a lot of people working on it. There could be some research and submit, or something, but I don't see it moving at the moment.

Dave: No. I mean paint worklets -- that's what I'm using -- are pretty cool. The typed OM, CSS properties and values, I think that's where you can just define an app property. That's kind of in that type stuff, but you can be like, at property - whatever - --foo, and it's a string or something or it's a color or something like that. You know?

Chris: Right.

00:54:20

Dave: The one thing we kind of didn't get is layouts.

Chris: Yeah.

Dave: And adding to the parser. Font metrics API, I don't know if we have that or not. I don't think that ever showed up.

Chris: Yeah. Layout probably would have been a big deal, but we got Grid and Flexbox strapped so strong, and then container queries, too. It's like I don't think people are really--

Even like Masonry is part of Grid now, kind of. I don't know if it's--

Dave: Yeah, and it was kind of pitched as that was the layout thing, right?

Chris: Yeah. That was the coolest thing Houdini could possibly do. So, I don't see people like, "Oh, we need more powerful layout." I think, if anything, people are pretty sadden with their layout abilities on the Web at the moment.

Dave: You know animation API, Web animation API, I think we're getting scroll timeline and stuff out of that. Yeah, it's kind of the layout API is kind of the only thing that didn't come. But, man, with Grid and container queries and stuff, we are so strong right now. I don't think we need--

Chris: Yeah.

Dave: I don't need anything.

Chris: Maybe we just hang Houdini up and say that was a great idea. It pushed CSS forward. Thanks. So long, and thanks for all the fish. You know?

Dave: Mm-hmm. No, I mean it's worth noting my site does look different in Safari because they don't have the paintlets and stuff like that.

Chris: Oh... really? They don't do paint at all?

Dave: Yeah. No, they don't do paint at all.

Chris: Oh, that should get on that.

Dave: Yeah, hopefully.

[Laughter]

Dave: You know. What can you do?

Chris: It doesn't seem like hyper-crucial. I'm sure you used it in some progressive, fancy way. Right?

Dave: Oh, yeah. I mean it's almost like a background image. It's a canvas, literally. You know?

Chris: Yeah, I used it for the little speckles on CSS-Tricks for a while. Is that still there? It probably is.

Dave: It might be. But yeah, I used the speckles too. And then I used the hand-drawn borders because I was - I don't know - tired of the Web.

Here's what I like about Houdini. I'm tired of the Web being boxes and circles and really primitive shapes, and Houdini kind of opened this door up to where you could have rectangles and sci-fi rectangles. Chris, we talked about that in the D-d-d-d-discord.

Chris: I mean as long as you want them to be JavaScript powered, essentially--

Dave: Hm... Yeah. Yeah.

Chris: It ends up as a background. And what else can you make out of a background? SVG, images, whatever.

Dave: Mm-hmm.

Chris: Anything that it can do can also be done by an image, so I don't see the door being totally blown open to do new things because, in the end, it's just a background.

Dave: It's just a background, but you can program the background.

Chris: Yeah, right.

Dave: It's procedurally generated background.

Chris: That's why I look at the speckles, and I'm like, the speckles are cool but I could have just used a jpeg. I don't actually care that they're randomized [laughter] even though they are.

Dave: Yeah. Well, I think what I'm going to do -- if I'm going to do anything with it, I think I want to have seasons on my homepage. I think I'm going to have it change over time. You know?

Chris: There you go. See, now you're using programming. That's very of the Web, which is neat.

Dave: I can't remember if I shipped it or now, but I was going to make it change every day. I think it changes every day (a bit). [Laughter] That's really bad for my Percy integrations. [Laughter]

Chris: Yeah.

Dave: But the page changes every day (just a little bit).

Chris: Indeed.

Dave: Yeah. Well, cool. We got a fine question from the D-d-d-d-discord. Burritos versus tacos.

Chris: Oh, God.

Dave: You've got to choose, Chris. I'm eating a taco right now, so I choose tacos.

Chris: I'll choose burritos just to be contrarian.

Dave: Oh, man!

Chris: Says the guy who made a whole burrito website.

Dave: Mac versus Windows.

Chris: You know it's hard to get a good taco around here, I'll tell you. Dave, it's not nearly what you have to offer in Austin. Burritos are much more commonly produced for some reason.

Dave: Are you saying I need to ... 10,000 degree heat here in Austin, Texas. Move up to Bend and make a taco shop.

Chris: No. It's hot as hell here, too, man.

Dave: Oh, man. I'm sorry to hear that.

Chris: But yes you should, though. [Laughter]

Dave: Well, all right. We'll figure it out.

All right, well, 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 for eight tweets a month. We're really not bumping the Twitter, are we? [Laughter] But, hey, that's fine.

And then join us in the D-d-d-d-discord, patreon.com/shoptalkshow. We have a YouTube, too. I think we're going to do some videos now that we're all back from vacation and whatnot.

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

Chris: Oh, ShopTalkShow.com.