Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and it's just me today because we have a very special episode.

We were invited to SmashingConf Live where we gave a cloud business webinar. We are excited that we are able to bring that to you today, a live recording of the webinar. You will probably -- a little bit of housekeeping. You will probably want to go to get the slides over at my noti.st/davatron5000. That's going to have the slide deck for the webinar. It'll bring everything into context for the webinar before the Q&A.

Thanks to Vitaly and the gang for having us on. SmashingConfs are always a lot of fun; a lot of good, high energy there; and, oh, hey, we'll be doing another live show at SmashingConf Austin. It's not really in Austin, so it's like virtual Austin, but whatever. It'll be fun. October 13th and 14th, so please join us there. Find out more at smashingconf.com/austin-2020. Smashingconf.com has a link in the header.

Without further ado, here it is, our webinar on the ShopTalk Marketing Cloud.

Chris Coyier: Are we live, Dave?

Dave: I think we are live. Hello. Welcome, Shop-o-maniacs. Welcome to the ShopTalk Marketing Cloud Webinar. We're here to talk about life, business-changing software. Step one -- oh, man. Clicker. Oh, boy. [Laughter] Okay, here we -- okay.

Escaping system pitfalls. Chris?

Chris: Our software has charting and single sign-on. Um--

Dave: We believe you can achieve your customer velocity today!

Chris: If these charts don't convince you, our backwards compatible enterprise product solution will. Log onto our portal and download our password-protected PDF for compelling growth strategies and high yield human capital. Now back to Dave for more interoperability, turnkey, best of breed strategy supply chains.

Dave: Customer satisfaction, you bet! It's all here. The quantum improvements, numbers.

Chris: [Laughter] Note the flexibility. We're talking no SQL here.

Dave: We can give you a one-time, disposable facsimile that you'll never have to see again. If I understand it correctly, this is very on-trend with the industry.

Chris: Leverage that!

Dave: Okay. Wrapping up. Any questions? I'm looking to the chat or the crowd for any questions. Oh, high five. Yes. Synergy!

Chris: Synergy! [Laughter]

Dave: Hi. Thank you so much for attending the webinar. I am -- it's 104 degrees outside, and so I'm going to take off this wool blazer.

[Laughter]

Chris: That's cool. That's cool.

Dave: Oh, boy. That's cool.

Chris: Uh -- you're not in the wrong room, people! This is really -- [laughter] this is really--

[crosstalk]

Dave: --not a webinar.

[Laughter]

Dave: Chris, um, so--

Chris: Yeah.

Dave: We are here at the jamstackconf.com -- no, smashingconf.com and this is -- I said JAMstack because I want to get down. There were quite a few talks on JAMstack-iness. But I want to get to the meat and potatoes here and play a little game I like to call "Who won the conference?"

Chris: [Laughter] Yeah. Yeah, all right. The best speaker award goes to--

Dave: Goes to--

Chris: You've got to go. We can't do that. Or are you going to do it?

Dave: We can't. No, we can't choose favorites, but I did -- I liked all the talks. You know Dan's talk was pretty good. I identified with quite a few things. I'd love to know what you really liked about it.

00:05:14

Chris: Well, here. I'll tell you a story. Do you want to hear one? I had to -- I tried to reschedule a meeting but I couldn't. So, for one little part of today's conference, I had to jump over to a Zoom call, much like this one, but there were different people there, you know.

It was about component refactoring. It was about, like, oh, we have this text field component, but we also have an input field component, and they kind of do the same thing, so which one should we pick? How should we think about the API forum? Should it support everything? Yadda-yadda.

Then somebody brought up this one other use case where we use this component on the site and it didn't have a label because it was kind of like a matrix of inputs. It was this little situation. I immediately thought of something Dan said.

At one point in Dan's talk he said, there are extremes of design systems. One extreme is, "I don't care about design systems. I'm just going to code this thing up and just whatever. It's useless to me. I'm going to use zero percent of the design system." That's one extreme.

The other extreme is 100%. Nothing goes into our app if it's not a part of a design system. The design system rules all. It's the most important thing. That's like 100% design system, the other extreme.

Dan is like, neither of those extremes are realistic or useful and that not everything has to be. If there's a little one-off or something or you need some extra creativity here or something, it's okay that not every component on your site needs to be necessarily a part of the design system.

In this meeting I just had today just solved that issue. It's like, ah, let's just not have our design system handle that particular area of the site. That'll just be a one-off and it'll just be handled on that page just how it is.

Dave: Yeah. No, that's like the more I think about design systems, build them, and whatever, it's like maybe the hero unit does not go in the design system. Maybe that should change with the weather. It should be very creative and just one-off like this is your front door. Paint it whatever color you want.

Chris: Yeah. Right on. Inline styles. Go crazy.

Dave: Just do it!

Chris: Yeah.

Dave: We call them Web components now.

[Laughter]

Dave: But just do a one-off. I like Dan's analogy of the Lego store. Put the high impact stuff upfront. Show that stuff even in your design system.

Chris: Yeah. Yeah.

Dave: As you go back into the back of the store, there's the….

Chris: What did they call it, a signature component?

Dave: Yeah!

Chris: But that was almost -- was that cool or not cool? I have a feeling it was not cool, like, don't work too hard on that one.

Dave: Yeah. Yeah, I mean that would be, again -- I don't know. I guess, yeah, you need your bread and butter components and that needs to go in a section. I mean I don't know. Alphabetical is always everyone's favorite way to browse stuff. [Laughter] Dan has other ideas, apparently.

Chris: Oh, my gosh.

Dave: It's nonalphabetical organization.

Chris: I have a question for you.

Dave: Oh, no.

Chris: I love that you're ending questions while they fill up, too. Let's just leave that. That's really good.

Dave: Oh, yeah. Any questions throughout the show, we will happily ask questions chat.

00:08:33

Chris: Well, have you done this? This is another thing from Dan's talk. Have you ever done the "sneak it in" approach to a design system? You're kind of known for working on design systems or at least you've done a bunch of them. Have you ever been like, I'm not going to even use the DS word, but they want us to work on re-CMS'ing or something? Do you just slip it in as part of that work, like the old trick-a-rina?

Dave: Yeah, sometimes. There is one. We did a site for the Austin Chamber of Commerce, which is a chamber of commerce here in Austin. We built the site, but we built it in components. Then it was put into Vue, I believe, Vue/Laravel sort of back-end.

Chris: Okay.

Dave: We just delivered front-end HTML in a Jekyll or something and then they put it all into the Vue components. Then low and behold, I don't know. Two days later they were like, "Hey, we built a whole About page using the components. Is this okay?" We were like, "Yeah. They're yours. Use them."

Chris: Yeah.

Dave: [Laughter]

Chris: That leads me to another point that front-end -- to me, front-end development is really heading towards a componentized model.

Dave: Yeah. Yeah.

Chris: It's just all over the place. Even native technology is going there, right? Components. Components. Which makes it seems like that design systems are just -- you're not -- you know how you -- I don't know.

To me, at least, you get a new client or whatever. Not that I do client work, but you're working on a new project. You don't have a conversation anymore about whether you're going to make it responsive or not. Of course, yes, you just are. You know? The fact that we build everything with components, maybe it will stop being a conversation if we're going to use a design system or not because you're making a bunch of components. So, like it or not, you made a design system. You know?

Dave: Yeah. No, and even with all these frameworks, Tailwind UI, Bootstrap, or whatever, it's almost like which component from this thing do you want? Which one expresses your values or which one should we start with and customize?

You even have -- prefabs is what I call them from the video game world. You have these prefabricated things that you just kind of, okay, let's see. Let's start with this or something similar to this and see what it looks like.

Yeah, we build in components and even code in components. You don't want to repeat yourself, ideally, as a developer. We code in components and that's the best way.

I think there is what Dan is kind of getting at is the nuance, right? Know when to bail out. Know when to or what to emphasize or when to bail out of a design system or priorities, prioritizing what components go into the first round because that's a thing too if you let a design system sit for 22 years. It's just only going to ever be 66% implemented.

Chris: I feel like if it sits for one day, you're already screwed. The design system should be that integrated that you're using it. Dan also said, "Start today and never stop," or at least that was incorporated into some thoughts in some way. I like that because it was like, this isn't a sprint, necessarily. It might be a sprint to get it started or get some motion on it or something.

Dave: Yeah.

Chris: But you work in it all day every day. It's not a thing that just is done when you're done with it.

Dave: Well, and I forget the name of the woman from Airbnb, or was it Lyft? But it was just, our design system is evolving. It is kind of like we talk to customers and we get feedback. We change our product based on the customer feedback.

You need a design system that can be agile, too, or meet customer needs. I think Gina has talked about that or Dan referenced Gina as well. How do you meet people? Design systems are for people, so how do you meet people with your design system?

Chris: Yeah. Isn't that interesting? That seems like most of the talk around design systems lately has been the technology part is not so interesting anymore. It turns out to be a people issue. We watched that happen with responsive design, too.

Dave: Mm-hmm.

Chris: Like Ethan and Karen at the forefront of responsive design decided to do a podcast about responsive design and it had nothing to do with the technology of responsive design. Every show was about what was the organizational situation like.

Dave: Yeah. Yeah, and it's all about how people were figuring this out from an organizational level. People weren't like, "Oh, man. How do media queries work?" [Laughter] That wasn't it at all. It was all, how do we do this as a person?"

Chris: Yeah. yeah.

00:13:37

[Banjo music starts]

Chris Enns: Hey, folks. Editor Chris here. I was asked to help with this read because it's for a conference that's normally held in Canada, eh. The conference is Web Unleashed 2020.

What is Web Unleashed, you might ask? It is the ultimate three-day conference for front-end development folks. You can enhance your skills, learn new techniques, and be inspired by your peers. It's all happening October 5th to 7th, 2020, online of course.

There is an insanely great lineup of speakers like Tatiana Mac, Rachel Andrew, Kyle Simpson, Wes Bos, John Papa, Harry Roberts, Ethan Marcotte, and even ShopTalk's own Chris Coyier. Chris is going to be MC'ing the first day as well as doing a special interview with Mina Markham, which should be awesome.

Your Web Unleashed ticket includes three full days of inspired learning plus attendance at every session including presentations, Q&As, live chat, and breakout rooms, a dedicated Slack channel that allows you to virtually mix and mingle before, during, and after the event with other attendees and speakers, and you get six months of access to all the presentation videos afterwards. You'll want to get your tickets soon because you can save $100 off the ticket price with code SHOPTALK. That's valid from September 14th to September 20th.

Once again, use code SHOPTALK during checkout to get $100 off the price of your ticket. The full ticket price is only 249 Canadian, eh, which is less than $200 USD, depending on the exchange rate, of course. The website link is in the show notes or tappable on your podcast player right now, or head over to fitc.ca for more details. Our thanks to Web Unleashed for sponsoring this episode.

[Banjo music stops]

00:15:16

Chris: Well, you've got to iterate on it. Wasn't that the--? That was perhaps a big core thing in Nadieh Bremer's talk, right? I know you keyed into that, that quality takes iteration, right?

Dave: Yeah, I think, kind of like how, on an audio podcast, do we talk about amazing digitalization? That's not going to scale well.

Chris: Oh, look at all these Skittles all over the floor. How many Skittles are there?

Dave: Yeah.

Chris: There's [buzzing] Skittles.

Dave: [Laughter] Yes. Yeah, exactly.

Chris: Audio in visualizations.

Dave: Yeah, exactly. This one looked like a brain and it had -- [laughter] so, the graphics were amazing and they told a story. But what I found most interesting was the iteration on the graphics that she showed. I guess the probably quintessential one was the lineage of royal families or whatever. You start with one pass at it and you're like, "Oh, this doesn't really--" I mean the data is there but it's not really telling me anything. Then you do a tweak or you compress one side of it.

I found that iteration stuff really amazing. I'm blanking on what the other one was. Shoot. The dances. The dances, like the etymology or the creation of dance or how they relate to each other. The first, the primary and secondary sort of features of the dance told nothing. It just looked like a ball, a tennis ball. But then you pull in the first primary thing, yeah, the Unesco stuff. Thank you, Jessie.

You pull in the primary aspects and now, all of a sudden, you have, like, data starts grouping together a lot more clearly and it was very -- I don't know. Just -- I like--

Chris: Isn't that a skill? What if you took--? I think there are a lot of courses. You go to LinkedIn Lynda or whatever it is, or Front-end Masters, or places that are known. There are definitely going to be courses on D3 and they might even have a whole course structure on data vis.

You could do that, but I don't know that you'd necessarily come out of it with the sensibilities for being able to iterate and trim down and be good at this skill. It's almost like two skills in one.

Dave: Yeah. That's what I found interesting. The tech stuff is like, you could spit out a graph. I can follow a stack overflow and spit out a graph, but how do you show something? That's different. That's a different skill or even that's a honed skill.

I think in our day-to-day lives, it's like, "Hey, man. We need a graph by Tuesday. Give us the graph on the royal families. Do it." You're like, "Oh, man. Okay. I've got to do the graph by Tuesday." You're just going to make a nest of all the royal families, and there is your graph.

Chris: Yeah.

Dave: But a good graph is iterated on and you're just like, "Okay. We spit out the data. Now what can we do with it or what do we not know?"

Chris: What's the story? What's the insight? Yeah.

Dave: Yeah, and I think that's -- and then even just the design touch of rotating it. That was -- anyway. It looked good, but I thought that, for me, just in my life and prototyping and stuff like that, that really hit a thing. I'm reading a whole book on it. Ken Kocienda talks about -- he calls it Creative Selection, which is kind of like a Darwinism reference. But it's kind of Apple's design process and how they built Safari, how they built the iPhone, how they built the iPad. Their iterative process where they go kind of prototype-to-protype and they say, "How does this work? Does it look good? Does it tell us something?" And so, I just thought that was very, very cool.

You almost -- I don't know. It's almost like artists in residency or something. You know? [Laughter] More than -- I don't know. Some data vis could be like that, you know.

Chris: Yeah.

Dave: But it can also be just spitting out charts. If that's what you do, that's great.

00:19:39

Chris: I wonder if you could have the technology help you find those things by the nature of how you code it? You know, as somebody who looks at a hundred, at least, pens on CodePen a day just because it's kind of part of my job a little bit--

Dave: Okay.

Chris: --I'm attracted to the idea of any kind of visual thing in which that gives me some controls, some knobs and stuff to turn.

Dave: Yeah. Yeah.

Chris: Generative art uses this a lot, you know, kind of like -- I don't know. What's the color palette you want it to be? How dense do you want it to be? What's the stroke weight? You know?

Dave: Mm-hmm.

Chris: Instead of just guessing that in code, build yourself some controls so you can mess around with it there. Maybe even have a randomized button, you know? Sometimes, I see great things that have lots of controls be like--I don't know--just F me up, you know? Boom. Boom. Boom. And you can see generative art happen.

Dave: Yeah.

Chris: But that's generative art. That same kind of concept could be applied to a data vis, I would think. Maybe through random happenstance, you'll land on beautiful things. You know? Who knows?

Dave: Yeah. You know I think data -- I think that's how she started the talk was making connections through, like, astronomy. Those are just balls of gas in the sky but, for some reason, we're like, "No, that one is a lion and that one is a guy shooting an arrow at something."

Chris: You just did Lion King.

Dave: Yeah.

Chris: Oh, that's great.

Dave: I just think it's very -- I think it's great that they -- I don't know. We make connections. If you just only make one layer of connection, it doesn't tell you anything. We have interactivity now with the Web. I thought that was cool.

Chris: Yeah. I think that's up your alley. You're so into prototyping, iteration, and stuff. That's been rattling around in the Dave brain.

Dave: Oh, it just jingle-jangles.

Chris: [Laughter]

00:21:31

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Netlify. You know them. Netlify.com, the Web hostest with the mostest for all your JAMstack sites. You know, sites that are hosted on a global CDN, so you prebuild as much of it as you can because it's just going to arrive to users smokin' fast. Then do your logic somewhere else, you know. Don't get a PHP file. Come on. You can do better than that.

Oh, just kidding. It's an architecture that I happen to really like and I think is kind of the future. You know a lot of people have bought into it. You know how many? Well, at least a million because they've been celebrating their one million developer and business milestone.

Let me see. Let me see where my spot in line is here. I'm sure it's not that impressive, but it's kind of cool. Lovely site here built by Sarah Drasner and friends, which just goes through a bunch of milestones for Netlify, which is super rad.

I have to authorize the application here. It's going to tell me which place in the one million developers I am. When did I first put a Netlify site out? I'm not 125,143, so in the top 20% there. Not bad. I'm pretty proud of that. It would have been nice to break that sub-1,000 level, but I'm not that cool.

Anyway, Netlify is a great host. They have tons of great features. Just because you're hosting a static site doesn't mean that it's just literally only static. Of course, JavaScript can take over and do anything. They will help you do that a bunch.

One of the obvious things is just like, well, how do I process my forms then? Well, there are lots of services that can do that, including Netlify themselves. The easiest way to handle it is just to put the Netlify attribute on your form and then Netlify just takes it over and will process it for you and save the data and allow integrations and all that stuff. It's pretty rad. Thanks, Netlify. Bye-bye.

[Banjo music stops]

Dave: One thing, so the next talk was Guillermo, right? Guillermo.

Chris: Yeah. Well, you said there's lots of JAMstack talk and this was no shortage of it, yeah.

Dave: Yeah. This was sort of the core, but I think all of this, too, kind of factors in just because it's like, how do we iterate quickly? Guillermo, he sort of cited the rule of least power or just even, like, if you have too much power, you almost get stuck, right? Like, oh, we have this gigantic CMS that does everything. But then it's like, who wants to work on it? It's like, no one wants to work on that, right?

I felt that way with WordPress or whatever. I think he makes the point, if we want designers and developers to collaborate, it all sort of ties together for me. I think you need a static component to your site or static-ish. Anyway--

Chris: Is it because it allows you to work on it easier, is your hypothesis there?

Dave: That's my thing. I think even, too, barrier to entry is way lower. Asking a designer to type next in the command line or versal, that's easier than, "Okay, install MySQL." You know? "Then run this migration." Lowering that barrier to entry is pretty critical, I think, to getting something out there.

Chris: Yeah, you could make the argument that WordPress does that, too, even though it leverages more complex technologies later. We were just talking about, we have this podcast, right? That's what we're doing live, the ShopTalk Show.

Dave: Yeah.

Chris: Hopefully, this will turn into an MP3 and we'll host it somewhere. Then we will click some buttons, add some text, and it's going to turn into an XML file that is available at a URL that podcatchers will hit and get the latest podcast from us. We use helpers to do that. I don't hand code that XML feed. I don't think most people do. Although, some people occasionally do, but that's no good.

Dave: Jeremy Keith does, but--

Chris: Yeah, I'm sure he does.

[laughter]

Chris: But you know, so WordPress generated it for us. But when we set that up, we were all proud of ourselves. Oh, god. We did it. You know? Look at this plugin. This is a nice little system.

We've even evolved it over the year and redesigned stuff. We do data maintenance and stuff. But the ShopTalk Show, I hate to admit it, people out there. You might think this is our full-time job. It's far from it. We don't have -- it's pretty far down the totem pole of technology time Dave or I could put in. You know?

Dave: Yeah. Yeah. Yeah.

Chris: Little baby chunks here and there. Now, this plugin is ancient. It's not updated anymore. It's not even on the plugin repo anymore. It's super dead.

Dave: Yeah.

Chris: Now we're in this, like, so how do we iterate on it? Well, if this was a JAMstack site, we'd find the template and we'd change it. It's like the barrier to entry for us would be lower.

Dave: Yeah, but because it's tied to this database and these specific fields I have to spit out and names, it's like, oh, man. Updating that plugin is going to be a lot of work for 420-some episodes.

Chris: Yeah, and the result is a site that works the same way as it did before, hopefully.

Dave: A lot of work.

Chris: That's the goal.

Dave: Yeah, a lot of work to stop getting an email from the hosting company every week or whatever.

[Laughter]

Chris: Yeah.

Dave: Hey, your website is old, so yeah.

Chris: Yeah. I mean we're still going to do it at some point, but who knows what the internals of this -- I mean one of us might have to write SQL. That's not going to be fun.

Dave: Uh, that's not going to be fun, so.

Chris: [Laughter] Anyway, Guillermo is a smart guy. His blog is amazing. Every time -- he's a big thoughts kind of guy, you know. The perfect--

Dave: Big thoughts.

Chris: Perfect CEO kind of guy, you know?

Dave: Yeah. Yeah.

Chris: Yeah. Anyway, I like that he was talking about … technical priorities. Put security at the top of the stack. That's wonderful. Availability right below that. Awesome. Performance right below that. All huge things. All prioritized above the DX of it. Those things are all kind of tied together, but I think that's kind of neat.

It was a big hat tip to JAMstack saying that the first three things in that list are check, check, check for JAMstack. You know?

Dave: Yeah.

Chris: The security of JAMstack is nuanced but, largely, they're static files. You can't really hack into them. There's not an option to do that.

Dave: Yeah. Yeah.

Chris: Availability is, you know, what JAMstack assumes is this global CDN network. The availability of that is going to kick ass - check. The performance, too, is right there. That's nice. It's no wonder people are flocking to that stack even though he objected to the word "stack," which I don't really blame him for.

Dave: Yeah, I thought that was interesting, too, that JAMstack is maybe too broad of a term. You know? I like JAMstack as a term. I thought Phil Hawksworth was going to be very upset that he was going for the name.

[Laughter]

Dave: But I do--

Chris: Remember, it's not capitalized anymore, Phil.

Dave: Oh, yeah.

Chris: Phil nixed the capitalization on JAMstack.

Dave: Okay.

Chris: Good job, Phil.

Dave: Whatever Phil wants to do; we'll do whatever Phil tells us to do.

Chris: Yeah.

Dave: All lower case jamstack, which is worse, all lower case jamstack is like--I don't know--yeah, maybe a broad term because you could be like, "Are you talking about Jekyll? Are you talking about 11ty? Are you talking about Nuxt? Are you talking about Next? Are you talking about Redwood? Are you talking about one portion of your site or something?"

Chris: Yeah. In the past, a stack has been highly prescriptive and this, as a stack, is entirely un-prescriptive.

Dave: Yeah.

Chris: In fact, the only thing that is required, I think, for the jamstack isn't represented there, which is the static hosting part of it.

Dave: So, jams, jammish--

Chris: Perhaps.

Dave: I can't do it. Yeah. jamishstack.

Chris: Pretty cool, though. Then you had this thought about the rule of least power, the principle of least power. That's been quoted often, isn't it? Doesn't even the HTML spec even mandates it or has some quote in there that feels pretty philosophical for a spec, but yeah.

Dave: Yeah, well, I think I've literally heard it a dozen times this week. You know? Referenced in talks or other things I've watched or whatever. I just was like, ooh, there's another mention of it. You know?

I wonder. You know when you hear something ten times, you're like, what's up with that thing I heard ten times?

Chris: Mm-hmm.

Dave: I wondered if that term is popular because things are so complex right now. You know what I mean? We're like, oh, it's about the rule of least power now because everything is way too complicated. I wonder if that's where we're coming.

Chris: Probably.

Dave: I wonder.

Chris: An extension of that is then seeing these complicated things.

Dave: Mm-hmm.

Chris: Then having somebody who perhaps know a simpler way to approach it, look at it just jaw dropped like, "What the hell are you doing?" You know?

Dave: Yeah.

Chris: Like what did you -- what? You know? That's crazy. Then the solution is to do--

Although, there's just nuance to all that stuff, you know? I like the concept but, at the same time, it's almost like principle of lease cognitive overload or principle of practical least power or something. It's like I know that I can make a toggle in CSS with a radio button and is CSS automatically less powered than JavaScript? I think you'd argue that it is, right? Don't do something in JavaScript that you could do in CSS. Don't do something in CSS that you could do in HTML.

Dave: Yeah.

Chris: Like kind of fall down the stack is what it implies. But it's like I find sometimes toggling a class with JavaScript is the least cognitive overload. It's more clear what's happening than using a chip selector or something, you know?

Dave: Yeah. Yeah. Yeah. No, I mean I definitely think that's -- it's easier just to use JavaScript.

I had a question about this. I asked Jeremy Keith about it this week because, again, I was talking about this. I am making a website. I have kids. [Laughter] I'm making a website. I want to mess with images, like squoosh or something like that, right?

Chris: Oh, yeah.

Dave: Or even, like, whatever. I was thinking when you go to a website and you want to click the red dress and see the red dress or the blue shoe or the pink shorts. If you wanted to image manipulate like that on the client-side or whatever, I can do that in JavaScript, right?

Chris: Client-side.

Dave: I'm pretty good with Canvas. I can do that. I can change some pixels. Okay?

Chris: You just render every other pixel. It halves the size right there. It's amazing.

Dave: Yeah, so I'm good at -- so, I can do that in JavaScript, but I'm wondering. WebAssembly is the better tool. Some sort of more powerful tool, in my mind, to do that more efficiently, but I'm wondering where that sits on the rule of least power scale because, in my brain, it's a more powerful tool, right? It's more. If I'm using the rule of least power, well, I can technically do it using a whole bunch of JavaScript.

Chris: That's an interesting nuance because I wouldn't even know where to start. My mind did not go to WebAssembly like yours did. Even if it did go to WebAssembly, I've never written a WebAssembly thing literally ever in my life. I wonder if that same extension falls down to other people who are like, "I don't know. I made the menu open with React because I didn't even think about doing it any other way."

Dave: Yeah, I don't. I don't know how jQuery works, so React worked great for this. [Laughter]

Chris: Yeah. You know what? It made me think of this optimizing images, though, because I just did this, this week, that I thought was fascinating. I've been using GitHub Actions more. Have you used it at all yet? It's like they're--

Dave: I have not. It's on my to-do list because I think I've said it on the show before, but I ported my whole blog over to 11ty because I want to run Lighthouse CI on it.

Chris: Right. Yeah.

Dave: Just check my performance as I go. But then 11ty was like one second slower than Jekyll and I was like, oh, I'm not going to switch yet for whatever dumb reason.

Chris: For built time. Right.

Dave: For one second of build time, I didn't switch it over, so it's all sitting in a branch. It's all fine, but one second of build time. Now all these posts -- this has been a hot week for JavaScript build processes. [Laughter] Certain frameworks take up words of 30 minutes to build a website and I just was like, oh, boy. [Laughter] Maybe I should be a little nicer to Zach Leatherman over one second of build time.

Chris: We have a great post on this coming out on CSS-Tricks where this fella I'm working with took six static site generators and wrote up a little Bash script thing that will generate one, ten, a hundred, a thousand, a hundred-thousand gibberish Markdown files with metadata.

Dave: Okay. Heck yeah.

Chris: And then shoots them through the SSG with minimal templating and stuff just to measure their build speed. It's really interesting data. I don't want to ruin it too much, yet, but you know Go is the fastest thing that's ever been -- you know, like Go is just ridiculous in how the speed is as a language. It just crushes. Hugo just crushes in build speed.

Dave: Well, but it comes with a templating language, you know?

Chris: Yeah, sure. You're not--

Dave: If JavaScript had a templating language, we'd a lot faster. You know?

Chris: Yeah.

Dave: I don't know. It seems like an apples to--I don't know--

Chris: So, the GitHub thing, though, this is--

Dave: --rocket ships comparison.

Chris: This is a shoutout to the gang at Calibre. They released an action. GitHub Actions, you can just write your own.

Dave: Mm-hmm.

Chris: It's not a difficult thing to do. You just make this little XML, this little YAML file that's like, "Do this crap, please." You know? "Just run it," and it will. You'd be like, "Run it on an Ubuntu. Run this NPM," whatever.

Dave: Yeah.

Chris: But there's also a marketplace, so you can be like, "It uses this action," so then you have to write even less code because somebody else maintains this, like, marketplace action thing you can run. It's like commoditizing CI. It's pretty cool, I think.

They've made this image optimize one. I was like, I'm going to try it. Let me just get it into a thing, you know.

Dave: Yeah.

Chris: It's so clever. You're like, I only want this to run on pull requests and whatever. Then it just does it. There's like 12 lines of code that I just copied into a .github folder in the repo. Then you do a pull request and it optimizes all the images and then makes a comment on the PR that says, "These are the images that we optimized for you." Then you've got to pull again because it committed the re-optimized images. You know?

Dave: Sure. Yeah.

Chris: It's so clever, you know? It guarantees that every image in your project is going to be optimized.

Dave: That seems like the best place to optimize, at the pull request.

Chris: Yeah.

Dave: If you have a good branching strategy. If you're just committing to master all the time, maybe that doesn't work. At the pull request level, then you're gatekeeping, I guess. But you're trying to say, "Hey, before this comes in, we want to do minimal due diligence and make sure that this got crunched down."

Chris: Yeah. Well, think of a checklist. But now that you've done that, it's easy to start an obsession, right? You're like, we've got to run this through Lighthouse or run it through SpeedCurve CLI or something.

Dave: Yeah.

Chris: Run a synthetic test and get some numbers on perf to make sure you didn't screw the pooch on perf. Run it through an accessibility tester tool. Make sure that you get all green checks out of that thing. You know?

Dave: Yeah.

Chris: You know.

Dave: Yeah.

Chris: Run it through all your minifiers and all that, although that probably happened in clients. It depends on where, but I really like the idea of making it so easy to do all of those things that just everybody does it. It just becomes a natural part of all build processes like, yeah, just run those things. Of course, you run those things.

Dave: Yeah. Of course, everyone knows when you--whatever--deploy, you just look at the list of images and check them off. You know? Can't we just--? We should just normalize that. It would be cool.

Chris: Yeah, so I'm kind of working on it. It's been on my brain a lot. Visual testing too because those tools have gotten better, too. These take a screenshot of what this URL looks like and compare it to what that URL on master looks like.

Dave: Yeah.

Chris: Just tell me if it's different. Maybe I'll just be like, "Yeah, that's fine. I changed it," or maybe I'll be like, "Whoa! Whoops!"

Dave: I would love a list, whether GitHub Actions or CIs or anything like that. I installed this and it makes my life better. I would love a list of those. [Laughter] You know? Sometimes you'll set up a whole CI for testing or whatever and it'll fail. It's just chucking errors and deployment blocked.

Chris: Right.

Dave: Everyone is mad, so you turn it off and you deploy it and you have errors.

Chris: Oh, been there. Yeah.

Dave: But anyway, I would love -- I integrated this action or this build process and it made my life better. I would love a blog post on that, like, here is something. Here are five build processes I've used that made my life better. I would love a post on that.

Chris: Yeah. You can go overboard with it.

Dave: Yeah.

Chris: You need something that's deterministic, I think, or at least as close as you can. If you write 200 integration tests, unfortunately, as awesome as I think they are, you're going to have random failures. Then as soon as you're in the territory of having random failures, you kind of stop caring. You're like, "Oh, whatever. That one failed again? I don't know. Just deploy it. Who cares." You know?

Dave: Yeah. Yeah, well, you need -- that's where it made my life better. Not like I'm so obsessed with whatever. I'm trying to think of, like, I wanted to count all the points in all my SVGs, so I set up a CI. That doesn't matter to me. [Laughter] I want, like, I installed this. It made my life better.

Chris: Yeah. Yeah.

Dave: It was minimal effort.

Chris: Guillermo had a blog post about this the other day. I'm still talking about integration testing. You're at one or imply that that's -- it goes to your homepage. It checks the title. Does it have the title that it expects to have, that it says, like, CodePen in it or whatever? Done. You know?

Dave: Yeah. Yeah.

Chris: If that works, a lot of stuff went right.

Dave: Yeah.

Chris: Your dev server booted up. It returned an HTML document. The title was there.

Dave: With the right title.

Chris: Yeah. Yeah.

Dave: Yeah.

Chris: That's good stuff.

Dave: Yeah. Hey, we got a question in. Hawks Fillworth writes in, "How do you stop yourself from becoming blind to those build errors warnings that you can live with?" Just kind of how do you--?

Chris: I don't know. I don't know. I want none. I want no false positives. [Laughter] That's probably--

Dave: Yeah. I have a client and they run, you know, it's like the test but it'll block the commit. You know? Where does it happen? It's a pre-commit hook. Yeah or pre-push hook or whatever that is. I think that's commit. It's kind of frustrating because you'll code something. You'll change a doc, like the changelog or a document. Then you'll just push that up and it's like, "Fail!" You're like, "Well, why?"

It's like, oh, I need to NPM install. Somebody went through an NPM installed something, so I have to update an NPM to run the test correctly.

Chris: Oh, right.

Dave: That's fine. I'll do that. It slows down my day, but it's fine. I think there is, just hitting that failure, you get saltier. You're sour about it. You're just like, "You're not my friend." You're my active enemy. But I don't know how you do that. Maybe these robots need faces, these bots, and they're like--I don't know--like buddy cries kind of like, "Trying to help!" [Laughter]

Chris: …make interesting because they're at a different level. They happen on your local machine, not the CI machine.

Dave: (Indiscernible) Yeah, and it would be more salty later if it was happening later. I would be double, triple salty.

Chris: Yeah, I think we do it. For some things, like Prettier, I think we do it at two levels. We have a pre-commit hook does it but then the CI thing does it too, just in case. We don't ever want to pull code and hit save and then, all of a sudden, you're responsible for five changes that Prettier made because somebody else didn't. It just constantly prettifies everything.

Dave: Hopefully, they're using the same config.

Chris: Well, yeah.

Dave: Because if they weren't--

Chris: Well, that's--

Dave: That would be a nightmare.

Chris: That's a prettier battle.

Dave: Yeah.

Chris: We should set up -- that would be great to run a cron job with two competing Prettier configs.

Dave: Yeah.

Chris: Just on the hour, every hour, they just fight back and forth.

Dave: Oh, god.

Chris: That'd be great.

Dave: I'm sweating.

Chris: [Laughter]

Dave: Then Visual Studio code comes on, "Hey, I can do this. I've got plugins." [Laughter]

Chris: [Laughter]

Dave: Just like, "Oh, god, man. Not you. You're great and all, but we don't want that." [Laughter] Oh, man.

Chris: Well, there's Josh, too. He has got this funny moment, I think, in the talk where he's like, "Well, we brought people on the team. She was huge on spreadsheets. Prioritized stuff in a spreadsheet, and then zooms into one column," and he's like, "And there's the wireframe."

Dave: Yeah. [Laughter] I thought that was interesting.

Chris: That's funny.

Dave: Josh is like, "Let's all quit designing and just do spreadsheets." I thought that was really compelling. Somebody who loves to Notion, I thought that was a very compelling talk. Just get rid of design and do spreadsheets. I didn't get to see all of Josh's talk, but I think that was what he was kind of getting at. Yeah.

Chris: Dave had some slights to make.

Dave: I was busy on a webinar preparing for a webinar. [Laughter] We had a … session to get ready for the webinar.

[Laughter]

Dave: Yeah. No, that's one talk I'm definitely going back. Of course, there are talks tomorrow that I'll be attending. It's fun. Good times here at the--

Oh, hey. Hold on. Okay. Get rid of spreadsheets and get rid of design induced spreadsheets. Yeah, I think that's good. I think everyone tweet that out. That's a good -- [laughter] summation of the talk, I think. Yeah.

This was fun, so thank you, Smashing. If anyone has any questions, here's your time. We technically have another hour, so we can just sit here for another hour.

Chris: [Laughter]

Dave: But I think this might conclude our webinar here. I feel like we've addressed all the value propositions that we were here to address. Yeah, I can put these -- I'll put these slides up on Noti.st. It'll be up there later today. It's … right now.

Chris: All your goal-oriented model networking needs.

Dave: Please, clouds, for your business, we appreciate it.

Chris: That sounds like economically sound, out of the box thinking, Dave.

Dave: We'll sign your enterprise contract today.

[Laughter]

Dave: All right. We've got to go. Thank you, dear telecommuter, for watching this on your hop in. We really appreciate it. Thank you for downloading this in a podcatcher, if you did that. Follow us, @ShopTalkShow, on Twitter for tons of tweets a month.

If you hate your job, head over to ShopTalkShow.com/jobs. There's a job board. You can check it out. People want to hire people like you.

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

Chris: That was a smashing ShopTalkShow.com.