Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to a future episode of the ShopTalk Show coming at you live from 2020. I'm Dave--in the future--Rupert - Hoverboard Rupert. [Laughter] With me is Chris--DeLorean with a garbage compactor--Coyier.

Chris Coyier: Hell, yeah.

Dave: Hey, Chris. How are you doing?

Chris: I just had to take my auto-tying shoes to the cleaner.

Dave: Yeah, I made some sports bets on future baseball.

[Laughter]

Dave: You know. Yeah, it's good, so far.

Chris: McRupert! McRupert!

[Laughter]

Dave: That was literally my AOL screen name.

[Laughter]

Dave: That is -- wow! Wow! That's -- hey, wow. Throwback.

Chris: Mm-hmm.

Dave: Hey, um… So, we're here in 2020, and everything exists in CSS now. Isn't that great? For the last 20 years, we've been saying, "Maybe in 2020, we'll have that," and it's 2020, and we have it all now. So, there you go.

Chris: Well, there was some sentiment going around about, you know, like Scott Jell wrote for CSS-Tricks, like the tools are here. There's a sentiment that, "Wow! Things got really good in the last bunch of years." We're not sitting around like, "Well, the Web would be good if we had this." It's like, "No, we've kind of got it all."

We still wish for container queries and there's all this stuff. But we'll always do that. We'll always be like, "More. Give me something cool." But we've gotten so much and it started to roll out in slightly better cross-browser ways. It's just better now, in a way, the Web is.

Dave: It's neat because all the problems, layout problems or responsive issues, a lot of those are just solved. I use Grid like a maniac now and it just solves so many problems. It's easy to layout a page. It's trivial. You just write the code and it's done. [Laughter]

I mean there's a little bit of footwork to do for the responsive view but, man, it's so easy to layout a page now. I think it just generally changes everything about CSS. Now, instead of spending three days on getting the layout all in order, the Grid CSS file, it's just done. It's one line of code and I use it when I need it. I don't know. it's a good future.

Chris: Yeah, it's a good future. Kyle Matthews, Gatsby, he's their guy over there who was just tweeting today this massive thread of future predictions. I probably read more future predictions this year than I ever have in my life. My gosh. Everybody and their sister wants to tell me about what's going to happen.

Dave: Yeah. Adam Margo had one…

Chris: Oh, yeah. I liked his because it was all CSS only.

Dave: Yeah.

Chris: You don't see a lot of people doing that. There are not that many. It feels weird to say, but people just aren't writing about CSS as much as they used to. Uh… That's weird.

Dave: Well, I've got opinions on that. But, yeah, you know I think, just before the holidays, I wrote a thing about details not being an accordion element.

Chris: Yes, I remember. Yeah. What was your postulate there? It quite literally isn't. Don't try to make it one because it will be problematic.

Dave: You can't. No, because the summary element has role=button. Most browsers, I think there's technically a role=summary, but I could be wrong on that, but role=button. If you put a button, it eats the semantics of everything in there, so you can't have a heading inside the button. Button H3 just will nuke the H3, basically, to a screen reader. If somebody tries to browse by headings, they don't….

Chris: Well, what if your accordion is just paragraphs inside of it? Is that cool then?

Dave: If it's just like strong tags, yeah. You know it depends on your design. But the WAI Authoring Guide, the Web Accessibility Initiative Authoring Practices, they actually recommend having a heading in there. They require that or they say it needs to have a heading inside of it to be navigable. If you think of an FAQ page, somebody has to listen to every single -- they can't just browse by headings. They have to go through the whole page or whatever.

Yeah, I don't know. Anyway, I sort of punched the Web standards bees nest by suggesting we need things like an accordion element, a tabs element, a dropdown element or, God, tooltip. I mean any of these things we do every time in every single design system, we need elements or primitives for this.

Chris: Yeah. Yeah. Yeah. The story, as you know, is long. It's not just delivered on a platter one year. As a matter of fact, what this makes me think of, just as a minor aside here, is that it's hard to write a post that says, "This is what happened in HTML and CSS in 2019."

Dave: Right.

Chris: Things are longer than a year span. It's not like we shipped some version of something and then it's production-ready, everybody can use it, silver platter, go. When a framework ships something, that's what it is. It says, "We got this and now everybody can use it. It's here. Let's talk about React hooks. It's ready to rock for the world." That happened in 2019.

Dave: Mm-hmm.

Chris: The dialog didn't happen in 2019. Nothing happened in 2019. Kind of. There are a handful of things, but you know.

Dave: [Laughter] Yeah, if anything, we found out we couldn't use a lot of stuff in 2019. You know?

Chris: Right. You can't use dialog. You can't use menu. You can't use -- blah-blah-blah-blah-blah. Yeah.

Dave: Yeah. No, I found out. Somebody said it and I didn't believe it, but the main element, M-A-I-N--

Chris: Yeah.

Dave: --that's the main content section, how many years to get that going, Chris? How many years would you think it takes?

Chris: Oh, I don't know. I guess since the early days of HTML5. Four or five.

Dave: It's a fancy div and it took ten years.

Chris: [Laughter]

Dave: And it's just a fancy div, so--

Chris: Yeah.

Dave: I mean there are things like, I guess, what you know about it had to evolve, like role=main, you know, things like that. That maybe didn't exist ten years ago when they started proposing it, but anyway.

Chris: It's slower. It's just a different--

Dave: It's a lot slower.

Chris: The way that you talk about it has to be different.

Dave: Even, like, I encountered a lot of upset Chrome developers through this thing, through this blog post. They were like, "Well, Dave Rupert, you made fun of Toast when it came out."

Chris: Hmm.

Dave: "You kind of spread some fear, uncertainty, and doubt when Toast came out," and pointed to a very dumb Twitter joke I did on Twitter.

Chris: Okay.

Dave: Which has me not wanting to use Twitter anymore.

First of all, sorry. I say dumb stuff on the Internet. I apologize. I'm just going to blanket apology.

I think, if you've listened to this show and you've probably heard me say, Toast, I feel like, its problems are it's very Google-centric and I felt like it was just rushed out the door. This was over the summer, right? I felt like Chrome was just trying to pilot a, "Here's how we do Web standards the fast way," you know. "We're going to ship a Web component but it's not going to be an actual Web component. It'll be inside the browser and then we're going to ship it. Then people are going to use it. Then we'll standardize it," like a different route for standardization.

Chris: Mm-hmm.

Dave: I think Toast itself is very Android-specific. You know it's like an in-browser notification or in-page notification.

That said, I was looking at standard Switch the other day for a design system because I just was like, oh, this is a cool way that they are doing switches. I can't NPM install it or anything, but I can use it or I can see what they wrote and I could port that code and use it.

All this to say, I actually don't hate the standard element process that they proposed. I just think they kind of went about it in a bit of a poor fashion.

Chris: It was scary words and, I think, when people are scared -- I kind of get their perspective, too, that if everybody dunks on it then we've halted future progress on future things because it's like, "Oh, my God. We tried to do one thing and you dunked on us so bad," but like, "Okay. Forget it. Let's not do stuff." You know? That's a little unfair, maybe, but--

Dave: Everyone has kind of got a chip on their shoulder or is very sensitive or was bitten by that whole experience.

Chris: But we have to watch it, my God. It's so easy to ruin what we have. There are so few watchdogs. We're going to be watchdogs. Most people aren't. Most people are just like, "Oh, here's a thing. I'll use it." You know?

Go to a meet-up and be like, "Ampo, what's that? Is that that thing we need? Oh, yeah, I guess I'll look into putting that on our website."

Not to say people are dumb, but they're busy. They've got other things going on. They just use what's there. They're just like, "Oh, that's a thing now? Okay. I guess we better get on it," you know, because they're busy running their businesses. You need watchdogs at the technological level.

Dave: I saw a blog post on Google that told me to use it. I Googled it and it showed up on CSS-Tricks because somebody was writing a post about it.

Chris: [Laughter]

Dave: I was like, "Oh, therefore it's a thing." You know?

Chris: Yeah, just be careful.

Dave: Yeah, you need people who kind of say, "Whoa, whoa, whoa," so I don't know.

Anyway, I think, rather than the two weeks they tried to ship Toast, from that being the low end and the ten years it took to ship the main element, I would love something in between [laughter] to where we could ship new HTML and CSS, you know, something in between there, two weeks and ten years, would be awesome.

Chris: Yeah.

Dave: I don't know. Anyway, what's neat, though, is I'm going to be in some conversations kind of about potential solutions, so there's a pretty good implementation that didn't go very far from Brian Kardell from Algolia [sic] who did a panel and panelists.

Chris: Is that where Brian works? Brian Kardell works at Algolia? Seriously?

Dave: Yeah. Algolia, if you don't know, is a -- it's basically like a--

Chris: A search thing, isn't it?

Dave: Pay to hire. No.

Chris: I think you got it wrong. Algolia is search.

Dave: No.

Chris: He was at Apollo Group.

Dave: No.

Chris: No?

Dave: Hold on. Is it Apollo?

Chris: Not the Apollo like GraphQL, like a different Apollo. [Laughter] Sorry.

Dave: Oh, man. Hold on. It's Igalia. Hold on. I'm losing it. Oh, man. Anyway--

Chris: We all know how Brian is, though. I want to bring him up for another reason. He really has his finger on the pulse of a lot of stuff that's going on. I just read a post about his about some color things that I won't take us down that direction just yet, but there's a way that Web standards can work and that other companies get involved. They do the work and then ship it upstream to the browsers.

That's how we got CSS Grid. It's a wonderful story and it means that it's not browser vendors themselves that you have to rub their shoulders and do all the politics of internalizing. If the community really wants stuff, you can actually throw some money at it and get stuff done.

Dave: Okay. I have it.

Chris: Okay.

Dave: Igalia. Igalia. Not Algolia, Igalia.

Chris: Cool.

Dave: Got it. Igalia. Yeah, they're like a contract for hire. Like if Chrome implements something, Chrome will pay them or Amp or somebody will pay them to implement something in Webkit or something like that.

Chris: Oh, okay.

Dave: Or in Gecko or, like, "We need you to implement this," and so, yeah, right now he has kind of a proposal up. Unlocking Colors is his blog post. It's about possible new color functions and things like that happening in CSS and stuff like that.

Chris: I think this is mouth bloggable for the podcast. It was an Adam Argyle tweet that was so great. There are three color swatches; imagine three color swatches: on the left, gray; in the middle, blue; on the right, green. Now, that's terrible mouth blogging because you can't see the exact shades of them but imagine that they just luminate a little differently.

They have different lightness to them. You look at them and be like, just guess which one of these do you think has the most lightness, is like the brightest one of them, and which is kind of the dullest one them? You look at them all and you're like--

Dave: The gray is a dark gray.

Chris: Yeah.

Dave: Like space gray.

Chris: So, pretty low.

Dave: Green is like a neon green.

Chris: Pretty bright.

Dave: Like spray paint.

Chris: Pretty bright.

Dave: Right? Blue is like--

Chris: Meh, in the middle.

Dave: --a nice blue. I don't know.

Chris: Yeah.

Dave: Like a -- yeah.

Chris: You look and you're like, which one has the most lightness? You're like, I don't know. The green then the blue then the gray, probably. Just trust your brain a little bit. Which one has the--? You know.

Dave: Yeah. Green….

Chris: If you're making a color system, you'd probably want to throw the same, like have numbers that reflect that. Be like this number is this brightness because my brain thinks it's that bright. If I use the same number that I'm going to get colors that feel equally bright.

Well, it turns out, in HSL, which is kind of our best color format for this kind of thing at the moment, you know. Like RGB, whatever; it's just random numbers. You're not going to get anything useful out of that. Hex codes are equally -- pfft -- who knows what I'm looking at with a hex code?

He's saying all those three colors, those three swatches, they all have 50% lightness in HSL, all three of them. It's kind of like, that's not that useful for us. Wouldn't it be nice to have another color format that has numbers in it that are even easier to reason about than HSL? I think.

I don't know much about LAB color, this other -- what is it? There's another thing: LSC. I don't know. There's some other function that goes along with LAB that's a function in CSS. And so, Adam opens up a thing and, look, we should put this -- you know, it's already spec'd out in CSS 4. Why don't we just do it?

Tab Atkins chimes in. He says, "This is easy. We're not asking the browser to do anything particularly weird. We're just going to map the color down the same way we map all the other color functions. This is not a big deal."

He even called it, like, this would be like -- what do they call it in GitHub when you're committing something for the first time? #FirstBug -- something. This would be something that a browser--

Dave: Yeah, first commit.

Chris: Good first commit. This would be good first commit for a browser vendor person because it's so straightforward to put out there.

I think kind of the point from all this is that it doesn't have to be Chrome who does it. It can be Igalia or whatever else, you know.

Brown even tells me it's like 150, 200 hours. That's not just to do it because you've got to do it. You've got to write tests. You've got to play politics a little bit. You've got to dance around it a whole bunch, but 200 hours; you get this done.

Dave: One person, one month, boom. Two months. Let's say two months. Not saying it's easy-peasy, but yeah. If it's just some--whatever--math inside of a C function, that should be able to port over to other browsers too.

What's interesting -- I don't know. Did you read--? Christopher Schmitt, a long-time friend of the show, had an excellent color theory and contrast ratio post on 24a11y.com, like an advent calendar for accessibility. He just goes into color. It is just maybe the best thing about color I've ever read in a long time. [Laughter] I just was like gripping my seat with excitement.

But at the end, he actually points to some issues where the SRGB minimum contrast and stuff is all calibrated wrong or it's off or something. This is from some person and they have a bunch of examples where, technically, this stuff passes but it obviously looks terrible and is unreadable.

Chris: There's this accessibility blog out there that I can't remember it. I'm not sure I would name and shame on the show anyway, but everything they post, I feel like, gets hammered by the accessibility community. You know what I mean?

Dave: Yeah.

Chris: There was a post on there that had this blue as a classic example. It's like a pretty light blue and you look at white text on it and you're like, "That looks pretty good," but it actually fails WCAG or whatever. You look at black text on it and it totally doesn't read well, but it passes. Is that what he's talking about here?

Dave: This one is actually -- that one is more like subjective.

Chris: Yeah.

Dave: Like, "Uh, accessibility is ruining my design."

Chris: Yeah. Right, right.

Dave: Like blaming the standard. Does that make sense? This one is more evidence-driven, if that makes sense. This is more like, "Hey, I legitimately think the contrast algorithm is wrong." I think even some of this stuff, all these color functions and stuff like that, I think they could all play into having a better set of color standards or even groups, or just even thinking around what are accessible colors and how do we make colors and create colors on the Web and stuff like that.

Chris: Yeah. yeah.

Dave: Anyway, that's the….

Chris: I should read that one more carefully. I remember that he posted it. I read the Una Kravets one posted about color systems, too, but from a -- look at what you can do in CSS without any JavaScript, without any pre-processor, or anything, with calc or custom properties and HSL. You can make a numbers-based color system in totally raw CSS, which is cool. I don't know that her post goes into any of this LAB color stuff, but I think that's what's kind of being looked at here. People are wanting to be systemic about their colors.

I see this all the time. I have guest posts getting written to me all the time. One that we just published about using Sass to mathematically calculate a color system that is based on accessible colors. I have another one in the pipeline of somebody doing the same kind of thing. People are really trying to approach color scientifically, more and more and more and more.

Give us LAB color. We'll take it.

Dave: Yeah.

Chris: If it enables this stuff. I don't even get it. I don't even understand what the numbers in the LAB function are but, apparently, they're better.

Dave: Well, you know, if we get more math in the browser, maybe we can start having things like lighten and darken in native CSS.

Chris: Yeah, yeah. Yeah, we didn't even mention talking about the color adjustment functions that there are always being talked about, but that's a whole thing.

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by An Event Apart. Just put AnEventApart.com into your Web browser and go check it out.

They have six shows this year. They call them shows. They are conferences: Washington, D.C.; Seattle; Boston; Minneapolis; Orlando; San Francisco. They're multiday events that are just awesome. They're the best conferences there are for front-end, UX, design, building for the Web.

I think Dave is going to be at the Seattle one. Go see Dave in Seattle. That'll be awesome.

Even if you miss Dave, pick one of these cities. They're all in the U.S. Just go. You'll learn a ton. They're just the best ones.

The food is good. The music is good. They get the best speakers in the business to come talk. I can't say enough good about An Event Apart. If you're going to pick one conference to go to, that's the one that I would suggest. Do the classic thing where you start thinking about it now, here in January. Start thinking of ways to convince your boss to pay for it or save your pennies or do whatever you have to do and just go, just soak it in, and just become better at building websites.

[Banjo music stops]

Chris: Okay. Early on, we were talking about all these people have got all these predictions. We've been talking about that forever and I mentioned that Kyle Matthews thread or whatever. It's kind of all over the place of weird predictions and stuff.

One of them was kind of about, like, that CICD is going to be big. It's already big. What I mean is continuous integration and continuous deployment.

Dave: Yeah.

Chris: Just meaning that what we work on, on our computer, there's a bunch of stuff that happens on its way to staging, production, and all that stuff. Now, of course, that's true. It's already big now but I think his idea is that it's just going to be much more prevalent.

Dave: Mm-hmm.

Chris: I think we're seeing that, in a way.

Historically, there's always been stuff. Ruby's make and there's all kinds of history to this that's interesting. To me, the big player for front-end developers was Grunt.

Dave: Right.

Chris: The arrival of Grunt was, now front-end developers are in charge of build process kind of stuff. I was looking back at a post about 24 ways RIP shut down this year. They had a killer end of year, I think; just the greatest year they've had in a while, to me.

Dave: Yeah.

Chris: A lot of stuff resonated with me. So did that accessibility, that 24a11y one. They had a damn good year too.

Dave: Mm-hmm.

Chris: They had a REMs versus EMs one that we could get into or EM versus PX that was killer.

Dave: Perf Planet had one where they measured the impact of CSS and JS on the client. Whooo….

[Laughter]

Chris: That's a good one. God, what's with blogging in December? People need to blog in August. That's….

Dave: Oh, that's hot, man. It's hot.

Chris: It is hot. Okay, so Grunt comes on the scene. JavaScript-based, so all these JavaScript developers love it. We use it to process our Sass and optimize our images and all that stuff. Great.

In my post, it was on 24 Ways, and I think I called it Grunt for People Who Think Things Like Grunt Are Weird and Hard.

Dave: Yeah.

Chris: Which was a bombshell article for them that year, I hear.

Dave: [Laughter]

Chris: Because it was from me. It was so foreign to me then, but I just forced myself to learn it. I was like, "This is great. I can use this on all my sites," so now I can do stuff like Sass, which, before, felt foreign to me because it's not just Sass that you need to learn. The hard about learning Sass is setting yourself up in an environment in which you can write it nicely. It's more of a dev environment thing than a language thing.

Dave: Yeah, the syntax was not really the huge hurdle in Sass, in my opinion.

Chris: Yeah, exactly. But I think I speculated what if a GUI for Grunt. To this day, I like GUIs. To this day, I use Git through a GUI.

Dave: Yep, the same.

Chris: Anything I can use a GUI for, I do. I just like it. I prefer it. If I can, you know. It's just, that's my style.

Dave: I use my operating system through a GUI. Did you know that?

[Laughter]

Dave: Yep, my whole damn operating system is a GUI. Did you know that? It's wild.

Chris: Oh, my God. Dave, incredible.

Dave: Yeah. Yeah.

Chris: Incredible.

Dave: Yep.

Chris: Incredible. DOS.

Dave: Then I use a -- yep, yep, Slack. Technically a GUI.

Chris: [Laughter]

Dave: We're not just writing SQL queries into….

Chris: I think it's a microbrowser, micro front-end within a micro browser.

Dave: Yeah, that's true.

Chris: Okay. I speculated Grunt, okay? Why not a GUI for Grunt? It just does all the -- it's just little -- piece together little things like you just end up, you know, copying some chunk of JSON to throw in your config anyway. What that config is saying is, like, stuff that could be expressed, in my opinion, with an input, a checkbox, a select button, or something. Couldn't it be a little dev tools addon or some kind of app that I open up, I point it at a folder, and I say, "These are the things that I want to happen"? Why isn't there grunt.gui?

Dave: Grunt.exe, yeah, gimme it. Gimme it!

Chris: Yeah, gimme it!

Dave: And pre-pros or -- was code kit is also--

Chris: Right.

Dave: It was great for Sass and stuff like that.

Chris: What's funny about code kit is it's kind of best of both worlds, in a way. I still have it in my doc here because there are some apps, including the current version of ShopTalk Show, which we're burning to the ground. Finally, we're on it, people. We're neck-deep in playing around with the ShopTalk design, in which we're not using Grunt, but we are using Gulp, I'm afraid.

Dave: We are having Git merge collisions, folks.

Chris: [Laughter] Yeah.

Dave: It is that level of excitement around here.

Chris: I just was working on it while Ruby napped over the holidays. I had Ruby all by myself, so it was like a break for me. As soon as she went down, I'm like, "I need to do something with my adult brain," and I chose to work on--

Dave: [Laughter]

Chris: --on ShopTalk Show, so it was a really fun design. A good high-five to Afia and Dan who were killing it on that design.

Dave: Yeah. Hitting it home. Thank you.

Chris: We never got a GUI for Gulp or Grunt.

Dave: No.

Chris: But why not now? We're still in this world. It's still there. It still feels like, "Oh, I just need my build process to do X, Y, and Z. I think you were, before the show, thinking in the same--

Dave: Yeah. You know when I write a Gulp file or whatever, it's like task, gulp.task. I name my task and then there's a function. Then stuff happens in it. It's like, get all the CSS and then pipe all the CSS to autoprefixer. Then pipe all the CSS through -- or I guess you do Sass and then pipe it to autoprefixer or whatever. You do steps, right?

Chris: Yeah.

Dave: It's just steps inside. I don't know. Are you familiar with Scratch? It's like a programming language they teach kids?

Chris: Mm-hmm.

Dave: It's kind of kids, like my nephew has made video games in this and is better at coding than me with this because he uses this visual GUI. [Laughter] Scratch is like an MIT kind of software.

You drag these blocks like if, move, turn, go to, if. You drag these blocks into your program and then you hit "play" and it'll execute these blocks in order and stuff like that. You move it left to right or whatever. Usually, it's for animation. That's what kids engage with. But, logic wise, everything is there, like wild loops, for loops, things like that.

Chris: It's not limiting your ability. Sometimes I think, with a GUI, I'm like, "Well, okay, so you have a Sass block and you have your input block," probably, right? Like a square that represents a folder or something that perhaps it's watching. Then you connect that block to a Sass block. Then the Sass block to the autoprefixer block. The autoprefixer block to a post CSS or whatever.

Dave: Yeah.

Chris: Then, finally, to an output block, which is a different folder, probably.

Dave: Yeah, exactly.

Chris: Then you hit "play" and it runs it. You'll have to have some opinions in there, but it could be as complicated as you wanted it to. You open up the Sass block and it gives you options in there. What kind of formatting do you want? Which version of Sass do you want to run? That type of thing. It doesn't necessarily need to limit your abilities. In fact, my GUI client for Git does all kinds of -- there's nothing that it can't do. It just does all of Git, which is great.

Dave: Right.

Chris: I have open, on my desktop right now, a program called Audio Hijack.

Dave: Yeah.

Chris: Which is from -- who is it from? Who makes this thing? Rogue Amoeba.

Dave: Rogue Amoeba.

Chris: It's audio that's this. I have my microphone as a block and I drag it to my recorder block. Then it goes -- it saves to my desktop. That block syntax, I drag these little boxes around because it's designed -- I use it basic-basic-basic, but you can pipe it through a broadcast thing that sends it up to Twitch or whatever. You can pipe it through a thing that makes my voice sound all crazy or cleans it up or something. You could have ten things it's stringing it through. You're proposing the same kind of box, drag boxes to other boxes, GUI, but for a build process.

Dave: But for a build process.

Chris: Beautiful.

Dave: Then you have the visual thing. How many times have you jumped into a project and you just have this -- I'll throw Webpack under the bus. You have a Webpack RZ or whatever or config. You're just like, "I don't know what's going on here. Let's see. Okay, you're using this plugin. Okay, what's this plugin do? Okay. I have to Google it. Okay. Here we go. Okay, what's that?"

I feel like that's part of the reason no one ever touches those things. Once you have it running, even if it's running bad and spitting out the wrong thing, you won't fix it.

I would say 40, 60 hours a year of my time is spent tinkering with build processes. That's terrible. What if it was visual? Why can't it be visual? Let's make it visual.

We're making front-end design or no-code stuff visual. Why not build processes as visual.

Take it a step further. Have you ever made a service worker before? That could be visual. It's like these five events and then you say what you want to happen in the five events. Oh, cache these files. Oh, look in the cache for these files or for the request. If it's there, serve the request. Otherwise, don't serve the request.

Oh, is it a Git request? Don't do -- go get it from cache. Oh, is it a regular request or a post request? Never do anything with that.

Chris: Yeah. Yep.

Dave: Very simple sort of things we could do to--I don't know--make programming these configs and all this crap that we have, we can make it easier. A Grunt file, Gulp file, Webpack config: these are all the same thing.

Chris: Yeah.

Dave: In my opinion, yeah.

Chris: I feel like it's just complicated enough that it's off-putting to entrepreneurs or something.

Dave: Yeah.

Chris: This thing is just stepping into a bees' nest of complication because it's just hard.

Dave: Or maybe it could happen, not to put it all on code, but what if it's in your code editor, Visual Studio code or something? You open a Webpack RC and it's like, "Oh, cool. I'll just give you the block UI for it instead." You know?

Chris: Yeah, I wonder if that's what you'd approach. Some part of it makes it appealing that you don't even see a Gulp file. It's not like a GUI on top of a Gulp file. It's just its own thing.

Dave: Yeah.

Chris: It's not a GUI. It's just no code, you know. I think Buddy is not quite this, but it does have these pipeline ideas that's kind of there. The things that you put in the pipeline are so simple. It's like BYO stuff. It's like, "Run this command." You're like, well, that command, you still have to then write all the code to do what that command does. It's not actually helping you. It's like a little bit deeper level than that.

Dave: I feel like that's sort of -- GitHub actions kind of has this.

Chris: Mm-hmm.

Dave: If this, then that, sort of UI.

Chris: Yeah.

Dave: If this happens, then do this. That's all I'm saying. Maybe as the minimum is "if this, then that" for build processes that I have on my local machine. I don't want to sign up for a third-party.

Chris: You want it to be local, a local deal? Yeah, that's tricky, too.

Dave: I think local.

Chris: Yeah.

Dave: Yeah, I mean I guess now I'm just asking for….

Chris: Maybe it works in both ways, you know. If it can run locally in a doc or whatever, why can't it run on a server too?

Dave: Well, yeah. We were just saying before the show, we have WordPress. We have WordPress and we're using Gulp locally. One of our collisions we had was on CSS, right?

Chris: Yeah.

Dave: Oh, crap. Our CSS files are colliding. We know how to do that. We know, okay, let's not do the commit. Okay, now we'll just have to go to the website, and we'll have to add a build process in here. There are ways to do that, but wouldn't it be cool if you were just like, "Cool. Go into my WordPress build and then I just edit the block interface for how to build my website. Then it's done."

You go into Netlify and they give you a little command. They're like, "What commands do you want to run to build your website?" You're like, NPM run build or whatever. It would just be cool if you could--I don't know--just kind of visually program this wherever you go. That would be my dream in 2020.

Chris: It seems a little inevitable, especially in a five- to ten-year timeframe because it is true that we're just doing the same things. Process my code in this way. Optimize my assets in this way. Put my files in this place. Move my files from this place to this place. Run this special action that is unique to my site. It's all pretty similar.

Dave: Yeah, and if this is what programming is, can we just make it easier instead of the stupid way where, like, if you miss a semicolon, it doesn't work at all?

Chris: Mm-hmm.

Dave: Can we just do it a better way? I don't know. That's all I'm asking for - one day.

Chris: That was fun to think about. Yeah, one day, perhaps. Make it for Windows first and make Dave happy.

Dave: Yeah, make it for Windows.

[Laughter]

Dave: You chumps. I've got nothing over here. You all got your cool little screen recording apps. No, I'm good.

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Jetpack. That's JetPack.com. Jetpack is a plugin for your self-hosted WordPress site that, in a sense, connects it to WordPress.com and thus gives it all kinds of powers.

In fact, in the past, I've kind of described it as like a kitchen sink of new superpowers for your website including just really classically, obviously great stuff from a front-end development perspective like having your images CDN hosted and lazy-loaded. Just flip a switch and it's on and you're doing that, so all kinds of great stuff. I won't do the whole feature list here because it's just too much to cover in a small ad.

But there is a change this year in Jetpack that is worth getting excited about. If you hear me say, "Oh, it's a whole kitchen sink full of stuff," and you're like, "Gross. I don't want a whole kitchen sink," well, fine. I might argue against that a little bit because you just turn on what you want and leave off the other stuff. But whatever.

You might feel like you're paying for too much or something if you decide to opt for a paid plan on it. You can now, a la carte, perhaps one of the best features on Jetpack, which is the backups if you don't want anything else in Jetpack except for the backups, which is the best possible way to back up your site.

It backups your theme and all the files of your entire site and the media, all the images you have loaded and all that stuff, and the database. It is your whole site, all the backup stuff, super well done. In fact, if you go all the way and pro up all the way, it'll back up in real-time. It's not like yesterday's backup. It's like last-minute update, which is awesome. And it helps you roll back to that moment. If there are any problems at all with your site, you can just be like, oop, I want to roll back to that point in time. If that's all you care about, that's what you really need and want for your site, you got it with Jetpack and you can a la carte it. You don't have to opt-in for the kitchen sink plan if you don't want.

That's that, Jetpack.

[Banjo music stops]

Chris: Let's do a few questions from the people just to say that we got to some. I think there are some interesting ones in here this week. Of course, we encourage you to send in your questions from the website. Hopefully, we'll make that more obvious and easy in the new design because we love your questions.

Dave: Yeah. Hey, I'll go. Ben Gosho writes in, "I maintain a PHP site that uses a third-party API wrapper." It could be…. "As I understand it, the wrapper uses Guzzle 6 to make cURL calls to the API and return content. It works great. I use it to display three events in a small section towards the bottom of the home page. However, the other day, the API went down and, since my home page calls vendor-auto-load.php on line one, the entire page was blank. PHP was logging in error 500 and then just quitting," so like you're getting the white page of death, I guess, on the PHP, right? Or the system error, which is double suck and prefer the white page. Site down.

My question is this, "What type of fallback needs to be implemented and how, so that if the API goes down again it doesn't take down my entire site? I've used Nette PHP caching in the past but I don't think it solves the issue of reaching the endpoint or not."

Chris: It's just--

Dave: What do you do?

Chris: I hate to tell you, Ben. There's just kind of some bad coding happened here. What's happening is that a browser asks your server for the HTML for that website and it goes to your server and your server is like, "This is PHP. I'm going to execute this PHP," but part of this PHP that I'm executing has to ask another server for a Web request. It's going to go make that request, get it back, continue running that PHP, and then finish, generate that HTML and send it back.

Instead of, "Here, server," just being ready to respond to that request, it has to ask some other server for code first. Now, that's not the end of the world but, in that situation, all red flags have to be up and you have to say, "We cannot rely on that third-party server having stuff. We just can't. We can't because it's going to happen like this."

For speed and reliability reasons, we should make that request some other time. It can be the first request if it has to be. Ideally, you run it on some kind of cron job or something that hits that third-party server, gets what it needs, and then caches it on your own server so that, when you make that request that PHP is going to run and pull that from cache which you know is full because you can just kind of guarantee at some point something put something in that file and do it that way. You've got to have some kind of cache in the way.

Yeah. I don't know what Nette PHP caching is or whatever, but fine. Use that or save some stuff to a file or something. But you can't; you can't rely on making a third-party request.

We don't do this on the ShopTalk Show site, but I'll probably put it in the new version. CSS-Tricks does, for example. If you go to the homepage of CSS-Tricks, you see some jobs at the bottom from the job board. It's the very same job board that CodePen runs.

Although, on the CodePen side, what we do is a little jQuery. I think Dave just rewrote it in vanilla JavaScript because why not. Let's get rid of jQuery.

Dave: It was easy. It was easy.

Chris: [Laughter] When you load the jobs page on ShopTalk Show, JavaScript goes and asks that page for data, gets it, and puts all the jobs on the page because there's a JSON API that we can hit for that data. Now, that will never "white page of death" the ShopTalk Show site because it's happening client-side. If the request fails, you just won't see any jobs there. But at least it's not white page. It's still not ideal.

Dave: Yeah.

Chris: On the homepage of CSS-Tricks, I make the request for those jobs with PHP like you are, but I use a WordPress transience, so it makes the request, puts the data in WordPress transience, which is a cache, and then it pulls from that cache. If the request ever fails, the cache is still there. It just sits there.

Asking for a transient will never white the page. It'll just return nothing if it just happens to have nothing. It's just coded in that way.

When you're dealing with server-side code that way and, Dave, maybe you can expand or correct me if I'm wrong, you just can't have it rely on a third-party. Not to mention, it'll just be slow as hell.

Dave: Yeah, well, and what seems like a bummer is its ministry platform API, which I guess is probably some faith-based ministry manager. But it sounds like that code is hardcoded in there and, like, you require this auto-load.php and that is what makes the request.

One, I would file a bug with them. But then, yeah, you're going to need a cache. You're going to need some fault tolerance, like, if this fails then do this. Then return nothing.

Chris: Yeah.

Dave: Or just an empty array of events or groups or whatever it is. It looks like it has events and groups is kind of its two main tables. Or like you were saying, the cache is basically just always hit the file that I have on my server, and if there happens to be a newer file, we can go get that later or refresh that cache. We can always fall back to this file I have on my server. That's probably what I would -- I mean I think that's what you're going to have to do.

You could always make the endpoint. If you can't modify the source, like this is a package that you don't have any control over, then that's one thing. You basically just need to, like, have an if statement where you simulate an empty event. But if you don't have control over that, like the auto-load.php is just failing, then -- gosh, what do you do?

Chris: Are you blaming this on the--? They didn't even write this fetch call. Their API wrapper should have had fault tolerance built into it.

Dave: Yeah, I'm wondering if it's the level is one level deeper than their own code. If it's your own code, you can control that. You need to do your best. But if it's not, then what I would probably do is spin out whatever page.php, events.php into its own page and then make a call to that page from a static page, just like we're doing with the ShopTalk Show, but you're hitting your own fake API. Go hit that and then, if it's a 500 or from your own server, then just gracefully handle it however, like, "We're having troubles," blah-blah-blah. I would -- yeah, I don't know.

Chris: Two final thoughts here: one is, just do it with JavaScript. All you're trying to do is show three events at the bottom of your page. Just snag them with JavaScript and throw them in a template.

Dave: Yeah.

Chris: And/or is it any surprise that people are so into JAMstack? With a JAMstack build, you do this at build time. Then you could just run it every day or run it like Phil Oxworth, literally every second. [Laughter] Don't do that.

Dave: It would be worth--

Chris: [Laughter]

Dave: It'd be worth whatever if I just logged into my computer. Crap. You can probably configure the robot on your phone, who shall not be named. [Laughter] You can probably configure that to go do a Netlify build for you.

Chris: I know. I know. I use it. I literally use a Zapier to rebuild the conferences website. I just do it once a day so that the dates are right on the site.

Dave: Yeah.

Chris: The point is, in a JAMstack like setup, you can make this call to whatever API has these events at build time.

Dave: Yeah.

Chris: You run it every day and the events…. Then, like remember how I started this answer? When your browser makes a request for this website and the HTML comes back, the server is just like, "Here you go." It's already got it.

Dave: Already got it.

Chris: It makes no network request. It will be ten times faster.

Dave: Yeah. Yeah, I mean you could make my-events.netlify.com and just have it just hit your own little private endpoint.

Chris: Oh, I love that.

Dave: Save it. You could just….

Chris: I want to see more people use Netlify for little bits and pieces like that. You don't have to rebuild your whole site. You just make it do one dumb little job. Your own little API. Build your own little service that has my-events.json.com and it puts it on your server.

Dave: You mean like build your own podcast feed just for a secret set of MP3s you got?

Chris: Yeah. [Laughter]

Dave: Why? Why? I don't know who would do that. Who would do that?

Chris: Oh, that's hilarious.

Dave: Who would do that?

Chris: All right, here's a quick one. Taj writes in, "I work for a digital marketing company." It looks like it's about half and half SEO specialists and Web designers. "We're looking to redo one of our sites. We're going back and forth about platforms. We're on WordPress right now because the SEO people like it. It's easy to edit content, optimize pages," yadda-yadda.

"The Web designers don't like it because they feel like most of the themes are very cookie-cutter and they feel like they have little control over the look and feel of the site. Is there a better platform which has the ease of WordPress for posting and editing content but gives designers more control over the look and feel of the site?"

Now, I would of course just hit everyone with a shovel on their head with this and saying that WordPress absolutely don't care about the look and feel of your site. You can do whatever you want. We're doing some crazy nonsense with the ShopTalk rebuild.

Dave: It is kooky.

Chris: Yeah. [Laughter]

Dave: It is out there. [Laughter]

Chris: CSS-Trick is WordPress. You can do whatever you want in there. I don't know what your Web designers are talking about. WordPress does not enforce you to do anything with it. You can go as crazy as you want in there.

Now, I get a lot of people do use themes. Fine. If there's no talent at your company for editing WordPress themes--that's not a slight. It's just that different people have different abilities--then I can understand. But I don't know what you mean. I don't know what the skill level is of someone who feels like they have complete control over the look and feel of a site in one CMS but not another. They must, at least in their head somewhere, know that, like, "I could control this. I just don't have that."

If somebody threw a Drupal site at me and said, "Chris, please design this beautifully," I'd be like, "I know that I can. I have no Drupal experience, so it's going to be a little bit of a curveball weirdo week of learning curve for me, but I know that Drupal doesn't tell me what I can and can't do with the front of the site.

Dave: Right. It's going to be hard to get SEO folks off of WordPress. I'll just say that straight up because Yoast and stuff like that is so critical and so easy.

Chris: Yeah. I think people -- I don't like how it fricken' updates every minute and it bugs you about all kinds of stuff. There's plenty of stuff that's obnoxious about Yoast, but it is also pretty nice, I think.

Dave: Yeah. Well, you've got to empathize. You've got to put on a different brain. It's like, what's important to them? Oh, descriptions and keywords is the most important. Getting a little green checkmark that you have been indexed and stuff like that, those are very important features.

I will say … last year did a couple of Craft CMS stuff.

Chris: Yeah.

Dave: I would super recommend it. It has a pretty good SEO….

Chris: Oh, yeah.

Dave: But you know, re-platforming sucks. [Laughter] Make sure you're good. Prototype it. Make sure everyone is comfortable or whatever. I wouldn't do it just to do it. You could probably spend more time--whatever--beefing up WordPress theme skills. It's sort of like, yeah, I think I would work with your designers and maybe solve the cookie-cutter theme thing. Figure out how to break out of that would be my--

That said, I can smell a WordPress page. I know what they smell like, so there's a vibe. Drupal pages have a small.

Chris: [Laughter]

Dave: Anyway, I like Craft. Craft is good and clients tend to like it, so you could check that out. It's not going to have all the SEO tooling but you could prototype with, like, Netlify in a static site like Gatsby, Jekyll, 11ty, or something like that with Netlify CMS. I would recommend that, too. Just be like, "Is this acceptable to everybody?"

Chris: Yeah, it's cool. I've been to that open authoring thing … not to take it too far, but I'm going to put it on the conferences site I have because one thing that's neat about it is that, like, I have four conferences on my to-do list that I've got to add to the site that runs Netlify CMS. I don't have to write a single line of code. I go put /admin at the end of the URL. I log in. I add them all. That's great, but what if you could do that? What if Dave could do that? I didn't even invite Dave to do that, but he could because I'd just turn on this open authoring feature. When Dave adds the conference, it becomes a PR for me in GitHub to do it. That feels like a little ad for Netlify, but I feel like I'm a fricken' walking ad for Netlify, so sorry.

Dave: It's fine if they want to pay me to be an ad for Netlify. [Laughter]

Yeah, so I mean, prototype it out because I don't think that's -- a mix of SEO and Web designers, you've got to make sure the tools you use work for your company, in my opinion.

All right. The next question. Do you want to do one more here?

Chris: I'd love to. This is a good one.

Dave: James Hamon writes in, "How would you recommend someone start getting into Web components?" Any ideas there?

Chris: I don't know. [Loud exhale] This is just a bees' nest, isn't it? Here's a way to get it started.

Dave: This is a very 2020 question.

Chris: Yeah.

Dave: This is such a 2020 question.

Chris: Yeah, I feel like they're warming up to Web components again because--whatever--they're framework agnostic and yadda-yadda, but I still don't think you're going to be like, "Wow. I'm going to build this big production app. I'm just going to use all Web components because, for example, Web components don't help you with state.

What are you going to use for state management? I don't know. You're going to have to pick something. I don't understand how that operates, in a way.

That seems like such a big thing in my brain and maybe it's not, but I can't use Web components because it doesn't have the crap I need. But it does lighter stuff than that. For example, there's this great YouTube embed that Paul Irish put out: Lite YouTube Embed. There were lots of people who were playing with this idea, but Paul just made it a Web component, shipped it on GitHub, and anybody can use it.

It's kind of a great example of something that you could just use anywhere, including on your dang React site if you wanted to. It just encapsulates a small bit of functionality that totally makes sense. Instead of embedding an iFrame straightaway on your site like YouTube does, which is over two megabytes, no joke, of stuff that downloads to put a YouTube iFrame on your site, it puts a lightweight image there instead and a play button. Functionally, it's the same exact thing. You play the play button, the video loads, which then is in an iFrame, and plays the video.

That means the loading of the page is like 50 times faster because it's just cool, right? What a perfect little idea for a Web component. It doesn't matter what framework you use. It's just a nice API.

Dave: Yeah. No, I mean Paul says it renders 224 times faster than the normal YouTube embed, so there you go. It'll play.

Chris: Third-party Web component is a way for you to dip your toe.

Dave: There's a Lite Vimeo, too, it looks like somebody has. Somebody also made one where the play button is included. I think Paul -- they have a div where you have a play button and gets all the ARIA, I think.

Anyway, what I was going to say is I made a website called Awesome Standalones or it's on my GitHub, davatron5000/awesome-standalones. This was based on that blog post about accordion and details or whatever. Just the idea here is, wouldn't it be cool, a list of Web components? Not every Web component ever, but just things you can copy a URL and import into your project today.

That's what it is and that's kind of how we're defining standalones. There's really some bad nuance happening. Standalones is a terrible name, but in the comments. I think people want to, like--

It's not clear what standalone is, what that means, but it's just this idea of almost a component I can use. It does not attach to a framework, a design system, or whatever. Can I just use it?

Chris: Yeah.

Dave: Yeah. But if you want to start writing them, I recommend LitElement, getting into that. There's LitHTML, which LitElement uses, but LitElement, if you're coming from a React world, it's probably the easiest way to get a feel for how things are, so I would recommend that. It's a pretty good situation. I've written a few things in Lit and it's just like, "Oh, okay. It just works."

Chris: Yeah.

Dave: I can write it in a CodePen too.

Chris: If you had state management, what Lit does, because you give Lit a template with a template literal, which is a very nice way to make a little chunk of HTML, isn't it? God, I love template literals.

Dave: Yeah, and I'm not a pro here. Some of this, the component level state is just handled itself, sort of, you know. It's like you just pass, update a prop and it's like, "Oh, the prop updated. Okay. Cool. I'll just update it myself." You do that through normal JavaScript. You don't have to commit to a store or set state or something like that.

That said, if you wanted something interesting, you could use Haunted [laughter] or JS hooks. Haunted is a thing that goes. It's React hooks for Web components. There are some pretty good examples of that being used with Lit or Hyper HTML, so pretty cool. You stay in a component level way like that, if you don't like that.

But then what do you do if it's like you need a global store. I don't know. You can maybe use OmniStore or something from developit, Jason Miller from Preact.

Chris: Yeah.

Dave: If you wanted, but that's -- yeah, I mean--

Chris: I think the magic of it is that, let's say you build all of your stuff with Lit, which are little tiny components and bigger and bigger and bigger and bigger. Let's say you're three components up. It's a pretty damn big component. Maybe it's your whole sidebar and you change a little data on it. Well, if you're just winging it, the whole sidebar is going to re-render. You're going to go dot enter HTML equals this whole new template, and that's not an acceptable performance situation in most cases.

What Lit does, I don't know if it's a virtual DOM or what it is, but it knows, "Oh, only just this little bit of data change. I'm intelligent enough to go change just the little chunk of the DOM tree that needs to be changed," just like React does. It has that ability baked into it. It's just templating with smart updating. It doesn't actually help you manage the state, but if you are managing your state in some other way, then cool.

Dave: Yeah. It's not virtual DOM like Svelte and Lit don't use that but, yeah, it'll create a document fragment, basically, or a template fragment or something. Yeah, it just intelligently knows, like, "Oh, that updated. Okay, I'll go update just the value. I'll use the same template, but I'll just spit out the value correctly." It's weird. I don't know. it's smart and it's very lightweight.

Chris: Yeah.

Dave: I'm curious where this goes, but you use this. You use Haunted. Then you use OmniStore to put something. But, congratulations, you just made your own Frankenframework that no one else uses. [Laughter] That's not good either.

Chris: Right, right. Probably use--

Dave: You just kind of made this weird--

Chris: --Svelte.

Dave: Right. I would just use Vue, to be honest. But that said, I don't know. I like Vue quite a bit, as I've said before. I built a couple apps.

I don't know. I'm getting flash of handlebar templates. Does that make sense? I don't even know how that's possible, but I'll pull up an app I'm working on, on a phone or a slow phone or something, and just ever so briefly I'll just see a little curly brace, you know, curly brace template or whatever while it's mounting itself or figuring itself out. I'm like, "Ooh, I do not like that whatsoever." I'm sure there's a way around it, but it's just aborable.

Chris: What would you--? Like this is a Dave -- has it been a minute since you've had to write any PHP or do you dabble?

Dave: Oh, yeah. I'm not good at PHP anymore.

[Laughter]

Dave: I think I was working on the ShopTalk site because it's in WordPress or whatever.

Chris: Yeah, and we've had to write a little bit of PHP to get it done, but not too much.

Dave: I was trying to do something and it just was like, "Nope. You did not even do it."

Chris: I have a -- a situation came up where I needed to do some templating. I'm so used to working in templates. It's starting to bug me a little bit about working in WordPress.

Let's say I do a new design a year from now for CSS-Tricks. It's somewhat likely, you know. I want to write it in real components.

Dave: Yeah.

Chris: I'm going to be looking into Forest. I can't even remember. There are some true--

Dave: Twig.

Chris: Well, Twig is like the--

Dave: Offshoot.

Chris: Twig is just a PHP templating language, but there are some frameworks that use it on top of it that are like, "You can do kind of like some MVC stuff for WordPress." That appeals to me because I want to work in true components. But, hey, maybe I'll just do Gatsby, or maybe I'll just use Vue something and actually just make them JavaScript components.

Anyway, that's neither here nor there. The idea is that I needed a template right now. I needed a little template. Basically, I have this advertising partner. They're not sponsoring this show, but we know them. It's Mark and whatever in Minneapolis, Frontend Masters. Great. Great partner, right?

Dave: Mm-hmm.

Chris: They're going to be doing some advertising on CSS-Tricks this year. I don't have any other real advertising partner or learning partner like that, so I'm just going to tell everybody, "Do you want to learn more about this topic? Go learn it on Frontend Masters." It's going to be a cool partnership. I dig it.

One of the ways that I'm put together for them, I'm like, this is what we'll do. If an article has a tag, React, then I'll show an ad for Frontend Masters that's about React and Frontend Masters and what they have on Frontend Masters. If it has a tag, Vue, we'll send them to the Vue course. If it has a tag, Webpack, we'll send them to a Webpack course. We've got not quite 100. There are groups of them, but it'll be a lot of these customized templates that all have different HTML because they have different images. They have different headlines. They have different URLs, which, to me, is a little React component or Vue component or anything else.

What is the manifestation of a component with different data in PHP? Well, a little Twig thing, right? But you don't have Twig in WordPress. You could probably find something to add it, but I was like, "I don't want--" this is just one little thing. I don't want to add a whole templating language for that. What are the options?

You make a function that just returns some HTML. You pass the data to the function. But then how do you write that HTML that isn't obnoxious? There's no template literals in PHP? You have to write this string concatenation garbage, you know. But they have this thing that's a little bit like template literals called Here Doc that's like these weird three angle bracket things in the PHP syntax.

Dave: Okay. Yeah, yeah.

Chris: It's a little bit like template literals because then you can just use dollar sign variables within it. I have that going and I think it's an okay system, actually. You know? It's just a PHP function that returns a chunk of HTML that plops these variables into it so I can call that function with the variables.

I'll tell you. Even calling the function with long strings of where the image is hosted because I'll throw the images on Cloudinary and then use that long URL for the images. Then a title and then a chunk of HTML as parameters makes the call to the function really gross code.

Dave: Yeah.

Chris: You know what I mean?

Dave: It starts getting rowdy. Yeah.

Chris: Ugh. So, I just haven't solved that. It solved the problem. I'm doing it. It works. It's in production. It's the whole thing. But the way that it's coded is not super my favorite, but it's an opportunity to grow as a developer and figure out what the heck to do here.

Dave: Yeah. You can also do the import a partial or whatever, but it's different, right?

Chris: Yeah, and then you can't pass a partial locals in PHP. You have to set them.

Dave: Oh.

Chris: You can kind of because you just set them as a global variable and then the partial uses that global. Then you just reset the globals. That's kind of gnarly too.

Dave: Yeah.

Chris: Isn't that gnarly?

Dave: Right. The scope is defined in the parent so, yeah, that's rough. [Laughter] That's rough, but oh well. No, I definitely like working on this ShopTalk redesign. It's like, "Oh, man. I'm so used to some kind of component system," and we don't really have one. And so, it's like, okay, how do I do it here? It's a little different. But anyway, we'll figure it out, I'm sure. It's just figuring it out.

All right, we are--

Chris: Out of time.

Dave: Right at the hour mark. We've got to power down. We do have a fun season here for you of the ShopTalk Show, the eighth season of ShopTalk. We did it, so thank you. Eighth or ninth? Have we been doing it? I forget. Cripes! I should know.

Chris: Well, we're coming up on Episode 400, which that's seven weeks away. Gosh willing, we'll launch our website at that time.

Dave: Yeah, so look forward to that. We really appreciate everything you all do for our show, sending in questions, telling people about it, subscribing in your podcatchers. We appreciate that. 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.

If there's something you want to hear about in 2020, ping us, @ShopTalkShow. We'll put in our show ideas list. We've got one a mile long, so we really appreciate y'all, again.

If you hate your job, head over to ShopTalkShow.com/jobs. Get a brand new one for the brand new year because people want to hire people like you.

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

Chris: ShopTalkShow.com.