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 Web design and development. I'm Dave--in a new office, so I might sound a little weird--Rupert.

Chris Coyier: Ah!

Dave: With me is Chris--in a perfect audio sound booth--Coyier.

[Laughter]

Chris: It's just the way it is, but you sound good, Dave. I wouldn't worry about it too much. Plus, we have the masterful Chris Enns on audio engineering to take care of anything weird anyway.

Dave: I flew him down from Canada to sit by me on a mixer.

[Upbeat music]

Dave: He's working a mixer, live, right now. [Laughter] No, that's not true.

[Record scratching]

Chris: You know what I noticed? I do this thing where I'm like, let me say something really emphatic and normal, [speaking slowly] and then go like this to complete my phrase. [Speaking normal] It's a weird audio quirk.

Dave: Ah--

Chris: It almost annoys me when I listen, so sorry, listeners. I'll try to speak in a more even tone if I can. I can't promise anything.

Dave: Interesting. We're 360-something episodes into our podcast.

Chris: I'm just learning, really.

Dave: I still figure things out. I'm like, oh, did you know I say "um" and "like" sometimes, Chris? Did you know that?

Chris: [Snickers].

Dave: Or I'll just laugh uncontrollably when I want to finish a sentence? That doesn't make sense, but I do that. Oh, well. Hey. Welcome to the ShopTalk Show.

Chris: Well, it's just me and you this week, Dave. This is something we are familiar with where we're going to answer questions of y'all. You know, while this redesign of this website is going on, I want to make really sure that the website itself heavily emphasizes the ask a question thing because I love getting questions from y'all. I'd say, over 363 episodes, the velocity of that has suffered a little bit, although we still get plenty of questions to do the show. I just think the more the better that we get to pick from and stuff.

I'd say you have a pretty decent chance of getting your question on air if you write in, so that's what I've done. I've, of course, like on all these shows, picked out some of the ones I think would be great to talk about and that's what we're going to do.

We have Bart who challenged us to say his name correctly. He said he would write in and tell us how we did. He didn't give us any pronunciation notes, but it looks like Mic-zek. Bart Miczek writes in, "What are the rules on displaying your email on a website? I've seen some developers, for example, write out in plain text, name [at] company.com." and you've seen that before, haven't you, Dave?

I think the gist of it is, it's not a real email address, but a person looking at it with their eyeballs can be like, "Oh, I see what they mean. They're trying to put their email address here, but not actually put their email address, instead of just writing their email address. They don't use a link. They don't use a mail to link. They do anything.

I guess the point of that is to prevent scrapers or whatnot from just grabbing that email address that looks legit and throwing it on some kind of spam email list. What do you think these days, Dave? Do you ever do that? Do you still do that?

Dave: You know in a tweet or something, I will do name [at] company.com or whatever.

Chris: It seems like it's extra susceptible to a scraper, do you think?

Dave: Well, I feel like the at symbol is a telltale, like I know how to write that RegEx. I can make that happen, like scrape an email address. It's maybe less of a problem with good spam filters and things, like Gmail and Askimet and all those kind of products, but I would still -- unless you really want to risk getting spam hammered, I would still probably just do something silly to kind of obfuscate it, if that's the word.

Chris: Yeah. Yeah.

Dave: Try to confuse the computer only because you know those emails, like the phishing emails or the emails that you can't ever unsubscribe from. That's where they just find your email somewhere; they sucked it up off the Internet and email you. It's probably less of a problem than it was ten years ago when a lot of people did this. We used to all use this tool that Dan--

Chris: It seems like it. Yeah, right. It used to be really common. People used to be really worried about getting on spam lists and stuff. I think that probably was in the water. It was a reaction to the technology involved. It's like, chances are that people's email clients didn't deal with it particularly well and that spam in your inbox really was an actual problem that you had 15 of in there every morning or, God forbid, hundreds of them and you had to swipe, swipe, swipe, or we probably didn't even have swiping ten years ago. You had to click a little checkbox….

Dave: Mark as read, trashcan, mark as read, trashcan.

Chris: Yeah, and that's no good. My mother still does that! To this day, she has an email address that doesn't have a particularly good spam filter thing on it and she just kind of considers it part of her day-to-day life is managing literally hundreds of spam emails, which to me I look at and I just can't. I can't even look at it. I have to forget about it sometimes because that's crazy talk, you know. I've just never dealt with it.

Dave: Does your mom run an email blog?

[Laughter]

Dave: Does your mom know you run a blog about emails or what?

Chris: No. Most people don't, really, but I do. I just had this idea that I wanted to write about email a long time ago. I thought the path forward was just to make a blog. Then once I hit hundreds of blog posts, I can start distilling the thoughts that presented themselves in there.

There used to be some old research on this that took a brand new email address that never existed before and it sprinkled it onto a website in the different ways, like this at in square brackets kind of thing. There used to be about a dozen different ways you could try to obfuscate it. You could inject it in JavaScript somehow. You can write the email name backwards and then flip it around in CSS to visually show it the correct way. There is even more clever ways than that and it ranked how successful it was at not getting any spam. There were only a couple of them that were perfectly effective and all that.

The number one point I want to make, just before passing it back to you here, is that I just have always used Gmail. I'm a good 15 years into using Gmail, and spam just isn't a part of my life. Maybe one a day, typically. Usually, zero but maybe one or two will slip by, and I just don't even think about it. I just whisk it away. I just click, "Report Spam," which is satisfying because it's probably training some kind of machine learning thing somewhere.

I plaster my email address everywhere, all over the Web, and I never think about it. I just never get any spam. I just credit Gmail for that.

Dave: Yeah. Well, you know, we've complained about it on the show before, but you know those, like, "Hey, my boss--" What was our boss's name? Turdy McTurdson.

[Laughter]

Dave: Whatever. Anyway, "Steve McTalks-a-lot wants to come on your podcast."

Chris: I still get a ton of those.

Dave: I wonder if people are harvesting our email or mine from the RSS feed, which has -- I shouldn't say this on the show -- an email address in the RSS feed.

Chris: Hmm. Right, so I complain about not getting spam, but I actually do. I get this different kind of spam. "My boss wants to be on your podcast," spam. That's fair.

Dave: Yeah. Yeah.

Chris: It's kind of worse because it takes mental cycles to get into their email to realize what they're asking.

Dave: The worst thing, though, is when you're on a mailing list and you request to get off of it and you don't get off of it. I think we're on some kind of publicist loop for some stuff, and it's just like, "Please take me off. Please. Please. Please." It's like, "Nope, we're not going to do it."

Anyhow, yeah, I would say just put your email. If your email starts getting bad, then just change it a bit, Bart.

Chris: Sure.

Dave: Miczek. I'm going to go Mi-check.

Andrew St. Angelo writes in, "As a full stack developer and not a designer, I enjoy tweaking and editing webpage layouts, but I'm always averse to starting a new project from scratch because I have to design the layout. What resources do you recommend to Bootstrap your website's layout? Do you have any free website templates, sites do you recommend?"

Chris: That's cool. The first sentence, "I'm a full stack developer," that's a whole can of worms. Maybe we won't do it right now, but it probably means that he has some server side experience and some front-end development experience and considers himself pretty talented at poking around the Web stack and getting things done as a Web designer. Very cool. Or a Web developer/designer, but feels not particularly design-y, especially from that starting a design from scratch thing, so not into that particular aspect and likes tweaking the layouts and the designs but not from scratch, which I get it.

It seems like people in that boat are commonly Bootstrap people or what's another one that I like recently that's in that category that I thought was cool? Anyway, or you like pick a WordPress theme or whatever.

I don't know. Traditionally, there have been stuff like Theme Forest or whatever. I'd mention a couple other names, but some of the other companies in this category that are kind of known for selling webpage layouts are so obnoxious of companies, speaking of obnoxious sales emails that I get that I won't even say their name.

Dave: Mm-hmm.

Chris: I see their URL in an email I get and I just archive it or perhaps write back and tell them how annoying they are because it's like, "My God, people! Let it be."

Dave: For me, I feel like you've got to first know what kind of site are you doing, right? Is it a blog? Great. You're probably going to have a post template and an archive index. Those are your two layouts you're trying to figure out. I think you have to quantify.

Are you doing a restaurant site? Okay. You're going to have a menu, and that's going to be a pretty intricate layout. Maybe you want the very cool picture on the front page that's somebody--whatever--making a fresh salad. That's a restaurant site.

If it's photography or architecture, you'd probably want a big photo. That's what you're enhancing. You want the architecture to shine. You kind of have to A) decide what you're making.

Chris: Yeah.

Dave: You can go find some websites like that. This is where I love your perspective because I've seen you do this a couple times recently, Chris. How bad do you want to break the mold? I feel like, with Chris, like CSS-Tricks, the redesign, which is awesome, I guess this is the 2019 edition, the ombre, orange to pink ombre version.

Chris: [Snickers]

Dave: That was an awesome way to shake it up. Not everyone has this blog layout, and I thought that was really cool.

How do you decide to do that? Yeah, I think you can break the mold, but how are you going to break the mold is kind of the big question.

Chris: Yeah, when is it time to get weird with it? I don't know. I don't have a super strong answer for that.

In my cases, they were just presented to me largely from Kylie, who is just good at that kind of thing as a designer and I'm just like, "Rad! Ship it. Let's do it," you know. [Laughter] I think I'm much more boring as a designer if I'm left to my own devices, you know, like Andrew is.

Dave: Mm-hmm, but no. If you get past the first couple--I call it--layers of the sandwich, the first couple layers of your homepage sandwich, it kind of goes back into a static or classic, I should say, list view, but you did this background image fade thing, which is super cool, on all the posts. There's stuff like that you can do, like visual tricks. Yeah, I don't know.

Chris: I think I love the idea of looking, like, what are you building? Look around at other examples that you think have done a good job. Like Dave said, if it's an architecture site, it may behoove you to look at some other architecture sites to see the vibe going on there because it doesn't hurt. But then, do you want to look like every other architecture site? Maybe this is an opportunity to kind of understand what, generally, architecture sites look like and then decide are you going to go along with that or are you going to bust it down? I like that kind of thinking, in a way.

Andrew was kind of asking, like, I just want to be given something. I guess if that's what you want, then I don't know. Dave and I probably aren't the best people to ask, but there are probably some template farms out there that you could find that will cough up some stuff for you. They've got to exist. I just don't use them all that often.

Maybe it's even like CMS-based in a way. It seems somewhat common that, of all the major CMS of which that's a huge topic but, regardless of what they are, there are generally themes available for them. Whether or not they are a heavily theme-based CMS or even if they're not, there tends to be themes available anyway. They just are, generally. Just look around. Be like, "Show me popular Gatsby themes," or whatever. I'm sure even 11ty has themes these days you could find around lately.

Maybe if the CMS drives your choice and you just want to be given a theme to start with, the CMS choice will probably cough up some theme choices for you, you could start with.

Dave: Yeah. Well and, for me, it's sketching too. I have probably stacks and stacks of little applications I want to build all sketched out. I have the kind of index view and then the detailed view and then maybe some kind of flows that I have. I have piles of these ideas and stacks of sketches. Then it's just a matter of building it out.

With stuff like CSS Grid, it's super easy. It's painful. It's painfully easy to build out these experiences now. Your sketch to layout, that delta used to be huge. You used to have to be like, "Well, I'm going to make a grid system and the grid has to support all 12 columns." Now it's just like, "I'll just write one line and have a grid system." It's awesome, so anyway.

Chris: I love that.

Dave: I think you're so close. If you can sketch it, like sketch out the idea and just draw boxes of what you need and kind of have a loose idea of what you're going to put in there, you're minutes away from having that in Grid. Grid is just the jam, so.

Chris: We've had Adam Wathan on from Tailwind. That can be kind of cool too. Maybe that will click with you if you're not super into the making layouts from scratch thing, maybe this will click with you because it's just like this class library that you don't even write CSS. You just write all your styles in HTML classes and stuff. I know that there's a lot of controversy around that, but if it clicks for you, it clicks for you. That's good.

Balmo was the one I was trying to think of that's Bootstrap-like in that it's this massive component library, but it's just CSS, so you just use the classes they recommend and you get some nice styling out of it. I just like the look of it. I think it's a classy looking little library.

But of course, you know, you build an architecture site. It's not necessarily designed for that. It's designed to be super-duper-duper generic and just kind of look website looking. [Laughter]

Dave: Yeah. Yeah, it was kind of like if you go to Tailwind. Are there starter templates for Tailwind? There sure are. There sure are.

Chris: They tend to be component-based, like, this is how you would design a card in Tailwind," and it's designed to kind of teach you, like, "Look at this big chunk of HTML now that designs that card. It looks like a lot of classes but, hey, remember; there's no CSS. You've just loaded up this library and got a bunch of free stuff from this thing."

It does have a little different approach in that it's designed to be customizable also. It's just tricky, and you don't actually ship every possible class in the universe. It also encourages this build step that only ships the classes that you use, so the CSS that you ship is also kind of microscopic. It's pretty cool, really, but it doesn't actually solve any layout for you necessarily, unless you're doing what you said. You've looked around at some galleries and you're just kind of stealing bits and pieces from layouts that have been provided for you.

Dave: Bootstrap, for all it gets, it has a concept of themes and expo of cool Bootstrap implementations curated by MDO himself. Again, you've just kind of got to find -- I don't know. Don't look at the content, exactly. Look at the layouts. That's kind of what you're trying to figure out, right? How do I get this layout to be what I want?

Chris: Yeah, I've always thought that separates the CSS people from the not. I think anybody really has an ability to pop into a CSS file and change a couple of colors or whatever. The degree of comfort with that is generally fairly high on the Web, but what stops people is this moment, I think, that's stopping Andrew is this, like, "I don't want to do it from white page on though."

There's something about layout that hurts people that they don't want to be responsible for the whole thing. It's got to already exist and then they'll tweak it, which I think means that you're scared of layout in CSS, essentially.

Break that barrier. Andrew, you already call yourself full stack, so earn it, man.

Dave: Earn the badge.

Chris: Level up.

Dave: Earn the badge.

[Banjo music]

Chris Enns: This episode of ShopTalk Show is brought to you by Discover.bot. Discover.bot is an online community for bot creators designed to serve as a platform agnostic digital space for bot developers and enthusiasts of all skill levels to learn from one another, share their stories, and move the conversation forward together. Discover.bot was built by Amazon Registry Services and it's an informational place for novices and experts in the bot development space.

Discover.bot regularly publishes how-to guides and the latest bot building resources. Some recent guides are: How to Design a Bot Personality, How to Set Up Payments Through Your Bot, and How to Stop Shopping Cart Abandonment.

Discover.bot also shares expert advice and provides insights on all things bots. For example, what KPIs are worth measuring, why emojis may be breaking your bots, and how to write an engaging chatbot dialog. They cover all sorts of topics and genres including bot development, bots for business, chatbot news.

If you're new to the bot development space, Discover.bot will teach you everything there is to know about bots. There's a guide called Beginner's Guide to Bots, which will teach you how bots were invented, the basics of how bots work, what bots can do, and where bots were developed and published.

If you've already got a few bots of your own, Discover.bot can help you choose a framework that's aligned with your business. For example, e-commerce, travel, finance, hospitality, and more. They've got a great guide just for you called Guide to Bot Building Frameworks. From NLU features to platform connectors to APIs, there is a lot to consider. Find out what all the major frameworks have to offer, so you can choose a chatbot framework that fits your objectives.

To find out more, go to Discover.bot/shoptalk so they'll know you came from us and check out Discover.bot. Our thanks to Discover.bot for sponsoring ShopTalk Show.

[Banjo music]

Dave: Sam Smith writes in, "I've been thinking a lot about adopting coding methodologies for doing things the way you really want to for want of a better term. I remember Dave saying recently that he sort of uses BEM but doesn't fully commit to it. I've wondered what your thoughts are on when/why we stray from conventions such as this. Personally, I want/tend to push back on rules that I don't quite believe in, especially when it comes to creative tasks. BEM was an example of this for me. There are other aspects I didn't like.

Then there's a surprise twist in this.

Chris: I put that in here because it was just kind of like--

Dave: Yeah.

Chris: I thought the beginning of the question was just like talking about coding methodologies and just like, what if you're on a team that has a coding methodology but you just don't like it? You just don't love it.

Dave: Mm-hmm.

Chris: I even find it -- I don't know. If I went to go work on WordPress Core or something -- highly unlikely because that's not necessarily my skillset, but you know how their PHP has that look like a for statement is for and then, without a space, there's an opening parentheses and then a space after the parentheses and then the statement is inside, whereas the way I'm used to looking at for loops in JavaScript and stuff is for space parentheses, and then no space between the stuff inside. I just like the look of that better, but they're very consistent. So, if I worked on this project, I just have to bite my lip and say, "No, this is the standard. The entire code base is written this way. Plugins that are meant to be part of the true WordPress ecosystem are written in this format."

It's not the only thing. That style permeates through all of its structure. I think, if I worked there, I wouldn't even bite my lip. I would just get used to it. This is just the way it is. There's no reason to change this. It's just an established standard.

For me to roll in and be like, "Hey, I think we should change this. I prefer this other look of code," is just stupid. Whereas if you rolled into a project that firmly, strongly uses BEM, you know, bite your lip if you have to or just get used to it, unless you can present some compelling argument why you think you should break the whole thing or whatever.

But then, it's totally different if it's your project, you're starting greenfield on something else. You just prefer the look and the feel and the coding ergonomics of some other format, then fine. It's your project. Do whatever you want. But I feel like that's the trick we're in here. I would say, don't be that guy who rolls into a project and says, "I think we should just change the whole coding methodology on this project because I like something else that you don't."

Dave: Yeah. Mowing down isn't cool. Yeah, you've got to be a special person and it's a lot of work and talking, I think, in reality. Yeah, for me, the terseness of BEM, the verbosity of BEM is just like, eh; I don't want to write all that, so I don't. [Laughter] You know?

Chris: Right.

Dave: The problem it solves is people stepping over each other like, "Oh, we both wrote class highlight and it nuked everything in my highlight because I had a class highlight," or whatever. I understand that. I have experienced that. For me, it's more like, let's just talk to each other or whatever. I'd much prefer the, let's just talk it out and have a plan.

I'm not saying non-BEM is the best way, but it does force having conversations about things like, okay, we can't do this because this is actually a conflict here. But it also forces you. I don't know. BEM sort of tries to solve naming, which is a common, like, why I use CSS Modules or CSS in JS. It's like, no, naming is hard.

But I'm just like, well, if you talk about it, naming can be okay most of the time. You may have collisions, but--

Chris: Mm-hmm. Mm-hmm.

Dave: You know. I don't know.

Chris: It seems like it helps. What you're often naming is the root thing.

Dave: Mm-hmm.

Chris: Then once you've named that, it kind of matters a little bit less, particularly in BEM, what you name internal things because it's already namespaced, so the danger is quite low, whatever you name the rest of it.

Dave: If I walked into a project and they were like, "Oh, we're super BEM," and it's like, "Okay, cool. Let's get along with it."

I kind of had a situation this week where it was like, "Hey, can you look at this project?" It's like a Bootstrap project. It's not my preferred thing to work in Bootstrap, but it's like, okay, I can probably figure it out. I would provide feedback like, oh, Bootstrap Grid is kind of super verbose. I feel like, again, you could do better with CSS Grid and figure out IE after the fact, but a handful of classes can replace a gigantic grid file.

Chris: Mm-hmm.

Dave: That said, whatever.

Chris: Let's get it going.

Dave: I'm not going to mow it down. I would propose enhancements but try to be specific about those enhancements.

Chris: Yeah, right, because that argument is real. That argument is, look at the kilobytes in this grid file. I think we can be better, more flexible, have it lay out faster in the browser, et cetera, and remove those kilobytes from this file if we did it this other way. That's something you can bring to a meeting and it has weight.

To say I don't like that you picked BEM because I don't like underscores in my CSS, that has no weight. It has no value or anything to the meeting.

Dave: Right.

Chris: It's not useful. Anyway, the surprise twist in this, to me, was that that Sam writes in. He's like, "Well, so I don't like BEM that much, or I wanted to push back against it, so I wrote my own methodology. It's called C3CSS," and that's the URL for it, too, C3CSS.com. It looks nice, really nice looking thing, and it just looks like a BEM alternative, in a way. It just looks like a slightly different.

Dave: Slightly different BEM. What I like is using ARIA for the context and for ARIA current page and stuff like that. That's a first party consideration in it. I like that, so it looks pretty cool.

Chris: Yeah, I actually think I'm probably even closer to this than BEM in how I naturally write anyway, so I think well done on the little framework here. It looks good, but I don't know if I'd roll into an existing BEM shop and say, "Let's use my thing instead," because it really is just a choice of how you name things, really.

Although, that's not true with the ARIA thing. I think that actually holds a little water. I think we should style things based on accessibility classes. Heck yeah.

Dave: Yeah, especially current or active. We have that ability, so let's do that. Yeah, I think it's cool.

Chris: Yeah.

Dave: Put this on your website.

Chris: Yeah. Good job.

Dave: Dave and Chris say, "Even better than BEM."

[Laughter]

Dave: Then we'll just see if it gets very popular. [Laughter]

Chris: Sure. BEM got weird for a minute. Every time you mention it, you get an email from like BEM PR that was like, "I think you should--"

Dave: Oh, you did BEM wrong. [Laughter] Was it that one?

Chris: Yeah, either you did it wrong or I think you should link to the official BEM documentation. There is always some kind of ask from BEM people. I'm like, what? Do you have to pay for BEM now? I don't know.

Dave: Oh, you have to get BEM certified.

Chris: I feel like I'm not qualified. I should probably just stop talking about it. I've never done a project in 100% strict BEM ever.

Dave: Yeah.

Chris: Never have. All right.

Dave: It's pretty similar.

Chris: There's an anonymous person that writes in. This is a totally legitimate way to submit a question to ShopTalk Show, by the way. No reason for us to read out your name if you don't want us to. It doesn't matter. It makes for just as good of a show anyway.

They wrote in, "The majority of websites I've created are built with Dreamweaver using HTML, CSS, and JavaScript." They still make Dreamweaver, by the way. It still makes websites. They write, "Does anyone build websites this way anymore?" I'm sure they do if Adobe still makes the product. I don't hear from them an awful lot, but there are an awful lot of Dark Matter developers out there.

The real question is, "If the customer has no desire to maintain the website themselves, do you see the benefit of using ACMS?" Content Management System.

I feel like that's often the sales pitch for a CMS or perhaps a requirement of a CMS is that you want to hand your client the keys to something in which they aren't in control of every detail of how the website is built, but they do have the power to, for example, change paragraphs, headings, pictures, and things that you've kind of configured the CMS for them in such a way that it's kind of a user friendly experience for changing content. That's definitely a big reason to use the CMS. Probably a lot of CMS are picked just for that reason, but it's not the only reason.

I would say CMS is also reached for in any situation where you're just producing a lot of content and it's an abstraction of that content from the website itself. Sometimes CMS is kind of like the only choice because it's the connection between abstracted data and the rest of the site. Regardless of whether there's a "client" or not, sometimes the CMS is just that choice because the website has a lot of content, so you kind of need something.

Dave: Yeah, I was going to say an old friend of the show, Dave McFarland, he works at Treehouse now. He used to be big into Dreamweaver, like wrote books on it and stuff. I'm not sure if he's still using it.

Chris: Oh, yeah.

Dave: I think it's still a valuable -- like if it's giving you value, use it. I think a lot of people either A) switched because of FOMO to another editor or there is something about the editor that you really like or provides value for them specifically. There was kind of a big trend--I don't know--five years ago about really customizing your editor and getting everything right, getting your theme, getting your settings, getting your plugins all set up.

Chris: Yeah.

Dave: I think that's one thing that the new modern editors have that Dreamweaver doesn't. But when you say there's Dreamweaver versus CMS, that's kind of the positioning in this question. I started wondering, like, oh, are you using Dreamweaver templates? It was like a .tpl file or something, right? It's basically Jekyll built into Dreamweaver and it spits out a static site. You upload the static site and the FTP is built right into Dreamweaver. I think that's pretty cool. I don't know.

The modern would be more like, oh, you make a Jekyll and then you push it to GitHub. Then a CI takes it over to Netlify or whatever. I love that stuff too. But if you're really able to power through with Dreamweaver, that's awesome.

I think where this does not work is let's say if it's just you and you have this $100, $200 piece of software, that's fine. But if you're on a team with 100 people and they all have to buy a $100 piece of software, that cuts into your profits pretty huge.

Chris: Mm-hmm.

Dave: That's where I would maybe -- I think we build out of Dreamweaver at, like, three people or Coda, even, which RIP Coda, I think it's coming back in some form or fashion.

It was just like, okay, everyone has to pay for this, like every update? Okay. It just sort of was, you become dependent on that tool and all your processes are centered around that tool. It just costs money. So, if you wanted to bring somebody on, they had to have a Mac; they had to have Coda. I think you have to be slightly conscious of the financial cost of the tool, with a tool like Dreamweaver.

[Banjo music]

Chris Enns: This episode is sponsored by Datadog, a scalable, full stack monitoring platform. Datadog synthetic API tests help you detect and debug user-facing issues in critical endpoints and applications. You can build and deploy self-maintaining browser tests to simulate user journeys from global locations. If a test fails, you get more context by inspecting a waterfall of visualization or pivoting to related sources of data for troubleshooting.

Plus, Datadog's AI-powered browser tests automatically update to reflect changes in your UI so you can spend less time fixing tests and more time building features. You can create tests in minutes with their Webrecorder. Build browser tests without code to record user actions via an easy to use GUI-based Webrecorder. Validate responses with flexible assertions and variables and reduce the time it takes to create browser tests and remove technical limitations.

You can check them out at DatadogHQ.com or follow the link in the show notes. Proactively monitor user experience today with a free 14-day trial of Datadog. Our thanks to Datadog for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: You mentioned Jekyll for a minute. I feel like the more time goes on, the more and more fascinated I am with the world of CMS, so I think there'll be some upcoming shows on that in the next couple of months just because it's just endlessly fascinating to me. But anyway, do you consider -- I mean Jekyll is thought of as: it's a static site generator. Would you give it the CMS label also?

Dave: Um… I mean I guess not.

Chris: I think I'm going to say no, too, because what the CMS is in Jekyll-land is your code editor. It's those Markdown files and however you edit them. It's not really a CMS, but the CMS is the thing that you use to edit the content and, I guess, in this case, it's just a text editor with a sidebar of files or whatever. That's kind of become your CMS. Jekyll itself isn't really.

Dave: Yeah. I think the classic CMS, you have a database somewhere, so your content and your presentation are somewhat divorced. I think that was the historical reason we all use Blogger.

Chris: Right. It's like whatever you're looking at when you type the letters of content is the CMS part of it. There are so many different kinds these days. But, yeah, generally, the static site generator part is divorced from the CMS.

I'm making that distinction because you can't put a CMS on Jekyll. These days, there are these new categories of CMS, like Forestry and Netlify CMS and stuff, that sit on top of flat files and become the CMS for them.

Statamic is in an interesting category, too, in this way in that it's PHP and it requires PHP on the server, too, so maybe it doesn't quite get the JamStack moniker, but it's a flat file CMS. Kirby is like this, too, and Perch, maybe even, too. I don't know. Perch requires the database, so not quite, but the flat file CMS are interesting in that it's still flat files. It's still some Markdown files that you can edit, largely, but provides this editing interface on top of them so it becomes the place where you type the paragraphs into text areas, essentially. Fascinating.

Dave: See, and I'm all for them, but I do wonder. How long do we need these? We spend thousands of manhours, just human work effort, to build these CMS or plugin interfaces or whatever to manage tags or whatever. But if we all became more computer literate or even were just like code is actually a great tool to go through all your static files and update the tags, maybe it actually is better.

That said, there's something about, for regular people and not to make tech people seem superhuman or something like that, for people who just want to do their job, having an interface on the CMS, the classical, "I logged in, I edit this page, and then I hit save. Then I refresh the page and I see the page," I think it's a lot of value to them. But then I also think developers deliver a lot of bad CMS, if that makes sense.

Chris: [Laughter]

Dave: We overcomplicate the admin interface with all this junk we think is cool, like custom fields and all this stuff. The people editing the content are just like, "Ah, this is a lot of action."

Chris: Yeah, it's so easy to screw up, isn't it?

I'm kind of fascinated. Does the idea of a flat file CMS -- where does it break down in terms of what you're able to do with it? Maybe not just the fact that it's a flat file, but how those flat files are digested. I've done a couple of sites recently. My new serverless.css-tricks.com is all just a bunch of resources and stuff about serverless stuff.

Dave: Yeah, which is awesome.

Chris: Yeah.

Dave: Breaking the mold on layouts.

Chris: Yeah, it's a pretty weird looking site. Thanks, Kylie and Jerry. They worked on that.

Then my other one is conferences.css-tricks.com. They're both flat file, but they're static site generated. One of them is 11ty; one of them is Gatsby. The CMS-ness of it is just that. I don't connect it to any kind of interesting cloud database or user Redis or anything cool or SQL-Lite, even, or anything. It's just some Markdown files, just like your blog, probably, right? Just some Markdown files.

Dave: Mm-hmm.

Chris: That works great. It tends to work great for blogs. It works great for these little conferences because the little pieces of data are just little conferences. It generally works good for the serverless site because they're kind of like just little chunks of content that are in different kind of categories, so I put them in different folders and then the GraphQL nature of Gatsby allows me to kind of query for them based on where they are in the file system, which is just weird, but true.

What if it needs to get a little bit more complicated than that? What if they all have tags? I guess I can still use some kind of GraphQL thing to pull the right tag. When does that stuff, the relational database-y type stuff start to break down in that system, or does it ever?

These two sites that I built are just so simple that just some Markdown files works great, but at what point does keeping things in an actual database become necessary or unlock possibilities that you don't have any other way?

Dave: I think you see it with Jekyll. Your compile times go up to a painful degree, right? The more you kind of do and the more tags, it's like, "Okay. Now I've got to keep all this, every post in memory." You have 300 posts. Now it has to keep them all in memory and loop through each one and get the ones that match the tag and then spit out a page with those.

The amount of work you're asking your laptop CPU to do keeps going up. A server can just chew through that. I think Phil Hawksworth makes that argument for Netlify, right? He made a clock that regenerates every one second or something like that.

[Laughter]

Dave: Like a static site that rebuilds every second. You can do it quick on a server or something like that, but I think the size of the thing, like, do I want to power Wikipedia as a static site? Nah! Even CSS-Tricks would probably be like, "No," right?

Chris: No, it's too many pages to have to--

Dave: Too many pages.

Chris: But I think there are some solvable problems in there, like only rebuild the pages that need to be rebuilt, but maybe that's not possible either because maybe there's some timely content on there that changes. The second you have a featured comment widget in the sidebar or something that changes based on dynamic things that you select; it's not dynamically built anymore. But then that gets interesting too, like, well, why don't you statically build most of it and dynamically load in some other parts of it? Architecturally, the story is just complicated. It just depends on what you want to do.

I take your meaning here in that there are limits to statically generating files and those limits aren't particularly high. If on each build you need to generate 1,000 flat files, you're at the limit already or past it.

Dave: Oh, I mean there's one second a file, you're at 1,000 seconds. That's three minutes or something, right?

Chris: Or something.

Dave: No, I don't know. I did it wrong. But, yeah, it takes a while, right? It's probably 100 milliseconds of file, but--

Chris: You have to factor in how much you care about that, too, like how critical are super-fast deployments? Can you wait ten minutes to deploy or is that going to become an organizational pain point? It probably at some point will become an organizational pain point.

All of us want speed. I want to change a file. I want to see it immediately in my browser. I demand that as a developer. I'd like to be able to deploy it right quick, you know. I don't even want my tests to take three minutes. If I can dedicate a little work to make my tests run in one minute instead of 12, you're dang right I'm going to do it.

Dave: Yeah, I think that's the limit of these static sites is just volume. But I don't know; maybe there's some kind of whatever AI assisted static site generator in the future that's kind of like, "Oh, okay. I see you kind of edited this, so I have a little map in my computer brain of what needs to update." You know? Maybe there's smarter things ahead.

Chris: Yeah. This is totally -- we've totally strayed away from the question kind of thing, but I was coming across this yesterday in not a content way, but even in like a microservices kind of way. Let's say you have a dozen cloud functions. You have a dozen little things, little JavaScript functions you want to run in Node in the sky or whatever. These could be microservices of any kind. I'm just using Node as an example here.

There are ten of them, and you've decided to do these microservices because it's just a nice architecture. They all have a common API that they talk to each other, and it just feels like you're being a good developer and developing these independent little pieces that are all individually scalable and are predictable and testable and all nice and stuff.

But it turns out, all 12 of them, they need common code. They need to authentic requests in a special way, and they need to integrate with your thing that logs errors, whatever company you choose to do that. You want to save server logs in some consistent way.

There are all these things that a function might need to do that you might want to share across all 12 of them. I'm like, what is the answer to this? It seems like having one function per repo is nice because then you write tests for them, the CI for them, and test each one individually, deploy each one individually. They are these little independent kingdoms of themselves, but it makes the sharing code between them very difficult.

It lends itself to, like, well, we'll just copy and paste this function in all 12 of them and that's how we authenticate requests. Well, that's unacceptable. You can't. Then you have to change how you authenticate requests. You have to do it 12 times. That's not going to work.

Do you make the thing that authenticate requests into a tiny little repo of itself and publish it to a private NPM thing and install it in all 12 of them? Maybe, but that seems like a bunch of weird work and an interesting dependency that also doesn't feel great.

I think one of the answers to that is the mono-repo thing where you just put them all in one repo. Then if you need to share code between them, you just import it because they're all in one repo anyway. You just pull it in. But then, like a static site generator, what does that mean for deployment? Then every time you deploy, you've got to deploy all 12 of them or what? How do you teach your deployment system to only deploy things that changed? That's not normal. I'm sure it's doable, but it also has its own complications just like the static site generator thing. Generally, it just wipes away everything and rebuilds everything, but there are probably tricky ways to get it to only rebuild what changed. I think that technology isn't super advanced yet.

Dave: Right, or prone to accidents. But maybe that's all you need to work on it and then the big deploy just does the whole thing. I don't know.

All right. Should we do one more question? Does that sound good?

Chris: We'll do a quickie and call it. Yeah.

Dave: Here we go. Tyler Williams writes in, "When I think about my past projects, I can really identify a lot of flaws and mistakes I made. They stick out like a sore thumb to me. The more I learn, the more distance I get from old projects, the more I see them. I feel compelled to go back to old client sites and fix these issues. I don't want to charge my clients because it feels wrong to say, 'Hey, I made mistakes on your website two years ago. Will you pay me more money to do it again?' But I really do want to go back and fix them. Every now and then, I'll spin up a demo site and start thinking about redoing it, but I stop myself because it feels like I shouldn't be shortchanging my own time. I should be moving forward and, if a client is happy with what they have, I always give clients 90 days of free bug fixes, adjustments within scope, and content edits. I don't want to put them in a spot where they're all of a sudden second-guessing their website."

Well, what do you think, Chris? Do you go fix up old stuff or what for clients that already paid you and probably won't pay you again?

Chris: Absolutely not. [Laughter] I feel like you need to -- if I'm going to have a hardline stance on this and be like, "No, dude. You need to move on with your life." Nobody is 100% happy with the old code that they wrote but, is it sitting there doing the job for these clients? Did they absolutely not know any better or care at all? It's only you that's looking at this old code and being like, "Ooh, I could have done better here."

To have the desire to spin up that old site, fix it for free, and tell them you're going to fix it is like, why? Why don't you get some new client that's going to pay you some money, you know?

I get the desire. It's kind of cool that you have this part in your soul at all. It means you want to do right by people. That's probably a pretty cool thing to have up in your brain. But unless you have identified something that's really wrong with the website and can explain it to that client in a way that they're like, "Oh, I can see what's wrong here. Yeah, that would be good to get fixed," and there would be tangible benefit to everybody involved if it were fixed, and then maybe use that as a sales pitch to see if they'll pay you to fix it. I mean, sure. Maybe.

Dave: Yeah, so the only -- yeah, unless, "Oh, hey, I forgot to wire up your contact form," yeah, you should probably go in and fix it for free. But I think it's a sign that you're growing as a developer, that you look back at that old stuff and say, "Ooh, that was bad," or simply, in the last two years, just with the way our industry moves, best practices change. Like, "Oh, I didn't use a module pattern on my JavaScript. I feel so bad." No, I would just move on from that decision. [Laughter]

The only reason I'd maybe go back and fix something was if I sensed I was going to do future maintenance on that, if that makes sense. Let's say we had clients in the past where they just came around every year, basically, and were like, "Hey, every year, we're going to come and hit you for updates." I think when one of those annual cycles kind of hit, then we were like, "You know, let's fix up these things because it'll be easier to maintain the next time we get a request like this," or something like that. That's been the only time or one of the only situations where we were kind of like we'll do a free fix or something like that.

Chris: Right.

Dave: We may be when Responsive came out, we were trying to juice our Responsive portfolio, so we--

Chris: Well, then you had an alternate reason to do it. Yeah. Sure.

Dave: Yeah. We kind of juiced up some sites and made them more responsive than they were previously, but that too, that felt like it was the best thing we could do for them.

Again, it's about your business, too. I think you could totally sell work if you could quantify how much better it's going to be or something like that, like, "Hey, I can make this ten seconds faster and that'll result in more money."

Chris: Yeah, if there's some benefit for you beyond just some moral obligation to make the code better. Also, watch. We've talked in the show in the recent history about how sometimes refactoring old code just for the sake of it is just an actual mistake. It feels like you're doing the right thing, but you're actually doing the wrong thing because you're opening up the possibility for breaking something that ain't broke.

Dave: Mm-hmm.

Chris: It's not legacy code; it's legendary code.

Dave: Yeah.

Chris: That quote that I stole from somebody that I can't remember, but I love it.

Dave: Yeah.

Chris: There's some of that going on too. Like Dave said, if you forgot to wire up the contact form, that's just broken. It doesn't need to be refactored. It needs to be fixed. [Laughter] That's kind of a different category of code.

Yeah, if the clients ain't asking and it ain't broke, I'd rather work on something new.

Dave: Right. Yeah, sell them new work like, "Hey, let's do a microsite for this weird product you have," or something. Then you can sneak fixes in if it really, really bothers you or something. But again, it's kind of like if it's working, it's working. Schedule a thing to be like, "Hey, is your website meeting your goals?" Try to figure out what their goals are and if you're meeting them. If it's meeting the goals, it's probably great, so that's the thing. Just try to meet the goals. Hit the KPIs.

Chris: Yeah, hit your OKR.

Dave: Bar chart up, up and to the right, you know.

[Laughter]

Chris: Hockey stick that stuff, baby.

Dave: All right.

Chris: All right. Sounds good. Well, thanks for listening to our show. What do you got, Dave?

Dave: Well, I was just going to say, thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. Tell me how great my audio sounds in this episode. [Laughter]

Then if you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you.

Chris, do you got anything else you'd like to say?

Chris: Oh, ShopTalkShow.com.