Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I guess we do more. I should have said website. Dang it.

I'm Dave Rupert and with me is Chris Coyier. We do like 530 of them and you think, like, "Ah, man. I've got to jazz it up. And then you just fall back in the old one you've been doing for 530 episodes.

Chris Coyier: Yeah. Yeah.

Dave: Lame.

Chris: What did you want to say?

Dave: We do websites. We do improvisational jazz, old-time music. We do camping tips. We do -- ah, man -- so much.

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

Dave: Yeah.

Chris: Let's say I was going to -- here's one. I didn't even know that I was going to do this to you, but here we go. You wanted to make an app where the data matters but only to you.

Dave: Yes.

Chris: Let's say it's a mobile app, right?

Dave: Mm-hmm. Mm-hmm.

Chris: I want data on it and it needs to be reliable. I'd almost -- I wouldn't even mind it being in the cloud. I mean I don't really know how to think about that, but it never cross-pollinates. Any other user's data doesn't matter. But it is data-data.

Let's just say it's a notes app, like I'm going to write, "Oh, here's what I'm thinking about," or a diary or something. It only matters to me.

Dave: Mm-hmm.

Chris: What database do I use for that? Let's say it's going to be a mobile app, so I would like it to not absolutely have a dependency on the Internet connectivity.

Dave: Hmm...

Chris: So...

Dave: Okay.

Chris: I mean I guess I'm talking about mobile development, so the temptation is to find some mobile app building framework, probably that's Web-based because I'm comfortable with that, and just see what kind of DB connectors they offer.

00:02:12

Dave: I mean is using it on multiple devices important to you? If you drop that--?

Chris: I don't know. Let's say now.

Dave: --phone in the toilet, those notes are gone. That's okay.

Chris: I'm tempted to say that's okay (just for simplification reasons).

Dave: Mm-hmm.

Chris: But also, I'm kind of like, yeah, but how hard is it to just utilize? Let's say it's going to be an iPhone app or an iOS app.

Dave: Mm-hmm.

Chris: To flip on the little iCloud storage majigger so that I don't really care about the syncing as much as I care about -- I don't know. I just got cloud backup for free, but how for free is for free here? I don't know.

Dave: Right. Right.

Chris: Let's say it doesn't matter though.

Dave: I think one thing, there's local storage, maybe. That's going to be a little bit brittle because when Safari decides I want to--

Chris: Yeah.

Dave: --or Google, whoever decides, "You know what? I'm out of memory. I'm going to go clean up."

Chris: Too scary. Too scary. Can't do it.

Dave: Good bye. Boom. Ka-plow.

IndexedDB on your phone might be a good choice. I think that's a little....

Chris: How long-term is it? Will it last for years, like infinity time?

Dave: I don't know, but I think it's a smidge more durable, if that makes sense. Right?

Chris: Yeah. It does. I mean more than local storage. I trust local storage about as much as I trust a cookie. You know?

Dave: Mm-hmm.

Chris: Which is not very much.

Dave: I would honestly probably just push it to the cloud, and I would just get a Supabase app up and going.

Chris: Yeah. That's kind of what I was thinking.

Dave: Supabase has authentication. Supabase, I can just go boom, straight in.

Chris: And then just have some kind of syncing deal that's like, "Hey, if you're offline, it's not like I'm going to gray out the app."

Dave: Right.

Chris: What do you treat as the source of truth then? If it's only ever one device, I guess the source of truth is whatever the hell is on the device, right?

Dave: I think so. That's where it gets tough because you're not syncing, and that's a hard problem, syncing to cloud. What if I just go on a delete spree and just start deleting stuff in my app? I have to remember the deletes and then say, "Okay, this delete action. Make sure that goes to the cloud."

Chris: Right.

Dave: You're kind of recording a list of actions at that point.

Chris: Yeah.

Dave: Then you need to play through that list of actions.

Chris: Maybe you're not, though. Maybe when you're offline it's not remembering anything. It's just when it returns new online, it's just like, sync all. Just whatever you've got, push that to the cloud. Wipe whatever is in the cloud and push--

Dave: Oh, yeah, because I guess the device is the canonical source, right? Yeah.

Chris: Yeah. I'm sure that's not what fancy people do. What do you do when you're fancy? Do you use CRDTs or something?

00:05:09

Dave: Yeah. Yeah, I don't know.

Chris: I don't even know. That seems more like for real-time or whatever, which is not the case here.

Dave: Yeah. That's like Dropbox-level problems.

Chris: Yeah, it really is, and they have very interesting -- I know Alex shared with me a blog post about how they do replication and were very clear about the problems that can happen and that it does have to do with, oh, but what if this person deleted this but you altered it or something? Somebody has got to win.

Dave: Mm-hmm. Yeah.

Chris: What's the deal? The worst-case scenarios are bad.

Dave: Yeah. I think soft deletes is a really good maybe action, too.

Chris: Hmm.

Dave: You can delete, but really you only ever soft delete. Because I know Notion has this paid restore feature.

Chris: Yeah.

Dave: Because Notion can get in the same situation.

00:06:12

Chris: Aren't you curious about soft deletes and GDPR a little bit?

Dave: Yeah. Right? Oh, my God.

Chris: I dug into this recently because we have soft -- just recently have soft delete on all at CodePen. We had not had that. You don't -- the CodePen users don't necessarily care about that. We didn't change any features. But we now don't hard delete anything.

Dave: Oh, well. Uh...

Chris: But there's a reaper.

Dave: That's a lot of CodePens with bottoms on them. [Laughter]

Chris: Well, there's not only a column that says soft deleted at. I think it kind of depends on the model, I think. There's a reaper date that's on all of them.

Dave: Mm-hmm. Okay. Yeah.

Chris: Then the thing comes and cleans them up. You know?

Dave: Yeah. Boy, that can be fast.

Chris: But the idea is, customer service-wise, it's a big idea. This has been a couple of years now, but this seems silly but sometimes old apps take a minute to catch up. There's basically a trashcan on CodePen. You delete a Pen. You can get it back (like for three days).

Dave: Hmm. Okay. Yeah.

Chris: There's a limit on it on purpose because we don't want you using your trashcan as privacy because that's a Pro feature. Otherwise, you could just keep all your Pens in your trash if you wanted them to be private. [Laughter]

Dave: No. Okay. Yeah, yeah. That's a good point. Yeah. Good workaround. Nice.

Chris: So, anyway, there's a three-day limit on it. If you want longer privacy, just be Pro. Then make them private and whatever. But that was just Pens.

Dave: Mm-hmm.

Chris: We were like, "This is so useful," while we're doing API work, that we extended it to every single database model of which there's, no joke, 74 or something on CodePen.

Dave: Gosh. Wow.

Chris: [Laughter] I know.

Dave: That's not small.

Chris: But if you treat them all the same way and you use industry-standard conventions of the column is called deleted_at and it uses this standard timestamp thing, your ORM and such can help you. It can make sure that when you query for things, you don't have to remember to say, "Oh, but also, deleted_at is not null."

Dave: Right. Even in a Rails world, your model can also be like, "I'm only going to show you freshies unless you requested deleted." Right?

Chris: Yeah. Right.

Dave: Yeah.

Chris: You can have helpers and such that make sure that you don't get that stuff. If you treat everything the same, your life is better. Anyway, yeah, soft deletes are cool. [Laughter]

Dave: Yeah, I've been thinking about that. I don't know. It also is such a nice little hedge against oopsies where somebody thinks they're heading down a right path and then they're kind of just like, "Ah, man. I nuked it."

I did that in my Notion the other day and it was just thankfully not critical, but it was just like, "Oh, if I had to move my whole Nuxt database or something."

Chris: Yeah.

Dave: It was something like moving it from a root to a page or something. It just didn't like that. I was like, "Oh, I could have really messed this up."

Chris: Hmm. Yeah, there's also this kind of concept of sometimes a hard delete, you have more work to do.

Dave: Mm-hmm.

00:09:29

Chris: A soft delete will always be instantaneously fast because you're changing the one value in one column.

Dave: Mm-hmm. Yeah.

Chris: It's like, "Okay. It's deleted now."

Dave: It's a bullion? Right.

Chris: Yeah, it's intensely fast. You know?

Dave: Right.

Chris: Whereas hard delete, I guess you could put it in a queue or something, but there's probably additional cleanup to do.

Dave: Yeah.

Chris: If you have any denormalized data, it's got to go deal with that. There might even be on third-party services. In the case of CodePen, it would be like, "Oh, well, we have to go over to the search servers and find it and remove it from there too because there's duplicated data there and those are hosted elsewhere.

Dave: Right.

Chris: There's also machine learning models things that it needs to go pluck it out of and make sure it's deleted and stuff. All those things are relatively fast, but not always.

Dave: Mm-hmm.

Chris: You know?

Dave: Yeah.

Chris: And you don't have the user sit there and wait for that. You know?

Dave: Yeah. The search can easily pick up on the soft deleted, right? It can almost--

Chris: Totally.

Dave: You still have to push that change, probably.

Chris: It's a fast change to push, though. Yeah.

Dave: Yeah.

Chris: Anyway, it's interesting stuff, isn't it? What they don't teach you.

00:10:37

Dave: Man, so you mentioned GDPR. Have you been getting into that? We had to write up a terms of service for Luro, privacy policy, and stuff like that.

Chris: Yeah. Mm-hmm.

Dave: Man, I get it. To be -- I'm doing nothing with your data. [Laughter] I am currently doing nothing with your data.

Chris: Yeah. You're probably fine then - for the most part. But you do have to adhere to some stuff like that deletion stuff. That's a thing with soft deletes. I don't know what territory that's in. But if somebody wants their stuff deleted, it needs to be actually gone from your servers.

Dave: Right. It needs to be--

Chris: Soft delete is not cool for GDPR, I would think. You know?

Dave: Right. Then they have to get access to what data do you have on them. That's another part of it, right?

But then I'm really looking for a GDPR for dummies, but not total dummies, like developers. You know what I mean? Not for lawyers because it just is really kind of overwhelming because they're like, "Do you collect any personal data?" It's like, "Well, yeah. The whole -- you need an email." [Laughter] That's personal data, so I guess.

It's like, "Well, are you processing that data?" I mean it goes through a computer processor. It does at one point, I'm pretty sure.

Chris: Yeah.

Dave: Am I a processor? I don't know. But there's jargon around that. It's like a process is something more like Google or something. Then there's a store, data is storing, store, and so I wish I knew more.

I'm not trying to invade anybody's privacy and whatever, but I wish I had the perfect article to wrap my head around what is this and what are my responsibilities. I haven't seen it. I wonder if it exists.

00:12:31

Chris: Yeah. There are connections to third-party stuff, too. If you use analytics, which you're probably not even quite there yet, but I'm not sure. Maybe you are.

Dave: We actually don't, but I think we would like to and we will be in a position or we're always one hire away from needing it.

Chris: I'm not even talking just about Google Analytics. Maybe I am a little bit. But more like that style of, like, I'm going to tell this analytics service what user I have here and what they're doing. Sometimes that stuff is really almost creepy.

I hate to say this because I actually think there are good ways to do this. But if you have ever seen that analytics service full story, I think they're pretty innovative in what they do.

Dave: Yeah.

Chris: But it also is like, you've got to be really careful about using that because you can very easily tell full story, like, "Hey, this is Mary Sue in Delaware, and not only is this Mary Sue in Delaware. Here's every freakin' pixel that they touched while using this website, including basically a video of them doing it."

Depending on what your app does, that can be weird. It's every keystroke. And people are rightfully pretty weird about keystroke loggers. My gosh.

Dave: You should be. You should be.

Chris: You should be. Yeah. That's a lot of creepy data, so one way to get around that is to be like, "When I instantiate this analytics library, I'm going to obfuscate everything. I am not giving them an email address. I'm not giving them any identifying information whatsoever. No names, nothing."

Dave: Mm-hmm.

Chris: It's all entirely anonymized, and then I'm only going to give them what I need to extract value out of the analytics service. Meaning - I don't know - like this user, when did they sign up for the service? Who cares. That's not super personally identifiable information.

Dave: It's not personal, and it's helpful to the business, like cohorting, and so you can calculate churn.

Chris: Cohorting. Exactly. Or be like, "Congratulations! You've been using this product for two weeks now. Can we ask you one question?"

Dave: Right.

Chris: Little stuff like that, which I'm sure plenty of listeners are like, "That's obnoxious," and then some people are like, "Well, yeah, but it's obviously useful. That's why people do it."

00:14:57

Dave: No. I guess I wish I knew. Yeah. Could I get a chart or graph that's how cool is this on the GDPR scale? You know? Here's common use--

Chris: Well, right. Oh, that's where I was going with that is like is it on you then to go scour that analytics database, which is a third-party service, so I'm not even super sure how you'd do that?

Dave: Right.

Chris: When you get a user delete request for a user, which you will inevitably get because, of course, because GDPR exists, there are services that market to users to be like, "Hey, for $30, we'll scour your world from the Internet," meaning you're just going to get automated emails for it sometimes that are like, you know, D'Quan Williams wants his data (via GDPR) scrubbed from your service.

Dave: Yeah.

Chris: You have to go, "Oh, fine. I mean I guess that's the law." Ideally, you build something where you can click a button.

Dave: Find that person and erase their existence, right? Yeah.

Chris: Right. But I'll tell you. How do you 100% know that you're doing that within the confines of GDPR? Well, partially, I think if you're really wondering that question, you're probably on the right side of history and the law. That means you're concerned about it and that you want to do it correctly, probably. I certainly do.

Dave: Right. Well, but you know, and it's--

Chris: You're not trying to get away with anything.

Dave: No. Same, same, but in a world of Google Tag Manager where anyone who logs in can click a button, add a completely invasive tracking service, I the developer have no idea that happened. You know? It's kind of shocking because now it's like, "Oh, now D'Quan wants his information deleted. I don't know. Oh, there are two more services and something that records every single user session on the site. Yikeronies. I have to go find that." You know?

Chris: Yeah.

Dave: That's hardcore stuff. Anyway, yeah. No, the use of those, I guess -- what would you call them -- user pathing tools or whatever, like Full Story or User Replay or something like that. That came up in our chats lately just from a bug perspective. It's so handy for bug tracking.

Oh, they couldn't log in. Well, what were they doing? What were they typing?

Oh, they typed their email wrong. They typed gmile not gmail. You know?

00:17:43

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by the brand new Wolvic XR Browser. XR meaning like VR and AR, meaning virtual reality and augmented reality.

I'm sure you've heard of devices like the Oculus, the VR Glass, the HTC Vive Focus, Pico Interactive, Lynx, all these devices that allow you to kind of live in another world. You know? You strap them on your face and you're seeing the world in a new way.

Those things have Web browsers in them because of course they do. They're connected to the Internet. They're for playing games and meeting with people and all kinds of different things. And it just makes sense that there's a Web browser in there.

But that Web browser, what's it going to be like? It's not just going to be a one-to-one mirror of browsers as we know on mobile devices. Just think how different the browser is between mobile and desktop. This is going to be similar, too.

What's pressing the back button like, and stuff like that? Is there even a back button, or is it some kind of a swipe of a controller? All those things need to be thought about and built. That's what the Wolvic Browser is doing.

It's brought to you by Igalia, who has done lots of Web work in an open-source fashion. It's just reaching 1.0, and it's default on some of these XR devices and installable on others.

It's really doing some unique, cool stuff. The fact that Igalia is making this browser at all is kind of diversifying who invests and makes these kinds of pieces of technology, so that might appeal to you as well.

It's just cool. It's cool to check out. I really encourage you to go to wolvic.com and check out what they're doing. Install it on your XR device if you have one and have a play. Thanks for the support, Igalia and the Wolvic Browser.

[Banjo music stops]

00:19:55

Chris: Want to do a question?

Dave: Sure. As long as it's not about GDPR, I'm great.

[Laughter]

Chris: "I'm wondering if you could provide advice on how to help some developers I frequently work with to match designs better? I lead cross-functional teams and have some very talented full-stack, back-of-the-front-end style developers from another department. They can work with React, Next, and stand-up powerful GraphQL APIs, but things often fall apart when matching a design from Figma. Things like font sizes and spacing will be all wrong, and they have trouble making choices when it comes up to the responsive behavior of elements. Usually fixing these issues means lots of detailed back and forth in Slack and our project management tool with me listing out things that are different from the designs, along with screenshots comparing the two."

I guess we can stop there, advice for Chris Coleman here. It seems funny to me because it seems like so often the tables are turned. It's like -- [laughter] or at least the jokes are, right? I have developers who can write HTML and CSS, but obviously, it's so much more complicated. Such a bigger job to stand up a powerful GraphQL API behind something. Isn't that--?

You're so smart. You can do that. But you can't even round a corner?

Dave: How about this, Chris? Have you tried handing them, condescendingly, a stack of Highlights Magazines and say--

Chris: [Laughter]

Dave: "Find the difference, you idiots." You know? You could try that. You know? You could try that.

Chris: Oh, my. Ruby rules at those things.

Dave: That's what I'm saying. Just give them one of these and be like, "Have you ever done this?" Then just see if they can do it. If they can't do it, you know, they shouldn't be involved in UI work.

No, I'm just kidding, but I think that's -- [laughter]. I think more seriously, I think one thing that maybe helps is PRs. On UI work specifically, make--

We put little screenshots on the template, the PR template. Just put screenshots.

Chris: Yeah.

Dave: Attach screenshots, videos, or whatever. That way people know it's going in.

00:22:26

Chris: Is it a different person, maybe? I mean if it's possible to be like, "Hey, can you just let these people--?" Do they want to be better at it or can they just stay focused on their database back of the front-end type of job?

Dave: Well...

Chris: I'm not trying to not fatten their tee or anything, but they're probably busy enough doing all that fancy-fancy work that's like, "Can you hire somebody?" Because even if they get better at making the rounded corners just right, getting the font sizes right, getting the padding right, fine. You forced them to get the design right, but that's the same type of work. You're in the same type of technologies where accessibility comes into play.

It feels like a problem that they can't even get the design even close to right. It means, what else is wrong? The semantics probably sucks. The accessibility. There are probably all kinds of problems under the hood there. Get somebody else to do that while they're dunking around with APIs.

Dave: Yeah. No, I mean I think it's part of the problem with an over-adherence maybe to agile where you're responsible for delivering the whole entire ticket. You know? It's like, well, maybe we need styling as a separate part of this so we can track how much time we're spending on styling and where we're getting blocked. I think, yeah, this is probably two different people.

I just wrote a post on "The Web is a Harsh Manager" over on my blog. It just kind of goes through the front-end is so broad; we probably need to start splitting it up. That's kind of in front of the front, back of the front, or design engineer was a term Natalya Shelburne put out there. Alex Sexton had front-end ops where you're kind of more with the tooling and the dependencies and builds and stuff.

I don't know. It sounds like you're in a situation where you need a CSS engineer or a design engineer.

Chris: Yeah!

Dave: Somebody who does this well, and that person can hand it off and be like, "Hey, I got it 80% of the way there. All of the form fields are there with the right IDs and names that we need. But can you make it good?" That's what I would say. I think you just need more - I don't know.

If fidelity matters, you need somebody who can do fidelity. You can maybe teach somebody to get there over a long period of time or just even as an organization be like, "Hey, we prioritize this. If you need help getting here, let's work on it outside of work tasks." You might need to take somebody to read... What is it? Web.dev's Learn CSS course is pretty good.

Chris: Oh, yeah. That one is great. I think that's cool that these things have to be kind of reinvented every half a decade or so.

Dave: Yeah. Yeah.

Chris: Language changes.

Dave: Be like, instead of making me pull the PR, build it locally just to look at your stuff, show me you solved the problem in a CodePen first. That could be another thing, too. Can you show the styling or what happened? Sometimes that helps me is take the markup, copy/paste the markup, copy/paste the CSS, start working on it in a CodePen.

00:26:00

Chris: Yeah. I love that. This is related to Christopher Stever's question here about "Any tips on accessibility/semantics on a Web app environment? I'm in the early stages of building out a Web app and new to professional Web development. It feels like I have no idea how to apply the accessibility in semantics knowledge I picked up earlier on the complexities of a Web app. After all, the ancients say HTML was designed for documents." Hot drama.

Dave: Yeah. Hot drama sound effects, please, Chris.

[Law & Order "dun-dun"]

Dave: That's my least favorite sentiment ever. I just hate it. I guess it's slightly true, but I hate that statement.

Chris: This idea that, like, "Oh, I can apply accessibility all day to some regular HTML. But now that I'm React, I can't possibly."

Dave: Well, not Christopher's thing, but just the, like, HTML was designed for documents - blah-blah-blah.

Chris: Oh... [Laughter] Yeah. It's pretty low-level. It's designed for whatever.

Dave: I mean, yeah, it's a markup. It's an expression. I don't know what you're looking for.

Where apps get in trouble is headings. You've got to make sure of your headings.

Chris: Yep.

Dave: Landmarks, got to make sure you have all the good landmarks.

Chris: Yep.

Dave: A search one, a main one.

Chris: Buttons. [Laughter]

Dave: Buttons need to be actually buttons. That's really not a hard thing for applications to adhere to. Links go to pages. Buttons do actions. Just abide in that and you should be mostly good.

There's going to be other stuff like disclosure patterns and stuff like, dialogs, et cetera. We now have dialog and details in HTML. Pretty good. Maybe you can use those.

Chris: Yeah.

Dave: Now beyond that, like contrast, those sort of rules, you've just got to do good at that. That needs to be something you can do.

Chris: You can always just pop open aXe for that kind of stuff. you know?

Dave: Mm-hmm.

Chris: It's going to show you the problem and then your brain should try to fix it at a systemic level.

Dave: Mm-hmm.

Chris: If your brain says, "Oh, the text on this page doesn't contrast enough with the background, don't fix it. Find out the root of that because it's probably not just this page. It's probably not just that component. There's probably something that's like, "Oh, can I change this generally, this background color all over the place?" Such that it fixes the problem more holistically - that type of stuff.

That sounds fancy and it's really not. It might be changing one variable or something.

00:28:43

Dave: Yeah. No, I mean yeah. Images should have alt text that describes what it does or, if it's redundant, don't have it.

Chris: Mm-hmm.

Dave: Where it's tough is WYSIWYGs and stuff like that. That stuff is hard, and you have to really sort of work at it.

Google docs has an accessibility mode I think you have to turn on - or something - to get the accessible Google docs. That stuff is super hard, so some of it is just figuring out what you can do and what's easy.

I was going to find out. There are a couple of user testing .com style services that you can pay. You can give them whatever, $1,500 -- I'm not sure -- and say, "Go use my site or a few pages and give me feedback." That might be something you'd want to look at.

Oh, Fable Tech Labs is one of my favorite. There's AccessWorks by Knobility who has sponsored the show before. Fable looks like a really good product.

You can have people with disabilities use your website and give you feedback.

Chris: Cool.

Dave: If you want to really start with real users, which is probably what I would do, do that. But you could also just make sure you have some things nailed down like flows, forms. Can you do it all with your keyboard? Stuff like that.

Chris: Yeah.

Dave: I think a lot of the things you do with a document website applied to an app website, there's just going to be -- the more JavaScript you use, the more, like, "If I turn this button, 70,000 things change," that's where you're going to have a lot of problems.

Chris: It sounds like Christopher has some accessibility knowledge and seems like doesn't know how to apply it to a Web app, which that I'm curious about because it's interesting to home in on that moment. Like, what is it exactly? What did you learn about accessibility that you feel like doesn't apply now?

Dave: Mm-hmm.

Chris: Or is hard to apply - or something. I'm just curious what it is, and it's not in the question, so there's not much we can do about it. But it is kind of a curious moment.

00:31:20

Dave: No, I mean yeah, I would definitely try to -- I don't know.

I think, too, maybe, Christopher, if you hear this and I didn't answer your question, which is totally possible, what exactly is not clicking? I think if we can get specific, we can really dial in what's hard about it. I think that would even be a really good blog post is what's hard about accessibility in an app context.

I think it's easy to be like, "It's different, so I don't want to do it." I agree with that sometimes. But I think if we could figure out what exactly is different, what's hard, what can we do.

00:32:08

Chris: It'd be all right. I'm tempted to see what you think about Heroku shutting down its free thing. This is going to air in about a little over a week, so there might be changes to the news, but I guess we could react to the initial announcement. [Laughter]

Dave: Yeah. Quite a bit of hot drama the week we're recording this. Oh, boy. I don't know, man. Heroku is cutting off the free tier. That's what is the announcement. Right?

Chris: Let me read the paragraph to set the stage.

"Starting October 2022, we'll begin deactivating inactive accounts." Okay. "Then in November, stop offering free plans."

You can't really argue against the second one. They're just going to stop having a free tier. You can react all day to it, but that's their choice, right?

To me, it feels like there's -- my internal feelings is that's deleting inactive accounts is crazy, right? What if it's just sitting there doing its thing, being a website, because you've promised that for the last 20 years or however long Heroku has been a thing. Doesn't it contribute to the link rot of the Web?

Dave: Yeah. Nah, I mean that's the tough part. They've offered free stuff and now they're just like, yonk. You know?

Chris: I wish I knew more about Heroku. On the free tier, don't they spin up and down randomly or something? You can't actually put a Netlify style one-page HTML website on Heroku, right? You can, but won't it spin down on you or is that not true?

Dave: No, you totally could. It's funny. My Heroku ID has been reset, so that makes me worried now. I was going to see what did I break.

Chris: Yeah. [Laughter]

Dave: Oops.

Chris: If you log in, I guess you'll get to keep the account. Does it mean that you get to keep your free account forever if you already have one? That's unclear to me.

Dave: Hmm... Yeah. Let's see. Enter verification code. What?

Chris: And plan to start shutting down free Dynamos and data services. No, if you have a free account, you don't get to keep it. Presumably, you can upgrade to keep it, but it will just be turned off. Even if you log in and become not active, they're going to turn you off unless you pay for it.

Dave: Yeah. Starting... Yep. Oh, man.

00:34:50

Chris: It's relevant to me because what if I decided to do that at CodePen and be like, "I'm going to start just deleting all CodePens. You're not free. Not too bad. I'm just going to delete your account."

I am not going to do that because it's part of our business model now. It's not a good plan for us - in a way.

Dave: Mm-hmm.

Chris: They must be backed against the wall in some other way either by investors or something. They need some money. They need to really juice their revenue, and they are thinking that this is the way to do that.

Short-term, I think you will -- like at CodePen, we would very short-term make a little bit more money, probably, to convince a few free people to go Pro and piss off so many people that we would be in danger. Now, Heroku and CodePen are not similar. Heroku does way more fancy stuff. It's obviously a way bigger company have way more sensitive stuff on it.

Dave: Mm-hmm.

Chris: They might be right. I have a feeling that this does kind of help them. At the cost of pissing people off, which it will piss off many, many, many that it will probably help solidify them as a company better.

Dave: Yeah, maybe. I mean I'm looking at what may die. You know what I mean? I have--

Chris: Of your own?

Dave: Yeah. But a lot of my stuff that's critical is on a paid tier, but a bunch of projects I did for a major pizza company and a few other demo sites or that clients--

Chris: Did you need something like Python or whatever behind them? Is that why you had to pick Heroku?

Dave: Yeah. Some of them were just Jekyll deploys, and that was the easiest way to get a Jekyll deploy behind a password.

Chris: Oh...

Dave: So we could put HTTP auth behind a Jekyll. That was free.

Chris: Hmm...

Dave: Now they are going to go away.

Chris: Yeah. That password protection stuff on Netlify is not free.

Dave: No. No. I mean we could use Netlify now, probably. I think you could. It's based on your team.

Chris: Yeah. I think that auth stuff is not free, though.

Dave: Yeah. Your team has to pay for that, but we would pay that. We would incur that cost as a consultancy or whatever. But yeah, it was the easiest way to get stuff up. I don't know. I have a couple of other things like that video game we made.

Chris: Yeah, so it literally is affecting you. I don't have anything on Heroku. I mean I have in my whole life, but I don't even think I have an account anymore.

Dave: I think what's not clear is what--

That was a big attractor to Heroku, like, "Hey, you can just push code here and just start using it," kind of.

Chris: That's a broken promise.

00:37:37

Dave: Well, and yeah, broken promise. It's kind of like that time -- wasn't it DigitalOcean had all these free credits? And if you went to a lot of conferences, you had like 200 years of free DigitalOcean credits or whatever? Right?

[Laughter]

Dave: They were like, "Hey, we're not doing the free credits anymore," and everyone was like, "What?!" You know?

Chris: [Laughter]

Dave: And stopped using them. Shout out if they're sponsoring the show. Love DigitalOcean. Actually using it, but it's kind of like that move. It's like what are you guys going to do? That's maybe what's not clear to me here. Maybe I need to read this, Heroku's next chapter.

What's the position if you're not the get up and going for free system? What's the marketing positioning? I don't know. I guess they could still be the slightly better AWS. But maybe they're just hemorrhaging that much server bucks on these unused Dynos.

Chris: Yeah. The stated thing is that there are a lot of developers burning hours on crap like fraud.

Dave: Crypto miners and whatever.

Chris: Yeah, just bad behavior on the platform, and it doesn't say this, but it's fairly obvious that when you put a paywall up in front of that stuff, that stuff just goes away.

Dave: Yeah.

Chris: At CodePen, we don't have -- there's no bad behavior of Pros. I think it happened once ever and it was probably a stolen credit card (just as an attempt to see what they could do with it).

Then you buy a bunch of, I guess, human hours back from that.

Dave: Mm-hmm.

Chris: Probably some real money, too, because you're certainly providing free stuff to people. It's not free for Heroku to do that. They just do it as a loss leader. You get your bucks back and then use it to - I don't know - support this fancier security stuff that they say that they want to offer.

I don't like how the blog post -- I have to scroll down nine paragraphs to find the actual news here of what they're going to do.

Dave: Mm-hmm.

Chris: That's burying the lead and you know what's important data here. You need to open with that instead of this thing, like, "Here are five different companies that love Heroku. Oh, by the way, we're turning off all free everything."

Dave: And we're taking these guys down with us. [Laughter]

Chris: [Laughter] Yeah.

Dave: Yo... uh...

00:40:28

Chris: What's your emotion? I can't react. I don't have any stuff on it. What's your actual developer--? I have actual things on actual Heroku, what's your emotional read?

Dave: I mean I do. Now my emotional read is, "Oh, goddam it. This is more work." They've been bothering me about upgrading my Dynos for so long. Now I've got to go and see if I have free stuff that I care about.

Chris: Yeah. More work for me. Great.

Dave: Yeah. Yeah because the idea is set it and forget it or, "Hey, you uploaded. Awesome. Go do it." But now it's like, "Cool, now I've got to upgrade stuff," and I should be upgrading. But it's like, "Cool. Now I've got to babysit all this stuff and make sure it works and updates. If it doesn't, what do I do?"

Chris: Yeah.

Dave: That's partly my naivety.

Chris: It looks like the lowest plan at the moment is $7 per Dyno per month. If you have three things you want to save, you're in the $21 per month.

Dave: And I think you had to do that anyway to get HTTPS.

Chris: What?!

Dave: Yeah. Yeah.

Chris: Oh, my gosh. Oh, yeah, you're right. Free SSL and custom domains. If you used a custom domain and not just blah.heroku.whatever.

Dave: Right. If you want a custom domain. Then I think, too, if you wanted to use -- I like Heroku still for they would let you do--

Chris: What if you just pass it through Cloudflare, though? That'll probably be still free.

Dave: Yeah, maybe. Yeah.

Chris: But it wouldn't be end-to-end SSL because it would look like it's HTTPS but, between Cloudflare and Heroku, it would not be HTTPS. You'd get that little half-lock.

Dave: Yeah. Then you had to pay $7, I think, to get a WebSocket, which sounds silly. But if you ever wanted to play with the chat app or do whatever, you had to get a website.

Chris: Hmm.

Dave: I guess it doesn't really -- like, you pay $7, but you're getting an actual server. I think it's fine. I don't know. I guess if I was a restaurant and I had an arcade machine that was free, and a bunch of riffraff kept coming in.

Chris: It's a quarter now!

Dave: [Laughter] Spray painting. Yeah. I would just make it a quarter, $1, I don't know. Just like, "Hey..."

Chris: There you go. Well, this has everybody thinking then is this coming for Vercel? Is it coming for Netlify? Are we going to get an email that's like, "All your Netlifies are going to be deleted unless you pay $7 a month for each"?

Dave: I mean that's why I was an advocate. I tweeted out a long time ago, like, "Give me a paid plan, Netlify." I'm on a cheap plan, like a legacy thing, but I pay for the--

00:43:19

Chris: Is that the problem is that the jump was super high? I always find that fascinating. Let's see what it is.

Oh, it's not that bad. But it goes right to Teams is kind of the problem, I guess.

Dave: Right. Yeah.

Chris: Even if a two-person team, me and you, we're at $40 a month, which is quite a jump. It always reminds me of Contentful. I'll never get over that, how they were like it's free until it's $800 a month or whatever.

Dave: Right. Right. Well...

Chris: Get out of here.

Dave: Pricing is hard, man. We've been doing that for Luro, trying to find the sweet spot.

Chris: Yeah.

Dave: Based on the value it provides and blah-blah-blah. It's difficult. It's hard to figure all that out.

Chris: Yeah, it because I don't think you want to go low. In fact, I'm pretty sure -- not you, but anybody. Low sucks. I don't really blame.

Here I am trying to convince Netlify that a $3 plan is a good idea when I actually don't think that. You know?

Dave: Well, yeah.

Chris: What I want is to never ever get rid of my free stuff, and it's not because of free. I'm happy to pay. But there is a value, right? I can't pay $40 for each one of these little ho-dunk little sites I'm doing for you. I think I'd have to find something else if that was the case.

Yeah. Generally, too low is a bad fricken' plan. You know?

Dave: Yeah.

Chris: Contentful doesn't want to have a bunch of $4 customers. They want fewer bigger customers because it's a matter of how well you can support them.

Dave: No, I mean directly. It's like money translates into support, and it's kind of -- or even I have to get a lot of people to pay me $10 a month to build out a feature that people want. But now I have 1,000 people paying me $10 a month, and they have 1,000 requests. You know what I man?

Chris: Yeah, it's fragmented then. Right?

Dave: Yeah.

Chris: Yeah. Enterprise is easier in that way. It's harder to get one, but then they're so juicy. It's like, "What do you want? Sure, I'm happy to build that."

Dave: Right.

Chris: You have one request. We're basically sitting here supporting you, one customer.

Dave: Right. Right. The money the enterprise customer is paying almost certainly offsets the cost of the team to support it.

Chris: Yeah.

Dave: Yeah.

Chris: Plus stable, though, too, unless you have lots of enterprise customers, which is everybody's dream, but that's not going to happen. Yeah, you lose the enterprise customer. Then you're in trouble. Whereas there's some stability and predictability to having a thousand $10 customers. That's not going to change all that much every month.

00:46:08

Dave: We once worked for a client. I don't think this is a secret. I'm not going to say the name. But they had a list of five. They had a list of 100 companies, but they had 5 that they were going for. It was just like we're targeting these five companies.

Chris: Oh, interesting.

Dave: If we can land accounts with these five companies, we're golden. And so, they had all this--

Chris: That's awesome. So, they'd probably get on a plane and go out there.

Dave: Yeah!

Chris: And go golfing with them or whatever bullshit you do.

Dave: They built custom landing pages for these companies and stuff like that. You know.

Chris: That's great. I love that. That's some hustle. Good job. Unless it was shady or something.

Dave: Well, the only shady part, and this is a feature that you can get on marketing platforms. You can detect if somebody's IP is in the IP range of known company's IP range. Does that make sense?

Chris: Oh, yeah.

Dave: That's an IPM address. Guess what?

I don't advocate for that. That was out of my pay grade.

Chris: Yeah. I see.

Dave: But I'm more of the--

Chris: What does that do other than--? What does that, make your nipples hard or something? "They looked at the email!"

Dave: [Laughter] Like the--

Chris: "They're looking at it!"

Dave: Vince McMahon WWF memes, like, "Whoa! Oh, my God! They knew what company I was at? That's incredible, dude!"

Chris: [Laughter] Yeah. Call him right now! He's looking at the website! Call him! Call him!

Dave: No way! No way! You knew I was there?

Yeah, gees. Yeah, no. I'm way more on the, like, just have a good product and let it sell itself. Edge, you know, but the idea, though, that you're like, "These five accounts, if we just focus our energy, that would make all the difference."

Chris: Yeah. Yeah.

Dave: That's kind of a cool business to me. I don't know. I think that's like, "We're putting our energy in this angle and that will change our lives." You know?

Chris: There's something attractive about it to me too. I think it's kind of cool.

Dave: Yeah. Yeah. It seems focused. Does that make sense? It's not like, "Gosh, I hope people will use it." [Laughter]

Chris: Well, it gives you focus to the product as well, right? You're pretty darn sure they need your thing. You better have validated that in some way.

Honestly, you're probably right at that point. If they don't buy it, it's almost like their mistake. [Laughter]

Dave: For sure. For sure. Yeah, so anyway, we're not doing anything like that at Luro, but it's very interesting to think about. Could you just--?

But I guess, tying that back to Heroku, who is Heroku going after right now? [Laughter] That's what I would love to know. What's the business plan here?

Chris: It reads in the post as a little bit like you can trust us even more now. We are going to double down on the infrastructural quality and stability of what Heroku is. If that matters to you as a developer, which all developers of course would say, "Yes, of course, that matters to me," it's them. Hopefully, that promise holds true or it feels good to people and that they're happy to pay for whatever tier because they feel like the quality is going to go up.

Dave: Well, and that's fair, too. It's like this overwhelming amount of free accounts was weighing down our ability to innovate, so we're not doing that anymore.

Chris: Mm-hmm. Mm-hmm.

Dave: That could purely be financial. You know what I mean? I mean in the current macroeconomic conditions, you may want to just be like, "We're reducing server time a lot. We're just turning stuff off." You know?

00:49:53

Chris: It feels like it highlights the house of cards that all this stuff is. There are no promises. AWS could decide S3 isn't a viable business model anymore and S3 goes away. Then what does the Internet do? Everybody has got to scramble.

They didn't promise us that. They're not going to do it because it probably is quite extremely profitable for them and the backlash would be insane. Who knows. There are economic principles that keep stuff like that in place. But clearly, those economic principles can be shaken sometimes, as we're seeing here.

Dave: Yeah. Yeah and that's -- I hate to boil it down to whatever (government, tax, inflation stuff) but I think it's having an impact. We might see a lot of flinches in the future. Who knows.

Chris: Yeah. This one also had that element of freeness to it that is always a little funky monkey, you know?

Dave: Free is tough. The freemium thing -- and you all kind of have it at CodePen, right? It's like, "Hey, it's free. Use it. Then pay more to get more things."

It's a very cool way to get a lot of users. It's a very good strategy.

Chris: One user costs us like a penny or less, probably. But let's say it wasn't. Let's say each user costs us a dollar because we were spinning up a docker for you or something.

Dave: Right.

Chris: That would change the math, obviously.

Dave: Right. Right.

Chris: [Laughter]

Dave: Now you're just like, "Wait a minute. That's less fun." Now you have - whatever - let's say 100,000 users and they all cost $1 per CodePen. Yikeronies.

Chris: Yeah.

[Laughter]

Chris: Yeah.

Dave: Immediately, you're like, "Okay. That's a lot. We need now a lot of paid--"

Chris: We just have this advantage of knowing all this stuff about our business now.

Dave: Mm-hmm.

Chris: It feels good to know that we're not going to make that mistake now. As we look forward and look forward to doing more stuff with your code and offering more features and stuff, we can be like, "Ooh, that looks intensive. Oh, well, we have a very easy solution for that. You can't use it if you're not paid. Otherwise, we wouldn't be able to support you."

I cannot be in a position where a free user could possibly cost me $1. I can't be in that position.

00:52:22

Dave: How about this? Let's do some flip-a-rooskies.

Chris: Yeah.

Dave: As a paying customer, a super-entitled super Karen.

Chris: Yeah. You can do whatever you want.

[Laughter]

Dave: Well, I'm paying for the freeloaders. You know?

Chris: Yeah.

Dave: One dollar of my $7 is going to the freeloaders. Maybe I don't like that. Maybe I want it to go to the product instead. You know?

Chris: Ah, that's true. Well, that's a good point. I mean that's what we're seeing there is that, yeah, I can't support you as well, so you would vote -- as somebody who likes and uses the product -- to remove the free plan because that would focus all of the attention of CodePen on that.

There are just some assumptions baked into that that may not be true. It's like, "Yeah, well, if we killed the free plan, maybe then there becomes a churn problem because we're not getting as many users. Then our numbers start to go down."

Dave: CodePen is super different because it's a community. It thrives on new blood showing up. You've got nine-year-olds ripping cool fricken' websites out. That's awesome. Maybe legally you don't have nine-year-olds.

Chris: Well, and then people being kind of like, "Ah, I'm not really a front-end developer anymore, so peace out." You know? You lose people on the other side too.

Dave: Right. Right, but I think there's -- I think the community aspect of it is super cool, fun, and vibrant. You want to keep that up. Payment kind of prohibits that. Or for some people. Not everybody, but for some people. But hey.

Chris: Yeah, indeed.

Dave: I can't live without my protected CodePens, so please don't take that away. [Laughter] Please don't ever say, like, "We're turning off protected CodePens." [Laughter]

Chris: We have absolutely no intention of doing that.

Dave: That will hurt me adversely.

Chris: [Laughter] Yeah. Yeah. Things happen sometimes, but we're just happily hosting people's Pens right now. I wouldn't have it any other way.

Dave: Good. Good.

Chris: I assure you, you're also probably in the penny category as far as costs are concerned.

Dave: Yeah. I'm not ripping as many CodePens as I used to.

Chris: [Laughter]

Dave: Just here and there.

Chris: Uh... all right, Dave.

Dave: We should wind 'er down. Hey, this was a fun one. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter for tons of tweets a month.

Join us over on the D-d-d-d-discord, patreon.com/shoptalkshow. Chris, do you got anything else you'd like to say?

Chris: Oh... ShopTalkShow.com.

Dave: Ripping CodePens.