480: Pushing Users to the App, Browser Feature List, Notion Fun, and The Surprise Chain

Download MP3

Does forcing users from the website to the app make the web devs feel sad? How do browser devs decide what to add? Having fun with Notion, custom media queries, and Dave's epic Surprise Chain blog post.



Chris Coyier and Dave Rupert in silly sunglasses and a sign that says Shawp Tawlkk Shough DOT COM

Chris Coyier and Dave Rupert

This episode is with just Chris & Dave, ShopTalk Show's hosts. Chris is the co-founder of CodePen and creator of CSS-Tricks, and Dave is lead developer at Paravel.

Time Jump Links

  • 04:55 How browsers decide what to update
  • 12:18 Sponsor: HubSpot CMS Hub
  • 13:36 Notion fun with data
  • 18:56 Custom media queries
  • 27:53 View counter
  • 29:47 Sponsor: Netlify
  • 31:18 The Surprise Chain
  • 42:56 Unit test vs integration test
  • 47:22 Social media share images
  • 55:23 CSS Scoping


[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. A little more sultry than usual. I'm Dave -- velvet sheets [laughter] -- Rupert and with me is Chris -- satin pillowcases -- Coyier. Hey, Chris. How are you doing today?

Chris Coyier: I'm doing quite wonderful, really.

Dave: Ooh...

Chris: Actually, I really like this shirt I'm wearing. It's nice.

Dave: Is it rayon?

Chris: I don't know what it is - from Patagonia.

Dave: Oh.

Chris: A little mountain GUCCI. Love it.

Dave: Yeah. Nice! Well--

Chris: Ah... I've got one for you.

Dave: Mm-hmm.

Chris: Let's say you work at Reddit.

Dave: I do. Yep.

Chris: Well--

Dave: No, I don't. [Laughter]

Chris: Contribute to their success, certainly, the endless scrolling. Whatever. Everybody reads Reddit. It's amazing.

I know it's problematic sometimes but, for the most part, it's fine.

Dave: Do a lot of corners. Yeah.

Chris: Yeah. That's a good way to put it. You know? I'm not here to defend Reddit. I'm just saying I want to talk about something else.

Dave: Yeah.

Chris: Let's say you work there, and you work on the Web team, like you make literally the website and the mobile website too because, of course, you can visit on your Web browser on your phone, right?

Dave: Mm-hmm. Mm-hmm.

Chris: Have you ever done that?

Dave: I do it all the time. Yeah.

Chris: Yeah?

Dave: Yeah.

Chris: Okay. Here's what you're going to experience (and this has been true for years and continues to be true) that they hit you six ways to Sunday about using the app and not the website.

Dave: Use the app. Use the app. Oh, you wanted view comments; use the app.

Chris: Oh, constantly.

Dave: Use the app.

Chris: A popup will come up to get you to use that. The header of the website just has a big "Use App" button.

Dave: Yeah.

Chris: As you scroll down, sometimes there are things in the middle that say to use that. They really want you to use the app, right?

Dave: Mm-hmm.

Chris: You work there and you work on that website. Your job is to get people to not use your work. Isn't that a bummer?

Tim Holman talked to me about this one time, or I just remember it coming up in conversation, so I'm stealing his concept, though. Can you feel me? Wouldn't that be a bummer? Are they bummed out or do they also agree that you should use the app? What's that about?


Dave: I understand businesses, right? There's this idea, generally, and probably some data to back it up, that app installs create better, more dedicated users because you're bought into the app and the service. Then there's probably (on top of that) they can collect data better than they can with you and your ad blocker. You know?

Chris: Mm-hmm. Mm-hmm.

Dave: And so, they want to collect data on what you read and stuff like that.

Chris: I guess that makes sense, and they have to have it because it's a website with content on it, so you kind of want to have the SEO of having the website and stuff. I just think what a weird morale thing that would be to constantly -- like your job is to get people to not use your work. [Laughter]

Dave: Yeah. Yeah.

Chris: That sucks. [Laughter]

Dave: Yeah. I don't know. It's turning into a service where you have to be logged in to use it. For the longest time, I didn't even have a Reddit account or I had one with zero karma. I think I'm up to seven whole karma now.

Chris: Yeah. I have something like that too.

Dave: I couldn't even buy and sell mechanical keyboards because they were like, "You need at least five karma, you fricken' strange-o." [Laughter] And so, I was like, "Oh, shoot. I'll post some power washing videos, I guess." That's how I got around it.

Chris: Yeah. I have a photo of a snowball I posted or something.

Dave: Yeah. Then somebody is like, "Oh, like, like, like." Oh, cool. Karma.

Yeah, I think you need some safeguards for a community, like people to be logged in. But the relentless pushing on the app is so weird because, Chris, I'm going to put some money down and probably say, guess what, it's probably just like a React App [laughter] that's been phone gapped. The native app is -- you know.

Chris: Yeah.

Dave: I don't know. Maybe not.

Chris: Maybe the people that work there don't care because they kind of work on both.

Dave: Yeah.

Chris: Yeah.

Dave: Then Reddit, too, it's such a big thing. You go to some subreddits and it looks like it was made in 1995. I think they opted out of the upgrade skin or the new experience and stuff like that. You know, I don't know. I'm sure it's a hard website to work on, so that's what I'd say.


Chris: I'm sure, and I don't mean to dwell on it. I just thought it was kind of an interesting situation because I also saw a tweet from Emilio yesterday (who works at Mozilla) where they are working on CSS Layer Rule. I think we've talked about this a little bit on the show where you declare a style sheet order. Even though it's the seventh one loaded, you could say, "Behave like this was the first one loaded."

Dave: Mm-hmm.

Chris: And ones come later, which is a clever ability. I'm not sure I wrap my head around it all the way, but it's interesting to me that Mozilla picked it up first. I think this is a brainchild of Miriam Suzanne, of course, who has been all over the CSS stuff recently.

Let's say you worked at Firefox as a browser engineer, which they still have even though I thought they fired a lot of them, but maybe not all of them. I don't really know how that's working, but they still are shipping updates to Firefox (the browser). So, obviously, there are still plenty of engineers there doing that.

Dave: Yeah.

Chris: What they could do at Firefox is just feature parity with Chrome stuff. You've mentioned in the past that they're kind of getting DDOS almost with features, which feels fair because Chrome moves super, super-fast, and they're implementing all these origin trials and new specs. It's rockets pace over at Chrome, and there's no way Mozilla can play that game with Firefox.

Dave: Mm-hmm.

Chris: What they could do is pick the biggest stuff that Chrome is doing and just get on and do that. But then they're just constantly in the footsteps of Chrome. And it seems like they don't do that, which this is the thread that ties it to the Reddit thing. They don't want to be on a team that's just telling somebody to use something else or in the footsteps of something else. I don't know this to be true, but it seems like they occasionally pick features that Chrome doesn't have.


Dave: Yeah. Possibly. They try to be first there and then they look like a market leader in some aspects, and then they'll backfill the rest, or maybe it's part of how the code works.

I've just been going through all these issues on this project, and being like, "Oh, wait. In order to do this one, it's blocked by this one," like this other idea.

Chris: Yeah.

Dave: Maybe it's like if they unlock layering, they unlock scope styles really quickly - or something - because that becomes like a pseudo layer - or something like that.

Chris: Yeah. You almost guarantee there's some stuff like that going on, right?

Dave: Yeah, I would think they stack rank them.

Chris: What browsers choose to work on, they're just people, right? If there's some engineer that's particularly excited about a thing and makes a case for it, and they get sign-off from a manager, there's a lot of people stuff happening, surely, with what features get picked to work on.

Dave: Yeah. Well, that's what I've been doing. We have all these features for this app we're building kind of mapped out. I've been building these things.

I went to Notion VIP. Are you familiar with that site? It's kind of like a Notion power user company. Anyway, there's this call, Marie -- and I'm going to blank on her last name or say it wrong, and so I don't want to do that. [Laughter] Anyway, Marie, she kind of has a lot of posts on how to categorize features and stuff like that. There are two matrices that you can use.

The Eisenhower matrix is, "Is it important and is it urgent?" For every feature, you say, "Is that important? Is it urgent?" Yes or no, yes or no, yes or no.

Chris: Yep. Yep.

Dave: Bugs are urgent, maybe, right? Then there's this other matrix called the impact versus effort.

Chris: Oh, I like it.

Dave: What would the impact be here: high, medium, or low impact? Then what is the effort? Is it high, medium, or low effort?

Chris: Mm-hmm.

Dave: You see how those kind of go against. Ideally, you're trying to find your high-impact, low-effort tasks and do those first. It gives you this whole matrix. Basically, if you think of a grid - whatever - a 2x2 grid or something. It's like, "Which quadrant does this task sit in?" It's basically how you get there.

Chris: Yeah. Not to complicate this, but I've broken it down one more step in the past. What did you call it? Impact?

Dave: Impact. Yeah.

Chris: Yeah, that the impact can be split in half. Is the impact really good for users or is the impact really good for business? Those are sometimes (and a lot of times) the same.

Dave: Mm-hmm.

Chris: And sometimes not because sometimes it could be something like advertising related, which no users -- like if anything, it negatively impacts users.

Dave: Right.

Chris: Users don't want ads. But it can be really good for business, so I kind of split in half because sometimes business concerns.

Dave: No, because you could totally have that. You could have two of those. I do this all in Notion. You could have two columns, and it's like the total user impact and the total business impact. You could be looking at those two things. I'm sure - whatever - users want sub-second Sass compilation. [Laughter] And so, yeah. Heck yeah, I want to do that. But I also need money to make that happen because we have to buy servers.

Chris: Yeah, I like it. That's a cool way to organize what you're going to work on next. You think browsers might do the same kind of thing. Almost surely they do. Yeah, there are just a lot of factors that go into deciding what you're going to do next.

Dave: Mm-hmm.


Chris: Some of it is emotional and some of it is just what you feel like doing. Some of it is because it's a blocker. I would put that on the Notion board, too. Does this thing block? Is it blocked currently? If I do it, does it unblock other things?

Dave: Yeah.

Chris: That can be huge, even if you don't want to do the task but it unblocks five other things. Well, do the task.

Dave: Yeah, so we were trying to figure out how. The big question is, how do we do ten installs of this application for companies - and stuff like that. We could kind of go the Basecamp route. You just sign up for an account, pay $9 (or whatever). We don't really want to do that.

How do we get multiple teams or multiple organizations on this? We're figuring this out, but part of that is -- guess what -- our test suites are bad. And so, I have all these tests. Now, tests are a blocker for the deploy-o-matic machine that we need to build. I have some degree of confidence, but I want really good confidence that we're not just shipping broken clones out everywhere. It's a lot.

Chris: Yeah.

Dave: Testing has been really interesting but really frustrating. Yeah.


[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by HubSpot, specifically HubSpot's CM Hub. It's a developer-friendly CMS designed to help businesses grow.

HubSpot launched a new tier called CMS Hub Starter for $25 a month. Hub Starter comes with all the features needed for fast, secure, reliable websites, including SSL, a firewall in front of it, globally hosted CDN - all really good stuff.

A lot of CMSs can be rather opinionated about how you then build the site around the CMS. Well, not CMS Hub. You're still building locally, even though this is cloud hosting, the CMS is in the cloud, and all that. You're still building locally with all these tools and the frameworks you prefer. So, however you like to build websites as a front-end dev, you can do it.

From there, if you want to upgrade to CMS Hub Pro or Enterprise, for more advanced functionality and develop sophisticated user experience using stuff like personalization (which is pretty rad) and dynamic content based on CRM data (also very fancy), those kind of features are on higher plans. Learn more at

[Banjo music stops]


Chris: I think Rachel put this on some of our Notion boards where we do a lot of Kanbaning.

Dave: Mm-hmm.

Chris: Then we use a master Kanban that has Kanbans within it. I don't know. It's all very--

Dave: Yep.

Chris: It feels very Notion VIP, how it's all set up. It's pretty neat.

Dave: Yep.

Chris: But there's this one extra. You can have an equation field.

Dave: Oh, yeah.

Chris: In Notion.

Dave: Yeah, yeah. Totally.

Chris: I put some screenshots so you can see in there that you can make ASCI art of how complete your Kanban is.

Dave: Mm-hmm.

Chris: You could see the equation there as a screenshot. It's all very, very fancy, isn't it? It's basically like you're writing JavaScript in there that counts how many cards are completed versus not completed and makes a little bar chart.

Dave: No, it--

Chris: It's about the fanciest thing we've ever done in Notion, I think.

Dave: I just did something similar. I just was like, I started rolling out OKRs. It's dumb. I don't even know if I've bought into the methodology, but I was just like, "Hey, here's a number." Now it becomes a video game. We just have to fill up the chart, get the chart to the 100% line.

The whole idea is, we have something we want to do. You break that up into - whatever - two, three tasks. But then you get, I guess, smart goals, like empirical kind of endpoints.

Chris: Yeah.

Dave: Like done and not done would be zero and one. You want to get to one. But then - whatever - if it's like we want five customers or we want to make our first $1,000 or 10,000 monthly recurring revenue, you could map it. You could just say, "We need ten paying users," or whatever.

Chris: Then the idea is that you actually -- sometimes, they're called a North Star Metric, right? There are phrases that go with it, like you work on what you measure or what measure gets managed, and stuff like that.

Dave: Yeah, measure what gets managed, measure what matters.

Chris: Yeah, but it's kind of true, right? If you're looking at that number all the time, it tends to influence your decision-making. It ought to.

Dave: Yeah, well, and the goal -- I'm not really trying to roll out a methodology or scrum my coworkers or nothing, but it's just sort of like, "Hey, here are a lot of--"

I like to put this stuff in there just to say, hey, there are a lot of ways we can shape the things we need to do and what we're trying to do. But if we can all agree these numbers are kind of correct, we want people to be using this, we want customers, and we want to be making money, great. Let's go." [Laughter] That's what we need to do. You can see that number is currently one and it needs to be ten. Let's go. Let's make it ten. Let's figure out how to make it ten.

Chris: Yeah, and not have too many of them, too. That's the other thing, right? You could think of 15 of these metrics, but you shouldn't do that.

Dave: Yeah. Yeah. You should only do whatever. Then your tasks, your features or tasks should support those metrics. That's the big OKR tree, right? All the teams. So now, as the engineering VIP, VP, CTO -- I'm a CTO now -- as the engineering lead, now I need to make sure all my tasks support the - whatever - get installs.

Chris: Yeah. It works with multiple levels of management, right? If I can say, "Hey, there's a manager over here. Technically, you report to me. But I'm giving you lots of leeway. You do whatever you need to do, but I don't have to manage every little task that you do because I've given you one task. It's an OKR."

Then, at the end of this sprint, quarter, or anything, I can be like, "What did you do to influence this OKR?" If you give me a bunch of stuff that's not related to that, I can be like, "Ah! You failed."

Dave: Yeah. [Laughter]

Chris: "You didn't do the thing that I asked you to do. I gave you lots of freedom with one North Star and you didn't point your crap towards the North Star." I think that works. It helps. It makes management easier - in a way.

Dave: Yeah.

Chris: That's a nice way to work. I don't work in a situation where there are levels of management like that.

Dave: Yeah, well--

Chris: Oh, well.

Dave: Yeah, and that's the thing, too. Sometimes, like in client work at least -- this is all my product brain and then my client brain is kind of two different brains right now. Client stuff is just like, "Hey, I woke up this morning, and I was thinking about this. Now it's important." [Laughter]

And so, you're like, "Oh, great. Let me shift." You know? That's kind of the hard thing, too. Everyone has to be kind of bought into the same system of, "This is how we prioritize," or "This is how we metricize." Everyone needs to be bought into it.

Chris: Mm-hmm.

Dave: If they're not, it's just loudest voice wins, which kind of stinks.


Chris: Well, speaking of things browsers should prioritize and work on--

Dave: Yeah. Hit me.

Chris: I have a note about custom media queries, which seems like, at this point, a little weird that you can't do it. Custom properties are everywhere. I use them pretty liberally. The more you use them -- I think this is an interesting thing that happens, too -- you don't really know something until you use it a bunch. You think of properties like, "Oh, cool. I'll replace my Sass variables."

But then the more you use and think about custom properties, I find the more opportunities there are to approach styling in a different way.

Dave: Mm-hmm.

Chris: Anyway, I don't have a great example of it but, yeah, I use CSS Custom Properties a lot. Great. You'd think you could set max-width 880 pixels and then use that in a media query, and you just can't.

Dave: Right.

Chris: It's like, why? It feels like custom properties themselves feel like that's more complicated than just a media query would be.

Dave: Mm-hmm.

Chris: I don't know. I don't know the complexity at all. Maybe they are ten times more complicated. I don't know. But there is a spec that's spec'd out for custom media queries. It's a little bit different of a syntax than regular custom properties are. You still use the double dash to name stuff, but there's an @ rule involved.

Anyway, but why. I'm not asking. This is just a rhetorical question. You don't have an answer, I'm sure, but it does seem like, "Hey, browsers. Let's do it."

Dave: Yeah, so it was like a Stefan Judis who kind of rang the bell this week, just like, "Hey, you know how you want to use custom property and media query? That doesn't work. But there's actually a solution out there that does work. It's in a spec. It just is not acted upon."

I agree. It would be very cool because the syntax--

Chris: There's stuff that gets acted on much before it's a stable spec. You know?

Dave: Yeah.

Chris: It just seems like a little forgotten. Hence, all this board stuff. What's the internal Kanban of what you choose to work on and what are the metrics that make this one so undesirable?

Dave: Mm-hmm. Yeah, no because syntax is pretty cool. It's like @custommedia, so that's browsers that don't support that, we're just going to ignore it. Right? Then you do dash dash narrow window. That's a custom property, right?

Chris: Yeah.

Dave: Max-width 30M, okay, so that's your media query. Then you'd say @media (--narrow window.

Chris: It's a perfect syntax. It makes perfect sense to me. Yeah.

Dave: Then the browser that doesn't get it is just going to say, "I didn't get that. Bye." [Laughter] If you're using max-width media queries, guess what -- or sorry -- min-width media queries, so your mobile first-ing it, guess what. They just get the mobile viewport. It's fine. We're good. We love it.

Chris: Yeah.


Dave: This would be cool. Sometimes I do think I don't have this problem. Maybe I do write a lot of media queries, but I don't--

I know you wrote the baby bear, mamma bear, papa bear post on these named breakpoints, and I totally agree, but I only use a handful. I don't know. [Laughter] I don't use it a lot.

Chris: Yeah. I see.

Dave: But I think it would be cooler in custom or element query land, too, because I think that's an issue as well.

Chris: I wonder if they're less dynamic. I wonder if they behave more like environment variables than they do custom properties. The idea with custom properties is that they're super dynamic, cascade, and all that.

Dave: Mm-hmm.

Chris: And that they can literally be changed at any time and, thus, the waterfall of changes.

Dave: So, these become more static. Yeah.

Chris: Are they? When could you change a custom media query? I guess you could override it through, and another style sheet could say, "Oh, no. Actually, the small viewport is 50M, not 30M," or some crap like that. But then it's still rather static. It just replaces all the--

I'm just thinking in the context of Polyfilling it. If they're super static and don't really behave like they can be changed at any time, it's the world's easiest thing to Polyfill.

Dave: Mm-hmm. Yeah. Yeah, I'm kind of -- hmm. I'm trying to read....

Chris: There's a Post CSS plugin for it, so that already exists, of course. But I don't -- I hate to say this, but I don't always trust. I don't just look at a Post CSS plugin and be like, "Oh, problem solved. It's Polyfillable," because there's some stuff that you can't really Polyfill by just processing CSS. There needs to be JavaScript involved or something. There just does. You know? [Laughter]

Dave: Yeah. Nah. Yeah, I mean if it's already in Post CSS, you could just kind of use it, right? That might be kind of cool. [Laughter]

Chris: Yeah, and that implies to me that it's static. Because it's getting processed out that there is no opportunity with this particular syntax and spec that it remains dynamic through the lifetime of page.


Dave: That's a huge namespace collision. If my ad vendor comes through and renames - whatever - carbon ads-green - or whatever - it's not going to conflict with my green, probably, if they namespaced it. Hopefully, all third parties would namespace this stuff, but you know. If some third-party thing comes in with papa bear custom medias, that would break my thing.

Chris: Yeah. Oh, that's true. Yeah.

Dave: But, you know, namespace....

Chris: I also think of the thing that always gets pointed to with problems with CSS stuff like the parent selector and container queries and all that is the loop, the infinite loopy problem.

Dave: Mm-hmm.

Chris: I imagine this is that times ten because, if you dynamically change a media query, there could be thousands of rules that get invalidated or validated immediately. Do you think that's going to cause some flow action on your page? Yeah, it definitely will.

Dave: Yeah. Yeah, if it just comes in eight seconds later and redefines all breakpoints. That would be kind of a problem, but you know.


Dave: Whoops!

Chris: I don't know, so I would process this away. I think it feels okay to me to just send it through the Post CSS machine.

Dave: Yeah.

Chris: And use it, especially because, at some point, then the stage changes and it stops processing it because it doesn't need to anymore.

Dave: Mm-hmm.

Chris: When I say Post CSS, I really mean Post CSS using exclusively the postcss-preset-env, not just whatever plugins you choose to run. That's what's always turned me off about postcss-preset-env it's just a bespoke little processors, which is kind of fine but it never goes away. It's not this promise that you're writing future CSS in which someday it stops processing those things. It's just locking you deeper into using a processor.

Dave: Yeah. That's -- yeah. That's part of the reason -- I mean what's weird is I don't really use Svelte. Svelte gets really hot in the D-d-d-d-discord right now. But it's because I was like, "Ooh, I don't know if I want to depend on that compiler for the rest of my life." But I depend on the Vue compiler, so I don't even know what I'm talking about. For some reason, I'm cool with Vue, but then I've got hang-ups about Svelte.

Chris: Exactly, like your brain isn't wired up right. Mine isn't either.

Dave: Yeah.

Chris: Some things, I'm like, "No, I can't do that," and I can't seem to get my brain to reevaluate it. [Laughter]

Dave: Yeah, and if you use React, which is very common, you're very dependent on the JSX transpilation and stuff like that.

Chris: Yeah. Babel is even more widely used.

Dave: Yeah.

Chris: It's in the same spirit. It's like, "Use future JavaScript today," and everybody is like, "Okay." [Laughter]

Dave: Yeah.

Chris: Postcss-preset-env is, "Use future CSS today," and my brain is like, "No!"

Dave: [Laughter] No.

Chris: Dangerous.

Dave: No. No. But I'm totally going to use whatever, this weird one-off JavaScript proposal. I'm totally using that. That's absolutely -- I'm signing up for origin trials - absolutely.

Chris: [Laughter]

Dave: But this random CSS?

Chris: Yeah.

Dave: Please, no.


Chris: You never know. I wonder if this -- it looks like Stefan's article, he's got a view counter on it. How classic. Three thousand three hundred and eighty-seven views at this moment. Pretty good. Pretty good turnout for this thing. It's a little pooper of an article. I don't know how it compared to other things that he's wrote, but you never know how popular an article is going to be. Do you, Dave?

Dave: No. Well -- [laughter]. No, never. [Laughter].

Chris: [Laughter]

Dave: Even articles you spend years on, it's almost inverse. There's an inverse law of blogging there.

Jon Kuperman, he used to work at Adobe. I'm not sure where he's at now. He wrote a little view counter on his site using serverless functions. He's like, "This is awesome!" [Laughter] Very quickly, he ran out of service minutes, or whatever. He was just like, "Oh, no! I have--"

Chris: Oh, because it's a serverless function?

Dave: Yeah. Yeah.

Chris: And then you only get so many invocations of that for free.

Dave: Yeah. Yeah, like 700 a minute or whatever it is.

Chris: Whoops!

Dave: He was just like, "Uh-oh!" [Laughter] Uh-oh. But you've got to be careful with those view counters.

Chris: Yeah. I wonder. What's the cheapest way to run a view counter? I know in the early days at CodePen, we tracked views. We knew not to put it in MySQL because that's a heavy write situation.

Dave: Yeah.

Chris: Or maybe we did at first, but we batched them somehow and didn't write -- it's not like the page loads and we immediately triggered a MySQL query to increment the thing by one.

Dave: Mm-hmm.

Chris: I think, ultimately, it's like that's what Redis is for. Redis is much faster and happier at that type of usage.

Dave: Yeah.

Chris: I think our views is just a Redis thing, and sobeit.

Dave: Yeah. Well, isn't that you need another appliance to make the simple thing work. That's sort of the law of website building. You need another thing to make the simple thing work.


[Banjo music starts]

Chris: This episode is brought to you in part by Netlify. High-five, Netlify. Really changed the game on the Web in a lot of ways.

Every site on Netlify is Jamstack, right, because it's static. That's the kind of hosting that they offer, but then has dynamic features that Netlify makes easy, like processing your forms, running your serverless functions, or helping you with Auth. They have all kinds of integrations for data and stuff. Very fascinating. That's what Jamstack is, really, is the static hosting base with services on top of it and ways to live in that world but make it dynamic.

The DX of it all is just so good. That's what's really changed. It's like even if you didn't care about Jamstack, if you didn't care that it was CDN hosted, fast, secure, and all that stuff, I think it would be worth using the Netlify platform just for the fact that you get deploy previews. Alone, that's just an amazing thing.

You have a PR against master and Netlify is like, "Oh, I'll show that to you. Here's a link. Just click it and see exactly what your production website is going to look like if this gets merged and deployed." That's amazing and just not something that other stacks really offered up until then. You know? I just like it.

Netlify was the first. They keep making it better and better and better with more integrated feedback and stuff like that. But I almost am waiting for the rest of the world to catch up. Anything that you work on that isn't Netlify you wish was Netlify so that you just had deploy previews alone.

Anyway, a little tangent there. Thanks for the support, Netlify. Bye-bye.

[Banjo music stops]


Chris: So, what is it? It's The Surprise Chain article you wrote, which is tremendous. It's a history of Apple. I expected it to show up on Daring Fireball, but maybe it just didn't cross the Gruber desk.

Dave: Gruber doesn't follow or subscribe.

Chris: Read

Dave: Yeah. Yeah, so The Surprise Chain, it's just something I've been thinking about for a long-long time, and probably since 2014, '15 when I switched to Windows.

Chris: Yeah.

Dave: It was like, "What makes Apple good?" You know? I think a lot of people think back to the iPod and the iMac and the iPhone. That's what was good.

But for me, I worked at Apple, in Apple Care, for this brief period in 2003, and that's when I switched to Mac and got my first iPod and stuff like that.

Chris: Mm-hmm.

Dave: But this was kind of like a weird time where Apple was switching operating systems. Then those weird Macs with the lampshade arm - or whatever--

Chris: [[Laughter] Yeah.

Dave: You know the iMacs came out. Then I remember a girl in my dorm got one of those pink iMacs with the see-through--

Chris: Yeah. Hell, yeah.

Dave: It was just like, "This is a weird computer, but it's kind of cool. But it's weird." You know?

Chris: Yeah. It wasn't just weird. It was kind of good, too. At the time, the specs were pretty darn acceptable for a college student, for sure.

Dave: Kind of okay. Yeah, for a college student. My roommate had an old power PC thing and it was just garbage. I just was like, "Good luck, dude," and he had to buy special software for it. I'm just stealing crap off the Internet for my Windows, my Gateway 2000 machine.

Chris: Mm-hmm.

Dave: So, I switched to Mac and it was going. It was kind of a weird time, but what was cool about that time was (every couple of months) Apple released something new. I just remember that time. I was like, "You know what? I'm going to go back and research that."

I went through all the screenshots of the homepage. I went through Wikipedia and Mac World articles and stuff like that. I mapped it out. There were some old Power PC things, but I really wanted to get to the new edge hardware, like PowerBooks, iMacs, and stuff like that. That starts around 1998.

Chris: Mm-hmm.

Dave: Where they start launching cool stuff. I went through, and it's like every month, two months, they're just launching something new, launching something new. "Oh, this got a major upgrade. Oh, this is brand new. Oh, this is new in a different color. Oh, this is - whatever - the new OSX is out." Oh, cool. Now we also have iTunes, and we have Office for Mac. That's a huge thing.

Then guess what. We have Apple stores. We have a new PowerBook. We have a new version of the operating system. We have a new Final Cut.

Chris: Yeah.

Dave: It just keeps--

Chris: It's exciting, but it was also surprising, right? You didn't know that those things were coming.

Dave: Yeah.

Chris: So, it was just like, "Whoa!"

Dave: You could probably be like, "Oh, they're probably going to update the calendar pretty soon." [Laughter] You'd probably be like, "That's going to happen." But it was just like a surprise.

No one saw the iPod coming, really. Maybe people did. But just like, boom, guess what, iPod. Before that, they kind of mastered iTunes, right? They were like, "We're going to have a vehicle for collecting your music because that's important to people."

Now, boom, we have an iPod, and it hooks up to your iTunes, and you plug in the iTunes to the iPod. Just really cool.

Chris: Awesome.

Dave: They just--


Chris: The point is, that's a good thing, right? There were surprises and then they worked out, too. Maybe not forever, but they were exciting. The press followed them. People bought them.

Dave: I think it keeps you in the zeitgeist. It keeps people's attention and eyes on you. If you contrast this to Windows at the time, Microsoft was doing nothing. They had maybe NetBooks. They had maybe, I guess, Internet Explorer releases, maybe. [Laughter] You know? Vista, I guess, technically came out in this time.

But it was just kind of like those weren't planned. They didn't come out in a cadence. There wasn't any sort of build-up or eye movement towards them. They weren't moving, and then they just kind of show up. They're like, "Hey, I did this!" You know? No one was watching that, and so I just think there's a huge effect, a compounding effect of being able to ship tiny little improvements or little features here, little features there, or whatever. I think there's a cumulative effect on your company, and so I just meditated on that.

Chris: You could plan for it, too. That's what I take from this, too. What could I do to make sure that the pace of surprise and, "We're shipping something that's for the people," happens, and that we don't do three things one month and then nothing for eight months and then two things? That more like every two months we're shipping something that we clearly can put on a silver platter for people.

Dave: Yeah. I mean maybe it's kind of what we were talking about earlier in the show. It's like looking at your feature board and then saying, "If we put this in order of importance - or whatever - could we get them out?" Then maybe you hold off on a release so that you hit the next cadence. You don't launch your - whatever.

I know lean and everything is like, "You just put it out there." [Laughter] "Get feedback." I'm totally into that, but I think there's a cadence, a breadth, a step of your business. You really can create that effect, and I think it has a social and mental impact on your users.

Chris: I like it. I think more people should read this. It's a bummer that you consider it a dude of an article because of reach and engagement and whatnot. In some sense, it doesn't matter. I think people will be thinking about this for a long time to come.

Dave: Well, thanks. Yeah. No, it's just kind of like this -- if you look at it and you think of things you like, it's usually people who were on a cadence.

Marvel movies, they did two a year, and so you just had a cadence that you're going to go see two Marvel movies a year. Now they do three or four.


Chris: Yeah. What do you think about video games? Apple is hard. Not all of us can release major hardware and software and all this stuff. We have limited ability to do that. But features can be that.

What about, how do you think about Nintendo or PlayStation or whatever? Surely, they schedule game releases with this in mind - to some degree.

Dave: Yeah. I think they have. The average video game takes two years to make - or something like that. But they probably have a few properties in their wheelhouse, like Nintendo has Mario Party, Mario Cart, Super Mario, Zelda - I don't know - Kirby, Super Smash Brothers. They have a few games in the wheelhouse, so they can kind of be like, "This game should come out this quarter. Let's rough this game in." If you miss a ship date, that's kind of a big deal. But maybe you need to figure out what's our backup, easy path if we miss one. Maybe that's something like you acquire somebody or something else.

One of my examples I use in the post is Devolver Digital. They're just a publishing house, so they chip money in and help your game get reach, get on platforms, and stuff like that.

Chris: Oh, they're not -- interesting.

Dave: I think they built games, too.

Chris: Oh...

Dave: They have probably a development arm, but I think a lot of their stuff is just like, "Oh, you're a small indie game shop. Let me help you be a very -- let me give you a big distribution, and so we'll take a cut."

Chris: Yeah.

Dave: It's kind of like the music industry style or whatever. But that's great for the indie developer because they don't have the marketing team. They don't have the press releases. They don't have time to do that and spend time on that and stuff like that.

Chris: Hmm.

Dave: That's awesome.

Chris: Interesting, so they've got to agree to take a cut, certainly.

Dave: You probably have to agree to take a cut, but you weren't going to get big.

Chris: Right.

Dave: So, you jump on the big horse and go fast. [Laughter]

Chris: It's like VC for video games.

Dave: Sort of, yeah, I mean in a way. But the thing about Devolver is they're always at the top of the conversation about indie games. They basically kind of own the space or own a portion of the space. You know?

Chris: Yeah, because you don't forget about them, right?

Dave: You don't forget about them.

Chris: If you forget about them for a second, next week there's a new thing, new game.

Dave: Yeah, and they do a really good job of teasing, but then they follow up. That's kind of the thing. Two weeks out, they drop the teaser. Then they're like, boom, the game is available in every, like, Steam, Switch, and stuff like that.

Then the last one is Playdate. I don't know if you've been following Panic. We love Panic here. Coda, they make Coda. It's now called Nova.

Panic has a new game console called Playdate. And what's cool is they're kind of--

Chris: The little crank thing? I think I bought one just because of FOMO.

Dave: The little cranky boy. Just because of FOMO.

Chris: Yeah.

Dave: Well, it seems awesome, but kind of the core principle of it is it's a subscription service. You buy the little device. You don't put little game cartridges in. You pay for a subscription, and a new game comes to your Playdate every week.

Chris: Hmm.

Dave: For like a season. They're kind of doing TV show season styles, and so it becomes kind of this limited time. That's kind of an interesting thing. But it becomes this sort of like, "Oh, you didn't know what you were getting. But guess what. It just showed up." You know?

You get these little -- you're building surprise into the product, and I think that's kind of a cool way to do it. I don't know. You've kind of planned out, okay, we're going to do a season of features, and we're going to launch these features every six weeks - or something like that. We just have a cadence.

If you think about Chrome the browser, why is Chrome cool? Because it just released every six weeks, eight weeks, or whatever. They've gone from version zero to version 95, I think we're using now. Incredible.

The cadence matters, I think. If things appear to stall out, I think users subconsciously feel that.


Chris: Yeah. You mentioned testing just a little bit. I'll segue into a question from Jose Blanco who writes in, "There's been some debate on my team about unit tests versus integration tests. What do you think about it? Do you think that everything should have a unit test?"

Dave: Oh, my god. Literally, for the last week, I've been writing tests.

Chris: What kind?

Dave: Mostly unit.

Chris: Yeah?

Dave: Partly because I can't get the integration test to work. [Laughter] For whatever reason, Playwright or whatever is taking a big dump, or the interface in which to run a Playwright and stuff like that is all kind of -- I don't know, man. Testing still frustrates me, but I will say I'm learning a lot. Even looking at code, there's a lot of code. I'm like, "Ooh, this could be better," or just simple, or Jest will complain about a method missing or not being covered or something like that. I'm like, "That probably doesn't even need to be a method. That just is a ternary." There are ways to simplify code and stuff like that.

Chris: Unit because they're almost easier to write because there's less that can go wrong, and that's kind of cool. I think there's a lot of value, and you can write a lot of them. They run really fast.

Dave: Mm-hmm.

Chris: It can get your brain thinking about, sometimes when you fix a bug, you do that thing where you just write the test first and then make the code fix it, and then ship it. Then not only did you fix the bug, but you made it more resilient for the future. No shade on unit tests. Pretty cool.

Dave: Mm-hmm.

Chris: I have always kind of thought if you had one integration test on your website, pick the most important thing that your app does. Write one integration test, not 50.

Dave: Yeah.

Chris: Just run it all the time and get it running in CI. That's so great because there's no real equivalent here, but to me, it's like the equivalent of 100 unit tests kind of thing because a ton of crap is going right on your website if your one integration test passes.

I guess they call those end-to-end tests, too. I don't know quite -- I think integration tests UI, but just tests one thing.

Dave: Yeah.

Chris: I guess that's the vibe of it. I guess I'm more talking about end-to-end tests.


Dave: Yeah. That's what's confusing, too. There's a lot of jargon that goes around tests. I felt like the last week was really just like, "What does this want?" I'm kind of in a weird, like, I'm within the construct of a Nuxt component. That adds some weird bits, just like, "Oh, guess what. Your Nuxt plugins didn't load." It's like, "Well, how do I get that mocked in there?"

The solution is always like, "Just mock it as like an empty function." I'm like, "I don't think that's testing." You know? [Laughter] I have this purity thing.

But I think I'm acclimating myself to it. I don't know why my intent tests aren't running, but that's a totally other problem, but I'll figure that out as I continue to code. I don't know.

The strategy I'm using is a lot of spec tests. Sorry. What are those called? Unit tests, specs, for my components because, ideally, your component takes a thing and does a thing. Like, okay, it takes a post and it spits out a post within H1. That's kind of stuff you can easily kind of write tests for. That's what I'm finding. It has this class fubar because I need class fubar or else the whole thing doesn't style - or something like that.

Chris: Yeah.

Dave: I'm enjoying stuff like that. If there are any accessibility features, they're pretty easy to test for. But I think the end-to-end is more for the page level stuff if you're like, "I want to make sure I go to this page, and I want to make sure it exists. Then I want to make sure that page - I don't know - you can click around on it or whatever. You can click this button, and then you'll go to this page."

Chris: I agree. All the tests are valuable. We can't possibly answer which one is more important to you and your company, Jose, by just declaring it to be so. But I think you have the information you need to make that choice, I'll say.

Dave: Mm-hmm. Mm-hmm.


Chris: You know we've talked about social media cards or open graph images on this podcast quite a bit because I was a little obsessed with it for a little while there. My favorite way is some kind of Puppeteer Playwright-based way to do it because it's like then you can use SVG or HTML and CSS and just template what you want it to be like. Wouldn't that be cool? That's the way to go, I think.

But of course, not everybody has access to something. It can be cumbersome. It can be tricky to pull off just right. Anyway, it just didn't feel like that was the right path for me on CSS-Tricks, although maybe it will be someday. I don't know.

I think I was talking about it in the old Discord, and Andy Bell is in there. Andy was like, "Oh, you should look at this Daniel Post guy's WordPress plugin." They must know each other somehow.

Introduced me to Daniel, and he had this plugin called Social Image Generator. He bought It's just a WordPress plugin, so this doesn't solve this for any other platform, but it looked pretty cool.

It looks like, "Here, these are templated cards." You can pick from a bunch of different themes and customize them. When you publish a post, you get that card. It's just exactly what I wanted.

Dave: Mm-hmm.

Chris: Images are involved and stuff. It's just that the templates aren't HTML and CSS. The templates are -- and Daniel had to do it this way because WordPress sites don't have a way to spin up Puppeteer. You know?

Dave: Right.

Chris: That's not going to work. He could have made a cloud service or something, but that's not the spirit. I think that this is much more of the spirit of WordPress. It's a plugin. You install it and it works.

Dave: Mm-hmm.

Chris: So, Daniel's templates use PHP, like ancient PHP methods for image generation, stuff that's just built into PHP that's just been there since the dawn of time - kind of thing. It does fine. It can use custom fonts. It's cool.

If you want to then design a custom template, then you need to learn this, which is a tall order. Fortunately, Daniel helped me with mine for CSS-Tricks, so I didn't have to learn the intricacies of PHP image generation. Got to benefit from that.

I was so thankful for Daniel helping me with that, and I was happy to buy the plugin and all that and blogged about it and stuff. But I work with Automattic.

I don't know if this podcast is sponsored by Automattic, but sometimes it is. We've worked with them forever.

Dave: Today is brought to you by Wix. Wix, thanks for -- [laughter]. Go ahead. [Laughter]

Chris: Whoops! Yeah. No, the other one. WordPress.

I use Jetpack on sites, right? Part of the reason is for some of the social media features it has. There are a million features of Jetpack. This is just one of them.

When you hit publish on the blog post, it goes "bla" and shoots to Facebook and "wah" and shoots to Twitter for you. It's programmatic, API-driven posting of that stuff.

Dave: Yeah.

Chris: Very useful. Love it.

Dave: Yeah.

Chris: It means that my @css on Twitter can just be a megaphone. It's an RSS feed for CSS-Tricks. But now, with the social images, they just look a lot better.

Dave: Yeah.

Chris: I just love it. I think it's so cool. So, there's synergy there between Jetpack and this plugin, and I introduced the two. I was like, "Daniel, you should talk to Automattic." You know? "You guys should have a little conversation."

Then just yesterday, as we record here, they announced that Automattic bought Social Image Generator. Now Daniel is going to be an Automattition. So, congratulations, Daniel.

Dave: Hey!

Chris: And congratulations, Chris Coyier, for this is the first meeting I set up that ended in acquisition. The point is, join the ShopTalk Discord. Get your company acquired.

Dave: Join the Discord. Have Chris shell it out to Automattic.


Chris: Yeah.

Dave: Bingo-bango, money.

Chris: Yeah, that's right.


Dave: That's great. No, I mean it's such a -- there were some really good discussions. I don't know if you read Jim Nielsen's blog post about social images where he's kind of like, "It's a lot of noise."

Chris: He poo-pooed it a little bit.

Dave: He's just like, "It's a lot of noise." It's not wrong, by any means.

Chris: No.

Dave: But in the context of the whole darn feed, the feeds are becoming very noisy. That's Facebook. That's Twitter. That's Snap. That's Instagram, everything.

Chris: Right, and low effort noisy.

Dave: Low effort.

Chris: These are very fair critiques, by the way. I just thought it was interesting because I'm playing this very same game. Then read Jim's post and it's very much like -- and he has examples in there of just the lowest effort cards ever that's just like a white field with the blog post title on it. It's like, "Oh, great." You know?

In a sense, if you're not doing it, you're making a mistake because you're not capturing people's attention in the same way that the next card down does.

Dave: No, you're leaving money on the table, essentially, because that's the game. Yeah, it's very interesting, and I think about it, too.

We should probably say we kind of started making a foray into YouTubes here. We talked about thumbnails or whatever on the last show. I'm like, "Oh, man. If we had our faces on the thumbnail, we'd make so much more hits, likes, and tweets, and whatever."


Dave: There's a brain game that goes on of, like, how do I make that number go up - or whatever? Even so, like this post about The Surprise Chain. Maybe if I had put a custom image, Chris, and I put a big damn Apple logo and Steve Jobs--

Chris: Yeah.

Dave: You know? Maybe then--

Chris: Oh, I hate to save it, Dave. It would have tripled your--

Dave: Fudge! Fudgesicle. I'm going to do it. I'm going to put a little pink iMac. I'm going to put a little weird Macintosh. I'm going to put a little....

Chris: Yeah, all at different angles and stuff.

Dave: Yeah. Yeah, and it's going to be a little collage board of surprises. I hate that, but that's what it's going to be. Then I'm probably going to double my clicks.

Chris: Oh, at least.

Dave: Just too bad. But I probably need to pay more attention to it. I don't know. If blogging is something you want to do and that's how you get eyeballs, maybe that's it. Maybe you have to put time into it.

Chris: It's not like it's Open Graph. It's a real technology. And it's not just Twitter. It's Facebook, too. And it's iMessage. And it's Discord. And it's Slack.

Dave: Yep.

Chris: It's a thing.

Dave: Everything. It goes into everything. I might even make a Web component where it's a card link component, or something like that, and it goes and fetches the head, the metadata of your article.

Chris: Yeah.

Dave: You could do fetch with a byte-range or whatever.

Chris: Mm-hmm.

Dave: Then you just spit out these Open Graph tags inside your blog post.

Chris: Honestly, our app idea, which we definitely still need to build, should be for Open Graph, too.

Dave: Oh, yeah.

Chris: If you need to build a one-off, you have titles. You pick some fonts. You drag some stuff around. You use the webcam to get your face in there. Maybe we have font awesome icons, too, that you can drag on.

Dave: Okay. Okay. Yeah, yeah, yeah.

Chris: I just think this is not just YouTube thumbs anymore. We're expanding our market.

Dave: Yeah, it's kind of everything needs -- I don't know. There's, I guess, a way to present. You can present, but I totally understand Jim's point. There's a lot of low-quality noise out there, and so that's unfortunate too. I'd be curious where people land.


Chris: All right. Do we have a wrap-up statement here? Let's see. I have something about CSS scoping, but I don't know if we have too much time for it. It's pretty interesting.

We mentioned it on the show already once. I just wanted to point out there is some interesting (I don't know if you'd call it) criticism of scoping, but it's kind of like just putting a class name in front of something is kind of like scoping too. [Laughter]

Dave: Yeah. Yeah.

Chris: Why do you need this whole extra syntax that, in a sense, just puts a class name in front of it? It's a little bit like just nesting a selector in Sass. That's pretty much all it does. That's not true, though, all the way through. For really basic scoping that's true. But it doesn't have the lower bound, so if that's of interest to you. I know it doesn't come up every single day. But I think, once you wrap your mind around it, I think it does kind of make sense (the lower bound scoping).

But the bigger one, and this is from a Miriam Suzanne blog post, essentially she put the spec together and all these writing about it. It's one thing to make the spec, but you've also got to talk to developers and think through edge cases and interesting problems. Part of one of those blog posts she calls the nearest ancestor proximity problem.

Dave: Mm-hmm.

Chris: If you click over to that, hopefully, you can see it. I'll just to mouth blog it a little bit.

You have a div with stuff in it. That div has a class of dark theme on it. That's perfectly normal. I think that's expected. Let's say you wanted to nest a theme, or you had a component inside that also has a different theme.

Dave: Mm-hmm.

Chris: There's a div inside of it. Let's say it's light theme.

Dave: So, I have div class dark theme, an anchor link, div class light theme, an anchor link inside that, and then I close div class dark theme or div class light them.

Chris: Yeah, then you close them both. They're nested themes.

Dave: Yeah.

Chris: Well, you're in this really weird situation, all of a sudden, in that, in your CSS, you might have CSS written that says, "Oh, the links," you know, "dot light theme A has this color and dot dark theme A has this color," but the source order is going to screw you there a little bit.

Dave: Yeah.

Chris: Even in the light theme, you're going to have dark theme colors because of the order of your CSS. There is nothing that says, "Oh, this is nested a little deeper, actually, so it should win." That's just not a thing.

Dave: Mm-hmm. Yeah.

Chris: In CSS.

Dave: Yeah.

Chris: You'd have to write more advanced selectors that say, "Well, if light them is within dark them then you win." It just gets to be this little fighting mess.

Dave: You fight. Yeah, because you can have the inverse, too. The inverse would then also have to solve the same problems.

Chris: Exactly!

Dave: And then do this--

Chris: And then nest it even deeper. Yeah.

Dave: If you have 15 themes, guess what. You're in hell.

Chris: Crazy.

Dave: Yeah.

Chris: And that's a thing that this scope handles. It says, "If you're in the scope of light theme, then make the links this special color. The scope is going to win." Yeah, that's awesome.

Dave: Scope wins! Scope wins!

Chris: That's a huge, huge win for the scope.

Dave: That's interesting because that did come up in the D-d-d-d-discord. It was just like, "Isn't that just classes or BEM? Doesn't BEM do the same thing?" It sort of does, but then -- I don't know. But yeah, scopes kind of have a bit higher specificity, I guess, then just classes, so there you go. That's it. That's cool.

Chris: Yeah. it just kind of deals with that contextual DOM proximity stuff in a way that nothing else does, which to me is worth it all by itself. Pretty cool.

Dave: Oh, boy. Hopefully, scoping comes out. Hopefully, layers comes out. There's a lot of stuff that needs to come out. Custom media queries need to come out.

Chris: CSS is poppin'.

Dave: Oh, it's a hot year. It hasn't been this hot since probably 2011. [Laughter] I mean this is just a good year for CSS.

All right. Well, let's wrap it up 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 probably now 16 tweets a month because we're tweeting about our brand new - whatchamacallit - our brand new video show over on the CSS-Tricks YouTube channel.

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. Then follow us on Twitter, @ShopTalkShow, for probably now 16 tweets a month because we have a brand new video podcast over on the CSS-Tricks YouTube channel. Go over and check that out. Search for ShopTalk or YouTube or CSS-Tricks over there. [Laughter]

Chris: Yeah.

Dave: Yeah, you'll find us. Yeah, or you can join us daily in the D-d-d-d-discord. Go to We'd love to see you there. Chris, do you have anything else you'd like to say?

Chris: Oh...