Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another 2022 episode of the ShopTalk Show barreling down the information superhighway to episode 500. I am Dave Rupert, and with me is Chris Coyier.

Chris Coyier: Yeah, man. 497. It feels good. We have a guest now. You know at the end of last year, there were a lot of Chris and Dave episodes we were trying to get through because it's easier to schedule. But we are committed to bringing you people (that are much smarter than us) to this show to liven things up a little bit and be able to talk about with more intelligence of some of these things that we bring up. Dave is very smart, but sometimes I just run my mouth about stuff I have no business doing.

Dave: Oh, no. I run my mouth, Chris.

[Laughter]

Dave: Let's not oversell the dynamic we provide. [Laughter]

Chris: We have an amazing guest on to talk. Here's what we're going to talk about. We're going to be talking about native apps, the things like let's say you're going to build one for your iOS device. The thing that you're going to write in Swift - or whatever - or write code that gets compiled to Swift - or whatever - and then put on the Apple Store. Or, if you're writing one for Android, you're going to write in Java, and you're going to write one of those - or whatever. The native languages of the platforms that, for whatever reason, those platforms really want you to write in.

Kind of like versus, I guess -- although, I don't want to necessarily set this up as a fight. But, hey. Maybe it's going to end up that way -- is building Web apps, you know, building an app that can do largely a lot of the stuff that native apps can do.

We'll talk about what the differences are, why you would pick one or the other, and projects that are in place to kind of help push the Web part of it forward. Specifically, one of those things is called Project Fugu, and we have a guest on from Google who is kind of spearheading that - Thomas Steiner. How are you doing, Thomas? Welcome to ShopTalk Show.

00:02:20

Thomas Steiner: Thank you, Chris. Yeah.

Chris: I tried to do the German way and I biffed it.

Thomas: [Laughter] Thomas Steiner, that's the official German way, but like everyone on the Internet calls me just Tom or Thomas. Steiner is how I represent myself in English, so yeah, here I am. Thanks for having me.

Chris: Yeah! You're welcome. You reached out to me, actually, and I was glad to hear from you because I just had on my - I don't know - my mind vine for a while this kind of like what's up with native apps versus Web. I'll say Web apps, even though I generally kind of dislike the term because it's all this, like, "What really is a Web app?" It's so poorly defined, yadda-yadda-yadda. I don't want to get all into that.

You can imagine. Your TikTok - or whatever - and you have a choice. Am I going to build a "native app" or am I going to build a Web app or am I going to build both? You don't have to be as big as TikTok to be making that choice.

So many companies and businesses are making the choice: Are we going Web? Are we going native? Are we going both? What tech are we going to pick? What are the tradeoffs? How do we decide between those things?

I'm not an expert in it. I don't even have a horse in this race. I like the Web. I'm very biased, right? I have some guess that the three of us are pretty Web forward kind of people. So, I didn't exactly bring on somebody to be really pushing the native side. Although, we'll see how this plays out.

I wrote a post called "Why would a business push a native app over a website?" I kind of listed the things that seem to me reasons why you might go native. Kind of like arguing against myself in a way, like, what are the most compelling reasons why you might be like, "You know what. Forget the Web. I'm going native"?

I listed them all out almost blissfully unaware that there were entire organizations dedicated to this very cause and, in a way, fighting against it - or whatever. Is that what Project Fugu is, or did I mischaracterize it? Tom, can you tell me what project Fugu is?

00:04:30

Thomas: Well, I would not formulate it in a negative way. We're not fighting against anything.

Chris: Yeah.

Thomas: We are enabling stuff.

Chris: Oh, sure.

Thomas: Project Fugu is allowing you to do everything you want to do on the Web platform. If there is a missing API, Project Fugu would work on enabling and adding this API to a browser. Ideally, not just to a browser (which means Chrome in the concrete case) but to browsers in general. If you wanted to - I don't know - open a file on the Web and then save back to this file, in the past, you could of course upload a file, make some modifications to it in the browser, and then download the result.

Chris: Right.

Thomas: If you were to then make a further edit, you would have to redownload the thing again, and so you couldn't just easily have this edit, save, edit, save, edit, save flow. So, we were enabling this technology with file system access API that is implemented in Chrome right now. Apple has started to implement some parts of it, so this is about enabling stuff that was not possible before.

There's a whole bunch of application ranges that we want to enable on the Web. Yeah, this is about enablement. This is not about fighting against Android, Windows, or Mac developers. This is really about enabling Web developers to build applications on the Web because we see a lot of companies (big and small), as you said in your intro. They're struggling.

They're thinking, "Should we be building Mac? Should we be building Windows? Should we be building, you know, iOS, Mac, Android, and what have you?"

At some point, they have to prioritize. Why is there no way for them to just build Web and, by this, target all the different platforms? This is what Project Fugu is about in a nutshell.

Chris: Mm-hmm. That was great! I thought the file system API is such a great example that you brought up. I think people are seeing it and feeling it a lot lately because people are so excited about seeing all these examples of VS Code in the browser. All of a sudden, you're like, "How the heck does that work? I could just open a project locally?"

Just go to vscode.dev. Open a folder. You can do it right in Chrome or Edge. I think it'll load up in Safari, right? But then it just kind of doesn't give you the option of opening a folder. You can only kind of connect a repo or something.

I assume that that means there's code in place that says, "Is the file system API supported? Yes? Then show the little open folder button. No? Then don't show it." Which enables this class of application that just wouldn't have been possible even a year ago.

00:07:17

Thomas: Yeah, probably. I think it started in Chrome 84. There have been some refinements and API additions. Yeah, as I said, if you open the same app in Safari, you should still get something.

I think most of these APIs that we talk about are in the sense of progressive enhancement. So, you get a baseline experience on any browser, and you should get a perfect experience that is enhanced with the latest and greatest features on browsers that support given APIs. Sometimes, it's a moving target. Sometimes, you start building your application and something is not supported quite yet.

Because you've built it with progressive enhancement in mind, all of a sudden when a new Firefox or Safari technology preview drops and you try your app again, it's like, "Whoa!" all of a sudden things are working just because you have not hard coded against a user agent. You don't sniff it. But you do feature detection. If all of a sudden feature detection happens to be, yeah, supported, then your app starts working.

I think this is where we want to go with everything that we build, so we try to make our stuff enhanceable, progressively enhanceable so that people can build applications, get a baseline experience everywhere, and super cool, amazing experience on browsers that support all these APIs.

Chris: Yeah. I've lots of blind spots that I'm sure you see as being a part of this team. All I build is - I don't know - what seems to me as normal websites for the Web. I'm not exactly pushing boundaries a lot of times with fancy APIs.

But let's say you're a game developer or something and you have this really cool game you're working on. I have an Apple TV at home, and I use Apple Arcade. Once in a while, I download games from it, and it says, "This game only works with a controller," so you have to buy one of these third-party little controllers that Apple doesn't even make one. You've got to just buy a third-party thing.

Some of them are supported. I don't even know how it connects. I guess it's Bluetooth. [Laughter] Then you can play the game - if you have the third-party controller.

Sometimes they're progressively enhancement coded in that they'll work with just the normal remote, and sometimes they're not. Certainly, the ones that work both ways are more fun because you're not limited in your ability to play them at all.

That would show up on the Web, too, wouldn't it? Let's say you're writing a game for a mobile browser and you want to support a controller that maybe it plugs in via USB or something. Maybe the USB APIs are available but the Bluetooth ones aren't. You could code it in such a way that's like, "Well, when Bluetooth support drops, then my code will start supporting it. But until then, I'll say that it's required to use USB." Is that kind of thing possible?

00:10:14

Thomas: On the Web, you would have the gamepad API that's been around for a very long time. The thing is it would allow me to get your joysticks and buttons and a couple of advanced. Rumbling, for example, is sort of working.

But then you look at controllers today, like if you look at Joy-Con controller from a Switch, it has a gyroscope. It has accelerometers inside. This is just stuff that is not supported by the gamepad API.

You could still use a Joy-Con controller with a gamepad API, so there is some compatibility layer. But if you wanted to actually get access to the gyroscope, you would have to talk to the controller in a different way. This is what the WebHID API supports. So, I think a little driver for the Joy-Con that allows you to read (via WebHID) the gyroscope from the accelerometer data. That you could then via just the JavaScript advance code against this application.

I have to say, I have not written this from scratch. I just looked at someone who actually reverse-engineered how it worked and sort of -- no idea, drop what I'm doing -- ported this thing to JavaScript, but it's sort of working. So, via the WebHID protocol that uses HID -- as the name suggests -- internally, you can get access to these APIs. This is also something that Project Fugu is about, opening up your browser to new devices or just existing devices that you have laying around that do something, that talk via HID, via Serial, via whatever protocol, and making it available to the Web.

I have to say I'm not much of a hardware person, so a lot of the things that I do or that people do, I don't understand or I have to look at someone who has an understanding and then port it over to JavaScript by looking at Linux and see and guessing what I'm doing. But there are a lot of people who actually do have a lot of insights, and they can then just directly talk to these devices and actually know what they're doing. That's pretty cool. That's definitely something that we want to allow with all of our hardware APIs, so there's Bluetooth. There's HID. There's Serial. There's media if you have a media device. There's USB, obviously, so yeah. These are the hardware APIs that it can use in the context of your Project Fugu APIs there.

Dave: Oh, I was going to say it's kind of, too, about -- I think of the Switch when I'm like, "Oh, I need to connect another controller," and I go to the menu in the Switch UI. Then I click the buttons to pair. You can't do that on the Web, right? You can't, like, pair controller with the in-browser UI. You have to go to the OS, find the Bluetooth dropdown, and kind of, I guess, hijack in. That's a limitation of the Web, right?

I can't be like, "Let me just ask the network, the Bluetooth network, [laughter] if there are any controllers around." I can't do that from my website, right?

00:13:32

Thomas: Yeah. Correct. For the Switch, you first have to pair it using -- I'm using a Mac, so using the Mac Bluetooth dialog. Once it's paired, we can then connect to it via the website. The Bluetooth connection has to do one thing and then the WebHID connection is the other.

It's sort of piggybacking on top of the Bluetooth connection to then talk to the HID protocol. As I said, I'm not much of a hardware person, so there are people who can explain this a lot better than I can. But once you have this connection, the browser then remembers it so that pairing again in the future is a lot easier. Yeah, that's what it can do there.

Of course, you know what you're expecting. So, if you're writing a Joy-Con controller driver, you of course know that you're expecting a Joy-Con, so you can limit the kind of devices that you see. Sometimes, when you scan for available Bluetooth devices, it can be hard to find the one that you're actually interested in just because when you are surrounded by Bluetooth devices, it's kind of hard to sometimes find the right one.

Dave: Mm-hmm.

Thomas: There you can just filter and say I want to search for something that has a vendor ID of Nintendo, whatever like that. You can just directly filter on the ones that you're interested in.

Chris: Hmm. That's actually a little leg up, I guess, then because you're not going to get that filtering probably at the OS level, right? It's just going to show you--

Dave: Yeah, just everything.

00:15:00

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Tabnine. That's tabnine.com.

It's like AI code completion for your code. You're just coding along and there are suggestions for you that are really intelligent and based on your own code. It's just really incredible. It's free, too, so you might as well install it and get going on it. It really comes to you in that it works in tons of different code editors, so VS Code, of course. I'm sure a lot of you are using that. But it works in Sublime. It works in Atom. It works across a whole slew of different code editors. So, it comes to you in that way.

It comes to you in the form of languages, too. Probably any language that anybody listening to this show is listening to - all the Web languages like JavaScript, Typescript, CSS, HTML, and all that. But also, Python, PHP, Go, Rust, and new stuff like that.

It's really powerful, so you're just coding along. There'll be autocompleted because your code editor is probably helping you with that kind of IntelliSense, auto-complete stuff anyway. But then there's Tabnine in there, too, offering its best suggestions of what you want to do. They tend to be more robust and more thoughtful than your average IntelliSense. Just more code comes out of it. Pretty darn cool.

Again, this is free. Just install it. Give it a play and see what you get out of it. Really powerful.

Then there are team accounts, too. Venturing into paid territory here, you connect it to your own Git repos. Then it learns. It runs that ML model on your code for your team, and then your team members are part of the thing, too. You're all learning and jiving from each other, so it just gets smarter over time. Really impressive what it's able to do that.

I want to mention one other thing that I think is cool. There's the IntelliSense, like there's the dropdown menu, and it gives you suggestions. There's a ton of stuff that's configurable about Tabnine, and one of them is that you're coding along. It can do the thing where, off to the right of your code, is grayed out code - that style of autocompletion too. You're like, "Oh, yeah. That's what I meant," tab, or "No, that's not what I meant," and you just keep coding, and it updates other options of what it thinks you might be doing. It's kind of take it or leave it code completion that I really think is cool.

Anyway... Thanks for the support, Tabnine.

[Banjo music stops]

00:17:22

Chris: That's cool. I'm interested in those little moments where the things where the Web can do something a little bit better, even, perhaps. Some of these APIs are so new that let's say you're Dave and you're developing this game. It's using a gamepad or something. You might look at the Web and be like, "Oh, that's kind of cool that it looks like it's getting there."

But is it still fair now that you'd be like, "Yeah, but I think I'm just going to make the native one because their support is just rock-solid"? Is that kind of the goal here too is to have people feel like the Web support is just as rock-solid as native is and even better, perhaps, when it can be?

Thomas: Probably yes. The thing is, when people say, "Let's build native," in many cases they don't really build native-native, but they build Electron, so this allows them to--

Dave: [Laughter] I'm looking at my doc right now. I have VS Code, Slack, Discord, Notion, Spotify, and yeah, browsers.

Thomas: [Laughter]

Dave: I just want to--

Chris: I have 1Password down there, too.

Dave: Oh--

Chris: Which said they're going Electron now, too, so that's just huge, isn't it? Just massive how many apps are built with Web tech lingo.

Thomas: Yeah, absolutely. Electron is a big, big topic. Interestingly, they actually maintain a Fugu compatibility spreadsheet too, so they have drivers that they can use to talk to HID.

I think, for HID, for example, they use node-hid as a package internally. Once the WebHID API was enabled, I think they were looking at deprecating their existing node-hid implementation and then migrating over to the WebHID API to allow people to do the same things that they did before.

Long story short, I think when people, "Let's build native," in many cases they still sort of build Web technology but just on a low-level stack, so that's something pretty interesting. As I said, the Electron team, they maintain this Fugu list, and they're actually active in the Fugu world as well. They sometimes attend our calls, so it's pretty interesting to see this native app world still diverge into a Web world sometimes. Definitely, it's a Web technology world, to begin with.

But then, of course, sometimes actually people still build native-native (no questions asked there). Yeah, we are seeing it less and less. We are seeing people trying to get one code base to do everything like React Native, Electron, or whatever. We're seeing more and more people building with that technology and, yeah, still trying to get this native look and feel or native downloading a package from somewhere, install it, that you can then just double-click and be good.

Yeah. In the end, people just want apps, so how they're built the regular user don't really care about. That's something we have seen if the Web experience is good enough and great.

Dave: Unless you're John Gruber, who really cares? [Laughter]

00:20:36

Thomas: There are people who care, and there should be people who do care. Just in general, a lot of people on the user side, they don't care much because all they want is an application that stores their passwords, as you just said, Chris, with 1Password. Something that just allows you to use Slack, so yeah. I think this is something that is a trend, in general, that people build applications using Web-like platforms or SDKs but then, internally, even run in a browser, but maybe just has bridges to some native APIs that are not supported on the Web quite yet.

Dave: I do want to celebrate. I mean we're coming up on ten years of this podcast. We're at ten years. I think, when we started, the idea of recording a podcast in a browser was just a no.

Chris: [Laughter]

Dave: It was, "LOL. Get wrecked, you nerds." It was never ever going to happen - ever. Right, Chris?

Chris: No way.

Dave: No way. Never would we do that.

Chris: Yeah. Even in the early days of it, it seemed so hacky and something I would never trust. Literally, as Dave said, our ten-year anniversary. It was in our ninth year where we started to have this trust for it, but it's happened pretty quickly now, and now we're just like, "Oh, yeah. Why would we do it any other way? This is clearly better."

Dave: Yeah, now the ability is here that we can actually record in a browser and video conference pretty effectively, bring guests in, and stuff like that.

Chris: Yeah. What a march forward for the Web, huh?

Dave: Yeah. We're not using Skype anymore. [Laughter]

Chris: [Laughter]

Dave: Definitely want to celebrate that. Like I said, a lot of my apps are -- I know because I'm a dork, but I know they're just Electron apps. A lot of the daily sweet of whatever (high-quality software) is just Electron under the hood.

Chris: On the desktop, anyway, but the phone story is a little different, right?

Dave: Yeah. The phone story does get different.

Chris: I don't think there's as big of a runaway winner in "use Web tech to build native app." Is there? There used to be phone gap, I guess, but is that a thing anymore?

Dave: Nah...

Chris: I don't even know.

00:23:08

Thomas: No phone gap. I guess phone gap is mostly dead-ish now, so it's called Cordova these days. Probably dead-ish is too much, but it's not the number one anymore, so I think React Native is still big. Flutter obviously is gaining a lot of traction recently. I think, on mobile, yeah, it's a little different. We have native script as well, so there are a couple of solutions out there. Yeah, it's not as clear as on desktop where everyone or most people are using Electron.

Chris: Yeah. Flutter looks super cool to me, but it feels like there's no CSS in Flutter. You know? It feels like a different language, not just Web tech that gets smooshed over into native somehow.

Can we go through a list of some reasons why a business might choose native and then see what the future holds now that we have Thomas to see if there are some answers to these things? Like the "people just want apps" thing that we mentioned, right? They don't care so much, right? They just want the thing to work. They don't care. They're not thinking, "Ah, I only like Web apps." Nobody says that, right? They just want their thing to work.

But that means, on their mobile device or their tablet, probably, that there's a little rounded rectangle that is that thing. If I'm a business, doesn't it stand to reason that I want a little rounded rectangle on there? How do I get my little website to be a rounded rectangle on there?

I think the story is okay on Android, right? You go to a website once, use it for 30 seconds, and you can get a little PWA banner that says, "Hey, do you want to chuck this thing on your homepage?" That story seems okay to me. Although, it would be maybe even better if there was an app store that would put them on there. I don't know what the story is there.

That story is freakin' awful on Apple, right? You just have to know these eight clicks to click. Eight is an exaggeration, but it's a buried feature to put a website onto--

Dave: Chris, click the up arrow box. Scroll down [laughter] to the third screen.

Chris: Add to home screen - whatever.

Dave: Then add--

Chris: Even then, it's a weird second-class citizen because it launches a little browser with the website. Maybe you don't want to see the browser because it's an app that doesn't need to look at the URL. I'm sure there are some choices there, but it doesn't feel good to me. But I've already said too much. I kind of want to hear your thoughts on this, Thomas, if you have any. Otherwise, we can--

00:25:55

Thomas: Yeah, it's kind of a long response there. As I said, PWAs are one big way how you can address this on Android where you get the install prompt. You can even control the prompt so that it shows right at the moment that you want to and not at a random time when it might not be the best time for your app to be installed.

We do have something called TWA (trusted Web activity), which is a way for you to get a trusted (as the name suggests) Web view where your PWA runs onto an Android application so that you can use this Android application to then submit it to the Play Store so that you can (with very little effort) get a PWA into the Play Store.

Chris: Oh, nice!

Thomas: That was even called PWA Builder that is run by Microsoft that allows you to submit your PWA. It does some magic using a tool called Bubblewrap and then gives you an APK that you can then submit to the store so you can get your application on the store there.

I guess the final part of my answer is PWA Builder also have allowed you to get an iOS package, so you can download an iOS package and submit it to the app store. There are a couple of apps that are built with this that are already on the app store so, on Apple, you can get the same.

I would say Apple does get a lot of negative developer feedback for how blurry this Add to Home Screen thing is. I think they're getting not enough credit for inventing this because before even PWAs were a thing, the earliest iPhone supported adding to home screen.

Steve Jobs initially had this vision of Web apps and only then in 2008 they came up with this vision of the app store, so I think they have forgotten about it a little bit, but it's still there. It's maybe a little less obvious than it was in the past, but it still works great. Once you have educated people to install your application, these apps run in full screen and standalone mode. You can get the application running with your ICANN, and it feels like a real app.

There's (every now and then) a bug depending on the operating system version that you're on. But, in general, the experience is kind of okay. Of course, we wish there were a way for applications to trigger this install prompt as an Android. But once people have discovered that they can install applications like that, it's working okay.

Chris: Okay. Okay. You're relatively positive about it then. I'll take that.

00:28:46

Dave: Can I add a twist to this story?

Chris: Hmm.

Dave: The user wants the icon on the home screen, right? But the marketing department also wants the icon on the home screen, right? They want whatever -- Dave Rupert LLC -- the icon on Kim Kardashian's phone (for whatever reason). They want the number of installs, and they want success metrics based on number of installs. How many people visited the website isn't enough anymore. It's how many people installed the app. You know? There's all this kind of--

I would argue it's kind of perverse. It's just these metrics are driving our decisions rather than metrics informing our decisions. How do we combat that? How can I walk into a meeting and everyone is like, "All right, 2022. We're going to reboot the app," and I'm like, "How about the website?" I'm just going to get laughed out of the meeting. How does that work? The marketing team wants the metrics, right?

Thomas: They absolutely do, yes. Before I became a developer advocate on the Chrome team, I was working in a team in Google that was working with big partners of Google. We were advocating for Web applications. Yeah, definitely these kind of marketing team questions come up a lot.

The thing is, if you want to track installs, you can still track there. There is a way for you to measure if your application was run as a PWA or if it was run as a regular in-browser application. You can, of course, just track the actual install operation per se, which is not very meaningful because, in the end, if someone installs an application and forgets about it, how much worth is that, really?

I do know that a lot of marketing departments still look at this number of how many people have installed our application. We always say you should be looking for how many people are actually using your application because this is a way more meaningful number. You can get both numbers using the Web as well.

I think a big, big problem also is app store discoverability. We have educated people to search for brand names on a store and then expect them to find the app. I've tried that recently for a new TV that I bought. It's just a Samsung TV. I was looking for the Samsung app that goes along with this TV. Have you tried that? It's incredibly hard because they're running apps for Samsung Korea and Samsung Germany and Samsung North America, and Samsung what have you. There are people who build - I don't know - the menu app for Samsung so you can get menus, but this is not even from Samsung.

It's getting a lot harder to actually find those applications and, in many cases, people have started on the website, and then they were asked to install the app from the store. Then they try to find it on the store and sometimes it can be a real hassle to actually then find it. The app store presence and discoverability is a big topic as well.

Then also this entire thing of presence on the home screen. I was working with a customer in the past. They had an agency. This agency said it's all about screen real estate. Rather than having one app that did everything, which would be the reasonable thing for this particular type of customer to do, they had several apps for each sub-thing that you could do with this particular customer.

If you were to install this, instead of just one icon, you had five icons on your home screen. It was all about presence and screen real estate so that people would be opening their phone or unlocking their phone and seeing these five icons and then reminding themselves, "Oh, I have to do this and that task," ... this and that app from this and that customer.

Yeah, it's just something that we observe, and it's annoying. On the Web, of course, the same can happen. People can still - I don't know - organize their business in subdomains and, for each subdomain, create their own PWA. Sometimes, for technical reasons, they have to because we don't have something called scope extensions quite yet. It's a feature we're working on. Right now, every PWA is limited to just one scope.

Chris: Hmm.

Thomas: Yeah. Long story short, I think there are a lot of reasons for people to build a lot of icons and get a lot of icons on their home screens with Web ... or with native, and especially with native.

Dave: It sounds like the HP printer CD. [Laughter] When you install HP software and second icons show up or Dell OEM software, the new Dell feel. That's where we're headed.

Thomas: Definitely rings a bell. Yes. I didn't want to mention brand names, but yes. [Laughter] We've all been there, right?

Dave: It's okay. I'll mention the brand names. You keep your job. It's fine.

Chris: [Laughter]

Dave: [Laughter]

Chris: It's fine.

Dave: It's fine. I'll sacrifice my client service business. No--

Thomas: [Laughter]

00:34:11

Dave: No, I think that's a good point. I think discoverability is a huge one. That's one thing you mentioned in your post. Right, Chris? It was just like, there's an app store. Being in that top ten of the app store, I know for games that's critical. If you're in the top ten of games, gajillion downloads. But if you're in the bottom ten, zero downloads.

Chris: Yeah. It's pretty dramatic.

Dave: The falloff is so huge. Even to the point, again, the incentives are messing up the reality. People just go hire click farms in Indonesia or wherever to install. It's more money -- like I spend money to pay people to install my app so that I stay on the list of cool apps. You know?

Chris: Yeah. I wonder how-- I don't know. It's not like the app store is the only place for discoverability though. Even if you're native only and you have to download it from the app store because it's the only way to actually get the app-app, you probably still have a website, and your website can have stuff on it, including a big call to action link that kicks you over to the app store to get it. But that's a potential for SEO and content stuff.

It's not like if I'm not high in the app store it's the only possible way to be seen. There are other games to be played for findability. But it does seem to be like--

I think we talked about this in terms of TikTok the other day in that TikTok is primarily a native app. It's way fast on your phone. You just click that thing and, boom, it's playing videos for you.

But they have chosen to make a Web app as well. There are both, but they have lots of money, right? They're bigger than Google now, they say, right? Yeah, right. [Laughter]

Dave: But the Web app is like 45 seconds of white screen or something. [Laughter]

Chris: It's the worst! But they built it anyway because of URLs.

Dave: Right.

Chris: Because then I can send you an iMessage with a TikTok in it and, maybe if the app is installed, it will open the native app. But nobody is excluded. You send it to grandma or whatever (who doesn't have TikTok installed) -- I'm sure she will soon -- then it will still open that video in a browser, and it will still work. They still chose to do that route.

So many apps -- it seems to me, the more money you have, the chances of you doing both are really high. You don't have to make the choice when you're rich (as a business). You just do both.

[Laughter]

00:36:46

Thomas: And people definitely do use PWAs who are just random websites as their gateway drug to a native application. You may remember Photoshop on the Web that was launched recently. They obviously are a big native publication that has been around forever. Something that they shared with us was, for a lot of quick editing tasks, people didn't feel like firing up the native application. So, if someone just wanted to remove a background from an image, firing up the application was something that was causing a lot of friction.

As I say, URLs are superpowers. People would be passing around URLs of images, for example. With the Photoshop on the Web application, people could then just launch Photoshop in a browser tab, load this particular image that someone has sent via URL, for example, paste it into the application, make the modification, then just go back to whatever chat application that they got the image URL from and send the edited image back. The sort of very interesting thing was Photoshop on the Web right now is not a PWA in the sense of they are not installable per se. Of course, you can still create the shortcut, but they don't prompt for installation. I think, technically, it's not even implemented quite yet because it's not offline enabled. Their flow was this entire -- for small edits, just use the Web app. For big, massive edits, fire up the native application and be good.

You said something about URLs before. On the Fugu team, we work on a feature around URLs as well. Let's say you have a music player app installed: Spotify, YouTube Music, Dees, or whatever. It's running as a PWA. Someone sends you a link to their latest favorite song, for example.

In the old days, it was not possible to open up the PWA from a link. But now there's a new feature where you can just pass a link and say, "This particular family of links (so, example.com/ whatever star) should be handled by the PWA that is the URL handler for this particular URL pattern."

That's something we've implemented, and I think it's one of these power features where people will see, "Oh, wow. A Web app can do that, and I can just double-click the link or click a link anywhere from any kind of application, be it the old school Skype client or be it something Web-based or be it an email that they get with a link." All these different targets will then all open the PWA experience.

I think just recognizing these small use cases and friction that was introduced by apps not meant to open in a browser tab and sometimes launching an application that you wouldn't want or didn't want is something that adds a lot of smoothness to how people experience PWAs.

Another cool feature is the ability for a Web application to register as a file handler. You could say, "I have an extension, example.example." In your file explorer, you can then say, "I want to open a .example file, but open with the example PWA," so it can even become the default handler for this. You can say -- in the Mac OS finder, you can say, "I want this PWA to become the default handler for .example files," so when you double-click one of those, a PWA would open right away and not open in a browser tab.

This ability to do this from a Web app is really a superpower because we've seen this with applications like Excalidraw, which is pretty popular cartoon-style drawing app. They have the extension .exaclidraw.

Chris: Hmm.

Thomas: Most people get into this flow of just double-clicking an application icon, launching the application -- sorry, double-clicking a file, launching the application, making the edit, and then going back to the saved file, using the file system access API to save this modification right onto the open file. They forget that they're using a Web application just because it feels so natural. It's just integrated very well into the operating system.

I think this is the tendency we see recently with PWAs, especially in Microsoft, because they run the Microsoft store that has PWAs as part of the listing options. We're seeing Microsoft pushed the boundary a lot with what is possible there.

But of course, we have Chrome OS in Google as well. We're also working on making the experience from going from a file, for example, to an application that is a Web application a lot smoother than it has been in the past.

Chris: Yeah, that's really great. Even from your local machine, some file that's just sitting on your computer called .dave, you could just even double-click it. Is that even going to work? How do you teach the operating system which PWA it's associated with? Doesn't the operating system need to kind of okay that?

00:42:15

Thomas: It definitely needs to. In your Web app manifest, you say, "My application can handle files with this and that extension," or with this and that mime type.

Chris: Mm-hmm.

Thomas: Then once you install the application and you (for the first time) open a file type that says, "Do you want to have this particular PWA handle this and that file?"

Chris: Oh, I see. Permissions.

Thomas: You can then say yes for just one time or yes always. It's definitely negated by a prompt. It is not just that any random ... website can become the default handler for - I don't know - .txt files.

Chris: Yeah. [Laughter]

Thomas: I remember.... You install real tech -- what's it called? RealPlayer. All of a sudden, RealPlayer -- oh, I see you nodding. [Laughter] RealPlayer was horrible. It became the default handler for any kind of audio files.

Chris: Hmm.

Thomas: And no questions asked. Like on Windows, you could just do that, and it was so annoying. On the Web, of course, we don't want to repeat those errors that we saw a lot of companies do.

Chris: Oh, yeah. Right. There's got to be some kind of prompt. Even a pretty bold one because it could be an app idea to be like, you know, get somebody to install something and be like, "I'm your new handler for .docx files," and the app just opens it and emails it and sends its contents to me," or whatever. It could be a security thing. There are lots of things that are security things, right? A big way to fight that is a big prompt that says, "Is this okay?"

Dave: I just think about Markdown files and editors. You know. It may be nice.

Chris: Oh, that'd be a nice one. Yeah, have a proper app for your .mds. Sure. There are all kinds of apps fighting for that one on my machine. I always am annoyed by it when apps take it over. I'd almost rather have -- it just feels like such a Web first format that I'd rather have a Web app do it.

00:44:12

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by CodePen, and I'm here to tell you to go Pro on CodePen. CodePen Pro is awesome now and it's only going to get way, way more awesome. I happen to know, as I - you know - work on and get to decide those features.

I'm so excited about the future of CodePen Pro. Of course, as we do that, eventually, over time, CodePen Pro is going to get more expensive, so you might as well get on one of those grandfathered plans. That's what I'm saying.

But of course, today, you get a bunch of features as well. A big one is privacy in that you can make your pens and collections and projects private on CodePen, meaning that nobody can see it unless you very explicitly share the URL with them. That's a big one.

Let's say you need an image in a pen. You draw and drop an image. We'll host the image for you. And we'll optimize it. And we can resize it for you if you want, serve it in the right formats, and all that stuff, things that can happen just with URL parameters for your images and other assets that you upload to CodePen. We'll handle all of that for you. It's a Pro feature.

There are things like collab mode, working in real-time with other people on it, and a bunch more features. Upgrade to Pro at codepen.io/feature/pro.

[Banjo music stops]

00:45:36

Chris: We've got another little list to get through, though. Let's do a few more, and then I want to talk about an app that Thomas created because that's pretty cool and it gives us some framing for some of this stuff, too.

I'm curious. Let's say you do it. We solved the rounded rectangle thing, and you get it on there. You open that thing up. It's still (like on Android) using Chrome, right? It's just a little isolated version of it. I don't even know how isolated it is. It's kind of the same story on iOS, I think. You get a little Web view instance to run your little app in.

But I find that, for example, let's say you were going to do that with Twitter. I'd go to twitter.com in Safari and then add it to my home screen rather than using their native app, say, that it's not going to hold onto my login credentials as well. At least that's what it seems like to me, that Web apps, your cookies expire faster - or whatever - rather than I open up Twitter on my phone. The native app, I am just forever logged into it. It never seems to lose that credential. That's one of those little use cases, one of those little rough patches in the road that - I don't know - just that is enough to get me to install the native app sometimes, that login thing.

Are there any kind of stories happening there? Do I just have it wrong?

00:47:01

Thomas: On iOS, they are very clearly separated, so your login story on the browser is something different from your login story once you install the application. On Android, it's different. On Android, we share the same context. When you're logged into the Web app, you're also logged into the installed experience.

Chris: Native? Really?! Oh, that's great! That's a big bonus for Android.

Thomas: Yeah, this would work. Expiring sessions are annoying, super annoying, indeed.

Essentially, it boils down the app developers and how they choose to expire their sessions. I have installed the Twitter PWA on iOS and it's running without interruption on iOS. I didn't have to log in again. The only thing that is annoying about it is I live in Europe, so I get cookie banners every now and then.

Twitter informs you regularly that they use cookies, which is, you know, a big surprise. You say yes. Then a couple of weeks later, it reappears. I'm still not sure why they forget that I said, "Yes, cookies are fine," but for the login session, it has never expired so far.

I think, if you experience that, it's just something that they choose to because someone told them it's more secure to expire sessions every other day or whatever. But technically there's no reason why it should be expiring longer or shorter on the Web than on native.

Dave: I think it's just culture, right? I think every beset practice is like, "Don't do user sessions longer than two weeks," if you're creating a user system. But then when phones came out, we were like, "Well, that's somebody's phone. They're not using it on the library computer." You know? There's no library phone. [Laughter]

Chris: That's assuming a cookie login, which is fine, right? Maybe that's how it works. I'm sure tons of websites do it that way. Some websites use JWT, which is a little different. It goes into a little different storage place, right? I don't know. What else? Is it just that only? Under what other circumstances can you lose that login status? Is it nothing? Does the OS get involved and flush them at some point or not really? I don't know.

00:49:27

Thomas: I don't think there's anything that would kick you out of a logged-in session. There's storage. If you're running out of storage, some of your cached items can be purged from the cache. Once it ... your cookies, I guess, is really the worst case, and I don't think this actually is happening.

Chris: Okay. Okay. All it takes really to have a website that you log in for a long time is you just set the cookie--

Thomas: I think it's really just that.

Chris: It's a developer concern.

Dave: Twelve billion. [Laughter]

Chris: Yeah.

Thomas: [Laughter] Yeah.

Dave: Max age.

Thomas: It might be what you said, Dave. There might be still this people passing phones around. Maybe this is happening less in the developed world, but maybe more in the emerging world. People share one phone with family members. It might be just a global thing. People or developers see people are using ... from, let's say, India. We know this is something that's happening where people share a family phone and pass it around. This might be a reason. Yeah, I don't think there is any technical reason why a session would have to expire.

Dave: I had a client, and they had Mac session two hours. We said, "That's low." [Laughter] But the security team was like, "We take credit cards, dude, so it's not." You know? I think the idea was somebody could yank a computer and just - whatever - rack up a bill.

Maybe there's a payment story mixed into all this, too, that we're not thinking of because I have to fingerprint ID to pay with my phone but I don't with the website. You know? I know there are Web payments API, but--

Chris: I mean kind of, but I have the Amazon app on my phone. I open it up, and I'm logged in forever. I have never--

Dave: Does your daughter ever buy stuff? [Laughter]

Chris: I mean she could, so that is a concern, right? But can you imagine Amazon making that choice?

Dave: Right.

Chris: Every time you buy something, you have to put in your password. That would just crush their sales. It would just be a disaster for them.

Dave: I can't say it's right, but I think it's just decisions people made. Then do I have the organizational fortitude to battle the security team for the next 20 years of my life - to Jerry?

Chris: No. Jerry is a beast. I don't want to get into an argument with Jerry.

Dave: Jerry is a bit of a curmudgeon. I'll be honest. [Laughter]

Thomas: [Laughter]

Dave: Okay. Yeah. Yeah. Do you have more on your list?

00:52:12

Chris: Well, there's offline stuff, but we kind of covered that with PWA because PWA, you literally have to have a service worker to have a PWA. Do you not? I think that's a requirement. I don't know that it has to necessarily store things in an offline cache. But now that you've got the service worker, at least you have the tech available to do that if you wanted to. The offline support is certainly a possibility with PWA land. I don't know that it's as straightforward as it is in native app land where you kind of just don't have to worry about offline versus online. I guess you do, to some degree. But at least you're rounded rectangle when you tap it is definitely going to do something in native app land.

I don't know. I don't want to dwell on that so much because we're running out of time and I want to talk about, Thomas, you made an app called SVG something.

Dave: Co.de.

Thomas: SVGCo.de.

Chris: Yes! I think I have it right that it takes a vector or a raster graphic and turns it into a vector graphic. Woo! That is fancy. Of course, you made it a website, yes?

Thomas: Sorry, yes. For a long time, there was this service called Potrace. It's a command-line tool for, as I say, converting raster images into SVGs or other vector-based formats like EPS. I've always needed this, and I always went to random websites. Sometimes, you end up having a great conversion.

Then before you want to actually download it, the app wants you to sign up for the service. I'm like, "Argh! Come on! I did all this work. I converted it. Now I can't use it because you want me to sign up or even pay." Yeah, I always ended up searching for a couple of services until eventually, one would work.

It's always feeling a little sketching uploading your stuff to a random service because you never quite know what are they going to do with it. Yeah, I had this library in my head called Potrace, built by someone called Peter Selinger. I went and said, "Is there a way maybe to use this in a Web application?"

Jake Archibald, from my team, has built something similar based on SVG Go that is for optimizing SVGs, so there was the command-line tool. That was converted into I think not even WASM. I think it's just a direct JavaScript port.

Jake just built the GUI around it, so that's essentially what I did with SVG Code. I wanted to make all the settings that you have on this command-line tool available and just allow people to playfully check these different settings and move sliders around and directly see the impact that it has on the application.

Yeah. Of course, being on the Fugu team, I had to use a couple of Fugu APIs where it made sense. Yeah, that's what I did.

Chris: Mm-hmm.

00:55:13

Thomas: This application now uses the file system access API to do this async clipboard API. It's using a pretty cool feature called Window Controls Overlay, which allows you to sort of get rid of the title bar and just move up your entire content into the title bar area, which is something that a lot of native applications do, like if you think of, let's say, the Spotify native app. It has sort of a search bar in the title bar area.

Chris: Mm-hmm.

Thomas: You can do that on the Web as well. Yeah, for now, it allows you to optimize your screen real estate that you have. Less wasted space on your app. Yeah, get more actually usable screen real estate back. Yeah, that's it.

Of course, you can also--

Chris: How does that work, though? Is it in a future version of Chrome or is it in stable Chrome now, that little--?

Dave: Title....

Thomas: It is about to be shipped, so there is an origin trial going on where you can test it with real users. I think it's coming out in 99, if I'm not mistaken.

Chris: Wow!

Thomas: The core idea is you just say, "Hey, my app supports this," which means the browser will get rid of the title bar, which means everything will shift up. But then it will disappear. The content will disappear behind the window controls, like the minimize/maximize/close button - and so on.

There are some CSS environment variables that allow you to say what is the -- I forgot what it's called. Like what is the title bar inset and so.

Chris: Yeah.

Thomas: So that they can move and model your content around this so that your content appears in the head bar area without being covered by the title bar controls.

Interestingly, this is also where operating systems come into play because the way windows work on Mac versus on Windows is different. The controls are on a different side of the window on Mac versus on Windows. So, having this all in CSS and having it all just as an abstract environment, a set of environment variables, allows you to very flexibly react to how the particular operating system is built. That's a pretty cool feature and I like it a lot.

00:57:33

Dave: Yeah, there's an A List Apart article, "Breaking out of the box," by Patrick Brosset. He's like, "What can we do with 30 pixels?"

You think, "Oh, it's just 30 pixels. Whatever." But, man, it just makes the difference. I don't know. It's like a tailor-made coat versus a coat you bought at Walmart or something.

Thomas: [Laughter]

Dave: It's just that different. It's cool.

Chris: I love this website. It's the coolest thing.

Thomas: Yeah, absolutely. This article is great. Patrick is from Microsoft, and I think Microsoft even entirely built this. Yeah, so sometimes on my team we just take the pleasure or have the pleasure of documenting stuff. So, I wrote the article on web.dev. Patrick wrote the article on A List Apart. Yeah, the more the merrier. The more we can get the word out about these features, I think the more apps will use them.

In the end, for us, it's all about usage. It's not usage in Chrome. For us, it's really usage in browsers on the Web. It can be whatever browser.

If I did a job with just making people use a feature in Chrome, I would do a bad job because, as I said, in the end, this is about the Web. It's not about the Web in Chrome. It's about the Web.

00:58:53

Dave: Can I ask one more question? I don't want to end on a bummer, right? [Laughter] But I feel like, if we don't talk about it (the big elephant in the room) a little bit, like Apple blogged or, on their blog (WebKit) about they're not going to support some of these Fugu APIs. I think there are 16 of them: Bluetooth, MIDI (which is terrible for keyboardists), NFC, stuff like this.

I know you can't speak for Apple. You can't talk about them, but has that shifted the plan? I think Mozilla said the same thing. Brave maybe said the same thing. Has that shifted y'all's plans kind of going forward for Fugu in what you're trying to achieve? How are you adapting to this kind of - I don't know - break-pumping, if you will?

Thomas: I think we have to say whenever any vendor says, "We don't want to support something," they have given us very valid arguments. In some sense, we may not agree with these arguments, but I guess in almost all cases this discussion around "Should a certain feature be supported on the Web?" has definitely helped the shape of this feature set, feature to improve.

Part of our shipping process is asking other vendors for their opinion. We won't stop if they say no, but we will definitely take their arguments into account. We will look at them. Sometimes our security story would be just a different one. Sometimes we don't agree with something being as much of a threat than another browser window security team wants or makes something to be.

But in general, yeah, we listen to everyone. We don't let us stop, but we will listen for everyone's opinion. Sometimes, yeah, as I said, we don't agree with those. But, yeah, in general, all the browser vendors have great people on these teams, on the security teams, on the engineering teams. Yeah, they built stuff, and of course, sometimes there are different motivations that even sometimes the vendors themselves can't talk about because maybe they're running a big native app store business. I don't know.

Dave: [Laughter]

Thomas: It might be some vendors in the space out there, but there are a lot of great discussion, definitely, with the engineers on the particular browser vendor teams.

01:01:29

Chris: Does that discussion mean that it's a no for now, but it's being talked about intelligently with reasons? That seems to open the door that maybe then the API could change a little bit such that everyone then does agree that it's a good idea because the original concerns have been addressed. Is that a possible outcome?

Thomas: This is definitely a possible outcome. We can say this because Apple have publicly said so. Apple builds features that they think make sense on the Web if developers want to use them.

They are working with Adobe as well. Adobe has said that they talk to Apple about Photoshop on the Web. As we said before, it's using the file system access API for some features. Apple have been convinced by the use case that Adobe have brought forward, but they need certain subsets of the file system access API.

In the particular case, it was about something called the origin private file system, so it's a file system that is private to the origin. You don't have to think about it as files on your hard disk. It's somewhere deeply hidden on your - I don't know - browser profile. It's not meant for looking at these files as a user. It's just files that get represented to the Web application as files.

Adobe uses this internally for essentially a massive swap file where, if you have a big photoshop image, that they could easily swap an image from in memory to disk memory. They have essentially, as I said, built sort of a swap file. Now, Apple is implementing this.

Initially, it was spec'd in just one spec, the file system access API spec, but also includes the picker methods, so show open file picker, show saved file picker and so on that Apple didn't implement. Because this situation occurred, the spec was split. Now we have a spec that is based on the discussions that are fruitful with the other vendor just partially implemented because this can't be. The spec was split into two. Now we have the origin private file system spec. It has a different name in the watch WG. We have a file system access API spec with the picker methods that has sort of been stripped away or stripped off the other origin private file system methods.

I think, in this case, definitely through this discussion and through this careful listening for arguments on either side, also listening for just use cases that people have brought forward and companies that have brought forward where we have, in the end, a better result that is something that everyone can live with.

01:04:24

Dave: Do origin trials help this, because "Hey, Adobe. If you want to do dangerous stuff or potentially privacy-invasive stuff like access file systems, great. Get in line for this key"? This feature may never come out to everybody but if you have a key, you can use this feature. Is that something that's helping or, I guess, mitigating some risk there?

Thomas: Absolutely. Origin trials have the objective of making sure that we build stuff that is right. If you build something that is sort of doing what it says on the ... but it has certain flaws and we were to ship this from the start, people would end up coding against this.

Once something is on the Web, it's very hard to take it back. You have to keep compatibility up. But if you just ship something as an origin trial, sort of the expectation is stuff is going to break. Whatever API shape you code against now might not be the final shape. It might still be, but there's a very high chance that some aspects of the API will break or will change before the feature ships eventually. This helps us test with real users and real developers how a certain API will behave once it's in actual developers' hands.

On our team internally, we call ourselves sometimes customer zero. We try stuff on small, internal play samples and demos and stuff and that we do for articles. But then once it goes out to actual companies like Adobe or whatever, people will sign up for these origin trials.

Of course, they have different expectations. They have different backgrounds. They have a different set of problems that they encounter in the real world.

They give us feedback, and they say, "Look, the spec says it should do X, but actually it should be X prime because blah-blah-blah. This is our use case and this is what we were expecting." Origin trials allow us to address this feedback and set everyone's expectations.

If you think back to Mozilla implementing WebKit window prefixes, this is stuff that we don't want to happen.

Chris: [Laughter]

Thomas: This is why we have origin trials so that we can have an origin trial where people still can build stuff that is in production on real users' browsers, but without baking it into the platform before it is too late.

Chris: Yeah.

Thomas: When they say, "Line up to get a key," actually, just going to the website (origin trials) and signing up for an origin trial is something that everyone can do. There's no you have to be a big company or there's no you have to have X users minimum. Everyone can really sign up for these origin trials.

It's a very low friction process. You add a metatag to your website. Then if people run it in a compatible browser, the browser will just enable this API in the current shape of the origin trial.

Yeah, once the origin trial is over, you won't even have to change, in the worst case. You can just leave it if you want to. Nothing will break because the API will just not be supported anymore.

01:07:38

Dave: But keys can be reverted if I was doing bad guy stuff, stealing credit cards, or whatever. You could yank my origin trial, right? Is that not something we can do?

Thomas: In this case, I think the key is really just a token that encodes: This is the origin, this is the API that you signed up for, and I think some metadata about what is the expected usage that you see. This is encoded in a token.

If someone steals a token, nothing really happens because the token is bound to the origin of your site. Even if someone steals your token, puts it in their metatext on their website, it will just be an invalid token that is not valid for this particular origin. You can just shout out your token into the world and nothing will happen.

Dave: Nothing will happen. Okay. Interesting. Cool. Thomas, thank you so much for coming on. We really appreciate it. This has kind of - I don't know. Do you think it's helped you, Chris, get vibes about Web-native?

Chris: Yeah, it does. It does. There are some points here to really dwell on. Some things that I kind of got wrong in my original post, which is nice to know. You know? And some things I missed and things that are interesting.

I'm so glad that this exists, that there are people (with the backing of a giant company) that are like, "We intend to make this better." The Web really does have some superpowers, right? We didn't even mention the fact that - but why? Well, because if you write a website, it can run on any platform that I don't have to worry about, like, "What's a native app look like on Linux?" Whatever. I'm like, "That just works because it's a website, and the URL just resolves because it's a website."

There are all these old, great things [laughter] about the Web, and it's what I want to hold onto. Not to mention that I don't have to write the app six times - or whatever - like, "Please, please let the Web win for that reason alone."

Dave: I agree. Thomas, thank you so much for coming on the show. Before you leave, how can people follow you and give you money?

Thomas: [Laughter] Give me money--

I guess my company gives me money, so people should not be giving me money. But yeah, how people can reach out. I guess Twitter is a pretty common way for reaching me, so we run a Chromium Dev account on Twitter. It's just the Chromium team. @ChromiumDev is the Twitter handle.

My private account is @TomAyac, which is also my domain name, my GitHub. And if you want to reach me by mail, you can also do that. It's just [email protected]. It's not a secret. Everyone, yeah, is really open on the team for communication and feedback requests.

Yeah, definitely do reach out. Don't be a stranger. We are all friendly people. Yeah. Thanks so much for the invite and letting me talk about all this because I hope that you can see that I'm really breathing for this stuff. I like the Web. I want the Web to win.

I don't want necessarily native to lose. I think there are still a lot of use cases where native makes a lot of sense. But for most use cases--

Chris: No!

Dave: [Laughter]

Chris: Just kidding.

Thomas: --the Web does make just more sense. This is where we want to go with Project Fugu and allow people to do just that.

Dave: Well, cool. Well, and you have a lot of good writing up at web.dev. Everybody, go sub to that in the RSS if you're not already.

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 16 tweets a month. We're going to resume videos over on the CSS-Tricks YouTube - probably. I don't know. We haven't talked about it, Chris, but I'm just putting that out there.

[Laughter]

Dave: We're getting back into it, baby! Oh, yeah! 2022!

Then join us for the ride to episode 500. And I'm trying to think. Chris, is there anything else you'd like to say? Oh, join us in the Discord, D-d-d-d-discord, patreon.com/shoptalkshow. Chris, do you got anything else you'd like to say?

Chris: Oh, ShopTalkShow.com.