Transcript

[Banjo music]

MANTRA: Just Build Websites!

Chris Coyier: [Laughter]

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show.

Chris: Whoo...

Dave: A podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris.

Chris: Yeah. This is the edition where we accidentally talked for 20 minutes before we pressed the button.

Dave: Yeah. We're coming in hot. Coming in hot.

Chris: Coming in hot.

Dave: It's good.

Chris: Yeah.

Dave: It's good. Yeah. Yeah. Yeah.

Chris: Don't worry. We were only talking about stuff that we can't talk about publicly on the air anyway.

Dave: Yeah.

Chris: So, don't even worry about it.

Dave: Just don't... Yeah, it's just a wonderful situation where it's Chris and I's secret time before the show. [Laughter]

Chris: Secret time.

Dave: Secret times.

Chris: Oh, sorry. I know you guys don't want to hear that. Let's talk about things that we actually can talk about. This is a little follow-up from an episode before. I think you turned a micro conversation, possibly, into a full-fledged blog post, which I frankly hope you turn out famous for because I absolutely love it, which is the 15-minute fix versus the 30-day fix. Tell me that, Dave.

00:01:12

Dave: Uh, yeah. I think it was kind of the last show. We were riffing on it. I think we called it the one-month fix, but I just was like, you know, 30 days makes a bit more sense.

Chris: Ah, a better number.

Dave: Yeah.

Chris: Oh, yeah.

Dave: Yeah, and it rolled off the tongue. The pros, you know, the pros versus -- you get a chance to fix that on the blog.

But I just kind of went through it. I think the tension is there, and I was looking at my own project, Luro. I'm realizing -- I was building an API. I have a post API. Get some posts - or whatever.

Then I was like, "Oh, I want posts, but in the auto-complete dropdown I want the list, but I only want ID and title. I want it to be really fast and efficient." Okay.

I've got to have another point where I return less fields. I was like, okay, that's easy. I did that, and then I was like, okay, now I want to do it, but I want to list them just by categories.

Okay, so I'm just piling on these fixes, these 15-minutes fixes. Where?

Chris: Meaning you're extending your rest API to have additional endpoints.

Dave: Yeah. Yeah, adding endpoints, adding features, adding little params. It's just little one-liners. It's not illegal. It's not bad. It's just like we're growing out of our pants a bit.

Chris: Scope creep of API action. Yeah.

00:02:34

Dave: Yeah, and it's not wild, but I think the twist is if we had sat down and designed a proper API and got out pen and paper, not that we didn't do this, but it was like, "Oh, we need CRUD, so I'll just generate CRUD," so I did CRUD, and create read update delete.

I feel like most APIs have something beyond this. Does that make sense? You need a little bit more than just those things. You need some get featured items or sort by date - and stuff like.

If I had sat down with clear eyes and infinite time, I could have said, "Okay. What is this actually going to need? Let's actually do a design of the API."

Chris: Hmm. Would you have V2'd it? [Laughter]

Dave: Absolutely.

Chris: Yeah.

Dave: That's the thing I think I come to in the post. I have a bunch of these 15-minutes fixes, and I could have done the 30-day fix plus the extra 30 days of, like, "Oops, I broke everything." I could have done that.

Chris: Yup.

Dave: But our point, what we're going to is trying to learn. We just want people to use it and learn from it. Of course, everything could be better. Anything. My car could be a Ferrari, Chris. It could be better.

Chris: Hmm. Yep.

Dave: It's just not right now. You know? [Laughter]

Chris: Mm-hmm.

Dave: It's a hand-me-down truck. [Laughter] It's a nice truck. It's an F150, but it's a hand-me-down farm truck.

You can always make something better, but I think what I'm coming to the conclusion is I don't know that we made a mistake by doing a bunch of 15-minute fixes. I wouldn't say that, but there is the "Could we have head off a bunch of problems by doing a 30-minute fix on this thing -- or 30-day fix on this thing early on?"

Chris: Hmm...

Dave: You know?

00:04:39

Chris: I don't know. You're right. The point of this isn't that one of these is better than the other. It's just that these are your two options, and sometimes you need to pick one and sometimes you pick the other. You're probably -- more like the 30-day answer is the right answer, but you can't only do those. There's not enough time in the world to only do 30-day fixes, so you have to balance it.

Dave: You can't be a company of 30-day fixes. Every project can't take 30 days.

Chris: Yeah.

Dave: You have to deliver things to customers. I think there are situations like that where maybe your company makes money hand over fist. You know? You've got Salesforce bucks and you're just making so much money. You can just take time to think every situation through. Maybe even if you're at this base level of API or some design system that every department is going to use. Maybe you do need to do -- everything is a 30-day fix.

But I think most people are in situations where you just have to kind of take the good and the bad and figure that out. Figure out which one you need.

Chris: Yeah. Yeah. Yeah. I notice the word--

Well, I have a couple of questions. One of them, this is philosophically wider than talking about a rest API. you were just using it as an example of something that could get away from you, right?

Dave: Mm-hmm.

00:06:13

Chris: Just to scope it to the rest API for a minute, I noticed the word GraphQL didn't make its way into this post at all. [Laughter] You don't have to come up with additional endpoints if you can ask for anything you want, Dave.

Dave: You don't. The front-end person doesn't. But me, the back-end person fucking does.

Chris: [Laughter]

Dave: You know what I mean?

Chris: Okay. Okay. Okay. Okay.

Dave: I have to build the whole shit. The whole GraphQL appliance. I have to write all the resolvers. I have to write--

Chris: It's true. You would have to make an internal thing that ultimately does the job of coughing up that data and making it available anyway. It's not that different than a rest API with a different URL.

Dave: No, and then, "Oh, surprise. All the GraphQL I wrote is just tanking the server," because you can absolutely get yourself into that situation in GraphQL.

Chris: Mm-hmm.

Dave: You know?

Chris: Fair enough. Fair enough.

Dave: In a three-person company with two designers, guess who gets to write the GraphQL appliance. Me. To be honest, I like GraphQL, but I took a whole workshop. I did all this stuff. My heart wasn't singing about it. I think it is very cool, but I just wasn't like, "Man, this is amazing." You know? [Laughter] I want to do all this work just to get rest differently.

Chris: [Laughter] Yeah, fair enough. If you're the full stacker in charge of every aspect of it, I could very much see that as feeling less transformative. It's probably a bigger team thing.

00:07:48

Dave: No. I went down the whole thing, like in the early days of Luro. I set up a Hazera, PostgreSQL backend with this Hazera appliance in front of it. At the point where I'm clicking checkboxes to build out a schema, I just was like, "This is so boring. I don't like this. This isn't fun."

Supabase wasn't really around. I could've maybe got into Supabase more, but I don't think that would fit our final situation. What was the other one?

Chris: Was PostgreSQL on the other side, or no?

Dave: Yeah, PostgreSQL.

Chris: Yeah.

Dave: I'm kind of going hard on PostgreSQL. I think it's great. It has JSON blob storage natively. That's really good.

Chris: Yeah. Probably not going to regret that.

Dave: I don't regret it, and it's proven to be even better as time goes on.

I looked at Fauna DB because I was like, "Oh, Fauna."

Chris: Mm-hmm.

Dave: This new thing, it's awesome. Well, it's not actually SQL. It's like Fauna QL, FQL, or something. And so, I was doing all this, and I was hoping -- what I wanted, what I dearly wanted -- all these things work if you have a GraphQL schema on your computer, like already built.

Chris: Mm-hmm.

Dave: And you can sometimes show up and be like, "Here's my GraphQL. Go build the database." That's cool. I didn't have that. I had nothing, so building everything from nothing was not fun.

Chris: Right. Right. Right.

Dave: That was... yeah.

00:09:24

Chris: I think of Sanity in that way, too, where they have their own Sanity QL to query their data, and they make these really strong points that their query language is better. It has cool stuff that it can do that other query languages can't, but there is no avoiding that now you have written queries that work in one place only ever.

Dave: Right.

Chris: They're just very different, so there's a degree of lock-in to that. That's fair. It's fair to say that if you go down that road that you are locked into that data store. Anyway, that's all I have to say about that.

Dave: No, well, and do you want to be something that's locked into something new or locked into something sort of tried and tested, which is PostgreSQL (in this situation)?

Chris: Yeah, it's old.

Dave: When we started this show, PostgreSQL was kind of a question mark. You know? "I don't know, man. MySQL is really good." Times change, for sure. I just want to point that out.

Yeah, when we had another situation, another 30-day problem, it was like we were pulling in all this data. It was just like, "What are we going to do with this?" It was just like, "Well, you know what's cheap and easy is just spinning up a Mongo and dumping it into Mongo." Right?

Chris: Hmm.

Dave: But then we have all these PostgreSQL to Mongo join systems in the code, and that wasn't fun. It wasn't fun to work with. It wasn't easy or ergonomic.

Chris: Wow. You've done lots of different choices here and ended up kind of back at old-school town.

Dave: I'm in old-school town, and I don't know. It's that "choose boring technology."

Chris: Yeah.

Dave: Have you seen that boring technology website? I want to do it justice. Boring technology, yeah, Dan McKinley and his blog is mcfunley.com. [Laughter] Choosing boring technology.

But then there's a whole website for his PowerPoint. He describes these things. Yeah, it's boringtechnology.club. He describes these things as these Elon Musk tokens, right? These are your little genius credits. Right?

Like, "I'm going to use this new age database, and it's going to revolutionize the world." That's one Elon Musk big brain token - or whatever. Then you count those up, and all those things are potential problems--innovation tokens, he calls them--are going to be a problem possibly in the future.

Chris: Mm-hmm.

Dave: There's a reason most websites you go to are Rails [laughter] and PHP with a MySQL back-end.

Chris: Yeah. Yeah. I tried to round up some of this stuff. I did an essay a couple of years ago called "Simple and Boring" that doesn't have any -- it's not me trying to add to the conversation necessarily. It's kind of like rounding up lots of other people's opinions on why boring is better.

00:12:37

[Banjo music starts]

Dave: Is your website running slow? Well, chances are it's images. That's why I'm glad today that ImageEngine is sponsoring the show. ImageEngine is a CDN that detects the devices that are visiting your site, automatically optimizes the images. It delivers them through their global CDN, so it gets to the user as quickly as possible.

You get an image payload that's reduced up to like 80% faster page speed, faster core Web vitals. That's good for SEO. Good for ROI. Really excellent performance gain, boost, and you can get up and running in about 15 minutes.

Check it out, imageengine.io. Thank you for sponsoring the show.

[Banjo music stops]

00:13:31

Chris: Okay. Rather than talk about rest or anything anymore, let's zoom out and say, "Okay, 15-minute fix versus 30-day fix," just to cap this up. Is there a world in which you are so experienced, so smart, so prescient as a person, as a developer, as a project leader, as a project manager, as a product owner that you always get this right, that you know when to pick the 15-minute fix over the 30-day fix, and that you're just kind of good at it, and that that's how you operate your company is you just know? Or is it a fricken' coin toss? Or somewhere in between?

Dave: That's a good question. I think seniority helps. You've seen a lot of situations. You've seen people. You've seen crashes and burns. You've seen projects fail.

But that also can be very contextual to the situation. Was management all bought in? Was there budget? Was there time? Is the backlog adding reverse pressure to finish this way too quickly, or something like that? Those are hard questions, and those dynamics change over time, too.

I think you can easily say this is a 15-minute fix, but you might be saying that purely because you have a backlog ten million miles long and you just don't have time or budget for the 30-day fix. You know what I mean?

Chris: Okay, so it's not just only experience-based. It's also looking at the world in front of you, based.

Dave: I think you have to kind of say that. Are there people, smarter people? If I had Alex from CodePen here on my team, he probably has enough experience to be like, "Well, you know what? Let's build the API this way," and it'll take twice as much time, but we can at least figure it out. It should be better going forward.

I think only through experience can you -- and hopefully, expertise and skill. Somebody is so good that they know kind of all the ten problems you're going to hit and, guess what, you can just kind of -- we can just build it quicker because I know all the problems already. I think there's some skill and expertise, too.

Or, I don't know, man. Maybe somebody needs to make a chart, like here are things you're going to have to build: a user system, a rest API, an API, a GraphQL. Here's how you do it, and here's how long about it's going to take - or something.

Or just use this. I think about something like Strapy, or something. You know? It's a really visual GraphQL API builder - and stuff like that. Maybe that would have been cool. Maybe I should have spent more time figuring that out - or something.

Chris: Yeah, maybe. I do think there is some value in code written schemas, whether it's GraphQL bound or just documentation or somewhere in the middle that's like once you have that, it kind of opens some doors to choosing storage that fits the schema rather than being like, "Okay. I don't know. Pick the storage and then deal with how it works."

00:17:01

Dave: One of my innovation tokens - bing - my Elon o'bucks - was spent on Prisma IO.

Chris: Yeah.

Dave: Prisma IO, it's for lack of--

Chris: I remember you liked it for a minute.

Dave: Yeah, well, I Hello, World it in Redwood. It's kind of core to Redwood.

Chris: Oh, it's part of the Redwood world. Yeah. Yeah. Yeah.

Dave: But it works on anything. It is a JavaScript, basically, active record for JavaScript if you want--

Chris: Yeah, with migrations. Right? Wasn't that kind of clutch?

Dave: Migrations is the key part. If I add a field, like I have to do today, [laughter] if I add a field to the table and I send it out to my test database, my dev database, and my prod database, guess what. It just automatically upgrades those databases. I don't have to manually hop in....

Chris: Your startup, you're going to have a lot of fricken' migrations. I'll tell you what. That's the name of the game in the early days.

Dave: Well, and then, too, I have to think about people and supporting the environments. Like if Trent or Reagan pulls it down and tries to stand it up locally, is it going to stand up? Can they fix it with one command?

I don't have to be like, "Okay, let's hop on a screen share and add whatever URL column to your database, your post table." You know?

Chris: Yeah.

Dave: Because again, that's another 15 minutes for me. It starts piling. The one innovation token I took was Prisma, and I'm pretty bullish on it. I like it a lot.

Chris: Oh, you're running it now?

Dave: Running it now.

Chris: Oh, good. Good. Good. Good.

Dave: Because you can just go -- it'll run. It'll do the migration. It'll stand up. It'll tear down. It can even--

Chris: Does it help you? Is this giving away too much? Do you want to--? I have a question about a thing called Terraform, which you're using because you're using--

00:18:55

Dave: I'm also using Terraform. Innovation token.

Chris: This is something you're willing to talk about? Yeah, it's interesting. It's a little bit of infrastructure as code, slightly, right? You could run a CLI command and it'll go boop-boop-boop up some infrastructure. What that gives away is that you're spinning up infrastructure on behalf of other companies, meaning that these databases that we're talking about -- because you're talking about Prisma -- there is not one of them. There are many of them, right?

Dave: Right.

Chris: If you offer a change to your core software, you're not just going to boop it once. You need to boop it for every client, presumably. I think it would be probably a little nightmarish to run different software for different clients, right?

Dave: Yeah. Yeah, so it's kind of like a white label system. Each customer will get their own white label install - if you want to think of it like that.

Chris: Yeah, which is very smart, I have to say, because that means if you're offering to install it behind their firewall and stuff like that, that's enterprise bucks. Do the enterprise dance because that's--

Dave: Enterprise money.

Chris: Yeah. [Laughter]

Dave: It is better than normal people money.

[Laughter]

Chris: It kind of is.

Dave: Yeah, that's sort of a situation we're looking at. We've had potential customers straight up tell us, "If we run this, if would have to be behind our firewall 100,000%. We cannot--" and so that sort of--

Chris: Totally understand.

Dave: --drove some of our decision--

Chris: We have requests for that at CodePen. I'm like, no because we're just super not ready for that. That's a decision that you'd have to make, for example, at the beginning of your company or be super willing to make that the thing that you're doing as a company, later.

Dave: Right. Right. Right.

Chris: It's not just a little bonus little add-on, I'd say, for most software.

Dave: It's not like, "Here. Copy the docker file." It's not quite that. You know? It's kind of a bit of effort. But infrastructure, and so, yeah, we basically have each customer will get their own white label instance. That's their own database, own S3 bucket, own server. That's a docker with (it could be) multiple servers. It could be a Node server, and API server. But right now, it's just one server.

Chris: Is that true, though? Let's say you decide you're going to add whatever URL column to some particular table or something. This might be too early to say, but are you going to run it locally and make sure it all works and then probably revisit all of your installs and boop it?

00:21:32

Dave: Yeah. Basically. Right now, how it works -- and this could be more automated, but we also don't want-- We probably need a lot more testing to auto-deploy to every customer. Does that make sense?

Chris: Yeah. You don't even have to-- I mean we have--

Just food for thought for you. We have an admin, like a screen on the installs.

Dave: You've got to click, click, click? Yeah.

Chris: Yeah. You click them. Click, click, click.

Dave: Yeah. See, that's probably where we're headed and I've started already thinking about that. But again, I have to build it, so it's going to be... [Laughter]

Chris: [Laughter] It'll be a minute.

Dave: Right now it's just me, so old Dave has got....

Chris: I got it. I got it. I got it. I know we're doing a little inside baseball stuff.

Dave: Terraform is actually very cool for this, and somebody had brought it up in the D-d-d-d-discord. They were just like, "You know I have - whatever - these five WordPress sites for different customers. Occasionally, I have to spin one up."

Terraform is really good for setting up an environment. If you're just like, "I need a server and an FTP - or whatever. I need these five things. Let's boot them. Let's go set them up."

But there's also, with GitHub actions and everything, you can kind of create a deployment story where that code can go out to the server too. And so, we're using Terraform to basically build out the infrastructure, and then we're deploying that all through GitHub actions.

Right now, I have to kind of do a manual command to deploy stuff. But like you're saying, it could be a UI eventually.

Chris: Mm-hmm.

Dave: But what I like about it is I don't have to. I don't know. [Laughter] What I like about it is I can, like, "Okay. Hey, let's try to fix a problem on the dev server first, the dev prod or whatever, QA, whatever you want to call it. Let's go try to fix that. Let's deploy it to that first to see if it falls over. See if we get back what we expect."

I mean you know. In SPA land and whatever--

Chris: Mm-hmm.

Dave: Sometimes the error tracking is opaque. It's like, "You've got a 500 error," and you're like, "Why?"

Chris: Hmm. Why?

Dave: What's going on? You go to the logs. Nothing.

Chris: Mm-hmm.

Dave: You're like, "Well, that's peculiar because I just had an error."

Chris: I'll tell you; it's even worse in GraphQL land, so if you already don't like that.

Dave: Whoops! Yeah.

Chris: [Laughter]

Dave: Yeah. Anyway, that's the thing, too. Your innovation token gets spent on now you have to kind of figure out why the innovation machine is broke.

Chris: Yeah.

00:24:20

Dave: I'm trying to be very tactical on those choices, and we spent tokens on--

Chris: How many tokens do you get? Five? Two?

Dave: I think if you've got five innovation tokens, you're probably doing a lot. You probably have a lot of potential--

Chris: Two or three.

Dave: I think two or three is a good budget. One of them, we were doing Netlify serverless. Every client we give their own Netlify instance, serverless functions. Boom. Spin up.

Chris: Oh, that kind of sounds good.

Dave: It was good until it wasn't. [Laughter] We had background. We had stuff we needed like CRON jobs, which Netlify supports now, and that's pretty cool.

Chris: Yeah, but as of two weeks ago, right?

Dave: As of like two weeks ago, and that would still probably fall under the innovation token. [Laughter] You know?

Chris: Yeah.

Dave: Then there was another one just like long tasks, tasks that take more than eight minutes.

Chris: Mm-hmm.

Dave: Mm-hmm. I think maybe I actually fixed that. Like it wouldn't take that long, but you've just got to think about that stuff.

Chris: If you go boring, you just have a boring server that probably doesn't have those limitations.

Dave: Yeah, because we went from having six servers, this Mongo server, the Node server, the Netlify functions.

Chris: That's a lot.

Dave: The PostgreSQL server.

Chris: Really?

Dave: Then the Netlify site itself.

Chris: What else? Maybe a Redis...?

Dave: Then the S3 bucket, yeah. Yeah.

Chris: Oh, S3. Woo! That's six. Ooh.

Dave: We had like six pieces of the puzzle, and now we're down to three: a Node server, S3 bucket, and a PostgreSQL. It feels good.

Chris: Mm-hmm.

Dave: It feels better. A lot less machines breaking down.

Chris: Yeah. You want low buckets. That's for sure.

Dave: We want low buckets and low innovation tokens. I obviously am still bullish on Netlify, like still love it very much, and everything else we are doing is basically on Netlify. But it was just one of those situations where it was like I'm hitting enough of a pain point where I can't do it on Netlify and now I have three other things, so I'm just going to try to mow it all down.

Chris: Yeah. Yeah. I wonder. It seems like--

This is not true, but certainly content focused sites will excel on Netlify, and you can absolutely make functionality and stuff on top of that. But I wonder if that's a little bit of a sweet spot. And if your thing is only exclusively like a Web app that the Jamstack thing is just a little harder to pull off, let's say. You know?

Dave: Yeah, I mean I could see internal tools, like if you have a receipt. [Laughter] Filing machine or whatever, and you just want to build a little UI for it or something. Boom. You could make that, like these internal tools work really well. I think there's a lot. We got very far with Netlify, but it just turned into a situation like, hey, I think for everybody's sanity, we probably need to back out of this.

We were hitting function limits. We have Puppeteer in a function, a Lambda function. The limit on Lambda functions are 69 megabytes, and Puppeteer with Chromium is 66 megabytes. So, if anything else shows up--

Chris: Under the wire--

Dave: --like the Prisma client, which is two megabytes, you're skating on thin ice, so you can't NPM install your problems away. [Laughter]

Chris: Hmm.

Dave: There were just tiny things like that. We were just running into it, and so, hey, we're in better shape now.

Chris: Interesting. Yeah, I wouldn't encourage you to flip this boat, but we have chosen Pulumi as the Terraform alternative.

Dave: Pulumi?

Chris: Yeah, P-U-L-U-M-I. It's very similar to Terraform. Of course, they both consider themselves better than the other, so a little hard to determine, and I'm probably not your guy.

Dave: Oh, yeah. Mine's better.

Chris: Yeah.

Dave: Oh, no, this seems cool. There's also Begin.

Chris: Hmm. Yep.

Dave: That's another infrastructure as code kind of thing, which is really cool. But we could maybe even do it through Kubernetes, just like we're putting up a Kubernetes, whatever that is. You know that's kind of like the series of dockers, but we could, in theory--

Chris: Yeah, but you still do your Pulumis to your Kupernetes - or whatever. [Laughter]

Dave: You put your Pulumis in your Kupernetes, and then what is it? What was that thing from weeks ago? This is faster than esbuild, or whatever.

00:29:10

Chris: Yeah. What's worth knowing about this, I'll just say for the audience's sake, is that first of all, we're talking about infrastructure as code. If you want a server, rather than logging into a dashboard and clicking "deploy me a server" and then you just copying out some keys to some other code or something, but there's no connection between your code, like in GitHub, and the servers that it run on. That's starting to be weird and the wind is blowing in a direction that the code in GitHub says what kind of servers that it wants and needs to run on. It feels like there's just a movement in that direction.

But more importantly than this, there becomes a scale in which you literally have to do it. Dave, this is going to apply to you. If you want to be SOC 2 certified, which is a big deal--

Dave: Oh, we're heading down that path.

Chris: There'll be companies in your future.

Dave: Yeah.

Chris: Yeah, there'll be companies in your future that say, "We can't use you unless you're SOC 2 certified." You need to have code as infrastructure to be SOC 2 certified.

Dave: Wow.

Chris: You have to do this.

Dave: Hey, I'm doing it.

Chris: It's not a choice thing. Good, you'll get that one for free. There are all kinds of cheesy stuff. There's like, "Is there a lock on your office door, Dave, in your shed? If there's not, you're not SOC 2 certified. So, maybe you should put a lock.

Dave: I do, but the lock is attached to a giant glass window. Is that a problem? [Laughter]

Chris: Just don't say that!

Dave: Oh!

Chris: Now you're on the record. We'll have to strike that. It's an oak door. Yeah.

Dave: It's a solid oak door.

Chris: [Laughter]

Dave: Very Danish modern. Yes.

Chris: Yeah.

Dave: Yeah.

Chris: Very strong, so we got it off a mediaeval castle.

Dave: Yeah.

Chris: Jerks.

Dave: Yeah, it's got spikes. [Laughter]

00:30:44

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Memberful. Memberful is software to help you sell memberships to your audience. What would your business be like? Do you need to build this? This is an awesome way to build a business.

But Memberful is for you the developer to build. This is a whole package of tools to make building whatever kind of membership business you want to build possible. It handles all the hard stuff. It'll take payments with Stripe for secure payments. You don't want to write that from scratch. Use Memberful to help with it.

There's a full on GraphQL API. Which user is it? What access level do they have? All that type of stuff. Web hooks, OAuth, single sign-on.

You're going to have to build a log-in process and account creation process. Why write all that from scratch? It's just built into Memberful, this complete package for dealing with membership stuff. It's so great.

Let's say the home base of your website is WordPress. There's a best in class WordPress plugin so that you can control who is able to see what and where the upsells are and all that stuff. Really tremendous.

It handles all those transactional emails - so much of that. It's just everything all bundled together.

You can get started for free. There's no credit card required.

Just think about it. If you're a smart developer, you're not writing all this stuff from scratch. You're leveraging other software that does what it does best so that you can build the integration of a membership website perfectly. Thanks for the support, Memberful.

[Banjo music stops]

00:32:23

Chris: Speaking of some Discord conversation... Where was I going to go with that? Nic Chan wrote up "My white whale: A use case for will-change," which I found good. We mentioned it on this show, so it feels like follow-up a little bit, and how I just wish, as somebody who has written an awful lot of developer documentation, that there's not a CodePen example of will-change that's just super dumb easy.

Dave: Mm-hmm.

Chris: That you're like, "If you do it like this, it's slow." Then look. You put will-change on it, and it's fast now. The point of will-change is that it's supposed to help the browser be more performant.

Dave: Right. Right.

Chris: Why can't I see a janky example and then put will-change on it and then see a smooth example? It's not a thing, and it annoys me that it's not a thing. Apparently, for Nic it was too.

But put together a little demo that happens to just work in Safari where it's a little background that shifts over something on hover, and then as you un-hover, the background slides away. In Safari, it leaves a little nugget of color behind.

Dave: Yeah.

Chris: It's very easy to replicate.

Dave: Yeah, it left a little--

Chris: You're like, "What's with the little--? What's the dingleberry of color there? What's going on there?"

Then you put will-change on it, and it goes away. So, it's a use case. It's a reduced use case, so you can at least do it, and will-change actually does the job, which is pretty cool.

Then the Discord came up with some other use cases. I think Alex did a marque-like example that you could probably see how it gets janky at the end of the animation. Boom. You chuck will-change on it and it fixes.

A couple of examples, but those are, like I said, dingleberry examples. They're like, "Oh, the browser just borks on rendering." It's not whether it's performant or not. It's a rendering glitch, like a bug that it fixes, which is not what will-change is supposed to do.

00:34:16

Dave: I would love to see an FPS meter, like this little animation is choppy in 8 FPS. Put will-change on it, and it's fast. Maybe somebody can get the knobs out - old knobs.

Chris: I know what you mean. Yeah, that's good, the little-- I like the idea of an FPS meter because it could seem like--

I'm down with a reduced test case that says at the top of the reduced test case, "Open this up on an Android 5 phone," or whatever, because I understand that the reduced test case might not work on literally the best computer that you can buy with money today.

Dave: [Laughter] Right. Right. Right.

Chris: I get it if it's smooth both ways on mine. Um... anyway. Awesome.

Dave: Yeah.

Chris: Let's see--

Dave: Yeah. That's kind of funny because it's that thing. It's like, actually, I've noticed with these M1 Macs. It's hard to diagnosis performance problems.

Chris: Indeed. Yeah.

Dave: Running Lighthouses on client stuff, and they're getting 20s. I'm like, "Wow, that's weird. It looks fine to me." [Laughter] But you know it's because I've got this really super computer, and it's just chewing through stuff. I don't know. I started wondering if Vite and all these new things. My Mac is hot. It's hot on the bottom, and even the M1. And so, I'm just wondering.

Chris: Right.

Dave: Am I really using it here when I do esbuild and all this stuff, or Webpack. I mean it's going fast, but it feels like I'm burning some energy because my battery only lasts half what it should.

00:36:02

Chris: This coming Tuesday, so I guess one day after this drops in podcatchers (and people might be listening to this on the same day - who knows) March 8th, there's an Apple event called Peak Performance that I'm worried about. What if they drop an M2? Then I have to start my guilt cycle of not having the best computer that is possible to buy.

Dave: I think there is -- I've heard there's an M2. Whatever. It feels weird to talk about it now because it will be announced after this is done.

Chris: I know. I know. I know.

Dave: What I've heard about the M2 is it's good. I don't know. I've heard it's good, but--

Chris: Maybe it's four different devices.

Dave: --it's not like, "Go buy a new computer." That's kind of what I'd heard.

Chris: Hmm. There's been people talking about that it might be an iMac, which an iMac is only plugged in all the time.

Dave: Ew. Okay.

Chris: As far as I understand these M1 chips is that they're so amazing, but they're designed to work either with power or not. They're flexible on how much juice they have access to, and that's a tradeoff. But I could imagine a chip being designed to be powered at all times, so it needs to be a little less concerned about energy consumption. I'm sure that's always, to some degree, a consideration. But if you want to design the smokin' fast chip ever, it would be pretty cool to design one that didn't have to worry about a battery at all. So, maybe the chip is designed specifically for, say, iMac, Mac Pro, Mac Mini, and stuff that literally have a power cord.

Dave: Yeah. That's an interesting thought. Hmm.

00:37:39

Chris: Did you see that Edge is sliding up over Safari in desktop usage world?

Dave: I did hear that news, and I feel like I deserve some credit.

Chris: [Laughter]

Dave: I'm a bit of an early adopter on Edge, so high-five to me. Yeah.

Chris: Yeah, it's good. It's a big, significant number, 10% - thereabouts.

Dave: Right. I think that's good. Edge, to me, is still the best Chromium-based browser for me right now. But you get all -- it just is. But I think that's maybe good for competition. Maybe that's what we wanted to happen.

Chris: Yeah. The battle of the Chromium feels like it's going to happen at some point.

Dave: Yeah. A browser is going up. That's good. You know what I mean? I don't think they're stealing from Safari exactly, but a browser is going up.

On that note, my wife just got a new Mac, a little MacBook Air.

Chris: Oh, yeah?

Dave: She checks tennis scores religiously.

Chris: A new computer. Fun.

Dave: Yeah, my wife knows the tennis. Every person in Austin -- every woman in Austin's tennis record. That's my wife's super skill.

Chris: What?!

Dave: She hawks.

Chris: Dang!

Dave: She's a hawk on these stats. It's like her ESPN. She's got every woman who plays tennis in Austin in her brain.

Chris: Just out of love for the game or is she into DraftKings? Does she throw a few bucks down?

Dave: No, no. That would be awesome. It's all like - whatever - amateur tennis, but she could maybe--

Chris: Oh.

Dave: I don't know if you can bet on amateur tennis.

Chris: I got my DraftKings right here. I'm not encouraging the use of this. I'm just saying.

Dave: If DraftKings wants to sponsor the podcast, we could encourage it.

Chris: [Laughter] I like to throw my little $5 bets on stuff. Sometimes, the fun -- and this is purely recreational and I don't encourage gambling in general, and I don't have a problem. I just think it's fun. And I'm an adult, so I'm allowed to do it -- is to bet on things that are happening right this minute.

Dave: Right. Right. Right.

Chris: Tennis is always -- there's always tennis happening at all times.

Dave: Oh, that could be fun then.

Chris: Yeah. You just throw $5 on somebody with the spread and see how they go.

00:40:13

Dave: No, that's fun. You know what my family does? Can I tell you a game, a game that my family does? We do micro-betting.

Chris: Yeah?

Dave: Let's say it's football, the sport. We basically say one dollar, they'll get a first down.

Chris: Oh, dude.

Dave: Everyone says, "Yeah. Yeah, I'm in." You know?

Chris: I'm in. They throw their dollar down?

Dave: They throw in either against you or, like, no way. You know?

Chris: Yeah. Yeah.

Dave: Then you divvy it all up. Or you just set a line, like they're going to score this drive. Then you can either bet against it or for it.

Chris: Yep. Yep.

Dave: Just one dollar bets. Boom, boom, boom. You're betting literally like 70 times a game.

Chris: Oh, my God. I want to come to your--

Dave: [Laughter] My family gathering?

Chris: This is what we did for the Super Bowl.

Dave: Yeah.

Chris: I had a stack of ones for the Super Bowl. I was at my buddy's house, and it was like the next commercial is either going to be--

Dave: Has Chrissy Teagan. Yeah. [Laughter] Chrissy Teagan.

Chris: Pizza or a phone.

Dave: Oh, good. Yes.

Chris: Or it's going to be for a mobile thing, or it'll be like, on the next drive they'll score but it won't be a touch town, and stuff like that.

Dave: Mm-hmm.

Chris: You throw a dollar. Then you have these little post-it notes because you'll never remember because there are like 20 bets going at once, you know.

Dave: Yeah. Yeah. Yeah.

Chris: Chances are people leave with the same money they came in with because there are so many bets. It's like how to you lose.

Dave: Oh, and the chance that you're going to win is pretty -- I don't know. Whatever. You can take a first down.

Chris: It's 50%, let's say.

Dave: It's 50%. Yeah, it's just every time.

Chris: [Laughter] It just is an opportunity to talk smack for two hours, and I love it.

Dave: Well, and then whoever, like your little nine-year-old cousin just has a fat stack, just has 52 ones.

Chris: [Laughter]

Dave: Doesn't know what to do, but they're just sitting there. She's just got a shit grin on her face, and you're just like--

Chris: Yeah.

Dave: "I'm coming for you, Dillon!"

Chris: Sophie needs a new pair of shoes!

Dave: Yeah. You know what, Dillon? I'm taking that money back.

[Laughter]

Dave: Go to the ATM. Let's go to the ATM.

Chris: Yeah. Dillon, I 'll bet you a dollar that they hike the ball in the next play.

Dave: Yeah.

Chris: Oh, I won! Sorry, buddy.

Dave: Dillon, I bet you a dollar your hand is bigger than your face. [Laughter]

Chris: [Laughter]

Dave: Anyway.

Chris: Oh, sorry you lost.

Dave: Oh, hey. Sorry. That's one buck. Yeah, you got me. Anyway.

Chris: Oh, that's the way to bet. That's the way to bet.

Dave: It's just dumb fun.

Chris: Keep all the money in the family. That's what I say.

Dave: Yeah, keep it out of the casinos. You don't need a casino for that.

Chris: Yeah, I know. It's not healthy. It's not healthy.

Dave: DraftKings is kind of -- I don't know. There's some-- It's fun to put--

Chris: I’m not going to defend it. I just have it on my phone. What else do you want to do here? We have just a few minutes to do it. We don't really have a lot of questions in the bank, I don't think. Please send in what you got. We love those. In fact, we wrote code to make that whole system work where it comes in via Wufoo form, which then hits the Notion API and makes a card with your name on it. It goes into a database. We can drag your card onto the show - kind of thing.

I'll tell you, Dave. It's not 2013 anymore where the questions filed in like nonstop, you know. The shows numbers are up, but questions have slowed down a little bit.

Dave: No one asks questions anymore. That's incredible. I think we solved all the questions, so that's good.

00:43:37

Chris: Pierre L. did write in though with one this week that was asking about Kirby CMS. Do you remember that? What was that name? Sebastian, Bastier - something. That was the guy behind that. Still works on it, I think. It was kind of an interesting take on a CMS - really early days where it was kind of an SSG but not really. You could still write queries. There was still some PHP involved, I think, so I don't think you could deploy it totally serverlessly.

Dave: Yeah. It was like a PHP app that read your static files - kind of.

Chris: File system. Yeah.

Dave: Yeah.

Chris: It was clever and it had lots of big fans. They're still at it, and Kirby 3.5, he says, brought an API to the party, which could be pretty cool, of course.

Dave: Mm-hmm. Mm-hmm.

Chris: Anybody that says we have an API now is usually met with clapping. Gutenberg like layouts, meaning I'm sure they brought the block editor to perhaps some kind of flat file production service or something. 3.6 has enhancements to that block formatting stuff, so pretty cool. Worth checking out. Getkirby.com is the URL for Kirby.

Dave: Yeah. I was going to say Bastian was on Episode 135 in 2014, and V2 was just about to come out.

Chris: Whoa!

Dave: Now they're on 3.6, I think, so there you go.

Chris: Yeah. Nice march forward for that. I like to see apps that stand the test of time.

Dave: Well, and that's it, too. Back then it was pretty new. There were a lot of competitors in the, like, "Let's rethink CMS," space. But none were mature. Now it would be kind of cool to revisit it just because now it's mature and we've gone through a whole static site generator era, too. Does it fit into that or no or is it better than that? That's the question.

Chris: Hmm.

Dave: Very interesting because it's got a beautiful UI, and I think that's it, too.

Chris: Ultimate cheat code, isn't it? Ooh...

Dave: Well, yeah. It's kind of back to the VS Pros, which whoever sent that in is a genius. My idea for a code editor for content editors.

Chris: VS Pros?

Dave: VS Pros, yeah, yeah.

Chris: Oh, I love it now.

Dave: It's beautiful. I think that was David Darnes. I'm going to say that was David, David Darnes.

Chris: [Laughter]

Dave: You know Kirby kind of has that. It's a very good UI over a little bit of a static vibe, so maybe that's the trigger you pull.

Chris: Yeah. Perhaps it is. Yeah, right one. Right on. God, there are already so many things to talk about, but maybe we just have a shortish one this week. That works for me.

Thanks so much. But do write in, and they don't have to be questions - remember. They can just be topics if you want, like Pierre did there with Kirby. Happy to do shout outs where appropriate and just bring conversation around particular things, you know, front-end, back-end. We're versatile these days.

Dave: We'll talk about it. All right, well, we'll wrap it up. Thanks, 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 16 tweets a month.

And we have a new, new, new, new ShopTalk Show Youtube, so go to that. It is our own channel.

Chris: Indeed, we do.

Dave: It's got all the videos of our videos, so go check it out. There'll be a link because we have 30 days and then we'll get the official one. But just--

Chris: What should we do? I guess we should just try to get ShopTalk, if we can, but we'll never get that, right?

Dave: We'll never get that because it's probably some peer-to-peer marketing thing or something. Anyway, hopefully, one day we'll get it. But we could probably -- we'll get a cool one. It'll be good.

Chris: Mm-hmm.

Dave: Yeah, and then, of course, send us your questions and join the D-d-d-d-discord, patreon.com/shoptalkshow. Chris, do you got anything else you'd like to say?

Chris: Oh... ShopTalkShow.com.