Transcript

Dave: Hey, there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about frontend Web design and development. I'm Dave Rupert, and with me is Chris Coyier.

Chris: Hey, everybody! Just Dave and I this week. I think the next three or four or so after this, we have guests lined up for, but just Dave and I this week.

Dave: So, if you hate the sound of our voices, have we got something in store for you.

[Laughter]

Dave: Oh, man.

Chris: Just a bunch of Q&A, so maybe we'll get to it; do as much as we can here. So, let's see.

Mike Bonds writes in. He's been at this. He's been coding at a company for six years, which is a super long time, I think. Congratulations, Mike.

Dave: Yeah.

Chris: He says, "Over that time, we've picked up different design patterns and conventions over the year for JavaScript. And, for the most part, we have not strayed from these over the years. We have a pretty solid conventions to use," which is good. "So, new hires learn to use these conventions and usually do a pretty good job of sticking to them, for example using snake case for data and variables, and camel case for methods." Other things would be like how to lay out your HTML and whatever.

So, one of their new hires, though, has been developing for a bit longer than Mike has and clearly uses different conventions picked up from his old job. "Many of these conventions don't fall in line with the conventions we have used and built up over the years. What would you suggest is the best way to approach them about this? They preach consistency but seem to be breaking the consistency we have in place for something else that they prefer."

Dave: Hmm. Um, I mean, it seems like if you set up the rules, the employee has to fit the rules. Am I wrong there?

Chris: No. To me, it sounds like Mike -- I mean, you know. It sounds to me like you're a little afraid of just talking to them very frankly about this.

Dave: Mm-hmm.

Chris: It's just a frickin' variable name. Go up to the person and say, "Look, you know, consistency is great. You know you talk about consistency. We've built up these standards over six years, and these are the standards that we want to go with a little bit." Not a little bit. You know, don't soften any of it. Just be like, "This is important to our code base, you know, and that's what we're going to go with," so there it is.

Dave: Yeah.

Chris: Then, if they want to argue, you don't have to say -- if you want to have them argue their case for you that we should change those standards, then have them give you a full-throated response to why those conventions should change. They probably can't because you're talking about camel casing and where you put spaces and stuff. It's such a dumb little thing.

Another way out of this is to set up proper linting, you know. I don't know if there are linters these days that can say, "Oh, I see you've camel cased something when you should have underscored it there." I think that might be a tough job for a linter to do, but maybe it can. I don't know. I don't know what the state of linters are.

Dave: Yeah. I would think you could maybe program a linter of some kind to do that, but I've seen companies in the past. They kind of have Friday developer meetings or something. It doesn't matter the day, but all the developers get together and kind of code review or talk about what they're working on and share code or whatever. Maybe, if it's possible in your company, kind of instituting something like that to where developers are talking to each other because, ultimately, this comes down to a miscommunication, it seems.

Chris: It does, a little bit. Yeah.

Dave: Then, once you have that forum, it can also be like this is a place where you can bring up ideas on what we should modernize. Not everything is going to be accepted immediately. We need to understand that. But, there's a better way to do variable naming.

Chris: Sure. Have a lunch and learn kind of thing.

Dave: Yeah.

Chris: There's also code reviews. They put in a pull request. You can just be like, "Hey, this looks good, but can you change to our conventions here?" It might be that you don't have published conventions either. If you have some kind of knowledge base for your company, make sure you get those in there.

Dave: Yeah.

Chris: Make sure that this isn't just in your mind, Mike, that you have these conventions, but that there is a document that explains what the conventions are because if you're mad about it but there's nowhere to point somebody to it to look at the convention, I mean, sure, you can say, "Well, look at another JavaScript file and see what the conventions are and copy those," but that might not be good enough.

I'd say if you feel pretty strongly about this, which it sounds like you do, get those conventions on paper. Do a Friday lunch and learn. Mention it in a code review. Talk to them about it in person. There's a bunch of ways to do this, all of which would work. But, again, it sounds to me like you're maybe a little afraid of doing it, so you might just have to pull up your pants and do it.

Dave: Yeah. No, I mean Brad Frost has this thing called Front End Guidelines Questionnaire. It's on his GitHub. We can drop a link to it, but it kind of has a "how we do frontend" sort of thing. This may be able to help you get started in that knowledge sharing. There are no questions. There are questions about, like, tabs and spaces, which you could be, like, variable naming, or you could make up your own sections, I think, just to kind of pad, just to give you a starting point for the questions you need to answer for this sort of knowledge base. I'd definitely build it out and, I think, talk to people. That's the big thing is maybe you do need to do some kind of code review.

I would agree. I think everyone agrees, and that's the thing is consistency is probably the best thing. Even if it's not the best practice, a consistent practice can be emulated and reused is good.

I hate to be one of those; I had for this to turn into a podcast where it talks about podcasts, which is actually awesome, so I don't mind, but I was on a road trip recently. I heard this podcast called the You Are Not So Smart podcast, which is really, really good. There's an episode there called the Half-Life of Facts, and it talks about how things that were true in science, in medicine, kind of lose their truthiness over time. As new facts come up, they dispute old factions and things are wrong.

It's kind of this idea, like in these fields, science and technology, things are always changing. Even at the point which you learn something, it could actually be out of date. All that is to say it was very [interesting], the podcast, and it made me think about how facts change, and conventions change in our industry pretty rapidly, almost on a six-month basis. It's not a bad idea to write these down but then also be malleable in them and maybe don't change for any reason ever, but be sure you're open to, like, "Okay, maybe this is a better way to do it. Maybe we should be using the" I don't know "class structure instead of an object structure in our JavaScript," or something like that.

Chris: Yeah. Oh, yeah. We went through that. I've gone through that change in the past.

Dave: I still have no structure for my JavaScript. [Laughter] It's clearly just a bunch of variables and a bunch of functions, so I don't know if that's called functional programming.

Chris: I've kind of enjoyed the iffy approach. I know that's just very generic, but if you break everything into little bits that can be smooshed together. If all of them are a little iffy, and iffy just has functions inside of it that you don't need to worry about namespacing so much, it's kind of nice, and they can still just be kind of smashed together. I don't know.

I know that it totally depends on the type of project. Like, if somebody out there is running an Angular 5 project with typescript, that has its own set of conventions that come with that. But, if you're just kind of on your own and doing whatever.

Dave: Yeah. Like whenever I write just a soup of JavaScript, I put an iffy around it just to be like, "You know what? I know this isn't the best, so at least I put a fence around it."

Chris: Well, what's neat is that, inside of that, you can have a function and call it function Dave's window clicker machine or something, and then call later Dave's window clicker machine, and that's fine. You'll understand that. But, a minifier can minify the crap out of that, where it can't if you have an object and the object has methods.

Dave: Mm-hmm.

Chris: And so, it's like method dot Dave's window clicker machine. That can't be minified away, that function.

Dave: Oh, interesting, because it's got to be part of the object. Yeah, okay.

Chris: That's a finer thing.

Dave: It has an address at that point. Yeah. Yeah, yeah, that's all. But, yeah. No, I think figuring out how you do that stuff, that's really valuable. You know what I mean?

Chris: Right.

Dave: That's--

Chris: To Mike's thing, though, if it's just like, "Oh, we have one space after our function names before the parentheses," if you guys just had to change something like that or y'all, you can do something like run Prettier over the whole dang thing with a different change and then it's all fixed in your entire code base. I like those type of changes, other than, "Oh, we've midstream decided to snake case instead of camel case in this situation," and now you have this code base that's half and half. Ugh! That kind of sucks.

Dave: I made everyone in my company install Prettier, and my blood pressure went down about 20 points.

Chris: Why is there no Prettier for HTML? Dave, tell me why.

Dave: Well, HTML is a declarative language. It is, therefore, inferior and, therefore, cannot be styled properly. I think a lot of people try, but I think because some HTML tags don't have to close, it just--

Chris: It's just too hard?

Dave: It's too hard. But, what's weird is browsers like canned processes, so something in the stack knows how to process it.

Chris: But you think it could be opinionated. That's the point of Prettier. If it runs across an enclosed tag, it'll be like, "I'll just close this for you."

Dave: "I'll close that for you." Yeah.

Chris: Yeah.

Dave: "It looks like you forgot to close something. Let me take care of that."

Chris: Somebody do it. I need it. It really bothers me. Maybe it is just too hard of a problem because you'd think, okay, Prettier doesn't have this, so somebody else will make an extension that prettifies HTML, and there are some. But, I feel like none of them are particularly good.

I don't know. I tried to install one, and then it kind of worked, but then it did other languages as well, so it was fighting with Prettier, and I just didn't take as much time to do it. I was like, God dang it does there need to be Prettier for HTML.

Dave: I have a few problems. Like whenever I use a Ruby or a Liquid one, like for Jekyll or Ruby projects, it does not. The syntax highlighter and the formatting does not pick up on Ruby. Or, if you throw an HTML comment in there, it just falls apart.

Chris: Yeah.

Dave: It's just like, "I didn't even know what you tried to do, guy. I'm just going to crash instead." Then, I also am working on this Java project, and I'm using free marker templates like Apache free marker. You didn't know it existed, but it's all right. It's a basic template language, you know. But, the VS code plugin with free marker has a bug in it where if you write a template literal, like dollar sign bracket to spit out a variable, it just crashes. [Laughter]

Chris: Oh, God.

Dave: The whole Visual Studio code crashes. It had been, like, just threw my projects or whatever, had been in kind of a structure list or whatever, HTML land, and it's a bit frustrating. I'd love it if Prettier showed up and solved it. That would be cool, but you know. I'm sure it's hard.

Chris: I opened a Handlebars file the other day and saved it in VS code, and it automatically, like Prettier does. I was like, Prettier somehow is cool with Handlebars? Then I was like, oh, it's actually not Prettier doing it. It's VS code has some built-in Handlebars pretty machine.

Dave: Oh, really? I'd even take something that was really aggressive on HTML and indented all my attributes to be the same depth or whatever.

Chris: Oh, yeah.

Dave: It was just like no more than two attributes or else I'm going to indent them all. That would be awesome.

Chris: Yeah! I have whatever. Our setup for React is like that. It's very opinionated about how many attributes can be on a React element in CSX, and I've come to like it. For a while, I was like, "No, all attributes in line. No hard returns for attributes in our ERBs." But, nah, I prefer hard returns and blasting those attributes down on individual lines these days. I don't even know what kept me with this inline.

Dave: Yeah. I don't know. I think it's that thing, or like if you rewind 300 episodes, we were probably talking about should we just write all our CSS on one line, or should we indent our CSS?

Chris: Yeah. I used to like single line CSS.

Dave: I know.

Chris: That was wild. I used to really like that. But, still, I mean once in a while you see a middleman kind of thing where people write, like, if you've got to do top zero, left zero, right zero, bottom zero, or something, they'll put that on one line because that just has a specific kind of meaning altogether.

Dave: Right. Right. That's kind of like….

Chris: But your linter is never going to leave them alone. Prettier is not going to leave that alone. Just let Prettier do what it's going to do.

Dave: Ain't no robot going to know about style groups. Anyway--

Chris: Well, we did half the show on one. Let's go another one. [Laughter]

Dave: Next. [Laughter] Next. We'll get through three questions here on this.

David Getz Baroni writes in, "I understand software testing is important. It is not just a fad. I know it can be easy to look up testing frameworks for your language of choice. For example, with JS there is ample choice. My problem and really what the reason I never wrote a test in my life is that I learned to code in a way that doesn't lend itself well to testing. When I face an issue, I tend to take a stab at it and write the procedural code to solve that and then maybe reformat to make that reusable. I found many online training on how to do testing, TDD, et cetera, but what I could not really find is a guideline on how to write testable code. Do you have suggestions, tips, recommendations?"

Chris: It sounds like you're talking about unit testing, like the kind of code that you are testing [is], when I call this function, I expect the result of that function to be something.

Dave: Mm-hmm.

Chris: Right?

Dave: Yep.

Chris: It just sounds like the vibe here. Yeah, I don't know what to tell you. What's the hot thing these days? What is a function called when it always returns the same thing no matter what? A pure function?

Dave: Yeah. Yeah, like pure functional programming.

Chris: Yeah, and that's the idea that those are super testable because there's nothing that can happen outside of that function that would influence what it is. An example of an impure function would be--I don't know--a function that needs to find the value of an attribute of something. It goes and looks in the DOM for that thing and then gets the value and then calculates it and then returns a value.

It doesn't seem like there's anything wrong with that, but it's the fact that it's gone external to its function to find something and then come back with that value means that anything could have happened in the DOM that's going to make this function return something wrong. I don't know how you rewrite that function in that scenario, but that's the idea is that you can't test that function because it's all-- [Laughter]

Dave: Yeah. Yeah, no, so I struggled with this, and I whined about it on my blog, as is the custom.

Chris: [Laughter] Okay.

Dave: Yeah, and I wrote it like my struggle with testing code is kind of based on Brad Frost's, My struggle with React," post. I kind of emulated that; just was sharing, here's my problem. You watch the tutorial on testing and it's like, expect page.title to be hello world, or whatever.

Chris: Yeah.

Dave: Sure, dude. Great. Or assert, add one plus two equals three. And, I'm like, great; easy; I can do that all day long. But then, when I look at my stuff, it's like, okay, on IE between 720 and 800 pixels, make sure that this has a clear fixed thing injected in there just to make sure. Those are the kind of problems I'm typically hacking within JavaScript, or accessibility, or adding ARIA and stuff like that, which needs to be tested. But, it's like, I'm just like, how do I test DOM manipulation? DOM manipulation tends to be something totally different, so I wanted to go back to the unit testing stuff.

Chris: Yeah, that's integrating testing, which is a whole different world.

Dave: Yeah. Just the pure, like add two numbers, or the business logic of your thing, it's best practice to break that out. I think I still struggle with where to break that out and how to extract that.

I posted on my blog and, of course, you get people commenting, which is a blessing and a curse. A lot of people are like, "Oh, you just need to know the inverse diversion." It's like the solid pattern for JavaScript, but it's basically like you have to -- here; it's like the five principles of object-oriented programming, the SOLID principle.

The D in that is dependency inversion, which means rather than -- it's tough to explain. That's where I kind of lack the ability here. Basically, you pull out your logic and then you make a wrapper function or component that references your logic that also depends on your logic. Your logic is tested, and then your wrapper, which is what you interface with and call, that is kind of untestable or it can be tested, or maybe you're just testing that it does also include this logic, but your logic can be heavily tested.

It's weird, and it's basically kind of creating two files to manage one function. But, the more I read about it, the more it kind of made sense. I think the example that you gave wasn't quite a full example, but you take a stab at writing the procedural code. Then you reformat it to make it reusable. Maybe you, just at that procedural code level, start writing tests. Then the reusability, you'll know it's still working if the tests pass.

I'm not making a whole bunch of sense here. Again, it's hard for me. I guess that's all I want to get out is it's hard for me to find those breaking points where I can snap things out. I feel like that also is, when I can snap things out to be async code or when I can snap things out and throw it into a worker, all that stuff is very hard for me.

Chris: A good thing to Google is just writing testable JavaScript. You're going to come across some Remy Sharp stuff, some Rebecca Murphy stuff, and Phil Marshall stuff. It's just kind of a good phrase that is going to get you on some conference talks and some articles that go into this a bunch. I don't mean to punt on that, necessarily, but writing testable JavaScript is pretty sweet.

Dave: Yeah. You said you've gone down the Cyprus IO path, haven't you?

Chris: Well, here's a path for you to look up. There's a thing called Puppeteer. Puppeteer is Chrome's API for telling Chrome what to do, like Headless Chrome, but it doesn't even need to be headless.

Dave: Kind of like Phantom JS replacement.

Chris: Yeah, but it's super modern. You look at the docs, and you're like, this is great. It's like jQuery for controlling the browser, kind of. You're like, go to this URL. Click this thing. Scroll here. Go to this input. Put this crap in it. That's the API for Puppeteer. It's great.

Dave: Mm-hmm.

Chris: It's like -- blah-blah, you know, and it does them in a row. You just sequentially write these commands and whatnot. Then you pair that with something like Jest. Jest is the expecting framework. You're using Puppeteer to say, "Go here. Go to this URL. Click this thing. Put this value in here," and you can throw another library on there like Faker. Have you seen Faker? Just put in an email address that looks like an email address.

Dave: Right.

Chris: And, a phone number that looks like a phone number.

Dave: It's like some schema data.

Chris: Yeah. Sure.

Dave: A data factory. Yeah.

Chris: You want to test your sign-up form. You have Puppeteer go to your sign-up URL even in development or whatever on your staging server or whatever you want. Then go to this input and fill in a fake username here. Go to the email thing and put in something that looks like an email address. Then go to the password field and put two passwords in each box and then click the sign-up button.

Then what you expect to happen is whatever happens in your app, like some kind of--I don't know--"Check your email," message appears or something. That's like five lines of JavaScript. That might be a little exaggeration, but it's pretty quick to do that, write that kind of thing in Puppeteer.

Then, Jest can be the thing that's like, well, expect then that that message appears like you want it to be, and that will either pass or fail and give you a little, like, interface kind of thing. Then you can tie that to every time you push code, run this test and, hopefully, these tests pass. That Puppeteer Jest thing is nice. I think anybody with some basic JavaScript skills can get that rocking.

I was surprised that I was able to, but it's so clear. I know it's Chrome focused, so that's not going to help Dave wanting to test a JAWS thing or test an IE6 thing or some crazy thing like that.

Dave: Yeah.

Chris: There is kind of Puppeteer for Firefox, so you can get a little bit of cross-browser stuff going on there. The deeper you go down this hole, you can find ways to control other browsers as well. But, I think Puppeteer is a great kind of dip your toes in it kind of thing. Testing that your sign-up form works in Chrome is probably going to cover a lot o ground for you. That's going to prove basically that it works in Edge and stuff too.

Dave: Right.

Chris: I think you'll be safe there.

Dave: Some of the point of testing is not giving you absolute proof. I think we've all seen the all tests pass jokes and memes on the Twitter or whatever. You can trick the computer into test passing, but I think it gives you a degree of confidence without having to do a long, manual, human entering that fake email address to get data. I think that is kind of the -- I think that's the whole point of testing, and that's what I need to maybe back away from in my brain is not necessarily this, I have made it 100,000% bulletproof. It's just this degree of confidence that you have tested the front-end.

Chris: There's nothing. The punch in the gut that comes from, "Oh, I broke sign up and I found out 13 hours later."

Dave: Yeah.

Chris: That's so crazy unacceptable at some level that you can't do that, so you have to have some tests for things like that. In some ways, you think of unit testing and integration testing as being so separate, but it's kind of not, really. If you have an integration test that tests a whole flow of a thing, that's doing a lot right there. That's kind of implicitly testing that your JavaScript is kind of functional and working and doing what it's supposed to do.

They are very different things, but the integration tests are almost better in a way. They're comprehensive. They prove that your app is doing the things that it needs to do, which is the important part anyway.

Then there's the Cypress thing, which we just explained Puppeteer and Jest, and I'm no master of this stuff, so I apologize for what I get wrong. Cypress even simplifies it even more. You just install Cypress, and you get this kind of testing. It's all together. It's all ready to go. It is Puppeteer, and I don't know if it's Jest or if they have their own testing thing or what, but it's the same kind of code. I started with the Puppeteer and Jest thing and then just ported them over to Cypress in, like, two seconds. It was not a big deal.

Then you run your tests in Cypress, and you can watch it happen. A Chrome window pops up, and it has this sidebar of all your tests. You're watching Chrome be controlled and running the tests. It's all very satisfying to watch. Then the thing turns green if it works. It step-by-steps through all of your instructions that you've told it to follow.

If it accomplishes the thing, if it goes to the input and fills in the value like you told it to, that's a little test in Cypress. It's like, oh, that worked. It passed. Whereas, if it doesn't find that input by the ID you gave it or something, it'll fail then, and it's like an implicit fail. Like, I couldn't find that ID, so your tests have failed. You didn't have to write, "Make sure that that -- you know, expect an element to exist." It's just implied. If it can't do the instruction, that's a failed test.

Dave: Hmm.

Chris: It's kind of like you can write 50 tests in one thing. If you write out your whole flow of, "Go to my login. Sign up a new account. Then go and do a task." I can be just one giant test, and it's 50 tests in one. You can watch it happen. Then, if it fails, you're right there. You have Chrome open, and you have the failed tests, and you can use the dev tools to go look around in there and see why it failed.

It's not totally on you to then redo all those steps and get to that point where it fails and figure out why. You're locked in time right there at the failing of the test, and you can be like, okay; I have a browser window open. I have dev tools right here. I can look around and see why it failed right in Cypress.

Dave: No, that's cool. That's cool.

Chris: Anyway, that was just it. They're not a sponsor or anything.

Dave: Well, they should sponsor, but--

Chris: Plus, I've written two things in Cypress, so I'm definitely not a pro. I just think it's sweet.

Dave: It even has this little electron app, so you download and just run the tests only if you want to do that, you know, like maybe not developers could do that. Anyway, it's interesting. Hopefully, that helps.

Let's do another question. I did get a text that people are on the way to place I am recording, so we'll have to wrap up a smidge early today.

Chris: Dave, if you disappear because there are big things happening in the background, I'll wrap up the show. It'll be okay.

Dave: No, we're good. Hey, beep-beep-beep-badeep-beep. Beep-beep-beep-badeep-beep. Chris, breaking news.

Chris: Yeah?

Dave: Guess what I saw on the Twitters the other day?

Chris: I don't want to know. Do I want to know?

Dave: There is a proposal for an intrinsic size attribute.

Chris: Oh! I saw that because I think saw Patrick Kettner - maybe. Was it him?

Dave: Yeah.

Chris: He said, like, rip Uncle Dave's old patted box.

Dave: Yeah.

Chris: We're getting aspect ratios, and not in CSS, weirdly, but in HTML.

Dave: HTML, which means, just when the HTML, the browser will be able to draw a box roughly of the dimensions that you're proposing that will fill the box. That means you kind of don't have that herk-jerk when you lay out a page. It'll be really nice.

Chris: Right, so imagine you have a paragraph, an image, and another paragraph. As that image in the middle loads, the browser has no idea how tall that image is going to be until it actually downloads the thing.

Dave: Mm-hmm.

Chris: This is you, much like responsive images or will change, or things like that, it's you telling the browser, "Hey, even if I don't know how tall the image is, I'm going to tell you, basically, how tall you should make your placement box," so there is no herky-jerky, like Dave was talking about. But, you don't even have to tell it how tall it is. You just tell it the aspect ratio of it, which is kind of even better.

Dave: Mm-hmm.

Chris: It works in fluid environments better.

Dave: I bet there are some things they have to figure out, like how it works with a picture element where you can change the aspect ratio, which I do all the time. But, this is going to be great. I'm very excited about this.

Chris: That came out of nowhere. I didn't know that was coming. I thought it was coming to CSS.

Dave: I mean every video you've ever put on a website or every iFrame, you know, most of the time you have an aspect ratio you're trying to hit. It's just going to be wonderful whenever it finally gets here. Anyway, I'm very excited about it. Please tweet about it. Make sure it gets very popular and say, "When is this coming? When is this coming, browsers?" And, make them do it, so that would be great.

Chris: Yeah.

Dave: Then I will be released from my open source Horcrux.

Chris: [Laughter]

Dave: Yes! Yes!

Chris: Congratulations!

Dave: Hey, all right. Hey, back to the questions.

Chris: We got one. A sponsor, WooCommerce, this week on the show, so thank you, WooCommerce, for your support of the ShopTalk Show. If you don't know what it is, it's an e-commerce plugin for WordPress. I think we've used it on ShopTalk Show before. We used to sell shirts and now don't anymore. I should know the answer to that. We don't sell shirts right now. I know that.

Maybe someday we will again, and the way to do that, for us, especially as we have a WordPress site already, we'll install WooCommerce on there. It takes one second to install, as all WordPress plugins do. We'll go new product. We'll say ShopTalk Show T-shirt, and we'll give it a price. We'll give it some sizes and stuff. Maybe we'll track some inventory in there. We'll connect our Stripe credentials in there with a little plugin for WooCommerce, and we'll be selling T-shirts, and it will take us no time at all. That's kind of the magic and beauty of WooCommerce.

I wouldn't say that they pride themselves on the simplicity of WooCommerce, even though it can be, and I'd argue that it is, to some degree. More so, they pride themselves on how powerful and flexible WooCommerce is. It can do anything. If you need to take some money from people on a website for any reason, WooCommerce can do it. If you were a barber and you want to book appointments, can you do in WooCommerce? Absolutely. You're selling a PDF for your freelancing guide and you need to digitally deliver it securely, WooCommerce can do that.

Dave: Nice.

Chris: Yeah. Totally, right? Do you want to sell memberships that provide protected access to parts of a website? WordPress can do that. Or, a subscription that's rebilling, all that kind of stuff, WooCommerce can handle that. Of course, it can do the physical products thing as well and help you with inventory, shipping, management, and all that stuff. It's just as powerful of e-commerce as you could ever want. It just has 450 plugins or something that extend what it already can do. Just out of the box it's pretty powerful. Anyway, that's WooCommerce. We literally use it and love it, so thanks for the support.

We have a question that came in about WooCommerce, so serendipity here. We might as well do that question. This is from Frederick Eckeland. "I listened way back when the show started. I get to land my first development job. Today, I work as a Web developer in a small, integrated design studio and started to listen a few months ago." Yeah. Thanks for listening, Frederick.

"We regularly develop e-commerce sites for clients. Our preferred solution is Shopify." Okay. "But, we also do WooCommerce. If possible, we try to convince the clients to go Shopify. But, for the sake of the question, let's just say that WooCommerce is nonnegotiable.

"For normal WordPress development, developing templates is pretty straightforward. You have your single dash. There's single.php, but there's singleposttype.php, and then there's page, and there's pageslug.php and all that. You have all this control with the WordPress templating system as far as your theme goes. That gives you total, complete control of all the HTML that's rendered for that particular page.

"For WooCommerce, however, they seem to be actively discouraging people from writing custom templates and, instead, encourage the use of filters and hooks to customize only minor parts of the page. That's a major hassle if you're trying to build a totally bespoke site. I knew WooCommerce lets you customize which pages to use for the cart and the checkout and stuff, but if you go that route, you're left to wade through API documentation to figure out how to write the cart template, coupons form, checkout, and so on."

So, I don't know, Frederick. I don't know if you're -- I haven't built, like, major client buildouts with WooCommerce, and maybe you have and know a little bit more. But, it seems like there might be a little misunderstanding here. I think that it's just kind of interesting in that I've taken control of full -- just like I can take control over my single.php page, I can easily take control of a single product page in WooCommerce.

It follows this pattern that other software products I've worked with over the years do, which is that the plugin itself has all these templates built into it with certain names. They live in the plugin folder itself. We're taught as developers, "Don't dig in there. That's not acceptable place to alter files," because, as soon as that plugin updates, those files will be wiped out. You never touch what's in a plugin file, a particular third party one.

What it does is, if that same file exists at the same place in your theme folder, it will override the one that's in there.

Dave: Nah.

Chris: Have you messed with software like this, Dave, to just put the same file in the same place and it overrides the one, the default one?

Dave: Yeah. I'm looking at the WooCommerce templates and, for the single product, they have a rating.php, like for your rating widget.

Chris: Sure.

Dave: If I code my own rating widget and name it rating.php, probably in like singleproduct/rating.php, it'll use mine instead of the production. Is that kind of how that works?

Chris: Yeah. It could be all the way up. Literally, any file, if you put it there, it will override it. I’m actively using WooCommerce right now in the CodePen store to sell stuff. I override the two pages that I just felt like overriding, which is the single product and then the archive pay, like the storefront homepage, just so I could be like, "Oh, I'm going to use a flexbox grid thing to show," because I just felt like overriding that. All I did was plop that file into the theme folder and, now, like you said, Frederick, I have complete HTML control over what gets output there. And, WooCommerce knows that you did that.

It will look in there and see what you're overriding and use that. Then it will warn you when WooCommerce updates. It'll say, "Hey. We've changed that template, and you're overriding that template, so you should probably take a look and make sure that that template that you've written has the new stuff that we've put in that template. This happened to me a number of times over the years.

Dave: That'd be cool.

Chris: You've got to just go look and kind of manually dif it yourself. If you're happy with it, basically, you change the version number in your template to be the same as the production one. Then they'll stop bugging you about it.

Dave: Hmm. That doesn't get easier, does it? [Laughter]

Chris: No, unless it's really different.

Dave: Right.

Chris: Then you're like, "Oh, crap. Maybe I should just kind of start from scratch here." But, I think that's the reason that, in Frederick's words here, what does he say? They actively encourage you to use filters, hooks, and stuff. All of WordPress does that. If you can get away with doing it through a hook and filter, what's nice about that is that hook and filter will be there forever and you're not overriding anything. It's just kind of the cleanest possible way to make an alteration to a theme.

Now, I know that's more complicated because you have to do that probably in a custom plugin or in your own functions.php or whatever in WordPress. It's a little more complicated. You have to find the right hook, and you have to write literal functions that return code. There might be HTML all up in your PHP. It's just kind of weird and awkward, but that way you just can happily update WooCommerce forever and never be bugged about anything, and things will be fine. I think that's why they encourage it.

Dave: Yeah. I'm thinking common things like--I don't know--I want five span elements around my H1's because I'm going to do some cool shadow or something. [Laughter] Rather than hard code that in the template, maybe just use a filter to do that every time because that's something weird for your theme you're doing, or reclassing, I could see. Like, oh, we're not using WooCommerce's classes. We're using Bootstrap classes or Tailwind CSS classes, so we've got to do special classes. You'd go through all the templates and replace all the classes. It's pretty tedious, so maybe there is some filtering. You could be like, change class rating to rating PB5109XRP1.

Chris: Yeah.

Dave: I think, yeah -- I don't know. I'm not saying--

Chris: Well, because it offers both ways to do it, I think that's all the flexibility you could possibly ask for.

Dave: Right. You could bake the template, or you could just kind of be like, "I'm going to programmatically alter it." [Laughter] I'm basically going to code mod it in filters or functions.php.

Chris: Yep.

Dave: Okay. Well, hopefully, that helps. Yes.

Chris: Good luck. I know this is -- you know that was -- you know, WooCommerce sponsors the show - asterisk.

Dave: Yeah.

Chris: But, we do quite love them. Here's an anonymous one we'll try to get through real quick. The SaaS company I work for, Software as a Service company I work for, has decided to implement a low code system in order to accelerate development and scale our product. I love the company but, as a developer, I can't imagine a scenario where I would want to code less. Do either of you have any insight into the low code world? Is this a dead end for my career?" Have you even heard that phrase, "Low code"?

Dave: I haven't, but it sounds -- I don't know. There's a Wikipedia link here, right?

Chris: I put it there because I had to Google it as well. But, it's kind of like a movement, I guess. Instead of writing code to use graphic user interfaces, allow people to build things without writing code. The whole point is to avoid code, avoid code, avoid code, I think, which is that avoiding the technical debt that is all code.

Dave: Hmm.

Chris: If I do this in this different way, I can maybe make it faster, easier, and simpler, and hopefully faster. I guess it's a bit of a movement, you know. I know you need to build things, but let's get away from having to kind of hand-code it, almost like an evolution of code.

Dave: Oh, interesting.

Chris: This anonymous person is saying, "I'm a developer. I like coding. I don't want to code less."

Dave: Yeah, I mean I see why code is expensive from a business standpoint. We've got to pay a team of people to write, check, and deploy little pieces of code. I think we all know less is more from a code perspective. A million lines of Java isn't necessarily better than 10,000 lines of Java. You know what I mean? It's maybe easier to hop into a 10,000 line of code project first, right? That's a lot easier to comprehend.

Yeah, I don't know where this move comes from. This strikes me as agile. Does that make sense? Agile was, like, "Hey, let's just try to make software faster. Here are some principles we all signed up for." Now it's like this enterprise level, like there's Agile coaches and 70 different processes that you can subscribe to or philosophies of Agile that you can subscribe to. It's all trying to make it faster, but it's more or less just make you feel good.

Chris: Mm-hmm.

Dave: Because true Agile is really just like, let's just try to be fast and work on what's important at the moment. But then, that doesn't super scale into large enterprises where you have to plan things out. But then, this low code development platform, LCDP, is really funny because it just strikes me as somebody saying, "Oh, it's better if we write less code." Then somebody is like, "Yeah. Yeah, I'm going to file a patent on that." You know? [Laughter] It's like, whoa! What the heck?

Chris: Yeah. Well, the other irony is that it's like, well, if it's meant for reducing technical debt, fine, it does in some kind of way, but it also introduces the ultimate debt, which is whatever platform you use to do it.

Dave: Right.

Chris: Moving away from one LCDP to another is probably not going to happen.

Dave: No. I mean -- yeah, I don't know. It's really interesting. I would love to see a true example of this. You know what I mean? Maybe Amp is an example of this? The code is kind of provided and you just kind of stitch it together.

Chris: I was imaging database schema things where you draw arrows to things, like an air table.

Dave: Right. Right, well, there's stuff like that too. I think machine learning is kind of all about that, right? There are all these tools for anyone. Kind of these, basically, graphical machine learning tools. You're like, okay, do this. Now run this algorithm, and now this is it.

Yeah, I don't know. I don't know. [Laughter] It's the fourth generation programming language, which that sounds like science fiction. Rapid application development tools of the '90s and 2000s. That came across my mind too. I think of like Rails was kind of a rapid application development. It was kind of like the goal was you have all the common development things built in, so you don't need to write your own database adapter.

All of that is provided for you, so you can write the code that makes your app work a lot easier. That's what Rails was for. Then everyone hates Rails because it's way too bloated and big. But, it's like, well, no, I solved all the application stuff. Maybe if it's on the Rails end of the spectrum, I like it. But, I don't know.

This automatic code generation thing that I'm kind of seeing seems a little different. I don't know. I don't know, Chris. Low code: I haven't come across it, and now I'm curious.

Chris: No, so let's just do a shout out for the readers. Does your business use one? Do you like it? Do you hate it? Is it the end of all time? Is it related to machine learning? You tell us.

Dave: Yeah.

Chris: It does look rather new. It looks like the term was coined in 2014.

Dave: I wonder if it's kind of like -- you know how backend software -- like some tools, like Rails admin or … would do this too. You'd basically tell it the database. You're like, here's what's in the database. It's like, "Cool. I got it." It can basically scaffold the frontend based on the fields in the database, which is really awesome.

Chris: Right. You know how Perch works too. They're CMS from Rachel Andrew and Drew Ellen that does the, like, you just start using stuff in your templates. It's like, oh, I see. I should account for that in the data entry area of the site because they're trying to use it, so we should….

Dave: So, we should build for it. Yeah.

Chris: We should have….

Dave: Yeah, I wonder if it's kind of like that.

Chris: Yeah.

Dave: Especially for internal apps where the UI can be a little bit less than stellar. I know companies spend millions on their internal apps when really it's data entry. You just need a data entry structure. Yeah, I don't know. Now I'm interested. I don't know. Tell us, Shop-o-maniacs, if you have any information. Please let us know. We're dying to figure out about these no code because, if I could quit coding, that would be wonderful.

Next startup, Chris.

Chris: That's my next startup.

Dave: Going no code, so there you go. [Laughter] All right, well, Chris, we should wrap this up before my aunt and uncle make a cameo.

Thank you, dear listener, for downloading this in your podcast player of choice. Be sure to star or favorite it up. That's how people find out about the show. And, follow us on Twitter at @ShopTalkShow for tons of tweets a month. If you hate your job, however, ShopTalkShow.com/jobs. 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: No, I don't think so. ShopTalkShow.com.