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 Rupert, and with me is Chris Coyier. Hey, Chris. How are you today?

Chris Coyier: Couldn't be better, really. Well, I could be a lot better in a lot of ways. My arms are still broken, so that sucks, but -- [Laughter]

Dave: Hey. Well, you know.

Chris: If they were, really -- you know, it's funny how the body works. I really can't -- almost every day, feel better in some minute kind of way. It's just cool to see the body working that way. My physical therapist is like, "Your body is actually--" like, this is weird, but I guess it's not weird. This is weird to me for some reason. Your body is actually really busy fixing stuff.

Dave: Mm-hmm.

Chris: It's doing work. It's like your whole body is aware of it and it's changing. It's different than a normal day. This is a repair day, [laughter] which is kind of funny.

I guess that there's a way to segue that, probably, into what I was kind of hoping we could talk about today. I don't know. We'll just see. Sometimes, I like these episodes where I can just talk to you about stuff instead of answering a bunch of questions, which we'll do next time, but just kind of talk about what's on our mind.

Speaking of what kind of day we're going to have, let's say a particular kind of day was a brand new project day.

Dave: Mm-hmm.

Chris: I feel like these are so fun that developers force themselves into situations like this on purpose sometimes. Some side projects are, "I just want a greenfield something."

Dave: Oh, yeah. Just like no rules, no one telling me what to do, no legacy to care about. You're just new file, go.

Chris: Yeah! Let's just do it. Let's call this show Greenfield, and greenfield is a metaphor so, if that sounds weird to you or you've never heard that term before, it means, like, I'm about to build something and there's no barn on the land. There's not a skyscraper already there. It's just a field of green and it's on me to dig the foundation and build what's going to happen there. It's just a metaphor.

It's sometimes used even in existing apps. If you're going to build a new feature and it doesn't touch a ton of the rest of the app, you might say that's a greenfield feature on a product. More commonly, it's used, I'd say, like you're just starting from absolute scratch.

Chris: Mm-hmm. Yeah. Maybe you're on a team and we all do React, so your next greenfield has to be React to fit into the thing, but I don't know. It could also be, like, no, now is the chance to experiment with Svelte or something new. Maybe this is the time. Yeah, I don't know. It kind of depends on your situation, right?

Chris: Yeah, well, let's cover different situations on purpose. I had some ideas, like sites we could theoretically talk about, because I don't think it's fair to say, "Oh, if I was starting a greenfield project today, I would use React." You know? Maybe that is true for you, but that's a little weird.

Dave: I think most of the world operates like that, but yeah.

[Laughter]

Chris: It feels a little weird to choose a technology with no parameters whatsoever. You haven't even heard what we're about to say, so, "What?" You know?

Dave: React. Yes, React.

Chris: Yeah. [Laughter] But it's true. I think a lot of people do. It could be okay if you're just learning or if you're just screwing around or whatever, to pick a technology and then build something with that technology. I'm not trying to crap on that. But if you're building something kind of for real, usually there's a little bit of evaluation phase that happens first and you end up picking technology.

Forget the world. Let's talk about me and you. What would we do?

Dave: Hmm. Yeah.

Chris: I thought, well, there are all kinds of different -- you know, when I brought this up, I already had a bunch of ideas. Then you were like, "Well, somebody put a lot of thought into this already," or at least categorizing the types of things that you can build on the Web.

There is this article called Application Holotypes, which is kind of an awesome word, but isn't the point of that different?

Dave: Yeah. It's Jason Miller from Preact, and he kind of comes around. He's just trying to give, like -- I'm very much a fan of this, rather than just saying there's apps and sites. That means very little to me. That means literally nothing to me.

Chris: It's been a longstanding problem. I feel like when you say that, in people's head they get it. You're like, "Oh, yeah. Some sites are kind of app-like, like Facebook or whatever. Some sites are kind of blog-like, like my personal blog." I get that there's a very clear distinction between those two things. But then, once you start defining it and trying to draw lines, it gets real muddy real quick.

Dave: It's nonbinary, I would describe it as.

Chris: Absolutely.

Dave: An e-commerce site totally just wrecks your whole dichotomy.

Chris: [Laughter]

Dave: Jason sort of comes up with this idea of holotypes. There are maybe different kinds of websites, similar to there are different kinds of cars or something like that. That's how I think of it. There are SUVs. There are compacts. There are scooters now.

Chris: Sure. This is just a crack at it. I think he's done a pretty good job here. As soon as you read all the way through it, I feel like the "well, actually" finger goes up or, "I can think of something that doesn't fit into one of your holotypes." You know?

Dave: Yeah. Yeah, and I found myself doing that, but then it was just like, but it's not even worth the tweet. It's so minute. He goes through and gives an example of a holotype and then he gives maybe an implementation idea, like a single page app or something like that.

Chris: Right.

Dave: The big buckets are social networking destinations like Facebook, social media app like Instagram, like the actual app you'd use. Not like a portal; more like an app or something. Again, the distinction there is very muddy for me, but that's fine. Storefronts: Amazon, Best Buy, New Egg.

Chris: Sure. E-commerce.

Dave: Content website: CNN, CSS-Tricks, my personal blog.

Chris: New York Times.

Dave: New York Times, PIM websites.

Chris: Isn't that funny? Even the distinction there is crazy. I can't compare my site to the New York Times. Are you crazy? They're nothing -- yeah, but anyway. I get they're holotypes. They're holotypes.

Dave: Yeah, big buckets, big buckets. PIM applications: I don't know what PIM stands for -- personal information management. Maybe this is like Gmail.

Chris: Salesforce. I don't know.

Dave: Salesforce. Even probably like a health app, you know, something with personal information, so you've got a security layer kind of thing. Maybe there's rich text. Productivity apps, Google Docs, sort of like you click a field and you're editing in the thing. Media players like Spotify. Graphical editor like Figma. Media editor like Sound Trap, which I haven't really heard of, but you could think of a logic in the browser.

Chris: Something that helps you edit photos and stuff? Wouldn't that be a graphical editor? I don't know.

Dave: Yeah.

Chris: He's using a lot of audio stuff here, so maybe it's bringing that type of editor.

Dave: Yeah. This would be more like -- I use an app called Zencaster for another podcast.

Chris: Oh, yeah.

Dave: It's just a record in the Web.

Chris: We should probably look into switching to that at some point. It's so good.

Dave: It's just a neat tool. I still don't quite fully trust a website.

[Laughter]

Chris: I know. It's a leap. It's a leap.

Dave: Anyway, but it's good. Actually, it's pretty good for what I use it for. Engineering tools is a code sandbox, CodePen, these kind of like type in a thing and then it produces an output. That could probably go pretty far. I don't know if that's it's its own holotype exactly. How is that different than maybe a productivity app, really? But anyway, let's just say it's different.

Immersive games and casual games, he kind of put two different levels. You think of like a Halo shooter would be very different than whatever my, like, click a button and see a color.

Chris: A whole jumpy platform or something.

Dave: Yeah.

Chris: Hmm.

Dave: Yeah, yeah.

Chris: Well, fascinating. This is to add some nuance to the conversation of, is this a site or is this an app? It's just Jason's take on the thing, and so it's easy to have your own experiences be like, well, I might combine these two. This one is too broad, and that type of thing. That's fine. It's just to say that now that we maybe have some, a little more nuanced of categorization, then we can think of what kind of stack or what kind of technologies would we pick to build the things that are in that bucket.

Dave: Yeah.

Chris: Even then, I'm like, is that -- I don't know.

Dave: React.

Chris: Yeah. [Laughter]

Dave: Yeah.

Chris: Oh, gosh. It's funny, though. Because technologies do sometimes cross boundaries in weird ways, like I'm sure of all the React enthusiasts out there listening, you might thing, like, "Well, React actually is kind of." For example, we use it at CodePen to build a lot of it, and I don't necessarily regret it. I think it's been a pretty good choice for us.

Then there are tools like Gatsby that take what React can do and make it very, I'd say, pretty appropriate for a blog. Feel free to disagree there, but that's kind of their bread and butter is, like, this is for making static sites too, which means that now this one technology, React, can fit into two holotype buckets pretty easily. Weird.

Dave: Yeah, well, and if you had -- I don't know. If you think about, you built your big app, the big holotype, the productivity app in React because that made a good fit, then you're like, okay, we've got to do the blog now, the marketing blog.

Chris: Yikes.

Dave: We'll probably need buttons. We'll probably need headings. We have those components from the other site already written in React. Maybe we should just chuck out React components. To me, that makes sense. It's maybe not like -- what would you say?

Chris: Your ideal stack?

Dave: My ideal stack, but it totally makes sense. You know?

Chris: Yeah, sure. Let's get a little personal, quick, and then keep returning to these holotype buckets just for fun to change speed a little bit. Let's start really small. Let's say DaveRupert.com. We've talked about it before. It's Jekyll now. It doesn't sound like you regret that decision in any way, but let's just say. Would you, right now if you were greenfielding the thing, not necessarily a rewrite, but I'm starting this blog from scratch and I intend to run it for a couple of years. It's my personal site. What would you go with, do you think?

Dave: I would do 11ty right out of the gate, I think. 11ty is about to launch version 0.9, I think.

Chris: Would you pick it because you're still writing blog posts in Markdown, right? Would you stick with that as the data source, still?

Dave: Yeah, I would. It's funny because these are still the same holotype, right? But if I were in a CSS-Tricks situation, I would be looking at something headless like Sanity or Contentful or something like that.

Chris: Why?

Dave: It's sort of like a factor of scale. One blog post a week, I literally write about 40 blog posts a year or something.

Chris: Sure.

Dave: I think I have some data that can be like that's my output threshold. If I'm writing that many, that's not burdensome. But if I'm 10 posts a day or something, or 5, or 3 even, that's 900 posts. I can't even--

Chris: Why does the scale factor into this? Is that too many Markdown files?

Dave: I think compile time, literally just compile time.

Chris: Compile time. Okay. Has there ever been a moment where you're like, "Gosh, I wish all these posts were in a database instead of Markdown"?

Dave: Not for me. Not on my personal blog just because, honestly, it feels portable. Does that make sense? A folder full of posts that are dated.

Chris: Oh, yeah. No, I mean I get it.

Dave: It's just written in Markdown.

Chris: I like that.

Dave: It feels portable.

Chris: Yeah. Yeah.

Dave: What's funny is, I've tried to flip my blog to 11ty, but I'm a little too bound into Jekyll just for weird stuff because I'm using things like Jekyll's data layer and Jekyll's weird kind of template tags or whatever.

Chris: It turns a day project into a week kind of thing.

Dave: Totally, and I started. This is something, sort of the nature of the beast with projects or compiling locally. I can't even get 11ty to spit out my site. I have to go through every single error it hates.

Chris: Mm-hmm.

Dave: I haven't even seen the fruit of my labors.

Chris: Why the switch then? What does 11ty do?

Dave: Purely speed. Node would be one thing.

Chris: Yeah.

Dave: The speed of node.

Chris: It's JavaScript based, so you like that?

Dave: I think, yeah, it stays in my developer wheelhouse probably a little bit better than Ruby even though I probably consider myself a Rubyist. Ruby is maybe just not super threaded, maybe not super great at munging through hundreds of different files. A lot of my situations are probably conditioned, too, on my Windows switch. It is a lot slower. It's like 7, 10, 18 seconds to compile my blog.

Chris: Really?!

Dave: It's not rad. Yeah. Yeah.

Chris: You hit "Save" on a blog post, do you even have it set up to be like, "Don't compile on save"? [Laughter]

Dave: No, I do. I just have it compile on save and then Jekyll has live reload now, so that's cool. But I would purely do it for speed.

Chris: Speed.

Dave: I think I'd get some speed gains. WSL2 is coming out.

Chris: Speed and then developer convenience. Okay. That's cool.

Dave: It's going to change my life.

Chris: It'll throw some curveballs at you, though. Let's say, all of a sudden, it's not just you anymore. There are three authors of this blog.

Dave: Mm-hmm.

Chris: What does that change? Do you think sticking with Markdown is fine there? What would you do for the author? Just front matter it?

Dave: Probably. Yeah, I think I could go pretty far with 11ty in that situation.

Chris: Mm-hmm.

Dave: Again, it's sort of like velocity. Is it three people still posting once a week or is it three people are now going to try to make this a business, turn it on, and do it three days a week or whatever? I think that would change my--

Chris: Okay, now we're still here and you're like, these two people you hired just aren't developers at all. Would you be like, "Well, too bad. Just send it to me in Word, Dropbox Paper, or something, and I'll drop it into the site"?

You're in a situation now. You're building a mini client site with multiple contributors. You realize, "This JAMstack thing is still kind of cool. I like 11ty or whatever, but I need a contribution model that works."

Dave: Yeah. No, totally. That would be a major hang up. I don't want more work, Chris.

Chris: Yeah.

Dave: That's what I'm optimizing for.

Chris: Don't send me your Word document to post on the site. I can't. No.

Dave: I mean I can do that. I can do that, but Netlify CMS, that's a pretty cool piece of technology just to hook into my Git repo and give somebody a UI who needs a UI. That's totally fine that they would. I don't want to be elitist or something like that.

Chris: Do you just like that it exists or do you think you would actually reach for it?

Dave: I think I would actually reach for it. I would probably consider it.

What do I want to say here? I think most marketing sites, which maybe this falls into a content site, the same holotype, but most of those are basically static sites. They could live as static sites.

Chris: Sure.

Dave: A lot them we put on CMSs and you do all that work just so people can edit it and stuff like that. I think -- I don't know. I would try the Netlify route. It's sort of like -- what does Jeremy Keith always say, "The principle of least power," or whatever?

Chris: Yeah, he does use that, but it's also a principle of the HTML spec or something. There's a standards body that has that mantra.

Dave: Yeah. It's just this idea, like, use the least powerful tool that gets the job done, sort of. It's like less moving parts. At the same time, now, compiling a static site, I feel like most marketing sites and a lot of that could be that.

However, you go a little bit bigger, 200-, 300-person company. It's like, are you really managing all your content through a static site or should you have Craft CMS, which is also another great product?

Chris: Right.

Dave: Maybe you do need to grow up at some point. I still think that's valuable, so I'm not negating that.

Chris: You would really reach for Netlify CMS in some kind of three-person static site still makes sense situation and then maybe a step beyond that with maybe possibly hundreds of people and a more complex CMS Craft.

Dave: Complex CMS Editorial Flow is a big one, right?

Chris: It is, yeah.

Dave: How much do you use draft posts on CSS-Tricks?

Chris: All the time.

Dave: That's a huge part of your business, right?

Chris: Yeah, Netlify CMS does have an editorial workflow thing that you just either flip on or flip off. It would be off if you just don't care and you're just like, "I just made the edit. Just go," or on if you want to be able to save it and have different steps of review and stuff like that. They've thought about it, which is pretty cool.

You mentioned the brochure sites and the editability of things, though. Let's switch gears to that for a minute. Let's say it literally is just like one of those scrolly marketing pages. It's got lots of three boxes in a row. It's got a hero. It's got headlines. It's got paragraphs of copy, but stuff changes. You're delivering this for somebody who wants to be able to edit the thing. I'm sure you've been in that situation for client work before. What kind of tooling, what kind of stack for that kind of situation?

Dave: We recently had really good success with Craft just because Craft kind of has this--I forget what they call it--blocks. Is that what they call it?

Chris: Is it putting you in in a page builder situation where you're dragging stuff around?

Dave: Kind of, yeah. You can kind of drag and build a page. Then you just specify what component that will block maps to. I'm sure Gutenberg sort of does the same thing.

We had a client and we made a design system for them, handed it off, and then a month later or whatever they were like, "Hey, we took all your components and made a page." It was like, "Great. Those are your components? This is awesome. It looks great. It spit out right."

Chris: Yeah.

Dave: You did a good job on the content sizing and everything. This is great.

Chris: Cool.

Dave: That's the sort of stuff. If we were on the static site thing, I don't think even as smart as maybe Netlify CMS is, I don't think it's like, "Yeah, drag this component in and now you're using that."

Chris: Ah, yeah. Just that word "drag" makes a big difference here.

Dave: Right.

Chris: It's putting you in the, like, "Well, should we be looking at Squarespace? Should I be looking at a page builder for WordPress like a Divi kind of thing?"

Dave: Webflow.

Chris: What if I teach them Webflow? Yeah, or something like that.

Dave: Yeah. Again, I think it's like, what do people feel comfortable in? Craft is very developer -- it's that, like, I'm editing fields in a database field. [Laughter]

Chris: Yeah.

Dave: But the live preview part of it is super good. It's like, click a button; you're live previewing your changes as you drag stuff around.

Chris: Mm-hmm.

Dave: That's going to be--

Chris: Gosh, that dragging thing. I also think of, like, a tool like Mavo. Have you seen that?

Dave: No. No.

Chris: Mavo.io. There's been versions of this over time, forever, I think, which is kind of like, just put some attributes on some HTML and a UI will appear over those elements after you log in that allows you to edit them, in a way. There's all kinds of clever stuff you can do.

The idea is, click edit. Edit the paragraph. Hit save. Done. You've edited the website, in a way. Lee Verou built this thing, I think.

Dave: Yeah. Yeah, it's intelligently built here.

Chris: There's clever stuff, though. There's, like, well, what if you want to upload a photo? Well, it's got stuff for that. What if it's a repeating field? Well, it's got stuff for that, but it doesn't necessarily give you, like, drag this in, drag this out.

I'm not sure where the limits, where the line is with Mavo. I think it's kind of fuzzy, in a way. Then where does that data go? Well, what's cool; it has all these extensions. You can send that data to GitHub, Dropbox, or what but the data store.

Dave: Have you seen Vapid?

Chris: I don't think so.

Dave: I should write a post.

Chris: You should.

Dave: It's Vapid.com. It's a weight shift project, so Naz Hamid and Scott Robbin.

Chris: Yeah, I've seen this.

Dave: I should write a post for CSS-Tricks about it. You just write HTML and then you hit Vapid in your command line. Then it generates the CMS based on your HTML.

Chris: Oh, nice. Like Perch does that.

Dave: Yeah, and so it's just like, boom. It's up and it's running on your machine. Then you hit Vapid deploy and it goes out; it deploys it out.

Chris: You have an index.html file that has these special Vapid things in them?

Dave: Headline, intro.

Chris: Then you edit. Then what happens? Do you have index.vapid.html and it compiles down to index.html? How does it combine?

Dave: It's create the CMS, and so you'll get, like, home in your CMS and you'll have, like, headline and intro that you can edit. Then you hit save, and that goes out to a data alert. Then I don't know if it is a static site generator on top of that that compiles those pages out.

Chris: It would be interesting if it wasn't, if it's like Vue or whatever where, like, the HTML comes down with a bunch of stuff in it and then JavaScript loads, gets the data, and replaces all the data in there. Maybe that's how.

Dave: Yeah, I think it makes a static page. That's what I remember the last time I played with it. I think all that data is also backed in, like, a Mongo of some kind or something.

[Banjo music]

Chris: This episode of ShopTalk Show was brought to you in part by Stackbit, stackbit.com/shoptalkshow. Stackbit is super cool. I swear to God.

Static sites, this JAMstack stuff, we talk about it around here all the time. It's growing fast. Front-end developers like us, we kind of get it already. It's really fast. It's really secure. It has all these developer conveniences. You get full control over the markup, the design, but the client's part is a little trickier. They're like, "Well, what do you provide for them to update their content? Where's the CMS?" It feels like that's a little bit of a hiccup in the super mainstream adoption of JAMstack in a commercial context is about solving that issue. That's where Stackbit comes in.

Stackbit allows you to build and deploy a full JAMstack site with the static site generator and a headless CMS in just a few clicks. That's the thing about it. You choose. You start with a theme. You don't have to. There are multiple ways to do this, but it's kind of like a wizard of, like, I'll take this theme on this static site generator with this headless CMS.

There's work to do when you're setting that up. All of you all can do that, probably, but it's like, wouldn't you like to just go, like, click-click-click and then you have it, it just deploys to your Git repo, and it's ready to use? The CMS all hooked up and all that stuff already is pretty great.

On top of that Stackbit just released custom themes. Now, if you've already built the them and you're working on a static site generator already, including the ones … plus like Gridsome, VuePress, and some other ones, you can put a Stackbit configuration there, stackbit.yaml file, and define the content … that your theme is already using and then connect it to any of these headless CMSs. It's pretty cool. You can use a part of the build process.

Stackbit allows you to test the strength and weaknesses of different headless CMSs because of that reason. It's easy to explore the different ones, which is pretty cool. We're talking about, like, Forestry, Netlify CMS, DataCMS, Contentful, that kind of thing. The SSGs are like Hugo, Jekyll, Gatsby. It's just a lot of combos there. It's all very exciting to me.

It just goes to your own repo, too. Stackbit just helps you get it all done but, in the end, it's just your code. Go to stackbit.com/shoptalk to feel the magic. Let us know what you think.

[Banjo music]

Chris: All right, so we've talked about possibilities, but let's force you to make a choice here. Making a brochure website, it needs to be pretty darn editable by clients. What are you reaching for, for real?

Dave: On that one, probably still in Craft. This is the other part of Jason's holotype post or the counterweight to it that I think is not covered is, what is the client comfortable with? I think I would be like, yeah, or Trent has kind of advocated. I think most people just need a static site like Netlify or CMS.

A lot of clients aren't ready to make that jump. They're very comfortable with this idea of a CMS that I edit content, but I think most clients aren't ready to make the jump to, "You know what? We're not doing a CMS. We're just going to edit in code directly." Netlify would bridge that gap, potentially, but this, again, that I want to drag and control the page. We've also found that clients, to some degree, really want that ability.

Chris: Right. Right. Right.

Dave: I think you have to offer that in a real world scenario.

Chris: That's what's so appealing to me about sticking with something like Craft or WordPress is that, even if you're building something simple that you've got this massive wrench that you can use in case something else comes along.

Dave: Right. Well, you'd mentioned WordPress. It's been a good long while since I've done a WordPress site, like big time.

Chris: Mm-hmm.

Dave: You know, a situation like that, you've got to think, like, who is going to maintain it? Am I going to sit around and maintain this site for the next 12 years?

Chris: Sure.

Dave: Or should I hand it off? Maybe I hire a junior developer. WordPress's ubiquity makes a very strong candidate.

Chris: Well, I think of, okay, we had three authors. Well, all of that stuff is built right into WordPress. There are users. You pick the author from a drop down. Done. You get the three author thing. You don't have to think about it. It's not like, "Oh, how are we going to make this happen?"

Dave: I've got to get them a Netlify teams account. I've got to them onboarded to Netlify.

Chris: Yeah. Right. It's all just interesting tradeoffs. But then where was I going with the author thing? The permissions thing, I think, is such a big deal, too. It can be just a weird afterthought sometimes, but it doesn't need to be.

Oh, now you've hired a fourth person and they should be able to write their own posts but not mess around with anybody else's posts, or something. They're like an author, but not an editor. But really only one of these people should be able to make new users. Well, they're an admin. Well, stuff like that, you're just kind of like, "Well, of course that's in WordPress, Craft, and stuff. Duh."

Dave: Yeah.

Chris: But you don't get stuff like that automatically with other workflows. As much as you like some static situation, and I do too, sometimes you've got to think about that stuff, the possibilities where you paint yourself into a corner.

Dave: I bet that's important for you in WordPress. I mean you don't want some whatever cold call writer to have access to every post historically, like dropping their own links to their own websites.

Chris: No. I use literally every single permission level in WordPress for different users.

Dave: Flipping it back on you, if you were going to redo CSS-Tricks today, what would you…?

Chris: I can't imagine not picking WordPress but, front-end stack, I would maybe change it.

Dave: Ooh!

Chris: I don't know.

Dave: Okay.

Chris: I take advantage of every feature WordPress has with all these custom post types, customizing the admin screen, and custom fields. I've got WooCommerce in there for selling stuff. I've got bbPress in there for forums.

Dave: It served you well.

Chris: It feels almost like WordPress was made for this site, in a way. Maybe that's the cart/horse. There's some stuff there because the site is so old that I, on purpose, have taken advantage of some of the things that it can do. But my gosh, is it perfect for the site - kind of. It's not like I can't imagine what it would be like in Craft or something. Sure. Other CMSs could probably replicate a lot of this stuff. Look at something like Smashing Magazine, which has a ton of feature sets and they've managed to go JAMstack with it. It's not impossible or whatever, but I have no regrets here. I think it's a good system.

Back-end wise, it's not messy but it's not great. Lately, I've been very convinced by the idea that building in components is so great for design, development, and flow. I wish the site had been architected from components so that I could have used a real design system that uses those components. I don't know any other good way of doing that other than JavaScript.

Maybe a Vue front-end would be cool or a React front-end, or pick Next, Nuxt, Gatsby, or something to build that front-end out, which gives me the components and puts me in a static structure so I can prebuild pages. It may be a little big these days for prebuilding pages, so I'm not sure that's right, but I am kind of envious of working in components front-end-wise. If not for that, I probably would pick some kind of WordPress thing that's more architectural these days like Twig and Timber or whatever that kind of gives you controller view separation, I think I might choose.

Just after all these years, my theme template is just very big. I have a functionality plugin that's very big. There's a lot going on there that could be cleaned up, I think. If I couldn't go all JavaScript front-end, I'd want the PHP side to be cleaned up, in a way. No regrets on the stack otherwise.

Dave: Yeah, I think you were able to grow CSS-Tricks into the Lodge and BuddyPress or whatever, like the forums.

Chris: Yeah. Those things come and go as well. At the moment, neither of those things are particularly active. [Laughter]

Dave: Right, but it was at one time.

Chris: Yeah.

Dave: It's kind of a good anchor point, source of income, or whatever - decent ad impressions or something from the forums. Doing that yourself, that's kind of hard.

I don't know. If you were to, like, "Okay, I've got to stand up like a Vanilla Forms, a Spectrum Chat, or whatever, and then I've got to do this," that's a lot of work but it's kind of cool that WordPress allows you to grow up and add on kind of big features. You did the Lodge for a while, right? Like paid video subscriptions.

Chris: Yeah.

Dave: Are you still doing that?

Chris: No. No, it's turned off for now. But I'll tell you. Just the other day, I installed WooCommerce again because I was toying around with potential ideas. I'd be like, "Gosh, it's stupid not to have something to sell, even if it's just something little, as long as that's low effort for me." Not low effort, but you know what I mean. Not like changing my career to do this. I think it's always nice to have some kind of call to action that can make you money.

Dave: Man, that's my Achilles' heel. We do the podcast. I guess I have stuff to sell, but I wish I had a product.

Chris: Yeah.

Dave: I wish I had, "Pay me $9.95 and this is what you get." I don't have that as a Dave Rupert.

Chris: No, and I understand. Don't you want that? I want that too. I have CodePen.

Dave: It would be cool.

Chris: I have some things like that and CSS-Tricks, specifically, as big of an audience as that is, it doesn't have that. I'd like to build that, I have some ideas for it, and it can involve a bunch of different things.

The Lodge, just through time, you get to know yourself and what you're capable of more. That was fine. I would do it again if that was my job all day. It's not. CodePen is my job all day.

Dave: Right. Right.

Chris: Ultimately, I ended up feeling guilty about the idea of people paying monthly for this thing that has kind of out of date videos on it that wasn't like, you're not getting new content every week or month. I'm not sure that, at this point in my life, I would put that back in place just how it was because the guilt got to me.

Dave: I hate to talk about money. I know you did the Kickstarter, and that was amazing. Everyone was like, "I'm going to do a Kickstarter now." Was most of the money made upfront on the Kickstarter or was it kind of made up over the longtail?

Chris: Yeah. This was a lot of years ago now, but it was in the -- oh, god; what did it end up at? $70,000 or something, all those years ago. All I did in the Kickstarter was promise that I was going to redesign the site, record some videos of me doing it, and you get access to those videos, but those videos will just be the first of more videos that I plan to shoot. You'll be a member of this exclusive club if you back me on Kickstarter. Also, after it goes up, people can pay for it. You'll just get it cheaper from the Kickstarter kind of thing.

I literally did all of that. I came through on it when I said was going to and stuff, but I ended up making nothing from the Kickstarter itself, pretty much, I think, because you got a T-shirt, which was totally expensive to produce and send to everybody. The number that you make on Kickstarter doesn't matter, in a sense, because it's like if your costs per person are high enough, you spend it all fulfilling the things.

Dave: Oh, yeah. Every time a Kickstarter I did, it's like, "Okay. The stretch goal: if we get more people and more money, we're going to explode the scope." I'm just like, "No! Please, give me the thing. I don't want more scope."

Chris: Yeah. When you change the scope just based on numbers, that doesn't work out. I understand there's an emotional obviousness to it. You're like, "Well, we were making $500,000. Now we're making $1 million on this Kickstarter, so we'll give you twice as much." You're like, "No, you have twice as many people now that you have to fulfill." I don't know.

Dave: Yeah.

Chris: You get it. It's crazy. And taxes. It's just income. It's just straight up income.

Dave: Yeah.

Chris: Depending on where you're at, if you make a million dollar Kickstarter, you're in a fricken' high tax bracket. They're going to take half of it - half.

Dave: Yeah, well, and Kickstarter takes 30% or whatever. Yeah.

Chris: Yeah, so now you've got a fraction of what was left. You've still got to fulfill all these promises. I don't know how many people lose money on it, but we came damn close.

Dave: Yeah.

Chris: Then you factor in all the stuff that we said we were going to do for the design, like, "I'm going to hire these illustrators, hire all these content strategists, and all that stuff." The money goes there. It's a wash in the end, at best.

Dave: Yeah.

Chris: But that was the thing, though. That's what Kickstarter is supposed to be. It's supposed to kickstart some future thing that you're doing, not be the sole source of success and income for your thing.

That's literally what happened. I launched the Lodge and then people would sign up and pay for it and stuff. Did I do particularly well on that? not really. I doubt it was Wes Boss money.

Dave: Not Wes bucks, but it's--

Chris: No.

Dave: Right.

Chris: I sure as hell didn't make a million dollars on it. Then the guilt got to me and I just shut it down. That doesn't mean you can't be like, "Well, okay. It's shut down for now," but here's the idea, essentially, Dave. I don't know if I'm actually going to follow through on this or not, but I thought it's stupid to have a publication called CSS-Tricks for 12 years and not have some kind of compendium of the best stuff on there. I feel like I could write a book about CSS. I never have. Not maybe just like the basics of CSS because that's been done six ways to Sunday. Not that people can't continue to do that. I don't care, but I don't know that I have anything to add to that story, necessarily. Although, we'll see.

How about one called CSS-Tricks? That'd be a pretty good book.

[Laughter]

Dave: Yeah. Just dumb stuff you can do with CSS.

Chris: I've already, of course, played around with the idea a little bit, but why not? It's a book and people like the artifacts. Sell that thing. In WordPress, that's a no-brainer. That's a one-day project to get that going on CSS-Tricks because of WordPress. I don't have to do anything. Install fricken' WooCommerce, upload a PDF, and I know there's more to it than that. I'm underplaying it.

Dave: No. No, I think that's the Smashing model right now, more or less, is trying to upcycle some of this content into webinars or into different books of some kind.

[Banjo music]

Chris Enns: This episode of ShopTalk Show is brought to you by something really cool. It's an alternative to .com. It's the .design domain name. In general, I'm a big fan of interesting, unique, good URL website names and especially alternatives to .com. If you're a designer and you've thought of a sweet name for your website and it isn't available under .com, check out .design. Chances are the domain name you want is waiting for you.

You can head over to Porkbun.com and use the coupon code SHOPTALK on the checkout page to get your free .design domain name for your website. Yes, you heard that correctly. It's a free year if you go to Porkbun.com and use the coupon code SHOPTALK on the checkout page and get a free year of a .design domain name that's bundled with free email hosting, WHOIS privacy, and SSL certificates.

I don't really consider myself a designer, but I didn't want to miss out on the fun of registering a .design domain name, so I registered IPodcastBecuaseICant.design, which you can go check out and see how it worked, but there are plenty of fancy companies using .design like Airbnb.design, Facebook.design, Uber.design, Adobe.design, and many more. It's exactly the same; just a domain name. Google doesn't care and it functions the same way as a .com or .org. It just looks a little more interesting.

Go check out Porkbun.com and use coupon code SHOPTALK at checkout to get a free year of a .design domain name. Our thanks to Porkbun for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: Well, let's talk e-commerce for a minute. You're charged with making an e-commerce site. Let's say it's a car parts store. They have 10,000 products. It's in Magento now. I don't know, but that's not greenfield, so scratch all that.

They just want to sell it and they have a large product catalog. You're making this thing from scratch. There's going to be a lot of data entry and you're going from scratch e-commerce. What are you going to do, Dave? Do you Shopify it for all that? Do you pick something like Magenta or WooCommerce? You certainly wouldn't write from scratch, would you? Would you?

Dave: No. I think, from scratch, and I've kind of done that, you know.

Chris: Mm-hmm.

Dave: That's a nightmare. If it's like Dave Rupert, I'm going to sell a video or a package, a bundle of videos on my website, you need to make this back-end for the distribution of the stuff, the education management software. I would probably just use Stripe integration or try to start there, right?

Chris: Mm-hmm.

Dave: The minute it's multiple products, car parts or whatever, honestly, Shopify is a very compelling piece. I've built a Shopify site a long time ago and it was actually pretty enjoyable. You just write the templates locally and shepherd them up to the main site.

Chris: Mm-hmm.

Dave: Then it's working. For me, though, it's the payment processing. That security, the account management, and stuff like that that Shopify gives you, you don't want to F with that on your own personal basis.

It would be hard for me to be like, maybe it's in the search functionality or something like that. Where does Shopify bail out? I don't know that quite yet, but I would be curious what people's experience is. I'd put, probably, Shopify and WooCommerce on the same level. Does that make sense? If I already had WordPress.

Chris: Yeah, although one is hosted and one is not.

Dave: Yeah, if I already had WordPress, I'd probably just use WooCommerce or something. Yeah, Shopify is so compelling, but then if I needed something bigger, I don't know. I've tried to do Magento before and it was just rough stuff for me. It was not comfortable or good. You'd have to use something.

Chris: There are different levels. Three T-shirts is like, who cares; use whatever. But then 100 products is a special scale that probably is particularly well suited for Shopify. Ten thousand, a hundred thousand, does Shopify fall over at that level? I don't know.

Dave: Yeah. Yeah, I don't know. I think probably the point -- I'm trying to think, like, there's a company in Austin called Tiff's Treats. It's a cookie thing. You order online and you can send somebody or yourself cookies. Order online. Cookies show up at the door.

I wonder what it's built on because my thinking is, Shopify is like, "Cool. Yeah, we'll take the order, but we're not going to dispatch a driver or do anything like that." [Laughter] "We don't cover that part of anything." Maybe you'd want a whole end-to-end system that manages that, that can dispatch a cookie delivery driver.

Chris: Yes. I'm so hungry now. This looks amazing.

Dave: Oh, sorry.

Chris: Incredible cookies. They have an app where you track the car on the way to your house with the hot baked cookies.

Dave: Yeah, and this is a local cookie shop. It's pretty wild for what it is. Anyway.

Chris: [Laughter]

Dave: Okay, yeah, the sandwiches. Get out of here.

Chris: [Laughter] I'm going to close that.

Dave: What you want is the Snicker Dudes, okay.

Chris: Yeah.

Dave: The Snicker Dudes is what's going to really pump up your jam.

Chris: Yeah.

Dave: You know what I mean?

Chris: Yeah. It's like something doesn't match up there. It's like, what, did somebody have a trust fund here and they just threw the kitchen sink at the thing?

Dave: Yeah, maybe, but it's worth it and it's a great business. I mean, whatever, a cake shop or something, wedding cakes.

Chris: Yeah.

Dave: There are a hundred other small businesses where you have to do the fulfillment too. I don't think Shopify or anything helps you on that end. What do you do? I don't know what I would do but, yeah, I would probably do something like Shopify or something.

Chris: I would too. I think so just because it's so, so tried and true. It's just nice software. It's just that; what are the pain points? Got to figure those out early on. Talk to some people or whatever. I guess that's it, really, and just be comfortable with the fact that it's hosted by them, not you, so there are limits here. What are they? You've got to figure it out.

Dave: Yeah. My brother does a lot of Shopify for people, so you can hire him if you're interested.

Chris: You know what's always appealed to me for a long time? They're ancient, but it used to be called FoxyCart. Now it's called Foxy.io.

Dave: Mm-hmm.

Chris: Kind of the fun part about it was that they're not a CMS. They're just this thin checkout layer on top. Let's say you had a WordPress site where you posted all these products but you didn't use WooCommerce. It was just a CMS or a Craft site that didn't use Craft Commerce or whatever. You just used whatever CMS you want to and publish products. Then as long as you know what the price is of that product and other metadata about the product, you can load the FoxyCart JavaScript, Foxy.io JavaScript on that page and it deals with the cart, the whole checkout process, and stuff on top of whatever CMS you wanted.

Dave: Yeah.

Chris: It's kind of cool. But then, like, does it do inventory? It probably does, but do you want that in your own database or theirs? Where is that data and what's the deal? You've got to find out the rough edges of all this stuff.

Dave: Have you ever had a contractor come to your house?

Chris: Sure.

Dave: Then they're like, "Okay. You owe me $100,000 for your toilet." You're like, "Okay. Do you take a card?" They're like, "Yeah," and they just whip out a Square or some weird Android thing. [Laughter] Then they just swipe your card or they punch it into a Web app that's on their phone. Those are cool to me, too. That's e-commerce. I don’t know what holotype that fits in, but it's like an app. It's all very interesting to me because I'm saying I do Shopify, but I totally forget, like, oh, what if you need a point of sale? Maybe Square is the tool for that. Maybe you do need the physical point of sale. Like, oh my gosh. What do you do there?

Chris: Yeah, that native app thing throws a twist in all this, doesn't it, too? What if you need--? It's got to at some point become an Android iOS app.

Dave: Right. Right.

Chris: That's tricky stuff. Hey, just for the sake of this, let's do a more complicated one.

Dave: All right.

Chris: Let's say Dribble because everybody can picture this.

Dave: I love Dribble.

Chris: It's like content. You have user accounts and you upload photos to it that are under your account. Then there's following, liking, commenting, and stuff. It's kind of like a CRUD app, you know, searching and stuff. But obviously you want to build it fast and good, last a long time, and not have a bunch of technical debt and stuff. Greenfield, Dave, what are you looking at?

Dave: Originally, Dribble was written in Ruby on Rails, which I think was very suitable for it because it was like, "Upload a shot. View a shot. Here's an index of shots. Here's a list of popular shots." It was very kind of low on the interaction, but now it's like liking, commenting, a big old tag interface for every single post. There's a lot going on now and even the whole, like, "Are you available to hire?" and stuff like that. There are a lot of features.

I would probably do something like a service -- sorry -- a client-side app like a Nuxt or Vue because that's what I like. Probably Nuxt just to get the routing right. I feel like you could rebuild it pretty quickly and start getting those interactions together.

Chris: Yeah. What is Nuxt giving you here? It's a router, but isn't it a static site thing too, or not necessary?

Dave: Yeah, it can build static sites, but it can also do as much as you need. It can build out the template so it's not all entirely just an empty div or whatever, like an empty button tag.

Chris: Where's the data?

Dave: Well, you'd have to connect to something. At that point, it'd probably just be a weird Postgres thing. Maybe it is even still a Rails app on the back-end that you just go fetch data from.

Chris: Mm-hmm.

Dave: Just because I'm comfortable with that. Is there a better thing? I don't know.

Chris: I don't know.

Dave: What's the better solution for a CRUD app?

Chris: Where you need some controllers.

Dave: I just need the service, right? Facebook, of course, is like some seven gigabyte PHP thing that does that that's compiled to C.

Chris: I don't know. I would think you'd be looking at what's the least I can do that gives me a very configurable GraphQL interface.

Dave: Yeah, see, and that still seems like Rails to me. You know what I mean?

Chris: Yeah, maybe it is. Yeah.

Dave: Like a very thin Rails that maybe I ditch active record, or maybe you're still using active record. You just write a GraphQL client.

Chris: You'd think somebody would have come into that territory these days, like some fancy AWS thing or something that's like, you don't need Rails. Just use this directly. It's faster.

Dave: Not like promoting this feature at all, but Azure did have a thing where you could just chuck JSON at it and it would build out the database for you. You just give it some JSON and it's like, "Cool. I can figure out what to do with that," and it would just write out a database for you. Now you just have a service that you hit. You just say, "Hey, service. Store this." "Okay. Here it is back." That's pretty cool, but probably underutilized and probably also -- I have no idea. [Laughter] I shouldn't even comment.

Chris: You're in like a Vue front-end with some Nuxt help and then just something on the backend. Probably Rails.

Dave: That's what I would think, and I think GraphQL is probably in there too.

Chris: I see GraphQL all over this thing. it doesn't necessarily need to be, but I don't know. With all the different, like, "Hey, this thing needs this data. This thing needs this data. This thing needs this data." It sure as hell is not going to be Rest.

Dave: You call for shots or pens or whatever, right? Then you immediately need the author for the pen. You can set up Rails to return the author for when you get shots, but you actually only want to do that if you need to. Then how deep do you go? Do you need all the comments? That's another data query. You only want to do that if you have to. Yeah, I don't know.

Chris: It was just the other show where you mentioned that a Rails Vue thing would have been a fun stack for you.

Dave: Rails plus Vue would be awesome. I still think that would be awesome. Maybe that's what I'm looking at here.

The only part is Reactivity. I think a lot of people choose React, Vue, or whatever for that cool, like, "I changed a piece of state and now the whole app responded." You know?

Chris: Yeah.

Dave: But actually doing that, watching a like counter tick up, that's kind of hard. Now you need some pub sub thing in there. Where does that come from? Are you doing that with--? Rails has action cable. I guess you could do that, but how are you doing that?

Chris: Yeah. I mean that's bread and butter GraphQL. It's a mutation. Run the mutation.

Dave: Really? GraphQL can just livestream mutations?

Chris: Oh, yeah, absolutely. There's GraphQL Subscriptions if you needed to, but what you do in this case is, when you click the like button, it runs the mutation that augments the like up one. It sends it back through GraphQL the same way that you got the data in the first place.

Dave: There's a subscription going.

Chris: Yeah, I think subscriptions are more about live updating of data, so you'd set up a GraphQL subscription if you're expecting some server side data to change and you want a Web Socket kind of thing for it to change the state on the way back in. But a mutation doesn't have to be live.

Dave: Right.

Chris: You'd write it optimistically, right? Generally, the like button is the perfect example for that. You click "Like" and, on the front-end, it just behaves exactly like you liked it, and it fires off a network request. In this case, a mutation to change that data and just assumes that it works. If it doesn't, you can always deal with that and throw an error, unlike it, or something. Generally, you don't even bother. That's such an unimportant action.

Dave: Yeah. Yeah. Yeah, like you just turn it off and say, "Whatever. Oops." Okay, yeah, so then I could subscribe to that data stream if I expect it to get real hot and change or whatever, or if you're making a Realtime dashboard or something.

Chris: Yeah, like if you're building a flight tracker app or Realtime thing at all. Yeah, so a lot of stuff. I definitely would think in that way these days and be like, if we're greenfielding here, just Realtime everything. [Laughter]

Dave: Yeah, yeah.

Chris: Then it feels very modern and fancy. Yeah.

Dave: Yeah. Well, we've got to plan for that. Yeah. I think I always think of Graph as a Rest competitor, but I really probably need to dig into it more. It's Rest on the client side or Active Record on the client, maybe. [Laughter] I don't know. It's like you just describe what you want.

Chris: I can't even tell you. I feel like I talk about it more than I know about it. My usage of it is like, you know, I open up Graphical, which is their little visual thing that ships with it and try to get myself a query going. That's the data that I need. Then use that query. I'm very much, like, most comfortable with just asking GraphQL for the data that I need and then using it.

Dave: Yeah.

Chris: That's about it. The subscription and mutation stuff is still not -- I don't write a million of them a day, but my team does.

Dave: Yeah. Yeah. No, that's cool. Yeah, I think that would definitely be a part of our modern stack. I am kind of curious. Who was it? The Sandy guys, they were kind of like, we've iterated on GraphQL." I would be kind of interested in….

Chris: Oh, I think this is absolutely fascinating. I have this all loaded in my brain because I wrote about it. I just haven't published it yet. What they were saying was really interesting. If you're just handed a GraphQL API, that's a little unfortunate because part of the strength of GraphQL is being able to change what's in there, like customize it to your needs. Their example was like, how many authors are there on a blog?

Dave: Mm-hmm.

Chris: Your GraphQL API might not have that in there. You might have to request them all and count them or something, which is kind of not really the spirit of GraphQL. If you want that, you should look at your author's query and return a count and then use the count.

Dave: Right. I might do something different if there are 2,000 comments on a post.

Chris: Oh, yeah. Absolutely.

Dave: At that point, I want to paginate or whatever. Yeah.

Chris: We had to adjust our thinking in some way. For a moment in our templates, once in a while, we'd string together a URL. You'd be like, oh, what's the link to details view? Oh, well, it's username/details/slug/ whatever. You've done that a million times, I'm sure, right? String concatenate a URL together.

Dave: Yeah.

Chris: We decided to stop that and be like, "No, no, no. When you request this item, the GraphQL response for that item should have within it URLs that represent all the places it could be. You have to adjust your thinking and be like, "No, no, no. We should never." That's just one example of a million examples where you're like, "The API could have. If the API could have given me that data, you should update the API to give you that data," and now it's kind of great because URLs in CodePen are a little weird. Sometimes they have team in front of them because it's a team thing or something like that, like probably a mistake. Early on in the days, but that's the way it is now.

[Laughter]

Chris: Now that the API deals with it, we don't have logic in our templates that say, "Well, if it's a team, string concatenate the URL this way. If it's a user, string concatenate the URL this way." It doesn't matter. You just use it. Just url.details and it gives you the right URL. You have to adjust your thinking.

Dave: Okay.

Chris: Every time GraphQL could be giving you something that would be really useful and uncomplicate things, in our case it's like a Rails model thing, which probably strengthens your argument that it should be Rails and adjust what the API is giving you. In my case, write an email. Go into Slack and ask the developer to give me the right data that I want.

Where I was going with that is like, now we have that control. If you're just given a GraphQL API, you don't have that control. It's not the same awesomeness.

We have this grok thing. You don't need to ask nobody nothing if you have this thing because it is the query language. You want the count? Run the count. You want some special data from it? You don't have to ask anybody or update anything. There is no configuration layer. It just is….

Dave: One extra step. Yeah. Yeah. See, that's smart. I think GraphQL is probably a safe bet or whatever, but it is sort of this -- what's the next? I'm always like, people have tried this out a few times, the same way as CSS and JS, which you all just posted on CSS-Tricks about that. It's just like, okay, okay, cool, cool, cool. What's next? What's the next iteration of this flavor of thing?

Chris: I couldn't even tell you exactly. In some ways, it's whatever Apollo does, in a way, because you've also kind of got to remember that GraphQL is just a spec of what happens, but a lot of usage of GraphQL is actually an abstracted layer on top of that, which is like, what is the client and server? What kind of niceties did they deliver to you? What is the caching situation like and the de-caching situation like?

Dave: Mm-hmm.

Chris: All that is kind of delivered to you through Apollo or other kind of competing tools, but Apollo is kind of the big one. It starts to get confusing, like, what is the language itself and what is a nicety that's being given to me by some extraction?

Dave: Yeah. Well--

Chris: Well, that probably is about it, huh?

Dave: Yeah. Yeah. No, well, that's cool. I mean it's just fun to think about it. I don't know. I don't know.

The other day I was just like, uh, I should write an app. [Laughter] You know. It's a terrible idea. I was trying to plan a talk. Why would I write an app while I'm trying to plan a talk?

Chris: [Snickers]

Dave: I write a little note in my notebook and say, "Hey, here's a dumb idea you had." You know it would be -- I don't know. It is sort of like, how would I do this? Technologies we didn't talk about are like Firebase and things like that. It's just like, how would I set all this up? I don't know.

Chris: Well, we talked about Realtime a little bit. Think of how nice. I mean I've used Firebase for stuff and Firestore in the past, but we dipped our toes in it a little bit. What if you just used it greenfield and just did everything in it?

Dave: Yeah.

Chris: It would be super great for some reason because everything would be Realtime. It's not Realtime yet? Oh, well, just use the Realtime API instead of the query API. Cool. Now it is Realtime. Amazing. Have that be your source of truth and you're locked in as hell. [Laughter] Sorry.

Dave: [Laughter] Yeah.

Chris: You want to move? Too bad.

Dave: Yeah, Google shuts it down; peace out to your company. Whoops.

Chris: [Laughter]

Dave: Not that that happens. Not that that happens. Yeah. No, it's interesting. All their limitations become your limitations. Does that make sense?

Chris: Yeah.

Dave: That's a bummer too, right?

Chris: Pricing changes become your pricing changes. [Laughter]

Dave: Yeah, or even like associating a user with a product, a post, or whatever, and Firebase is kind of weird. You have to redo your whole data structure, sort of. Do you want to show all posts or do you want to show all posts by user? You have to decide those things kind of upfront, and that, for me, I get hit with a roadblock. I'm like, "Ah!" Their limitations become your limitations, and so you just have to figure that out, right?

Chris: So much to talk about. We could go on forever, I'm sure. So many tech choices.

Dave: Yeah. Maybe let's do a show next week. We'll have a podcast next week. How does that sound?

[Laughter]

Dave: We'll talk about more Web stuff. That sounds good. We'll just wrap it up. 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. Head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. Chris, do you have anything else you'd like to say?

Chris: ShopTalkShow.com.