Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show - hard stop edition. I've got a meeting, so that's life in the corporate world. [Laughter]

Chris Coyier: Darn right.

Dave: Yeah. How's it goin', Chris?

Chris: I'm doing all right. Doing good. Doing good. So, I thought we'd do a little bit of a question answering, topic satisfying here in this one.

Dave: Sounds good. We do have some updates.

Chris: We do? Okay.

Dave: The classic thing where we hit record, stop recording, and then more drama happened on the Cloudflare front and the Cara front that we kind of talked about last week.

Cloudflare, in a weird Twitter thing, seemed to imply they were doing illegal activity, which is gambling. And that IP range was about to get banned, and that's why they had to sort of like pull out the hard stop. And the enterprise feature they were selling was this IP rotation thing. Blah-blah-blah.

Chris: Did they say that? Why didn't they just say that?

Dave: Yeah, I don't know. It was like--

Chris: In the emails to the customer.

Dave: Yeah, yeah, exactly. I mean... [Laughter] But I don't think the problem is solved. I just don't... The customer service angle is not there. You can't just yoink somebody's stuff.

If they were doing legitimate illegal activity, which I guess gambling sort of falls on the line, maybe yeah. Maybe it is a problem. But I don't know.

Chris: Thinking about it afterward, to me it's the all-powerful sales team that bugs me a little bit. I know that even the CEO was like, "The sales team is not doing enough," so the sales team felt like they had to step up their intensity game.

But I would think, okay, pushy salesmen are one thing. Pushy salesmen with a "turn off the website switch" that they control, blah!

Dave: Yeah. Well, and it's a pretty clear conversation, like, "You are about to get our other customers banned. You need to move to this rotating IP service that costs $10,000 a month. Otherwise, we cannot host you." That's a really easy storyline to tell. [Laughter]

Chris: Yeah, use your words. You did it in one sentence. Look at you.

Dave: "Thank you. If that can't work out, then we wish you the best of luck." You know? That's a pretty easy conversation. But anyway--

00:02:52

Dave: Then Cara. Vercel got back to that Cara, that new app, that kind of art-sharing app.

Chris: Yeah?

Dave: And was just like, "Hey, you use 56 million function calls." [Laughter] "So, our numbers, we're feeling pretty good about our numbers over here," so it just seems like, yeah, something. And they had emailed them, and so it seems like--

Chris: I did. I saw that response as well.

Dave: Yeah.

Chris: It was like, "We do have limit caps, so you can turn those on if you want. We'll also help you. We also emailed you like five times."

Dave: And it looked like there wasn't an email cap set up.

Chris: It was a little more defensive than you want to see, but you know.

Dave: Yeah but I don't know, man. It feels like every month there's one of these, right? Whether it's Netlify or Vercel.

Chris: Yeah.

Dave: These are all companies where it's like, "Oops, you blew through your usage. It's $100,000." "Oh, I'm going to write a Hacker News article." "Oh, then we're going to refund your money." You know?

Maybe we need an Integrity in Server Limits Act or something like that just to prevent this from keep happening over and over and over because I don't think it's fair that the hosting providers have to deal with this. I don't think it's fair to the users to have to suddenly get a $10,000 bill, $100,000 bill.

Chris: It sucks on both sides. Yeah.

Dave: Yeah, it sucks for everybody. I mean I guess, "Ha-ha-ha, business. We're going all the way to the bank with our new $100,000 that we just served out." But you know it could kind of be like, "This is a new application and suddenly it's costing $100,000. Maybe we--

Chris: Yeah, you'd think because you'd think that the host themselves would have those kind of alerts built in. That would be weird if they didn't. You know?

Dave: Yeah. Yeah, yeah. Anyway, life is hard. Anyway, I'm not saying anyone did bad or on the Vercel thing. I think it's just a victim of its own success sort of situation.

Chris: Yeah. Yeah. Maybe it's just marketing. Let's get really nasty and be like, "Oh, that's the trick for a bunch of, like, get in the news stuff is just to be like put a fake bill together and be like, 'Look at what happened to me!'"

Dave: Ooh!

Chris: "But don't worry." You know? That's probably what's happening here.

Dave: I like that. I like this malicious marketing move.

Chris: Yeah.

00:05:13

Dave: I also wonder. It's funny. We've gotten into this serverless, ultimate scale. Render is an app I use. You can have it scale up. And Dino is on Heroku.

Chris: You're on Render?

Dave: Yeah, yeah.

Chris: That's cool.

Dave: It's great, but it's that thing. It's like, "Oh, I don't want to fall over, so I want all this stuff." But if you built all this serverless stuff, you could have probably just built a $10 Node server and it would have held up fine. Or you would have known when it crashed.

You would have known. You would have been in charge of making the server scale up by getting a bigger box or whatever. So, maybe there's some wisdom in letting the server fall over under load and you figuring out what you need to do.

Chris: Hmm...

Dave: Just don't let it be a Reddit server. That's not the one you want to fall over.

00:06:09

Chris: Some questions, how about that?

Dave: Let's go!

Chris: Felix Yo writes in, "Any advice on setting up Prettier and auto-linting satisfactorily? I feel like mine is never right and I don't know how it should be set up. Bonus points for getting oneself out of any prior misconfiguring."

You know the technologies they're using is, like, they're in VS Code. They use Sass. They use Vue. They use Nuxt and things like that.

Dave: Mm-hmm.

Chris: That does kind of matter because if you're using something that has some kind of DSL or domain-specific language (or even just really specific APIs and stuff), those can be linted as well.

Dave: Mm-hmm.

Chris: I feel like a classic example is something like React hooks, which you can do without a syntax problem but a React hook-specific linter can be like, "Yeah, but you're doing it wrong," which can be quite valuable, really.

Dave: Yeah.

Chris: Felix didn't say what's wrong, though. Do you have a sense of what's wrong?

Dave: Well, you know it's that thing where there's lintering, pretiering, and editor config are all very similar jobs.

Chris: They are.

Dave: I think it's hard to figure out what's right. And some of it, too, like Nuxt for example, a lot of it you kind of hand over to a plugin, a set of plugins, like Vetur or what's the new... There's a new one. Not Vetur but whatever the Vite-based one for version three is. I'm blanking on it right now.

Chris: Okay.

Dave: But you have some recommended plugins that come along with it, and those are sort of the ones that you want to use with it. Yeah, you mix in VS Code extensions to where it's like, "Format on save," sort of thing. Now we're getting even more configuration. Yeah.

I don't say I have one, but I think you just try to make them all match. So, if they do fight, they fight together. You know?

00:08:26

Chris: Oh, fighting is the worst. What is a good example of fighting? I'd say what, Dave, you were saying about them kind of having similar jobs or overlapping a bit, I lived. So, let me explain that real quick. I lived through this just recently because we were using one called Style Lint.

Dave: Yeah.

Chris: Which I still think is a good thing. They've gone through some pretty big version updates. It wasn't even a day job, but it was some work to get upgraded to some of the newer versions. But one of the reasons they did it was, like, "Hey, we're ESM now." Yeah, that's nice but don't really care because it's just an internal tool anyway. It's not like I'm coding around it. But perhaps a little faster.

And then the bigger thing is, though, we removed a ton of what this tool does because it was created during a time where Prettier wasn't as big as it now where formatting tools weren't as big as they are now. And there's a bunch of stuff in there that it's looking for to be wrong with your CSS that will never be wrong because Prettier just doesn't let it be wrong. [Laughter] You know?

Dave: Right.

Chris: You hit save and then it's there. It's like, "Who cares about - I don't know - indentation - or something?"

Dave: Yeah.

Chris: You don't check for that. It doesn't matter. It's going to be fine.

Anyway, we ended up removing - I don't know - 60% to 70% of the rules that we had in place for this thing, and that's what I think of when you said the tools kind of overlap. But it's like, yeah, they do overlap. If you have a formatter that fixes anything that could be wrong, you don't need a Linter then to check if that particular thing is wrong because it won't be.

00:10:00

Dave: Yeah. Yeah. Yeah, for me it's funny because I use them at different levels. I kind of want my Linter to run pre-commit, like, "Hey, before I commit this code, make sure it's all linted correctly." It takes a second or two to figure that out. But my style lint, I want to run on save and fix itself.

Chris: Yeah. Yeah.

Dave: That's where it gets a little hard.

Chris: An example of fighting would be two tools configured to format the same file. I would think VS Code is pretty good at sorting that out. Sometimes you'll see a little menu that's like, "Okay. Which one do you want?"

Dave: Mm-hmm.

Chris: Then it kind of saves that preference somewhere. Ideally, that's not happening to the people on your team and that you can kind of fix any kind of problem like that.

Something like Prettier does require the cooperation of the host machine. I don't know if I've ever seen a setup where Prettier only runs in CI or something. That would be weird to me because then you commit some code, and then there's - what - another commit on top of it that you need to remember to pull down before you can push again.

That would just be awkward, right? You want your prettified code to go up in your git commits, meaning you've got to do it locally, meaning you've got to install it locally. And it's going to require the cooperation of something like a VS Code plugin.

Then any time it's reliant on the host machine -- like you and mine machines are going to be a bit different -- boy, you better hope that it works. VS Code does try to help with this a little bit. It has kind of like a required extensions file you can put in a project.

Dave: Mm-hmm. Dot extensions, .vscode/extensions.json. Yeah.

Chris: Yeah, there you go.

Dave: Yeah.

Chris: Required might be a little too strong, but heavily suggests them.

Dave: Yeah. Yeah.

Chris: anyway, that's--

Dave: The weird thing is you can just be like, "Nope." [Laughter]

Chris: Yeah.

00:12:02

Dave: Then it's just gone even though that is how you - whatever - run your Jest tests on save - or whatever. It's so weird. Yeah, you know my only advice would be... This one, I know--

I think my general statement is going to be, like, "Start with what the framework gives you by default. I think the framework stuff, part of the reason people use frameworks is just to abide in their ruleset, and so pull that down. Then make modifications elsewhere.

I think you're going to have... These things are all kind of there. They're all kind of fighting. Not everything in your project is going to be on the framework. I don't know if you write serverless functions or something. They kind of exist outside of the Nuxt templates or something like that.

Chris: Yeah.

Dave: It can get hard there. But I think abiding the framework first and use what they are trying to suggest and then... I would love to see if I could get rid of Prettier but it does things like fixes quotes and parentheses.

Chris: Really?! Why? Why would you get rid of Prettier? I can't believe it. [Laughter]

Dave: Well, I just don't... Is that the one I need? I don't know if that's the one I need. I feel like editor config is--

Chris: Oh, are you saying get rid of formatting?

Dave: I feel like editor config is for your tabs and spaces, right?

Chris: Yeah.

Dave: And your new line characters. I'm just going to go through...

Chris: Editor config meaning a file sitting at the root of your project that has those instructions in it?

Dave: Yeah, like trim trailing white space on Markdown files.

Chris: Does that mean if you have that, that something like VS Code would just do it for you?

Dave: Um... I think VS Code should just do it for you (and other editors would that use that sublime text - or whatever). Then you're going to have an ESLint. We just kind of actually use a custom config for that. That's in a package that we manage.

Then we have the ESLint config. Then that pulls in a bunch of - whatever - ESLint packages like the Nuxt one and the Turbo one and the Prettier one. There is this ESLint Prettier sort of bridge, too. That's the bridge you have to cross, and it's a weird one. I'm not explaining this very well. We have Jest configs. We have a Turbo config for our multi-repo, mono-repo thing.

Then we have Prettier. And we have that one is just semicolon is false, so no semicolons. That's kind of like a Nuxt thing. Allow parentheses always. Single quote true, trailing comma none.

I would actually change that. I like trailing comma. But use tabs true. So, that matches our editor config to use tabs over spaces.

Then let's see. We have a Prettier ignore to don't lint the dist folder or don't try to Prettier the dist folder because that needs to be all crunched up.

Then we have a Vetur config, which is the plugin thing.

Chris: Yeah, okay.

Dave: It just kind of has its own. I don't even know what it does, to be honest, but that was the old one. It helps your... I think it's almost like the syntax level of view syntax, sort of like highlighting and stuff like that is all baked in. But then you get the, like, "This is how we intent view components in Vue sort of deal." You get kind of the framework-level rules or language-level formatting rules - if that makes sense.

Chris: It does. Yeah, yeah, yeah, which you kind of want or at least it's a nice little piece of DX that doesn't hurt anybody.

Dave: Mm-hmm.

00:16:06

Chris: Somehow, I feel like I'm just such a big fan of DX, generally. But I always feel like it has to be caveated because of how much pushback on DX at all there is.

Dave: Mm-hmm.

Chris: I feel like there's so much, I guess, in the circles I'm a part of that it almost feels like a dirty word because it's always pitted against UX.

Dave: Hmm...

Chris: It's always like, "You slob. You're willing to have DX? I hope you're not one of those slobs that thinks DX is more important than UX," or whatever.

Dave: You jerk!

Chris: "Don't tell me that good DX leads to good UX because it's a lie!" Anyway, there's so much negative against it. But I'm like, "I don't know. I'm kind of in the DX business, so I kind of like it."

Dave: [Laughter] It's hard, man. Usually, it's one person who knows what they're doing set it up. Now everyone has to kind of just abide in it or live with it. I guess the question asker here is asking to be that person.

I wonder if there's also another future. I haven't played with Biome yet, that new kind of fork.

Chris: Yeah. I can't believe we made it this far without mentioning that. They were hoping to replace Prettier for one thing but also other stuff.

Dave: Mm-hmm.

Chris: I feel like that's probably smart to start with trying to replace one tool.

Dave: Yeah. It was supposed to be format and lint, so linter and formatter, so ESLint and Prettier in the same sort of save command. On save, fix box. Or warn them about both.

Chris: Makes sense. I'd love to have one tool that were simpatico.

Dave: Mm-hmm.

Chris: Plus, it's like, "Oh, that was..." It's amazing how fast tech moves, but Prettier is written in JavaScript, I think, right?

Dave: Mm-hmm.

Chris: Whereas I think Biome can be like, "We're in Rust," or something. Don't quote me on that. I don't even know if they are. But they do have a big performance chart on the front saying how slower Prettier is.

I do kind of smirk a little bit because I'm like, never once in my life have I been like, "Prettier is too slow." You hit save and it formats your file.

Dave: Yeah.

Chris: Never sitting around waiting for it to finish. I'm sure there are dev ops people that do it in certain circumstances that could use it faster - or whatever. It's not like I have any problem with fastness. But at some point you're like, "This is strange."

Dave: Yeah. Well, it's such a weird thing to get nerd-sniped by because it doesn't seem like the bottleneck in my programming. But yeah.

Chris: Right.

00:18:43

Dave: There as a big thing, like, "I'll pay $20,000 for somebody to write Prettier in Rust," or something like that. I think even Prettier put that out, that bounty, like 80%.

Chris: Oh, I remember that. And somebody took it up on them, didn't--?

Dave: It looks like Biome claimed the bounty.

Chris: Oh!! Yeah, well, fair enough.

Dave: Guillermo Rauch matched it to bring it up to $20,000.

Chris: The whole industry was nerd sniped by this thing that doesn't matter. [Laughter]

Dave: Yeah. Yeah, I mean, well, you put money on the line.

Chris: What I'm attracted to is not the speed, though. It's the idea that you need linting and formatting and Prettier just does the formatting and the big linting tool that tends to be used for JavaScript is ESLint. Those two projects have nothing to do with each other.

Dave: Mm-hmm.

Chris: Is that good because then they - I don't know - push each other or something? Or is it bad because who knows what. They just don't talk to each other. They could potentially fight - whatever. If you had one organization that was responsible for both sides, that's attractive to me.

Have I switched? No. I literally just read an article that said, oh, there were problems six ways to Sunday. They didn't hate it, but there was enough rough edges. When I saw those, I'm like, "Oh, those would be my rough edges, too. So, no thanks."

Dave: It would be hard for me.

Chris: GraphQL was one of them.

Dave: Yeah. Okay.

Chris: Prettier does GraphQL files. I have a lot of GraphQL files. I'm not just going to not Prettier them because I'm switching to Biome. That's a non-starter.

Dave: Yeah. Biome, they have some guides on how to migrate. It would be hard for me to pull off of ESLint just because it is such a stable community. You don't hear about, "Dude, oh, my ESLint - whatever - didn't work," because the second it doesn't work, a billion projects go down. There's a strength in numbers kind of there.

But seeing the surface area between a linter and a formatter, I feel like there does need to be something addressed. Maybe my grand thesis is to try to make each tool do its job. Let Prettier do formatting. Let Linter do linting. Yes and no to rules. Style lint, say yes and no to certain things. ESLint say yes and no to certain things.

Chris: Mm-hmm.

Dave: Try to get your editor formatting tools and your Prettier formatting to be very similar or at least use tabs and spaces the same. Then hopefully, the plugins that you lay on top also behave similar and have not been overridden by people.

00:21:41

Chris: Yeah, hopefully. How big of a deal do you think those plugins are? It seems like a big deal to me. We talked about it in the context of VS Code itself. If you're going to unseat VS Code, you're going to need to wrestle with the fact that the average person has 20+ plugins on the thing.

Dave: Mm-hmm.

Chris: Yeah. I feel like that's kind of the deal with ESLint, too. There are so many plugins that customizes its linting to different situations that if you're going to unseat it, you better have it be extensible or, better, support the plugins that are already out there.

Dave: Yeah, the plugins can totally wreck it because you have a user override and a workspace override. You can totally mess it up. I had a big problem with Jest, my plugins config. Other people in my company weren't having the problem. It was just like, "Dude, what do I have wrong here?" or "What am I trying to do that's illegal?" That was frustrating.

I'm looking at Vetur right now, the docs and what it provides. It provides a mix. It provides a language server. It provides syntax highlighting, semantic highlighting. That's part of the language server. Snippets - kind of interesting. Okay.

And it supports so when you type - whatever - my component into emit, it knows what it's doing. It provides linting rules or linting overrides. It'll do self-closing HTML off - stuff like that. Formatting, it provides some formatting, extra formatting.

Chris: How do you spell this thing, V--?

Dave: V-e-t-u-r. Then there's also... There's a new one. I wish I could do - whatever. Vue3 VS Code plugin - I wish I knew the name of it. It's called...

00:23:38

Chris: Oh, this is freaking me out now. I hadn't seen this before, but no wonder. If you're worried about things fighting, I could see it being highly attractive, like, "Oh, my god! It's going to do all my Vue stuff? I'm a Vue guy! All I do is Vue stuff. Of course, I'm going to use this."

But then if your editor is also configured with other formatters, fight-fight-fight-fight.

Dave: Yeah, everyone is mad. Everyone is not having a good time. Okay, it looks like Vue is recommending the official Vue extension. But let's see what Nuxt recommends. Anyway, I'm just Googling on the show. That's not fun. [Laughter]

This stuff is hard. This stuff gets in the way of your productivity. I wish I had a better answer, but it's just something... The only thing I can think of doing is the classic, like, take out everything, delete everything, and rebuild it starting with probably the framework layer first and then layering in some other stuff. That's the only thing I can think of for that. I wish I knew offhand.

There's totally a name. My brain is not working for this Nuxt stuff. Anyway--

Chris: Alrighty.

Dave: You'll find it. You'll come across it. It'll be like, "You should be using this instead." Anyway--

Chris: We have a little interesting sharing thing here from listener Eric Mickelson.

Dave: Voller. It's called Voller, V-o-l-l-e-r.

Chris: Oh, yeah, yeah, yeah, yeah.

Dave: Sorry. [Laughter]

Chris: You should be using that instead.

Dave: Yeah. All right. Okay, go ahead.

00:25:15

Chris: Eric Mickelson writes in with a thing, a sharing thing. He was working on a job but the company is rebranding. They've got a bunch of colors in this rebranding. A red, a yellow, a blue. It looks like whatever.

Then he decides to build this tool for color combinations and part of it is it has a unique input. The idea is let's say you have these 4 to 20 colors, say. The little tool that he built, which he did in CodePen first--

Dave: Heck yeah.

Chris: --was just to dump a bunch of them into a text area, so hex codes, HSL values, any kind of color value. You just dump them in there, and then it combines all of it. It shows you a combination, any two combinations of those colors and whether it's accessible or not, which is kind of cool.

I've just never quite seen a tool like that. I also don't often have a coma-separated list of colors on my clipboard.

Dave: Yeah. Yeah.

Chris: But it is kind of nice. I mean if my goal is, like, "Which of these two colors can I use together and which can I not?" this is kind of nice. It was useful enough that he really prettied it up really nice and then bought colors.fyi, which is a nice domain name. Good job.

I wonder if it's supposed to be multiple colors. But there's a link then to compare colors. It's colors.fyi/compare-colors. It's this tool, but it's all prettied up.

Dave: Hmm...

Chris: Then if you just want to see the output, there are some examples there. You can just kind of copy and paste the example up into the input and see how he's done it. It literally takes every two combination of colors and tells you if it's accessible or not.

Dave: That's cool. Yeah.

Chris: Useful to them, and good job with making it into a real thing. Again, that's colors.fyi. Good job.

Dave: Yeah, good share. Happy share time corner! That's great.

Chris: [Laughter]

Dave: Yeah, this stuff is hard. I think about it a lot. Whenever I see ten purples in a design system, I'm just like, "Why?!"

[Laughter]

Dave: Now you have ten times X number of colors of blacks and whites to go against to figure out color contrast. You've made it harder.

Chris: That does seem like the standard way, right? It's either you just have one or you have the dark, normal, light, or you have ten.

Dave: Mm-hmm. Or ten. It's like one, three, or ten only.

Chris: Yeah.

Dave: Of every color. You don't stop at one. I'm just like, "I don't know if that... You've made just a... Why not stop? Why not go to 256? Just every color."

Chris: Yeah.

Dave: You know?

[Laughter]

Dave: Maybe it's three buttons that can go from zero to 255. [Laughter] Did you consider that?

Chris: Yeah.

Dave: Three channels.

00:28:11

Chris: I struggle with that myself a little bit. I don't know. There's some analytical part of me that's like, okay, there's an OKLCH system. I like that format. Let's say I get the C and the H right, or something.

Dave: Mm-hmm. Mm-hmm.

Chris: Isn't my design system then just changing that first value? Can I just change the lightness?

Dave: Oh, for sure.

Chris: Now I have an infinite. I don't even need tokens. I can just use--

Dave: 0.1, 0.2, 0.3, 0.4.

Chris: Yeah.

Dave: Yeah. Then your design system has 360 colors for the color wheel, zero to 360.

Chris: But the little other bird on my shoulder is like, "It's never that simple, though." OKLCH might help because of its uniform perception of lightness.

Dave: Mm-hmm.

Chris: It's probably better than we've ever had before. But I feel like usually really bespoke, handcrafted color palettes aren't as mathematically pure as that.

Dave: I agree with that for sure.

Chris: They're just a little fancier.

Dave: Yeah. I feel like the ideal color palette has three reds, three blues, five grays, black and white (whatever your values for those are), and three greens, let's say. Yeah. That's it. That's it. That's the perfect design color system. I'm done. I'm out.

Chris: [Laughter] Good. Cool.

00:29:42

Chris: An old friend of the show Matt Soria writes in with one about doing client work. He says a lot of times they just use Craft CMS for the backend and then kind of lately have started (for the front-end) doing Astro or they could use a headless CMS like Prismic and then combine that with Astro. They have opinions about pretty flexible, cool tools for building client projects.

He's finding that more and more existing and potential clients are kind of pushing toward Webflow a little bit, and Matt is finding himself very frustrated. He's like, "I checked it out and what can be done with it for non-developers is," as he puts it, "pretty fricken' impressive." [Laughter]

But there are a lot of limitations still. It's like they have this tooling set already. They have this pretty modern way of building websites with no limitations. The data can be crafted in a perfect way and the front-end can do whatever. It's like we're not really buying much with the way that we build websites by switching to a tool like Webflow that's so, so, so, so different.

Dave: Mm-hmm.

Chris: You're not writing any code in Webflow.

Dave: Yeah.

Chris: It's entirely a visual tool of crafting stuff. It's not quite like Squarespace where you're also not writing code but you're more like picking templates. I would think, with both of these tools, there is some way to jam code into them if you really want to. But it's generally not... They want you to, too. But it's not the standard way of using those tools necessarily.

Dave: Yeah. Everyone wants to code. That's how they get the hooks in you. That's the hooks.

Chris: Yeah. But Matt is just like... I get the feeling... He's like, "Am I being a curmudgeon? Am I just behind the times? Is this where this is going and I should get with it or what?" I kind of feel 'em on this.

I'm not as involved with what clients are asking for. Are they really specifically asking for Webflow? On the one side, you kind of get it because, theoretically, when I'm done with this site then it's not totally off the possibility path that somebody else can go in there and tweak the stuff because it is a visual builder. They've paid their check. I've moved on. Somebody on their team can log into that Webflow, click on some stuff, and change stuff.

They technically have a little CMS in there. I have heard not much good things about it. But if you were to do that, they could potentially publish new content and stuff like that. They're good people and they're trying to make a very useful product. But it is a super different way of building websites than it is for Matt here and the way that he's used to doing things.

00:32:38

Dave: Yeah. At Paravel, we build quite a few Webflow sites, and we enjoyed it, but we actually ended up hiring this guy, Blake, who is really good at Webflow or just can do it. His mind is there, so it's not a huge context switch to go switch over to that. Shout out to Blake.

But what we came down to, we had three sort of candidates for CMS if a client came to us. It's all based on who is going to do the updating and the size of the CMS. I could make a chart or a blog post about this.

Who is doing the updates? Is it Paravel is doing the updates? Well, guess what. Then that puts you into either a static site generator like 11ty or probably Astro would fit in the mix now.

Chris: Uh-huh.

Dave: Or if it's a big site -- and that's for smaller sites.

Chris: Okay.

Dave: I'm just kind of arbitrarily drawing that line. But for bigger sites, we would do Craft CMS. It's bulletproof. It's huge. It can do everything you need it to do. It's very programmable CMS.

Chris: Okay. Yep.

Dave: Those are that spectrum. But if you are going to do the updates and you want to tinker and change text every week and do all that stuff, that puts you into the Webflow category.

Chris: Interesting. Okay.

Dave: Because managing all of those updates through a Markdown-based CMS is probably not for you. That's probably not your life. We would probably recommend Webflow in that situation.

We had clients come to us and ask for Webflow specifically. Then low and behold, we do all this documentation, "Here's how you update your site. Here's what you need to do. Go and log here. Do this. Do that." What happens, Chris? They don't want to update their sites.

Chris: Yeah, so you did all the work to make it updateable and nobody bothers to do it.

Dave: We catered time and time again to this Webflow thing.

Chris: Yeah.

Dave: This idea that they're going to just hand it off to somebody internally and update it. They don't do it. Not to say that's a Webflow problem. That's probably an organizational problem.

Chris: Yeah.

Dave: I think that's a risk, too. Then you end up doing all the updates in Webflow because they just decided, "Oh, yeah. We don't want to do that."

00:35:01

Chris: Yeah. It reminds me of a bigger-picture concept. When somebody comes in with a solution already and you're kind of like, "That's not quite how we work," that should be an acceptable answer, especially for a customer service, a customer-focused design agency. You should be like, "Hold your horses. Can we find together the pieces of technology that best suit this project?"

I think you'd feel like you've got handcuffs on immediately if they're hired and they're like, "Well, we need your expertise, but we're going to tell you what to use." I'd be like, "That's BS!" There's got to be a chill way to walk that back and be like, "We've worked with lots of clients before. Can we influence these decisions a little bit?"

It almost seems like a red flag to be told so specifically what tools you're going to use. Is that a good client? [Laughter] Not to say you didn't have good clients.

Dave: No, no. But people get it in their head what they want, whether type or, like, "I went to a marketing thing and they said, 'Oh, Webflow is the best,' so now we've got to use Webflow."

I can't. Some factors are out of your control. That's what's cool to them.

We do that, too. It's like WordPress is cool to me, so I'm using WordPress on everything. React is cool to me. I'm using React on everything (whether it's the right tool or not).

I think we do that, too, but so do marketing people who are making these websites. I think you're not a curmudgeon because it is this... It's like typing with mittens on, basically, is how I'd describe it. [Laughter] Building a Webflow site, you're like, "Okay. I can't just type out what I want. I have to drag something into the interface and build it. Then I have to find a data store for it. Then I have to get the JSON to loop through." It's different but it's a decent tool and once you are... If your customer is visual, I think it's a really good tool because it's a very visual builder.

Chris: Mm-hmm.

Dave: I would put it over my experience on tools like Squarespace and stuff like that. I've built people's Squarespace and they didn't update the site even though it was easy to update.

00:37:37

Chris: Yeah. What do you think about the pricing on things like this, too? Squarespace brings with it... There's a pricing link right on it. Customers know what Squarespace itself costs. But if you're trying to run a business and you can build - I don't know - a website a month, you need to find a way to be charging $10,000 to do this.

Dave: Mm-hmm.

Chris: I worry that that's a hard sell to be like, they know that Squarespace costs $20, but you're going to charge them $10,020.

Dave: That's a tough one.

Chris: Tricky.

Dave: That one doesn't work. [Laughter]

Chris: Yeah. [Laughter]

Dave: But you know. I do think there is a managed package, like we're going to manage this for you - and stuff like that. But what always happens is you get into this builder, like Squarespace, I build them a Squarespace site and he's like, "Hey, can I just get my Facebook events on here?" I was like, "I don't know."

Facebook had this plugin at one time that could do that. Now it's deprecated and dead. And so, it was just like, "No, you can't." [Laughter] I can paste a Google Doc in here, I guess.

It was really... I think people want this application. They want, like, "I want to build an application and do all this," but they rarely want to pay for it. That's the hard part.

Good development costs money and takes a lot of time, unfortunately.

Chris: All right. Well, thanks for writing in, Matt. It's been too long. Good to see you're out there building websites, doing your thing.

00:39:07

Chris: I like this one. Their name is Over Lay.

Dave: Good. Yeah.

Chris: Over Lay writes in, "What's your take on accessibility overlays?" Gosh, over the years, we've really gotten... There's been a lot of not-so-good press about those things. People being real mad about them, lawsuits slinging around, landing pages telling people how awful they are.

Can't say I disagree, really. To imply that accessibility can be fixed by adding a line of JavaScript to your page is just a little too good to be true. Not a big fan, myself.

I will caveat that, though. Hopefully, this isn't too unpopular of opinion. When was the last time you even seen one? I browse the Web all the time and they're not around. I never see them.

Dave: I tend to see them on websites, [laughter] shopping websites, specifically shops where I'm looking for something for my wife. Or it's kind of like - I don't know - an ebike website or something like that.

Chris: [Indiscernible]

Dave: I'll get them in... They're not great. What I don't like about them -- this would maybe be....

There's an article on Accessibility Project, "Should I use an accessibility overlay?"

Chris: Okay.

Dave: I'll put a link in the show notes here.

Chris: Yeah.

Dave: But the TLDR is no. I'll tell you what I don't like about them is I just feel like... On the one hand, I want people to have the tools they need to make an experience their own. I do support that. What I don't support is this idea that we're going to do a bad job intentionally, not fix anything, and they can fix it themselves.

That's what I don't like, this whole idea of, like, "Hey, disabled person. You figure it out." That's what I don't like about it.

Chris: Is there anybody? I'm sure this person exists but I've never heard of them. Is there somebody out there that's like, "You know what? I need accessibility tools to browse the Web and my favorite ones are these overlays."

Dave: [Laughter]

Chris: "If every website had an overlay."

Dave: I don't hear that that often.

Chris: That would be great.

Dave: But there's maybe somebody. There are all kinds of people. And accessibility isn't uniform.

Chris: True. Right. Yeah.

Dave: People's disabilities are different. Some people just need a little bump on contrast. Some people just need a little bump on font size.

00:41:51

Chris: It seems a little malicious to me. If this is your mission in life is to make more accessibility websites through tooling, so not asking much of developers. That's what you've decided. You're like, "Accessibility is too hard. Let's not leave it to the developers." That's more and more of a popular idea because, god, have we been trying to tell developers to make accessible websites for a long time and it only ever gets worse. Ugh... It doesn't feel good.

I feel like developers should still be on the hook for this but okay. Let's say that that's your mission in life is to not have it be a developer problem but a website problem. What you've done then is you've picked the wrong path. You picked "let's sell websites this tool to put on them" instead of - bear with me - a browser plugin that would fix all websites.

Dave: Right.

Chris: Don't you want that? Shouldn't that be your target is to fix all websites? Now 1000x or more, you have helped with this problem. If you're this altruistic person that's trying to fix the Web for people, tell those people, "I got you covered. I'm going to do this for all websites for you."

But no because you're not going to sell as many.

Dave: Yeah. The profit margins on a Chrome extension are zero dollars and the profit margins on--

Chris: Selling an ebike shop $100 a month plan to make their website accessible.

Dave: Sort of extorting them almost, just like, "Hey, your website is really bad."

Chris: You are because you kind of wink-wink you might get sued.

Dave: Yeah.

Chris: You do that little trick, too. Ugh!

Dave: It's not actual extortion but sometimes it is. But you know. But it is a threatening thing, like, "Oh, shoot, dude. We could get big-time sued. That would be bad for us."

Your appetite or your learned behavior around that is probably only if you've been sued before. If you've been sued before, you're like, "Dude, I do not want to do that again. That was bad."

Anyway, yeah, my thing is the same about AI fixing accessibility. It's like I want people to have tools. I think that's cool. I want people to have alt text on demand if somebody didn't put alt text in there. I want that to exist. But I don't think it's this...

I don't necessarily think it's this "fix everything" balm. Cure-alls cure nothing. [Laughter] That's an old Sawbones podcast saying is "Cure-alls cure nothing." I just don't think it's going to cure everything in one fell swoop.

But it's a weird situation. Deque has a big thing about AI is going to fix accessibility, help us fix it. Then a lot of accessibility professionals are switching over to these basically AI - or whatever - overlay companies. Or accessibility places are buying overlay companies, and it's just this big...

Not to be cynical but I think it all comes down to money. And it comes down to that whole Silicon Valley episode about the box or the platform. Do you remember that episode where they were like, "I can't sell a platform but I can sell a box"? Right? People don't want to make their websites accessibility, but they want to put a widget on their site and check that box that they did it. They want to buy the product that fixes the problem and think it fixed the problem.

There are website companies with... or accessibility companies with these overlay tools and maybe they're using that to start engaging them in actually fixing their problems or maybe they're engaging them in just--

Chris: Hmm...

Dave: Or they're just like, "We need recurring revenue," and these are recurring revenues. So, the goal is better websites. That would be great.

Chris: Yeah. Yeah.

Dave: But I just don't... I don't think a website-fix-o-matic fixes it.

[Laughter]

Chris: Yeah. Yeah. Yeah and to kind of handwavingly say that AI is going to help feels so strange.

Wasn't there A List Apart article about it, too, that was less vague, at least. It was like adding the alt text, great. Adjusting the colors. I forget all the specific things, but you can imagine a tool that has some smart automation in it to fix these kinds of things.

But then you're like, "Uh... But wait. Isn't that what an overlay is?" Danger, danger.

Dave: Yeah. It's very similar but different maybe. I don't know. I don't know.

00:46:50

Chris: We started the show talking about linting and all that kind of thing. Is that more useful, a tool that would tap a developer on the shoulder and be like, "Yeah, that's not good"? There already is some of that stuff. But if you have to have something be AI-powered, make that better.

Dave: Yeah. Ideally, yeah. It shows up on the tooling. But it is also possible to mess a site up on the content editing side, the WYSIWYG generating some barf or not adding an alt tag or whatever. That can be a problem.

You need the code-level assurance, like the continuous accessibility, Melanie's thing. Put it in the pipeline, the CICD pipeline. But you also need it in the production pipeline, too, the oversight.

Chris: Yeah. A lot of layers to this thing. We like to talk about really big, hard problems on this show.

Dave: Yeah. I have a post in my brain, in the ol' brain blog--

Chris: Yeah?

Dave: --about this. It's this idea of, like, champions or experts, accessibility experts, champions, and laypeople. I think we need accessibility experts, people who really understand the field. It is such a nuanced field; we need experts.

We need champions inside organizations on teams who will own a certain burden of, like, "I will manually check the tabs component. I will manually check this. That's on me. I will raise flags, squeak wheels if I see something that doesn't look right." We need a champion in there.

Then we need laypeople to have automation end-to-end. We need automation for the code you write to the code you commit to the code that gets merged to the code that's in production.

Chris: Yeah.

Dave: We need that, and that's an everybody job. You need everybody to be doing that bare minimum. That gets us up to like 54% accessible. Then the champion gets us up to like 80% accessible. Then the expert can bring us out to 100%. They can tackle big problems and big thinking.

Chris: That's your blog post draft? That's a good draft.

Dave: Yeah. It was a good draft? All right.

Chris: Yeah.

Dave: I'll put it on the old hopper to get done. I need charts and graphs. I started thinking about this stuff, and I'm like, "Ugh! It's visual."

Chris: Maybe, yeah, or bust out the... That was my dream for a while is to have such a good workflow for the iPad with a pencil or just your finger or whatever to be like, "Oh, man. I've written three paragraphs and there's nothing to break it up. Let me just scrawl something that helps make the point." Then I did it two times.

Dave: Mm-hmm.

Chris: But still, it's cool. I wish I had that as a real habit.

Dave: I wish I did, too. But occasionally, I do it.

Chris: Yeah.

Dave: But I wish I did it more.

All right. It is the hard-stop edition. Sorry. I apologize. I do have to get to a meeting.

Chris: Oh, yeah. You've got to go.

Dave: 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.

Mastodon and join us in the D-d-d-d-discord. That's where the party is, patreon.com/shoptalkshow. Chris, do you got anything else you'd like to say?

Chris: Oh... ShopTalkShow.com.

Dave: Also, join us at Frostapalooza. Yay!