449: JavaScript in 2021, Writing Workflow, Picking a CMS and Web Hosting, and Web Workers?
More on JavaScript in 2021, looking at Jay Hoffman's writing workflow, helping pick a CMS for fun blogging, helping pick a web host and the happiest path involved, and just what the heck are workers on the web?
Guests
Chris Coyier and Dave Rupert
Time Jump Links
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--still in my house. My shed is never getting done--Rupert. With me is Chris--comfortable in the booth with the just Miami vibes--Coyier. Oh, you're looking so good, Chris.
Chris Coyier: Oh, thank you, Dave. It's always good to talk to you. I woke up this morning thinking, "Gol, what's on my schedule today?" I was like, "Oh! I get to have a chat with Dave. I have this super busy day and I don't even care because I enjoy this so much. It's so cathartic to do this show."
Dave: Isn't it great?
Chris: It is.
Dave: You'd think after nine years, we'd get sick of talking to each other.
[Laughter]
Dave: Hey, here we are. It's fun. It's still fun every single time.
Chris: It is fun. You know I really enjoyed last week's show talking about ES Modules and all that stuff. I know that was really deep in the weeds, but I just loved that. It's just a different vibe of show when it's just me and you, but I am looking forward to figuring out what else we can -- I have a couple of ideas, but to extend that, like, what's up with JavaScript in 2021 thing. I think that'll be fun to explore.
Dave: We did the 2019 series, which is like -- do you think that was--?
Chris: I just looked at the year and I'm already checked out. I'm like, "That was two years ago."
Dave: Well, you would think that would still be super relevant.
Chris: [Snickers]
Dave: It is not! With this change into, like, IE is on the ropes of being just gone forever, IE11. Most people don't care about it. Even the -- Jason was kind of arguing, like, maybe you don't need it. If you just only output a modern bundle, you save so much code - and stuff like that.
Chris: Becoming a big talking point, this, like, we are shipping too much polyfilled code to all browsers, and that's kind of got to stop - thing. If the way to stop it is by stopping caring about IE, that's cool. There are other ways to do it that aren't that extreme.
Dave: Mm-hmm.
Chris: But if that's the thing that gets you to stop doing it, that would be cool. You're right. That was not what we were talking about in 2019.
Dave: No, but here we are. That's happening, this imports ES Modules. That's really, like, if you say, "That's my cut the mustard, that's my line of what's modern and not modern," wow, you open up so much stuff, so much simplicity, I feel like, because you're just like, "Import this thing from this thing." Okay, I know how to do that.
Or your code mod webpacking solution isn't like, "I'm going to go find this file on your computer." It's more like, "Let me just alter this to a URL that actually exists." [Laughter] It's just basically like resets your import statement. That's all it does, and that's kind of very cool to me.
Chris: Yeah. Yeah. Just to take this even just a deeper place just for fun to see what you think about it because you just mentioned importing, right?
Dave: Mm-hmm.
Chris: Importing, it's a big deal, as you build out a Web application, because it's how you write your JavaScript. It's how you write your styles, too, often.
Dave: Mm-hmm.
Chris: Even if it's in just Sass, or whatever. It's often a file at the top of a Sass file will have imports in it. I happen to be kind of neck-deep in a mono repo effort at CodePen. This is a year's long effort. It's not just like, "We should have a mono repo!" and then do that.
But I feel like I've talked about it a number of times. We kind of weren't. We'd be like, "Oh, we need a new Lambda. Well, let's just spin up a repo for that Lambda, write it all up, and then shoot it out." That was nice because the way that we could write deployment for it was just based on that repo, and you just rock and roll.
Dave: Right. Right.
Chris: Then, over time, it's like, yeah, but then that repo becomes this forgotten child, and the chances of it running the same Node version as everything else is low because it's just--whatever--it's just working. Just leave it alone. Or that it's got its own prettier RC. It's got its own everything. It's linted differently. It feels like it's not a part of the party and, when you pull things into a mono repo, you get the advantage that everything is a first-class citizen in your repo. I really kind of like that, as long as you get the deployment story right, which we figured out. It's kind of like that's -- it's just feeling more compelling, but it opens up some other problems. That's why I mentioned importing.
Let's say then that you write some little utility, or you have some constants. That's a big one, right?
Dave: Mm-hmm. Yep.
Chris: You're writing an app and you want to have one source of truth for some strings.
Dave: Enums.
Chris: Enums.
Dave: Enums, yeah.
Chris: Exactly. If you have three repos and three enum files that are repeated, you're kind of doing it wrong, right?
Dave: Right.
Chris: Because that's like, ew, those could get out of sync. So, you make a folder, say, at the root of your mono repo that's like your library, or maybe even call it constants because it's the thing. It almost would be a separate repo that other repos would import because that's where your enums are.
Dave: Mm-hmm. Mm-hmm.
Chris: But in a mono repo, you don't have to. But what you do have to do is figure out how to import them kind of cleanly.
Dave: Mm-hmm.
Chris: And so, you're in one area of your mono repo. The way that you write that import statement could be like: dot dot dash dot dot dash. Constants.
Dave: Yeah, and if the file ever moves, you've got to update the dot dot dash. Yeah.
Chris: Yeah, so I think developers have been annoyed with that. Somehow, you never see that. It's always like, "No, I will write Webpack config that sets that root."
Dave: Yeah.
Chris: So that if I ever do import constants/ whatever, it knows exactly where I mean.
Dave: I will. Yeah.
Chris: And it's config based.
Dave: Yeah.
Chris: That seems fine.
Dave: It solves for the thousand lines of code. I will do it.
Chris: I will! Yeah. There's no limit to technical debt that I will incur from making clean imports. I kind of don't blame anybody for that because it is kind of problematic to have too fragile of import statements.
Dave: You know what Nuxt does that I wish was a convention is, they'd use the squiggly, the tilde.
Chris: Hmm.
Dave: Like as root, so that's your project root. Nuxt, you can infinitely nest your pages.
Chris: Right.
Dave: Then they'll get routes automatically. That route then kind of misses, but they have the tilde for base URL, basically, or whatever, is what it probably would get transpiled to.
Chris: I like it because slash isn't enough. Is that too dangerous to use?
Dave: Yeah, slash, that's sort of just--
Chris: Too far? Too deep?
Dave: I don't know. Yeah, I guess slash would totally work, but then sometimes your slash isn't the same because you've compiled to a dist. Anyway, the tilde is a pretty cool convention there.
Chris: I agree. That is cool. But let's say you have to reach up outside of your Nuxt.
Dave: Hmm.
Chris: Your enums aren't in your Nuxt folder. They're up outside of it, still.
Dave: They should be. Yeah, they should be. I think that's where the tilde comes in because you go to the root of the project.
Chris: Then do dot dot slash.
Dave: Yeah, yeah.
Chris: Okay. Yeah, that's okay.
Dave: Then they do a little webpacking to yank those into whatever.
Chris: Right, and it's a standard, so it feels less fragile or whatever. That's one way to do it. Another way to do it would be symlinks.
Dave: Yeah.
Chris: In your Nuxt folder, say, in your mono repo, then you put (right at the root of it) a symlink to wherever the other thing you're trying to import is. Then it's magic.
Dave: It's kind of there.
Chris: I shouldn't call it magic because they've probably been around for a hundred years in computing, but the idea is you don't have to tell anybody what's going on. That folder (to the system) feels very much like the real folder.
Dave: Well, yeah. It's weird because you're like, "Surely, I made a hack that the computer won't get," right? But really, when you think about the folders, that's an abstraction.
Chris: It is.
Dave: All these things are just assignments on the disk, like 0XF00533. They're all just assignments on the disk. You create a symlink and it's just kind of like a fake folder that points to the memory address with another folder. Yeah.
Chris: Yeah, they feel unfancy, but they're not really. Yeah, and you can go ahead and look in your symlink and see what it is. The symlink is kind of a file that has a, "Where am I?" and "Where is it?"
Dave: Mm-hmm.
Chris: I've made them wrong before where I commit it and then, in the symlink, it was like, "Users Chris Coyier," you know?
Dave: Yeah. Yeah.
Chris: Then it doesn't work on somebody else's machine. I'm like, "Eh, yeah. Sorry about that."
Dave: That's one of those things. That and get merge. I've made a thousand million symlinks over the years, and I've merged a thousand branches. But whenever I do those, those are the two I'm like, "Hey, I'm just going to Google it because if I mess this up, I messed it up real good." You know?
Chris: [Laughter]
Dave: You don't want to do the backward symlink where, all of a sudden, you just whatever. Now your thing references the root of the hard drive or something. I don't know. [Laughter] Anyway, that's what I don't like.
Chris: I installed the thing that -- on my Mac, I found a way to do it where it's a service, so I can right-click. Mac, you can make an alias, but that's like a Mac-specific symlink.
Dave: Mm-hmm.
Chris: It's not real. That would be too dangerous to commit. You need a real-real symlink, like Unix style or whatever.
Dave: Mm-hmm.
Chris: Now I can right-click folders, go down to services, and say, "Make symbolic link," and then it makes a real symlink, which macOS also understands, but it's just not the proprietary one that Mac has.
Dave: Was that from your set app subscription? Did they go up and set it up?
Chris: [Laughter] No, I just think it was a Stack Overflow answer or something.
Dave: Okay. Well--
Chris: But I like it. I like it. So, okay, then there's this other way, though, which ups the complexity even again, which is: use Learna.
Dave: Ooh! Oh, yeah. Okay. You're going to have to give me a tutorial here.
Chris: Why?
Dave: I hear Learna, see Learna, and then every time, I'm like, "Let me check out Learna," I quickly nope out of it. But that's just me not wanting to....
Chris: [Laughter] It's exotic symlinks.
Dave: Oh, is it, really? That's it?
Chris: Yeah. Kinda. But I'm very new to this, so a tutorial, I cannot give you, Dave, but I can tell you that we've been playing with it because we've been trying to solve this problem and, so far, it has.
Dave: It's kind of the mono repo manager, right? Is that sort of its--?
Chris: Yeah, I can't imagine why else you would use it, but I'm only one organization, so I don't really know. But it feels -- [loud exhale]
Dave: Mm-hmm.
Chris: Some of it is internally facing, like I want to import stuff. I want to import my enums. I want to import more likely my design pattern library. And I want to manage that. Let's say you're using Nuxt, but I want to manage it outside of Nuxt. Maybe I have multiple Nuxt apps or something that just isn't Nuxt at all--and whatever--next to each other. I want to be able to import those like you would any other NPM package.
In your package.json, you're like, "Import this thing but locally." But it kind of looks like it's not local. It's just the name of something.
Dave: Mm-hmm. Okay.
Chris: Anyway, a little funky, but what it works is, when it does its NPM stuff. Guess what. In the Node modules folder, there's just a symlink sitting to that other thing on your disk. It's not that magical because, when you import something and then you run a bundler over it, it's going to look in your Node modules folder for that thing. Well, now there's a symlink sitting there to that other thing on disk. I think the magic is then, if there is some discrepancy in how that's handled on the other systems and stuff, that's where the value of Learna is, is that it will make sure that it deals with it for you. It's not like you didn't manually make that symlink.
Dave: Yeah. Yeah.
Chris: It kind of makes them for you, so that's cool. But I think it also is outgoing. That's the internally facing stuff, but I think there is some value in that let's say your Babble, or whatever, and you want to push to NPM all these different packages, but they're all in one repo. It can be helpful for that, too. I was, on purpose, trying to avoid having to publish to NPM or anywhere else. I made a change to my design pattern library. Now push it to NPM so that my other areas of my app can utilize it. I don't want to have to publish before I can use it. I want to hit command-S and use it.
Dave: Mm-hmm. Right, and I guess Learna kind of does all the auto versioning sort of help, right? Sort of for your sub-packages.
Chris: Yeah, but that's a choice. I don't think you have to version your packages. I think we're edging on not doing that because I don't really want to. I don't want to have an area of my site that has version 0.2.3 of my design pattern library and another area of the site that doesn't. I don't care that much.
Dave: Yeah, you're just going to -- well, what I like about the mono repo structure, I'm not -- I could go either way. I'm not committed. [Laughter] But what I like about that structure is, I think about it in terms of contracts, like, "Oh, I had to change the API of my--whatever. Calculate--"
Chris: [Indiscernible]
Dave: Calculate payment widget - or something.
Chris: Yeah.
Dave: Or function. I had to change the API to that. If it's in a totally distributed system, it's just like some function, Lambda function, calculate-payment.js. That's okay, but now I have to update that and land a commit in the main branch with the new API in every instance where it showed up ever. The chances of harmoniously landing those two commits goes down.
Chris: I know exactly what you mean. Yeah.
Dave: N number of repos. You know? The number of repos, it goes down.
Chris: It's a lot to ask to be like, "I'm going to change this API, and I expect the refactoring to be done absolutely everywhere that it happens, and those things are in things that are deployed separately."
Dave: Mm-hmm.
Chris: Ooh! Tricky, tricky.
Dave: But I've heard the converse. The tradeoff is there's a lot of activity if you're on a big team. Let's say, like Facebook or something. I don't know.
Chris: Mm-hmm.
Dave: You're on a big team that's doing a mono repo. It's a lot of activity in that repo. You say, "Okay, well, I'm just going to get pull." Seventy thousand commits come down.
Chris: Yeah.
Dave: You're just like, "Ooh..." So, maybe your -- the chances that you merge conflict are almost zero. Well--
Chris: Everybody is all over the place.
Dave: Everyone should be in their little sub-package, right?
Chris: Yeah.
Dave: Or their sub-folder. But just your thing becomes stale very fast, is sort of the issue. You could run into more problems the next time you start up, so.
Chris: Right. That's why this is a nuanced issue and that not everybody can take advantage of it. It's about people problems and organization problems and code problems. They're all tied together. It's not just a, let's solve the tech only.
Dave: Yeah, we're making something right now and bunch of Netlify functions.
Chris: Yeah.
Dave: We decided to change everything. [Laughter] Just obliterate everything. That's fine. But the Netlify functions, having those inside the repo is actually solid gold because we're just changing it and we just updated the functions.
Chris: Yeah.
Dave: It's kind of a really cool system, so we don't have to go far to make a big change.
Chris: Right.
Dave: We're just in the same pass.
Chris: But doesn't that highlight that exact issue? Your Netlify functions are public URLs. Let's say you make another thing that depends on it elsewhere - that's just deployed somewhere else. It's a totally different thing, but it needs that same function because that's nice. But if you change that API, you have no opportunity to ship a slightly modified version of it.
Dave: Yeah. Yeah, no.
Chris: Yeah. It just is what it is. I don't know. I don't know. These are weird problems, but they're fun to think about. You know? I'm trying to make it as simple as possible for us, like, how can all of these apps use the same design system? They're all React components, but some of them are, for us, in Next.js and some of them aren't. Even that is tricky.
Dave: Yeah.
Chris: Because it's like Next has its own opinions about how things should be structured. For example, we like CSS Modules. Next.js totally supports them. I'm like, "Ooh, harmony. Yay!" [Laughter]
Dave: Yeah.
Chris: That's cool, but it's also highly opinionated. It's like, if you're going to use modules in Next.js, then the file has to be called style.module.css.
Dave: Oh, okay.
Chris: We didn't do that, so now it's like, okay, I guess, let's refactor every single component to have that. That's a big deal. You just run a find and replace and you fix it, right? Not the end of the world, but it's like that introduces some possibility for breaking.
Dave: Yeah, if something was--whatever--expecting an endpoint at JS or something and now it needs to be module JS or something.
Chris: Yeah. Plus, Next is very -- it's not necessarily a normal, happy path to import components that aren't within the Next umbrella.
Dave: Yeah.
Chris: It can do it, but it's like a third-party plugin kind of thing to go grab a component from elsewhere and compile it.
Dave: You know what? This speaks to maybe my number one issue with adopting any kind of new tool is, there is the QuickStart guide. NPM install. NPM create my thing. NPM -- wasn't that cool? You know?
Chris: Right.
Dave: The path to "just spin it up, man" is so fast and so luxurious, you think, "Oh, this is amazing." But the path to integrate this into your thing sometimes is a world of hurt. Even for good software and bad software. It's kind of like sometimes the docs can be very misleading on the level of effort to roll it into an existing project. A lot of tools aren't designed for even existing projects. They're mostly designed for greenfield stuff.
Chris: It is.
Dave: That's my experience.
Chris: We're weeks into figuring out all this and having little hurdles happen that we just didn't know were happening at all, like the Next transpile modules thing I just mentioned, which is like, "Go outside of my repo and grab it." Well, it just wasn't working quite right with Learna for us, so we literally have this important package that we monkey patched. We had to yank it out of the Node modules folder.
Alex in there console.logging how it's resolving the files that it's finding and we're like, "Oh, weird. It doesn't like symlinks here," but I'm like, that's the whole point of this thing is that it resolves symlinks, but we had to change. We monkey patched the whole thing to change a false to a true and now we maintain this package.
Dave: Hey!
Chris: Oh, my gosh.
Dave: Congratulations.
Chris: But that's a world of hurt, as a way to describe it. It wasn't so awful that we couldn't figure it out, but it's like that's not anywhere near the happy path that it looks like it's going to be.
Dave: Yeah, the website is just--whatever--smiling group of people high fiving over computers. Then you're in here like, "I have to flip this to true?" [Laughter] "I have to write my own and fork this and make that say true? This is wild." That's computers, I guess.
Chris: It is.
Dave: That's been my experience is, like, "Hey, cool. Check out this cool thing. It makes you so cool. It makes cool websites." You're like, "Yeah. Great. I'm going to use that." Then you're like, "I'm going to put it in my project." Then you hear the record scratch. [Scratching]
Chris: Yeah.
Dave: There's me trying to import-- [Laughter] Anyway.
Chris: I know what you mean. You did the little romantic comedy interlude.
Dave: 1980s. That's me.
Chris: [Laughter]
Dave: Trying to import something into a package. [Laughter]
Chris: Uh-huh.
Dave: Yeah.
Chris: I know what you mean.
[Banjo music starts]
Chris: This episode was brought to you by FeaturePeek - a brand new sponsor. Thanks so much for the sponsorship, featurepeek.com.
Allow me to try to explain it. I think this is really legitimately super cool. Let's say you're working on your website and it's on GitHub, like every other website in the world. You do a pull request on it. Great. So, there's code that's going to be reviewed or whatever. Ideally, wouldn't it be nice if the pull request had a link and people could just click it and then see exactly what the website is like with that pull request in place? That's one of the things FeaturePeek does.
Imagine this. You install their app on your GitHub org. Then there's a config file. The config file that you put at the root of your project says, "Okay, FeaturePeek. My app boots up in this docker container and this port. Please do that based on the code that you see in this project, for us." Or "It's built from a static site generator, so this is a static site. It's in the dist folder, so please throw that up."
They'll then spin up a copy of the website at a special URL just for you so that anybody looking at that PR then opens up that link and is like, "Okay. Well, here's the PR with this working pull request code in place." So much better than just being able to check, you know, just look at the code and hope it's okay. It's so great to be able to look at what's actually happening there.
Then you follow that link and it's not just your app, but there is this sidebar there, too, which is like, "Okay. I have thoughts about this pull request. I'm looking at it now, and there continue to be problems," or I have comments or something. You open up that sidebar and you can comment on stuff. It's like a whole team product, you know.
It can be integrated with third-parties too, so it's like your GitHub stuff is right there, too. It's like, "Well, we track our stuff in GitHub Issues." Fine. Well then, in that sidebar, it's linked up to your GitHub Issues, so you can open stuff and relate it to that PR right from that URL. You're not managing multiple tabs and figuring out what's going on.
That's not even all FeaturePeek does. It's a really compelling product. The idea is that then you have to ping them as part of that pull request, like, run a GitHub action and tell FeaturePeek, "Okay. This PR is ready to go."
It just works in anything. It works in AWS Code Build, Azure Pipelines, or Circle CI - whatever. Just ping them and let them know that that PR is ready to go, and that's how it works. Really cool. Great product. Thanks for the support.
[Banjo music stops]
Chris: We have some interesting questions and comments from people, we'll get to, and then I'll interrupt us again and make Dave educate me on something else.
Dave: Oh, sure.
Chris: We had Jay Hoffman write in. Jay writes the "History of the Web" series on his own site and he publishes stuff on CSS-Tricks.
Dave: Beautiful. Beautiful. A thousand hand claps.
Chris: It's good. Yeah. I owe Jay. I want to do even more fancier stuff with the ones he publishes on CSS-Tricks because they're so good and interesting and cool. I'm glad somebody is documenting that.
Jay is a writer. You know? He writes great stuff. One day, these are going to end up in Wired or something. I feel like it's that level of readiness.
He says, "I believe you are asking about complicated workflows." Remember that, Dave? I've got one for you.
Dave: Oh, yeah.
Chris: "I used to track all my ideas for posts in a separate post status in WordPress." Even that is funny. You know? Like, invent a new post status that's not even draft, or whatever.
Dave: It's like idea.
Chris: It's like idea. Yeah.
Dave: Yeah.
Chris: "But since then, I've pulled them all out and put them in Notion. But I keep a running repository of longer notes in a different application. Notion isn't even where the writing is. Notion is just a list of links to another app where the actual writing is."
[Laughter]
Chris: Then he's like, "Now, this is where it gets tricky." I'm like, "Uh-oh. He really is convoluted."
"I really like writing in Gutenberg," Gutenberg being the WordPress fancy editor.
Dave: Mm-hmm.
Chris: Which I like, too. In fact, I listened to a podcast where Mullenweg is saying, "I want to open-source this thing so wide that it has nothing to do with WordPress. It's just the editor that everybody uses for anything."
Dave: Okay.
Chris: I'm like, "Well, that's actually a good goal. I love that."
Anyway, so he likes writing in Gutenberg, but he finds that he likes styling Gutenberg differently depending on the writing experience versus what it's actually like before publishing. Jay spins up a local version of WordPress just to have a customized version of Gutenberg in it just to have it how he likes to write. Then when it's ready to publish, he copies and pastes all of that into another site running Gutenberg, but is like the one on the actual Web, and then publishes that. Yeah.
Dave: Notion to a notes app to WordPress to WordPress to the email that comes in your inbox.
Chris: Yeah.
Dave: "I wouldn't have it any other way," he says. That's perfect.
Chris: Yeah.
Dave: Beautiful. Beautiful, beautiful. Well done, Jay.
Chris: Yeah. Love that.
Dave: You invented a monster.
[Laughter]
Chris: We've got another one here: Jason Laughton.
Dave: All right. Here. I'll read it. Jason Laughton writes in, "Help! I'm having analysis paralysis. I'm a WordPress dev by day and night, but I want to try out something new for my personal blog. Dave's comments about a personal blog being fun really resonated with me.
"I have a design concept worked out but I'm not sure what to use to power it. I could use WordPress. I want to try out something JAMstack-y. Ideally, I'd like to do the post pages via Markdown files hosted in Git with some sort of build process. I have a domain I host, so I'm not interested in Netlify, although, I feel like I could solve a few or most of my issues.
"I was thinking Gridsome, but I've never heard anything about it, so I'm not sure if it's a viable solution in the long term. Is 11ty a better solution? I'm not sure I'm interested in Gatsby due to the React requirement. I'm on team Vue."
All right.
Chris: Okay. Let's give him -- instead of giving you more analysis paralysis, let's just give you exactly what we think you should do, [laughter] like overly opinionated answers.
Dave: Use Gridsome. That's it. You're on team Vue. Use Gridsome. Just do it. Just do it.
Chris: Yeah, which we were talking about Nuxt. Nuxt and Gridsome, they're different things but they're related, right? Aren't they? They both do static site generator stuff.
Dave: Yeah, yeah, yeah. Gridsome is more -- what would be the--?
Chris: I don't know.
Dave: All the doc sites for Vue, almost all of them, I think, are written in Gridsome.
Chris: Are they?
Dave: If you went to a Nuxt site, I think Nuxt docs might be Gridsome. I don't know.
Chris: What?!
Dave: I don't know, actually, but a lot of the Vue doc sites are written in Gridsome. It's really good.
My friend Zach Meyer -- I can put a link to his blog here. He actually went through the same thing you went through, like WordPress. He does React by day, but he tried out 11ty. He spun it up. He was just like, "This is cool. I know everyone uses it and it's cool, but it's not me." Then he tried Gridsome and he's like, "This is me." It's a weird -- he's like, "I feel weird because, again, it's not the popular choice." It's not in the top five SSGs or whatever. But he was like, "This is just it. I feel productive in here, and I like it." So, there you go.
Chris: Cool. I don't really know the difference between Gridsome and Nuxt, but that would be -- that's wild. They both are highly regarded and people really like it. I don't even know.
The reason I've tried Nuxt a little bit recently is just because of how one-to-one it kind of seems with Next and I know Next.
Dave: Yeah.
Chris: I don't know Next, but I know it enough that it seems like that's nice to have that comparison to work with.
Dave: Gridsome is maybe more like Gatsby-ish, if you wanted to--
Chris: Hmm.
Dave: I don't know.
Chris: Does it have adapters for content? Oh, it's GraphQL internal. Yeah, I guess you're right.
Dave: Kind of in the hood, right?
Chris: Nuxt is to Next as Gridsome is to Gatsby?
Dave: Let's call that. [Laughter] That's my ignorant feeling.
Chris: Right.
Dave: Yeah, I think -- yeah.
Chris: We're saying Gridsome for Jason, and we're saying -- he's like, "I already have a host, so I don't want to use Netlify." Why? What is that host? I'd be fascinated to know what you think the thing is there because Netlify is just so easy and so JAMstack ready. It's two clicks to get it over there. I feel like it's almost more of a pain in the butt to try to wire up some old hosting with a deployment system than it would be to just use free Netlify. You know? But I don't know. I don't know what it is.
In fact, here. Let me. I'll derail us immediately. We have already answered your question, Jason. You're going to do your site in Gridsome and just put it on Netlify.
Dave: Yeah.
Chris: Done.
Dave: Easy answer. Done.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Algolia. It's a search company. It's like a search product. It's awesome. I've used it. Love it. It does a great job.
You need to give it stuff to search through. In Algolia, you sign up for it. They've got a free plan, by the way. The free plan is for anything under 10,000 search results, so pretty generous free tier there.
You've got to teach it. You've got to give it stuff to search through. Then once the data is in there, then you implement the search UI on your side, meaning you can build anything. The search experience is real-time, super-fast, but can be designed any way at all for your site because you hit it and it gives back JSON, which you can do anything with on the front-end.
What's cool about Algolia is it helps you with both things. It helps you get data into it to search and it helps you with the APIs and stuff for the other side, for designing the search experience in your UI. Pretty cool.
An example of that is plugins for languages that will help it suck in the data. You can also just go into Algolia and just type in. It's JSON, right? So, you put a blob of JSON in there and that's a record in an index that then can be searched, like all of it, and it does really intelligent stuff with search. You can help teach it and all that stuff.
There are plugins for WordPress or whatever, like, "Put all my WordPress data in there," and then I can build my own custom search through that data and that kind of thing.
On the flip side, then they have this library called instantsearch.js, which is just raw JavaScript, but then there's also an Angular plugin, React plugin, Vue plugin, and all that - if you want to do that. You'd say, "Here's my API key," and whatever. "Hook it up to that index." Then you hit it with search queries, and you just get data just immediately, super-fast data, which you can scope and finesse and do all that stuff. Build any kind of search experience.
Great product. Thanks for the support, Algolia.
[Banjo music stops]
Chris: Somebody wrote to me asking about hosting. It was one of those sites like, oh, I'll give you a couple of quick answers, but they had this legit thing where they're just like, "I don't even know what host to pick. There's stuff like GoDaddy and Bluehost and HostGator. Then there's stuff like Firebase has hosting and Amplify has hosting."
Dave: Mm-hmm.
Chris: How does Netlify factor in and Vercel? There's all this hosting and there is some degree of commonality and overlap to them. They host your website. That's a lot of commonality. But what's the difference? What do you pick? How do you possibly decide between all these things? I don't even know how to start thinking about it.
I started writing this post and now, of course, it's already thousands of words long. I'm like, "Oh, my god. This was a hard answer." But I'm curious how you think about those kind of things and if there is general advice to think about.
Dave: Like picking the right host or whatever?
Chris: I don't know. I don't want to throw somebody like HostGator under the bus because I don't really care if you have a happy time using HostGator or their price is right for you or it matches your needs. That's certainly fine. But it also feels like there is this bucket of hosts in that category that just are feeling a little long in the tooth in that they don't give you what these new hosts give you. They're not giving you SSL. They're not giving you an SSL or a CDN.
Dave: Yeah.
Chris: They're not helping you with the deployment story. They're not doing anything for you. It's starting to feel a little weird. What are you doing for me then?
But what they do is they run PHP and they run MySQL. There are a ton of CMSs in that bucket, WordPress included, and it feels like, "Well, no wonder you're still around because you solve this thing that powers half or more of the Web."
Dave: I feel like that you have to be like, "What do I need at the core?" Right? What are my core needs and how can this server meet my core needs?
Dave: If I'm building a static site, top of mind, some of it is top of mind, right? They have good developer advocates and evangelists, product evangelists, and stuff like that. And so, you're just like, "Oh, I thought of them. They're doing it."
Chris: Mm-hmm.
Dave: Is there an easy path? If I was building on the Goog stack, Angular, Firebase, blah-blah-blah, heck yeah I'd use Firebase for everything.
Chris: Right.
Dave: It is pretty compelling now, but that's maybe the easiest path to get forward. You know Netlify--
Chris: That's exactly what I was thinking is that it's about that happy path, right? It's like if I'm already using Firebase for a bunch of other stuff, doesn't it just then make sense to use the Firebase hosting too?
Dave: Yeah.
Chris: That's the happy path. Whereas, doing a Gridsome site and figuring out how to deploy it to my Bluehost is not a happy path.
Dave: Yeah. Can I even put Node on my Bluehost? I don't even know, man.
Chris: You don't know! That's the thing.
Dave: Yeah.
Chris: Here's the answer. Maybe. Kind of.
Dave: I mean it's a server. They have a server you could probably put Node on.
Chris: You can SSHN to it. You can figure it out. But is that a happy path? What happens if something goes wrong? Are they going to support it? There are precious little docs on this kind of thing.
That's why I was asking you the other day. I was mining for data, like, what comes to mind when you're like, "I want to run a Node server. What are you going to do?" Could you get it running on a GoDaddy server? Yeah, you could, but there's no way Dave Rupert is going to have that come to his mind as the first possibility.
Dave: No. No. I mean we had this the other day and we just picked up DigitalOcean. Some of the things are, like, "Oh, DigitalOcean? Oh, we can also just do a database," and "Oh, we can do a thing."
We had actually started out on Heroku and were doing there, but then we hit some weird limitation. I don't even remember what it was, but it was like we didn't have the proper database access. We have a proxied database access and we couldn't just use a tool to reformat the database. We were like, "Oh, we need a new host." We just tried DigitalOcean and it's running. It's $25 a month for all those servers. We're running like three or four servers. And so, like, whatever.
Chris: Those little $5 droplets do it for you?
Dave: Yeah. Yeah. The database--
Chris: Yeah.
Dave: It's kind of funny. I mean, the database, they start at like $15 for a database.
Chris: Yeah. Okay.
Dave: You can put a database on the $5.
Chris: Yeah.
Dave: But again, you don't get, I guess, the level of support. Anyway, we have one of their database products as well. But we're just basically like, "Can we do this?" Then if we wanted to do this again, oh, it costs $25. That's really not a big deal in the big, grand scheme of hosting.
Chris: Mm-hmm. I think people think of DigitalOcean because the amount of happy paths on DigitalOcean are many.
Dave: Mm-hmm.
Chris: They have a droplet for a Node server. A droplet can be anything, but they're ready to go. They might even have one for Gridsome. I don't know if they do or not, but there are a lot of pre-configured droplets where you're like, "Uh, I want that one. I want the Maria DB one," or whatever, or the Postgres droplet. Here you go.
Dave: They're a user-experience-driven company, is what I would say. They want your money, obviously, like capitalism. But no, they want your money. But they're a very user-experience-driven company - for the longest time.
Netlify is the same thing. I think probably any of the sponsors we have on the show are all the same, but they care about the user experience, the happy paths they're trying to mow down. If it's a static site, I'm going to go with Netlify because I just know they work really hard on it.
But then the other day, you and I were looking at AWSAmplify, right? Because we were just like, "Oh, maybe this is, you know, if I have all this AWS stuff, like an S3 bucket, blah-blah-blah, blah-blah-blah, maybe I just hit a button and it's there for me?" You know, a command line, and it's there.
Chris: Yeah. There are certainly happy paths on Amplify that are leaning into AWS services, like the happy path on Firebase is leaning into Firebase services. Let's say you're going to use Next.js. Who is the host for that? It's Vercel.
Dave: Mm-hmm.
Chris: Their homepage for it says, "Host on the platform made for Next.js." That's the happy path.
Dave: Yeah. Maybe you wouldn't even consider another one. I mean I know Netlify has been working on their Next support stuff, but that's -- yeah, it's like -- and then if I'm making a Rails app, Chris, you know where that's going?
Chris: Oh, let me guess. Heroku.
Dave: Heroku, 100 times.
Chris: Yeah.
Dave: I mean that's its bread and butter. That's what it was born out of. It is a Rails app. [Laughter]
Chris: [Laughter] Yeah.
Dave: But it does other stuff, too. Just because I have it pigeonholed doesn't mean you should have it pigeonholed.
Chris: Isn't that the funny thing because there's some muscle memory to this, too. There's like, well, you know, I have seven sites on Netlify so, even though I'm going to make a Next.js site, I'm going to put it on Netlify because I already know how all that works. I have a lot of built-in muscle memory for that kind of thing.
Or, like, I already do have ten sites on GoDaddy, or something. I know how their control panels work. I know how to SSH into their things. I know what to expect and what to get out of that.
It doesn't mean don't do it. Everybody is a little bit different. I just am talking about the happy pathing. If you're this person who wrote to me and they have no idea, my suggestion is to look for those happier paths.
Dave: Mm-hmm.
Chris: Python would be the same way. I'd be like, "I don't know. Heroku really makes -- they have a landing page for Python on Heroku."
Dave: Good.
Chris: It's like, I'm going to do that one then.
Dave: I'll do that one. Nah, if they care -- you know you can also ask your heroes in whatever language, like, what do you use? That's enough influence too. I think that makes a big deal. If somebody I know who deploys these kinds of products, they ship it out on this thing, then I'll probably do that same thing, too. I was just thinking about Craft CMS, a really cool CMS. You used to office with them.
Chris: Yeah.
Dave: You know, like, hey, maybe do it on DigitalOcean. I know a lot of people, Craft people, who do the $5 DigitalOcean, but they also now have a Craft cloud product, so maybe I'd just let them do all my hosting. You know? There are options there, too.
Chris: They have a hosting page for Craft.
Dave: Yeah.
Chris: I was looking at it just the other day of ones that they suggest. There are some pretty interesting ones in there, including names that I don't necessarily think of all that often. If Craft themselves is saying this host is ready to rock for Craft, and then I clicked over to the host company and it had a landing page for Craft too, and I was like, "That's a smart call," you know.
Dave: Yeah. Yeah. Yeah, that's how you do it. Yeah, you know, whatever. I put Craft on AWS before. It works. It's fine. It was a bit frustrating, but just from the AWS side.
Chris: Here's one: Cloudways. I don't know much about them, but "Craft CMS hosting with super-fast speed." They literally show Craft running on it and how they are really invested in PHP hosting and support that kind of thing. I'm like, gosh, that's great.
Although, it looks like maybe they're kind of like a reseller in a way. That's kind of funny. I think you start it with Cloudways and then they put it on a cloud provider.
Dave: All right. All right.
Chris: AWS, which is kind of interesting. That's a hard thing to explain, too. I'm not sure I'm totally qualified for, but to a newbie, be like, "Well, how does AWS factor into this?" Maybe the short answer is, AWS is the metal a lot of times. It's real low-level services.
Dave: Yeah.
Chris: You might find hosting providers that maybe they don't even tell you this, but they're built on AWS.
Dave: I think that's not -- I'm not an expert, but I think a lot of Heroku is that. It's just a GUI for AWS. [Laughter] A GUI you can use. Yeah, I mean the hardware comes from somewhere. I know sometimes they're just like--
Chris: Then why wouldn't you just pick AWS, Dave? It's DX, meaning developer experience, meaning they make it easier for you, but is it too much to struggle through just using AWS?
Dave: In my opinion. I think DevOps is a role. Could I say that? Is that controversial?
Chris: That's how I'm ending my post, Dave.
Dave: Oh, shoot.
Chris: It feels like I'm going to steal all your ideas. Well, I want to go through all this and get through this thousand-word article because I think it's going to be nice to point people to. In the end, it's like, if you're excited by all this, if this sounds fun to you and not a mess, you should consider DevOps because this stuff is hard.
Dave: Yeah. No, because that's my thing building out this little product. It's like, I want to offload the DevOps. I know that's fun and sometimes it's cool to play servers, but if I could just not have that a concern (as a small team) -- again, Paravel is three people. We bring in three other friends occasionally, four other friends occasionally. We're a small team and if one person is a bottleneck for servers or just stuff like that, that's tough stuff for a small team. But I feel like you could probably save money and you could probably get cooler stuff and have more value if you are a dedicated DevOps person or you hire somebody like that.
Chris: Yeah. You might get -- well, because then you're losing money on hiring the person, but you're gaining money in that you're not paying the overhead of some other host who is trying to make money on reselling AWS. You're just paying AWS directly.
AWS wants their cost to be really low so people keep doing that. We benefited from that at CodePen. You get an email once in a while that's like, "You know what's cheaper now? All your stuff. We just made it -- we found a way to just make it cheaper." You're like, "Oh, thanks. Yeah, cool." That's their style. I love that.
Dave: Sometimes, there's artificial limitations to hit billing, like, "Oh, you hit 4TB bandwidth on your DigitalOcean." You know? I don't know how quickly I'm going to hit 4 terabytes, but if you're on AWS, AWS is like, "We bill you for what you use." You know?
Chris: Yeah.
Dave: "Oh, you only had a 4 terabyte server, not an 8-ton terabyte server," or whatever.
Chris: Oh, my god.
Dave: Or like number of database rows. This is another common pay-to-play kind of thing.
Chris: Mm-hmm.
Dave: You're like, "I don't know how many database rows I'm going to need here," so.
Chris: Yeah. Tiered billing sometimes can feel kind of fair, although, the danger then is, what are my estimated costs? You don't just know. Whereas, if you buy the 4 terabyte--whatever--your cost is just going to be what it is.
Dave: Usually, there are some tells. Like if they have a gracious hobby tier, it's going to be more expensive when you get up to the big dog.
Chris: [Laughter]
Dave: You know?
Chris: Right.
Dave: Because they kind of got you. But, at the same time, they can also kind of price themselves out of the job.
Chris: Have you looked at the Contentful pricing? Contentful is this cloud CMS thing, which is really nice and I love their product. I love how they're dedicated to APIs. They're focused on one thing and one thing only. Just really dedicated to polishing what they have, and a generous hobby tier. The intro paid plan is $489 a month.
Dave: Whoof! Whoof!
Chris: What?!
Dave: But--
Chris: It's either free or $500 a month. [Laughter] What?!
Dave: That's a big jump.
Chris: It is a big jump.
Dave: I mean -- anyway. Is it? Aren't we supposed to be like drug dealers where the first hit is free and then, like--
Chris: [Laughter]
Dave: You get people. Then you kind of start--whatever--escalating it. Anyway--
Chris: Yeah, I think it gets a little dangerous if AWS somehow starts super perfectly nailing all the DX stuff.
Dave: Mm-hmm.
Chris: Then you're like, "Ooh. Why would I use anything else then? It's like everybody else uses you."
Dave: But that's--
Chris: I know it's more complicated because there are is Azure, which we didn't even mention, and Google Cloud Services, and everybody is fighting the same fight.
Dave: But if you're talking to old Dave Rupert and you're like, "Is $500 a month good for a CMS we don't maintain?" Oh, yeah, buddy. [Laughter]
Chris: [Laughter]
Dave: Heck, yeah.
Chris: Mm-hmm.
Dave: It's just up and it just works, then that's pretty good. I'm saying, on the flip side, because how many hours of Dave Rupert time is that worth? That's whatever. You know?
Chris: It's a good point. It's a good point. That number sounds crazy but it kind of is actually extremely inexpensive in some situations.
Dave: In developer time.
Chris: Yeah.
Dave: Is it important to your content people to have a good GUI? It might be, and it might be worth $500.
Chris: I remember learning this for the first time. A buddy of mine was working on a university and they were trying to buy a CMS. I was like, "They're free, so what are you talking about?"
Dave: [Laughter]
Chris: I can just install a CMS for you in two seconds. They were like, "But we don't actually have a team to maintain it." I was like, "Oh, interesting." You have nobody at all.
Dave: Right.
Chris: The deal would be that you need to deliver some really nice CMS-like experiments to people with nobody to maintain it. And so, if you're talking about then, okay, let's use a free CMS, well, then you've got to hire a staff. That's an incredible amount of money. Even if it was a handful of people, it's hundreds of thousands of dollars each year. That's just their salary and then there are benefits for all these people and insurance and stuff that the company is paying. You're probably looking at, for a staff of three tech'ers at a university level, it's probably getting close to $1 million a year.
And so, they're looking at a CMS that was $1 million and I'm like, "Okay, that makes sense to me now, all of a sudden." You have this million dollar budget for a CMS and it's actually economical to buy it? Well, that's how the numbers work out.
Dave: I have two thoughts. One time, the City of Austin put out a contract for a website and they paid some company in California like $2 million to build the website. It was proprietary Drupal. There was quite a bit of outrage in the local community because that could have gone into the community, you know, $2 million.
Chris: Yeah.
Dave: That would have bought a lot of beer here in Austin back in the day. Now, that's not a lot of money to me because I just understand the economics, like, a two-year project, ten developers or something. Maybe that's what it takes - or something like that. It was just kind of like, you know -- but the problem is, it's a proprietary....
Chris: When human beings get involved, the numbers change a lot, when you're talking about literal salaries and manhours.
Dave: Yeah, because it's like--
Chris: People hours.
Dave: It's literally digitize or search index every single--whatever--plumbing inspection in the whole entire city. You know? Like that stuff. That's not fun work.
I follow a lot of game dev stuff. You've probably known that if you're on the show, but the economics of that are really interesting. You think about 10 developers to make a video game at $100,000 salaries or something like that. Maybe you can go $60,000, $70,000 depending on the market. Let's just say $100,000 or something because it's even numbers. If you've got 10 developers at $100,000, that's $1 million a year. You're just burning through $1 million a year.
Chris: I'd almost double it, Dave, because I'm telling you the employees have all these other costs that aren't just their salary.
Dave: True, true. Healthcare. Whatever.
Chris: Yeah.
Dave: Whatever -- Office Max, you know. Get everyone a Macintosh or whatever, but yeah. You just have all these. It's expensive to run companies and stuff like that.
Chris: Now that's $2 million for one year for these 10 devs. How are you possibly going to sell something?
Dave: You've got to sell a lot of Mario Carts to make back that. [Laughter]
Chris: Yeah.
Dave: You know? Or skins in Fortnite or something. You know?
Chris: Which is why games are $65 or whatever.
Dave: Yeah. That's part of the reason, and they have ads inside of the games. [Laughter]
Chris: And they're limited. Hollywood is a little different. It's also very expensive to make a movie with all that staff and all that stuff. But I guess the idea is that if you make a big one that makes a lot of money, but then it continues to make money for forever. You know?
Dave: Yeah.
Chris: That's a long tail, which is probably less true of a video game, right?
Dave: Or even a website, yeah. You have kind of a big drop off after release day. You know?
Chris: Mm-hmm.
Dave: Unless you catch a second wind or something. Yeah, I don't know. The economics are just wild. This stuff is very time-consuming. [Laughter] Again, I just threw out that $100,000 number. If that's not you, that's awesome. Make your money. But I was doing that for easy math.
I hate it when somebody says, "Oh, developers should be getting paid $600,000." Wasn't that an ad for a job or something recently? I was like, "They should?" [Laughter] Anyway. I saw some Airbnb post for like $600,000 and I just was like, "Is that what -- we just chuck that out? Is that--?" [Laughter]
Chris: This is a fun one we'll end with, I think, from Ricardo G. who just has a question about terminology, which is kind of our fault sometimes for using words that we don't define particularly well. But this is a weird one because of how many things are named after the word "worker."
Dave: Oh.
Chris: "Oftentimes, I hear reference to "workers" or the "workers" API - what have you. I'm a designer. I'm looking to take the training wheels off when it comes to JavaScript development, but I find myself a little mystified on what "workers" do and what's the difference of them."
I found myself mentioning the concept of the specific Cloudflare workers recently, but that's probably less what Ricardo is talking about, unless he's listening to this show. There are two kinds of workers in native JavaScript that are easy to confuse. In fact, my coworkers, they know what they are. It's just confusing to remember to call it the right one, especially when you use both sometimes.
One of them is Web workers. Gosh, what a name, huh? But that's the kind that's a JavaScript file that runs on the client, so like in your browser it runs.
Dave: Mm-hmm.
Chris: But off thread, they call it.
Dave: Of the main thread.
Chris: Which means you have to register it. Then you tell it to do stuff. Now that's relevant because regular JavaScript that you execute in the browser is all what they call single-threaded. This was a special API developed just to do that. It can be busy working doing some other stuff totally independently of whatever else is happening on your page.
Didn't we have a guest on this, or something, and talk about it a bunch? There have been some people that have been on a crusade of, like, "We are not taking advantage of this enough in modern Web development."
Dave: Yeah. I think that Google is very serious about that, but it's also kind of a clumsy thing because you're like, "New worker, link to file." Do we even have link to files anymore?
Chris: Then you need some kind of pub/sub thing to wait for it to do stuff. Yeah.
Dave: Yeah, it's like a message and then you emit a message on the worker. But they're cool. They can do a lot of computation off the main thread and save you some jank.
Chris: Mm-hmm.
Dave: If you're doing complex calculations, it might be worth it to do that. Just put it somewhere else. That's what they always say, but what's a complex calculation? I don't know. Maybe you have to go through 3,000 lines on a CSV and turn it into JSON. Maybe that's a great place to do it.
Chris: Well, there is the gray, right? That one, to me, feels like firmly in the yes, of course.
Dave: Mm-hmm.
Chris: Of course, that's a worker. But how often do you actually need to do that? Then chances are, isn't that just like a Lambda or something?
Dave: Sure.
Chris: Aren't you making a server do that?
Dave: Well, and that's sort of this idea. If you think of workers as something that runs on a different CPU, with Web workers it's on the same CPU but a different thread. It's kind of just a different core, right? It's running on a different core.
A Cloudflare Worker is something that manipulates the code, but it's on a different CPU. It's not happening on your user's CPU.
Chris: Yeah, it's in the cloud.
Dave: If you want to think of workers as something that runs on a different CPU or core or thread, it's weird because you're getting down to the physics of the hardware, like where the code actually runs. Think of it that way. A service worker is a little bit different, but that's sort of--
Chris: Okay, so this also runs on your browser, but this is a totally different kind of worker.
Dave: It's a worker. You register it. It runs in a different thread, like a background thread. It's running in the background of your website. But this thing manages caching and fetching. One of its key pieces is the fetch. It can intercept a fetch, and so, whenever you click, whenever your browser says, "Hey, go fetch this file," or whatever, your service worker can intercept that and say, "Hey, I'm going to take over. I'm the captain now. I'm doing something with this."
You could literally -- whatever you want. If you want to change all the images to be like a picture of a cat or Beyonce or whatever, you can do that with service workers.
Chris: Super low-level -- low-low-low.
Dave: Yeah, basically, you're the network controller. You're in charge of the inbound and outbound traffic inside the service worker.
Chris: [Whistle] That's funny to think about it that way that a Web worker is to a Lambda as a service worker is to a Cloudflare Worker, kinda, because it also is based on the network and the URL transactions and stuff.
Dave: Yeah, and the same with like a Netlify function or whatever. It's kind of like--
Chris: That's more like a Web worker, a Lambda, but Netlify has this whole spectrum of them, so they have Edge Handlers too that are like Cloudflare Workers. Oh, my god. This is complicated!
Dave: This is complicated, Ricardo. You're very right.
Chris: I feel like I have it in my mind, but I can't explain it real good.
Dave: They do similar things. Service worker is like its own spec. It has its own API. It has its own superpowers. But then you get into the Cloudflare Workers, the Netlify functions, the Netlify Edge Handlers, these kind of AWS Lambda stuff.
Chris: And not Web standards. Those are just like things that some company provides. It's not native JavaScript.
Dave: Yeah, those are like tiny Node apps that just do one thing - more or less. They say, "Oh, you requested--" I don't know. What would be a great example? "You requested a file, like a secret file. Great. I'm going to request that file, but with API keys, and then I'm going to give it back to you. I'm just going to return that. I'm a little Node app that just sits in between your request."
Chris: Okay. Okay.
Dave: Or proxies or changes.
Chris: Let's do this, then.
Dave: Yeah.
Chris: We'll do, what's the perfect use case for a Web worker? Intense math calculations or something.
Dave: Big time math. You're changing the pixels on every single image of your page.
Chris: But you need to do it in the browser.
Dave: In the browser, yep. Canvas. You're manipulating Canvas or something.
Chris: Perfect. What's the perfect use case for a service worker?
Dave: Offline pages, like you say, "Hey, I'm going to -- when a user comes on spotty wi-fi, I want the service worker to return my offline page or serve them up a page I've already cached."
Chris: Mm-hmm. What's the perfect use case for, like, a Netlify regular function?
Dave: A regular function would be like proxy a request. Like, "Go get this but with my secret API key because I can't do that on my front-end because I would expose my API key."
Chris: Okay. Then an Edge Handler or a Cloudflare Worker, a perfect use case.
Dave: Okay. This one is tough. "Okay. Hey, I know you requested the account page, but guess what. I'm going to just put your little username right in there for you to make it look like I didn't make an extra request for usernames."
Chris: That's pretty good. That's pretty good.
Dave: Is that pretty good?
Chris: Good job, Dave.
Dave: I don't know.
Chris: A lot of these things use the word "worker" and they're all a little related but mostly pretty different and just blame developers for not being particularly creative. I'm going to give one to my coworker Dee, who is really funny. It wasn't about this specifically, but she was looking at a bunch of different Web nerd created metaphors.
Dave: Yeah.
Chris: Like Apollo is all space-themed stuff. Then we looked at five more and they were all spaced themed. She's just like, "What is with you fricken' Web developers? The only metaphor you can think of is space."
Dave: Yeah.
Chris: You're like, what's a good metaphor? Space. It's space.
Dave: Yeah. I wish it got better, but then you get into observers and it's just this all over. It's just--
Chris: [Laughter]
Dave: We've come up with a new word every three years and we just use it, or metaphor like space or atoms or whatever.
Oh, remember when we all had mascots for everything? Oh, man. That was-- [Laughter] We are just a hive of imitators. It's fine.
Chris: Yeah. Yeah. What happened to mascots? That's definitely coming back. Wait for that.
Dave: I need a mascot.
Chris: Maybe not this year, but it's coming.
Dave: ShopTalk mascot, what is it? It's just a -- I don't know.
Chris: A Canadian.
Dave: Mallard? It's a mallard?
[Laughter]
Dave: All right. Hey, thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.
Hey, we have a big announcement: a new website. We have a new website. Chris....
Chris: Let's talk about it next time.
Dave: Yeah.
Chris: But, yeah, we do have it. It is live now and the website is fine. I mean I like it because I like the simplification and I like some of the things going on.
But the bigger deal is that we wanted to put a big link in the nav that said, "Please join us at our Patreon." You can support the show that way. That gets you access to our Discord, so we can all hang out.
This is for superfans of the show. Do you love this show? Well, we love you back, but you have to then pay us. [Laughter]
You know what I mean. That's what Patreon is for. It gives you access to the Discord.
Dave: Keeps the riffraff out. Let's be honest.
Chris: Then we can talk and chat and have fun. Yeah, that's basically what it is, but it also means you want to be there and you want to talk to us and we want to talk to you. It's a little social contract for that. I don't mind it. Then once we're in there, we'll figure out what else we can do for you once we're there.
Dave: Sounds good. Yeah. Please sign up. It'd be great. We're still figuring out the community. There'll be a big announcement, but still figuring it out, so it's a great time if you want to jump in and whatever. We'll figure out the bennies of what this community is doing together, so we look forward to that.
Anyway, that's great. Yeah. Chris, do you have anything else you'd like to say?
Chris: ShopTalkShow.com.