Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about websites. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris. How are you?

Chris Coyier: I'm doing pretty good. Yeah. Yeah. We've got two special guests on today, both of which I believe we met through the ShopTalk Show Discord, right? Maybe we would have known each other in some other way, but certainly, that has solidified our relationships, wouldn't you say?

We have Andrew Walpole. Did I say it right? I'm sorry. I should have asked you before the show.

Andrew Walpole: You said it right. All good.

Chris: Oh! Andrew, it's your name .com. We'll put the links in there. You've got a blog kicking there and stuff. But your main thing in life, perhaps, is that you're the director of Web development at someplace called Traina, right? Which is an agency.

Andrew: That's right.

Chris: And so, we thought almost inevitably, during this show, we'll end up getting it that agency life thing a little bit.

Andrew: Oh. yeah.

Chris: Yeah. Then Alex Riviere. Hey, Alex. Did I do that one good?

Alex Riviere: Hello. Yeah. You got it perfect.

Chris: I'm so good. I think maybe when we met, you weren't at Traina yet and then became at Traina. Is that how that went down? Yeah.

Alex: Yeah, I've jumped around a couple of jobs the last couple of years, and so it's been interesting. [Laughter]

00:01:48

Dave: This is a Discord workplace bromance, you know.

Alex: Yeah.

Dave: [Laughter]

Andrew: It totally was. You know? I hired Alex straight from the Discord.

Alex: Yeah. Yeah.

Dave: There you go.

Chris: Nice.

Dave: Yeah. That works out. that's great.

Chris: Wow. That's cool. What is Traina, like, 30 people maybe? Am I in the ballpark?

Andrew: You got it. Yeah. Yeah, we're about 30. We are really more of a branding-first agency, but we've got--

Chris: Really?

Andrew: It's kind of interesting because we've got a really strong dev team, so small but strong, just five of us, and we knock out sites for all our clients who mostly come to us in the first place for branding, but we sort of surprise them in the end with, "Hey, here's a really good site."

Chris: Interesting! Branding like somebody is like, "I have a new chocolate," or something, "and we've got a name, but we need a logo. Help us tell the story." - all that kind of stuff. It's not necessarily, "I just need a website."

Andrew: Yeah. Even if you don't have a name, we do naming, so we have a full strategy team, and so exactly what you're saying. It might be a larger brand that has some new product that they're just like, "We know that engineering is going to build this box, and we don't know what to do with it when it's built."

Chris: [Laughter]

Andrew: We come in, and we strategize on what you need to do. Then we make it look pretty. Then we figure out how you need to launch digitally is really the big focus that our team has.

Then for smaller companies, too, we're not a huge agency - maybe yet - so, the primary branding of a company who is just either a bit outdated and needs to compete or you're a brand new, maybe well-funded, startup. It really ranges quite a bit, and it gives us some very interesting projects to work on.

Chris: I bet.

00:03:43

Alex: I am definitely surprised every time I hear about something that we're working on because it's always like -- it's very regularly a thing where I'm like, "Wait, we do that as well? What? What else do we do?"

[Laughter]

Alex: I'm relatively new to the company, and I'm still stunned every single time that I hear something that we're working on.

Dave: It's kind of funny. Naming, you'd think, like, "Oh, I name stuff all the time." But when you have to name a company, there's kind of some hoops. You know? Maybe just maybe a nuclear parts manufacturer in the state of Texas has the name you want and you can't use that or get a trademark on it because then you'll just be sued into the ground. That's a bad position for a small, budding company - as I've found out.

[Laughter]

Dave: Yeah, so you just can't do that stuff. Yeah.

Chris: Wow. Interesting. Yeah, so I think the agency stuff will show up as we continue to talk in this, but we're also, you know, ShopTalk Show is kind of a Web development kind of focused show, and that's what you two bring to the agency anyway. Not that you couldn't evolve. Maybe y'all will turn into the naming experts. I don't know. but for now, it's mostly Vue, right? [Laughter]

Alex: [Laughter]

00:05:05

Andrew: I mean we're across the board on platform. You asked us to come on, and I was like, "Uh... What are we going to talk about?" because our world, it spans such a wide gamut of things. I would say if you really want to draw a hard line, there's WordPress and not WordPress because you still get a lot of clients coming to you that's just like, "It's going to be WordPress," because they have a marketing manager and maybe that marketing manager is the main point of contact, and they are comfortable in that world, or their existing site is there, and you don't want to pull them out of their comfort zone, or they're not willing to be pulled out of that comfort zone, and that's okay. As long as it makes sense for what they're doing, I think it works fine.

We live pretty heartily in WordPress a lot of the time, but then what I'm really looking for when a new client comes on is, "Are you going to be the not WordPress client?" because I need at least a little bit of that in my life.

[Laughter]

Andrew: You know... For a couple of reasons. Yeah, I love doing Vue. If we can push somebody towards a Nuxt site, that's always a pleasure to build in. It's fast. You get up and running with the project quickly. You can iterate quickly. It's just a joy from a development perspective to do.

Then the other one is 11ty. We do a lot of 11ty sites, probably more. If somebody comes to me with a campaign, I'll be like, "How dynamic do you need this to be?" Because if you want a nice, fast, quick campaign site, 11ty just delivers the static site that you need, and it's been wonderful.

Chris: That's so interesting. How many pages until you reach for an 11ty? It's not dynamic. Even that is arbitrary, right? You could make it a little dynamic. It's not like 11ty demands that your site has no JavaScript - or whatever. You know it's made to build pages, right? If it's like three pages, then it's like, "Ah, well, why bother?" You know?

00:07:22

Andrew: I mean I've used it on one-page sites. There are a lot of different factors that come into play when you're working with a client where you just tend to get into survivalist mode where it's like, what's the unexpected thing the client is going to bring in the 11th hour?

Chris: Ah...

Andrew: You know?

Chris: Yeah.

Andrew: It's not their fault, but it's like the business -- there's a new business insight that has finally trickled down that just didn't get hit before that, "Oh, we need this in three languages." If it's in 11ty, I can just point it at a different JSON file with all my different language strings so quickly and easily, and it'll just generate off of one single template all the different language pages you need. Something like that, if you were doing it just full static hand-coded, you'd be in a little bit of trouble. You'd be in for a late night or something to get that going.

Alex: [Laughter]

Andrew: Try to just think about all those different things and get to know the clients really well so that you can kind of understand, hey, what might you need? Maybe I don't have to put a lot of effort into making sure that will be available but, hey, if it happens, we can make it work.

Chris: It's almost like a build process as defense. I love that because sometimes it's talked about or I think there's some momentum towards thinking, like, "Oh, build processes are so finicky," right? There's like this good chance that I'm building a site, I come back to it a month later, and it just doesn't run locally because - I don't know - maybe I changed my Node version or who knows what other kind of little crap can go wrong.

Dave: Chokidar 2.1.3. It's always Chokidar 2.1.3. [Laughter]

Chris: I'm afraid it's Nokogiri (in my life).

Dave: Oh, yeah. Okay. Yeah.

Chris: Nokogiri is the problem.

00:09:16

Alex: We had that the other day. Our Sass on something wasn't compiling, and I spent hours going, "Why isn't this working?" and trying to fix it. Turns out it just needed to update our Sass version, and it was--

Dave: Whoof.

Chris: Yeah.

Alex: It fixed the whole thing. There was an actual bug in Sass.

Dave: I had the opposite. I updated Sass, and it exploded.

[Laughter]

Chris: Fun.

Dave: Sass 6 to 7 was a bad jump for my situation but yeah.

Chris: Well, but sometimes that's not defensive. Sometimes doing that causes you more grief because then you have to have Alex come in and look at your stupid process because it's all broken.

Alex: [Laughter]

Chris: But it's also defensive, like if you have no build process, then you're not ready for curveballs because chances are a curveball is going to require some kind of something [laughter] that gets thrown in the overall bucket of a tool that needs to get put into a toolchain.

Dave: I had a client who was like, "Oh, it's just a simple site, a simple site, five pages." You know? I'm like, "Perfect! Let's go."

Oh, BTW, we collect quotes and we put them on there. There are a thousand testimonials. You know? [Laughter]

Chris: [Laughter]

Dave: "We use them all," and I was just like, "Huh?!" You know? That's a lot more than I intended and had budgeted for. Then 11ty can just chew through it. It just says, "Okay, yeah. A thousand whatever - I'll do it. Just send me a spreadsheet." Literally, just export. Save as CSV. You know?

Chris: Yeah. Then what would you do? Can you Excel to MD?

Dave: Yeah. Yeah, and just chew through it. You just treat it as data. Put it in the data folder as a CSV, and then you're off.

Chris: Oh... 11ty can read CSVs? Oh, wow. I didn't know. Who knew? Not me.

Dave: The business world knows. Those of us who have done client services know, Chris.

[Laughter]

Dave: We've done dirty things. We've done inappropriate, very big crimes.

Alex: Yes.

Chris: Okay. Well, that's pretty interesting. Yeah, a lot of big names of the stuff that you work on, too. Vue is a pleasure for both of you. That's pretty good alignment. I think that's very funny that it's like, "All right. I'll do WordPress if I have to," kind of thing. Admitting that it sometimes is kind of the right answer, but it doesn't mean I love it. You know? Or it doesn't mean that it's a pleasure to work in. Certainly, you don't get the hot module reloading and all those niceties.

00:11:50

Alex: Well, actually, a fun fact. We have a very nice WordPress setup. When I showed up, I was like, "Ugh. Okay. WordPress. Let me get into this."

Chris: Yeah.

Alex: They showed me their WordPress setup, and I got a repo. Downloaded it. In five minutes, I had staging on my machine.

Dave: Oh.

Chris: Mm-hmm.

Alex: Yeah.

Chris: Nice.

Alex: I was super-impressed. I was like, "There are some improvements we can make here, but this is really nice." We have a really good setup for WordPress, which I'm always stunned by it. It's always like, "Yeah, this is actually really nice to work in."

Chris: Is it one of those Twig? Does it have a bunch of opinionated stuff like that?

Alex: We just added Twig, actually. [Laughter]

Chris: Did you really?

Dave: Hey, that's okay.

Andrew: We're dipping our toes into Twig and Timber, which I think makes it really easy. I think I tried to get Twig going a couple of times in the past and sort of failed and yeeted out of that and said, "Another day."

Chris: Mm-hmm.

Andrew: But with Timber, which is a plugin for WordPress that adds Twig pretty nicely, and then there's a second plugin that is pretty nice.

It's funny -- just sort of as an aside -- if you really dig into it, Timber is -- I relate to it so much because you go, and you sort of figure out the story of how this plugin came to be and was built. It's just another agency needed to make their process faster and better and more efficient, and so they built this plugin and made it open. Those were the really nice moments, I think, just as a developer. It's like, "Yeah, you're making money with your clients, and you're producing that product. But then to connect with the broader audience of everyone."

You can write about what you're doing and share some insights there, or you can write some code and make it public and share it with everyone else to gain some proficiencies. That's exactly what we're seeing right now, dipping our toes into it. It's such a--

I am so overlooking at PHP code, like PHP is great. it's a good language, but I just don't like to look at it. It makes me ill to look at it for too long. Switching over to Twig (over the last couple of months) has been really nice.

Chris: Is the main point, you would say, that it gives all of your view files a controller so that they're no longer just one? You don't just make a single .php. There's a single controller that does all your PHP stuff, and then it really separates it from the view. It's like there's no logic in the view anymore. Or is that... I don't know?

Andrew: I would say that, yeah, it's part of that. I think the other piece, too, is we're really bought into ACF blocks, so Advanced Custom Fields blocks. We have not taken the plunge into full React-based blocks. There's a lot of overhead, and I think the product that you're left with is a little tough to deal with. So, we've very heavily leaned on them. What this plugin does is it lets you add.

It really just names a Twig file inside of a specific folder and you've got an ACF block. You can register it through a comment. It's almost like a single file component type setup. That was really the sell for me on that.

Dave: The Twig gives you a liquid-y syntax, right? Instead of PHP stuff.

Alex: Yeah.

Andrew: Yes.

Dave: You're just kind of dealing with hopefully pure data, right? You're not, like, big, old - whatever - string manipulation functions inside your post template, right?

00:15:46

Alex: Yeah. There's some stuff that we're picking up on. Twig has the ability to make macros, which is sort of like writing a function or a composable, reusable bit of HTML, essentially, where you can pass in parameters and then reuse it and import it all over the place. And so, we're experimenting with those as well because we're still trying to figure out, like, okay, what is the best workflow for this?

Chris: That's nice.

Alex: And so, you can sort of write a function in Twig and then import it into another Twig, and then just be like, "Oh, display this bit of stuff here," and it's really--

Chris: Just that sounds worth it.

Alex: Yeah.

Chris: I always have a folder called "Parts" in my WordPress theme, which are just reusable little things like, "Here's where we spit out the author and the date," and we use that a lot, so it'll be called authoranddate.php. But PHP, generally, that's not a function. That's just a file.

Andrew: Right.

Chris: If you want to pass stuff to it, you just set globals and hope that where you imported it just works. It's much more satisfying passing actual values to something. I don't know. Almost emotionally, as a developer, like, "I'm giving you data. Please use the data that I'm giving you." It feels better.

I'm so surprised, though, that you haven't. Another route you all could take is just to embrace the Vue thing even in WordPress land. Be like, "Nope. Screw it. We're going to still build Nuxt sites, but every WordPress we deal with, we're going to install the GraphQL plugin or just use Rest and just pluck data from WordPress that way and never build in PHP." You know?

Alex: We've talked about it some. I know that much.

00:17:35

Andrew: Yeah. I think quite a bit. I think we're on -- from my perspective, I would like to be on the pathway to that. I think there are some hurdles that we keep hitting that we sort of want to try to cleverly solve. Then I think we've also done some things that are a little bit intermediary, which we've really embraced Petite Vue quite a bit, and it is a great add-on to WordPress for interactive bits. I think we've got a decent pattern for doing progressive enhancement with it where, you know, let WordPress render the first version of it, but now I need to make it interactive, so hand it off to Petite Vue to almost recreate it but make it interactive. That works out really nicely.

I think, ultimately, though, what I would really love to see, and I don't think this is on anyone's to-do list, I would love it to be, but you know, make PHP render Vue components. I would love a PHP SSR of per view.

Dave: Mm-hmm.

Andrew: It would unlock so much. I think it would be mutually beneficial. Not just beneficial to WordPress people but beneficial to Vue in that it would really make it stand out in another angle. I think you see most of the main frameworks really just targeting Node SSR as it becomes more popular to have that capability. But there's still a big audience out there doing PHP stuff, whether they like it or not.

Dave: Yeah. I was going to say I think it's really interesting. You know there's a lot. I guess all the hacker news heroes are these mega-specialists. They get... I'm like - whatever - writing Bun, which is based on Zig. You know?

[Laughter]

Dave: Everyone knows that.

[Laughter]

Dave: I'm making Bun based on Zig. And everyone is like, "Dang! I love Zig. Wish I would have thought of that."

[Laughter] I feel like there's kind of this subtle slight or people don't appreciate the generalist skills of somebody in, like, an agency where it's like, "Hey, this week, you need to know WordPress. Next week, you've got to know 11ty really well." Then, "Okay, this has a Vue front-end, and that one is actually a React front-end," and so you're just kind of in this--

Jack of all trades sounds like a bad thing, but it's more like you just have such a broad exposure to stuff. You're kind of reinventing yourself every couple few projects. You know? I think that's really cool. I don't know. I just think it's undervalued in our industry that developers can have broad skill sets.

Chris: Does it make you tough? Does it make you strong? I always thought it's kind of cool. It's like, "Oh, you've got exposure to so many different technologies. I definitely want to work with you." Or I definitely would think of that as a plus on your resume and be like, "Look at what they've seen. That's amazing."

But you know. I don't know. Is it always that way or is there a world where they're like, "Yeah, but it also makes you not a deep, deep expert on any of it," or is that a lie?

00:21:02

Andrew: I think it makes you really resilient to the idea of being afraid to tackle problems. I think when are consistently changing mindsets and having to tackle new but very different problems, it gets you into a rhythm of kind of having to start from scratch. I think that builds up your resilience to saying yes or saying no, I guess, in the sense of somebody says, "Okay. We need to do this." All right. It just takes time. That's all. That's all I need to do. I can spend enough time, and it will work.

[Laughter]

Andrew: Then you just have to weigh, like, well, is that time equitable (from a couple of perspectives)? Yeah, I think it's really important to put yourself in a place to be tackling new, different things that are kind of scary because, if you keep solving the same problem over and over again, sure, you get really good at it. But I think there's a little bit of, like, muscle atrophy in understanding the whole landscape of everything.

Chris: Yeah. that's a complicated one.

Dave: Yeah. Is that hard? I feel like I kind of dealt with that. It was like, "Oh, cool. I get to do Rails again." Rails has changed in the five years or three years, two years, one year since I went to it last, and so, do you ever struggle with that? It's like you hop into a Craft CMS project today or something. Is it like, "What?!" Or is it like, "I know. I know this"? [Laughter]

What is it? This is Linux. I know this from Independence Day or whatever.

00:22:59

Alex: Yeah. It's one of those where I know, with new projects, there are a lot of me sitting and just reading code and going, like, "What is this? Where did this function come from? Who wrote that? Where did this... what?"

Dave: Is that because it's not code you wrote or your agency wrote, or possibly?

Alex: Yeah. It sort of depends on the code base. My first job was at a different Web agency that I had a lot of code bases that were just like, "I need a new feature on my website." "Well, what is your website written in?" "It's written in website." "Uh... okay."

Dave: [Laughter]

Alex: And they would hand it off to me, and I would have to figure out what was happening and how to add things to it. And so, I can dig through and figure out how code works, and so that's how my brain works.

Coming into a new system, as long as it isn't too magical and it has some documentation somewhere, I tend to be able to just figure it out. But yeah, there's a lot of just digging in code (for me) where I'm like, "Okay, we're calling this thing. Where is that? Did we write that? Is that from a plugin? Is that part of the core system? Is this a PHP thing I just don't know about? What is it?"

Chris: [Laughter]

Dave: You kind of have to build a mental model of how. You're kind of reverse engineering, but you're inside, so it's not quite reverse, but you're rebuilding a mental model of how it all comes together.

Alex: Yeah. When I go into a codebase, I go figure out where all the bathrooms are first so that I know where I need to. When I need to go somewhere, I know where to.

[Laughter]

Dave: That's a very awesome analogy.

[Laughter]

Dave: Wow! I hadn't heard that one. That's very good because--

Alex: What do you do the first day on a job? You figure out where the bathroom is. That's your job that day is figuring out where the bathroom is.

Dave: Fair point. I'm going to tell my kids that when they go back to school.

[Laughter]

00:25:01

Chris: Do you have an IDE that helps you? That's what it makes me think about in my little journey of learning Go. That's all I do now.

There's nothing you can't hover over, man. You can hover over anything and it will tell you exactly what it is, whereas Ruby does not have that luxury, I'm afraid.

Alex: I am a big JetBrains person. I really love all of their stuff. Everybody else at the company, I think, uses VS Code. No, that's not true. We have some other people who are using Atom, I think, still. I know that I'm a big JetBrains person, so PHP Storm.

Chris: Nice. Which is known for that.

Alex: Yeah.

Dave: Yeah. They built their fortunes on hovering and clicking through.

Alex: ...every dollar.

Dave: Yeah.

00:25:47

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Notion. You can get started for free at notion.com/shoptalk.

My favorite way to use Notion is to have everybody on your team use Notion to organize the work you do, talk about the work you do, get everybody on the same page, and having Notion open because that is the home base for the business that you're running.

A small example, we use it here at ShopTalk Show to manage our show calendar. That's one of the things that we have in our Notion. It's a database, you'd call it. Don't be dissuaded by that term. It's really not that complicated.

It's just kind of like a beefed-up Excel spreadsheet, in a way. I'm looking at it right now in table view, and there's a list of dates. What are the shows that we're doing dropping? What's the number of the show? Who is on the show? Who are the sponsors for the show? What's the status of the show? Is it upcoming? Is it being recorded but not edited yet? Is it being edited right now? All that information is in our Notion.

We also use the Notion API so that you, dear listener, can write in a question to ShopTalk Show. It uses their API and pipes that question right into an incoming questions database in Notion. We can drag those questions onto the shows that we're about to do. Now, if that all makes sense to you, you could imagine that is a very adaptable thing for any kind of business flow.

Now, I described the table view of this database. That same data can be viewed in different ways. With a click of a button, I can turn it into calendar view and be looking at that same data but as a calendar. Or I could view it as Kanban cards and look at the status of all the different shows in different columns, which shows are in which position.

That ability to look at data in Notion in different views and have that be so easy to filter and sort and arrange is the most powerful thing in Notion, I think. Congrats on the new status thing, too. That's a new-ish feature in Notion that's really powerful and cool. Of course, we're making use of all over the place.

That's notion.com/shoptalk to start for free and take the first step towards organized productive work and life today.

[Banjo music stops]

00:28:05

Dave: Okay. Here's my question. You're an agency. You've mentioned y'all are building custom tooling and starter projects and stuff like that. Why do that? Because, hey, you can pass that cost onto the client and make some money.

[Laughter]

Dave: What's the incentive to build tooling?

Andrew: Well, I would say automatically because of the nature of our agency, most of our projects are from scratch, ground up, brand new, fully redesigned sites. You know every once in a while when a new client comes on, they might need some work done on their existing site, sort of like preliminary to us redesigning and rebuilding a new one. But for the most part, we're building everything from the ground up, and so I think the way that we approach our tooling is very much how much of the boilerplate stuff can we get out of the way so that when it is time to focus on building the site, which is going to have all brand new components, all brand new CSS.

We don't do a lot of reusing front-end code. A little bit here and there. Some interactive stuff, for sure. But we want to be able to focus on the custom-ness of the thing that lands in front of us, and so as much that we can get out of the way in our build tooling and make easy and make quick is really a big gain for us.

Alex: For me, some of the tooling stuff, I'll be honest, I'm lazy. If I write something twice, I'm like, "Okay, we've done this twice. We might do it again. Let's just go ahead and have a way to do this. Let's figure out what the way to do this is, and then I don't have to write it again because I'm tired of writing it from scratch."

Chris: Look at you being all practical waiting for twice, though. That's cool. That's grown-up stuff right there.

00:30:06

Dave: Yeah. Have you considered just imagining it and thinking you'll use it a bunch, and then overengineering a solution? You didn't consider that? [Laughter]

Alex: No. No. I always wait. It used to be when I was at -- I used to work doing enterprise software and stuff like that, and my role there was always the third time, you write the abstraction because if you've done it twice, then the third time, it is a pattern at that point. I've sort of upgraded that to two for here.

But a lot of times it's that visually there's a pattern happening. The one that I did recently was we have--

You've all experienced this, I'm sure. You scroll down a page and the header nav at the top scrolls up off of the page. Then when you scroll back up a little bit, it pops down from the top. Right?

Dave: Yeah.

Chris: Classic.

Alex: Yeah. Yeah, and I did that once. Then I was like, "Okay, cool. Did that." Then the second time that I did it, I went, "Nope. This is going to turn into a function," and so I made a JavaScript function that we can just drop into anything and then use it and be like, "Listen to this. Call this function," and it'll do the thing because I was like, I am not. I am not rewriting this function every single time that we want to do this.

You apply a class, you remove a class, and that's it. Then the styling is what's unique, right? How do we style that? How do we do--? That's the part that is custom to the site, but the functionality of it is, oh, it's either there or not there. Put a class on it or don't, and then figure out what the styling is later.

And so, stuff like that, it's like I want tooling that it's like, "Okay, cool. We've figured out this problem elsewhere, so let's make sure that we have it available when we run into it again." Maybe we'll use it for a bit, and then maybe designs will change or the way that you use the Web will change, and you don't need it anymore, and it's still there. It's available to you if you need it, but at some point, maybe you get rid of it because it's like, "Yeah, that's not a pattern anymore." Yeah, always make it so that you can drop things in and take things out.

00:32:22

Chris: One of the things that's obnoxious about front-end right now is, as I think of that, and I'm like, "Oh, okay. So, there's some--"

Maybe you use data open equals true, and data open equals false - or something for that header to decide whether it's going to be visible or not. Maybe there are a couple of attributes because sometimes it's sticky and sometimes it's not - who knows.

But then you're like, okay, we're going to use this on a Svelte site or a React site or whatever (even though we promised we wouldn't talk about React). But what if React says, "Oh, but in that thing there's a hamburger menu," and I clicked it, and that's going to set state. And set state is going to decide that the component needs to be re-rendered, but you didn't write this little bar header thing with React in mind. It's just handling its class manipulation by itself.

So, when it re-renders, whether it does or doesn't have that class, React doesn't care. It's just going to put the default on there. Now you've written this component that works, but it doesn't jive with this other framework that I'm using. I think that sucks [laughter] sometimes, you know?

Alex: in those situations, you at least have the framework for, like, "Here's the logic. Check to see. Have we scrolled down? Have we scrolled up? Have we done this? Have we done that?"

Okay, cool. Instead of taking in two class names and applying those classes to an element, bring in a bit of state and then say, "Here's the current state of this thing and return Reactive objects," or whatever. You can still use that logic and then just change what the effect is, essentially.

Chris: I like that. I like that because you already learned it. What you're really getting out of your component is that you remember what APIs you even need and stuff.

Andrew: Mm-hmm.

Chris: In that case, isn't it like some kind of observer and whatever?

Alex: Yep.

Chris: If all of a sudden you're in a meeting and somebody is like, "How do you do that again?" you're not going to remember.

Alex: Yeah.

Chris: You're going to be like, "Oh, crap! It's that weird API that I only use once every two months.

Alex: Exactly.

Chris: Nope, you've already written it once, so it's basically a blog post.

Alex: Yeah, it's basically a blog post.

Chris: That's just free--

Alex: I just keep it in a GitHub repo. [Laughter]

Chris: [Laughter]

Dave: I feel like I'm an expert at intersection observer. Like three times a year, I'm the most knowledgeable person. Maybe it's every other year, I'm just the most knowledgeable person about intersection observer.

Chris: It just disappears, man. It's not my favorite API, even though sometimes it is. You know? Sometimes you're like, "Wow! That's really clever." But the fact that it disappears from your head doesn't speak volumes to its API quality. You know?

00:35:13

Alex: My whole thing is you need to know what's available to you. You need to know what tools you have available. Know the intersection observer exists and that there's documentation on it. Then you can go read that documentation and become an expert - temporarily - as long as you need it. Then once you're done, get rid of it. Other things to think about.

Dave: Is that kind of like, again, maybe touching on being a generalist, or is this kind of like use the platform sort of speech? I don't know. [Laughter]

Your stream, you have the Twitch stream, and you do terrible things.

Alex: I do terrible things.

Dave: You do terrible things with code. But I think one thing you always do is try to, like, "Hey, actually, there is an API for this." I feel like that's an Alex catchphrase.

Alex: Yeah.

Dave: And so, how do you memorize MDN or at least the chapter titles of MDN? How do you stay abreast?

Alex: Oh, gees. Well, honestly, for a long time, getting up to speed, I listened to a lot of podcasts. And so, it was just sort of like being inundated with, like, "Here are things that you should learn about!" and so it was just reading a lot of documentation.

Then this is the other thing that makes it easy for me to find documentation about things is that I am team no tabs.

Dave: Oh...

Alex: I close all my tabs regularly.

Dave: Wow.

Chris: Hmm...

Dave: Radical. [Laughter]

Alex: My whole thing is you don't need a link to get back to the thing. You just need to remember what it was you searched for to get to it, or you need to remember how to ask the question. And so, that's the biggest challenge, I think, for newer people is finding someone who can teach them the words they need to find the thing.

Chris: I love that.

Dave: That's funny because my friend Chase (growing up), [laughter] we'd always be like, "How do you know this stuff, dude?" I learned he is good at Google, and so he just knew how to do a Google query. I was like, "I'm going to be like that," and I learned enough to figure out how to get a good search term. Then I remembered those search terms.

00:37:32

Andrew: Yeah. I think that totally speaks back to being one of the benefits of being a generalist is you can throw it out of your brain, but the thing that will stick with you is that I did it. I once solved that problem. And so, then the next time it comes up, you're going to recall at least the amount that you need to get back to the solution you had. This path is a bit more beaten because I've done it once before or twice before.

I think that's the thing that I like to do maybe separate but related to work is follow all the new stuff that's coming down and then do it in a CodePen because that is step zero of establishing that, like putting it on your map and your radar is, like, I'm going to just try out this new thing. Maybe it's only supported in Canary or technical preview Safari, but just go try it, do it, or even just look at someone else's CodePen that has already done it and read the code. That is step zero for all of these new features that are coming.

Talking about that almost like defensiveness that we need to be doing right now because so many new things are about to hit. I was just looking at the release notes for Chrome 105. Good stuff. Container queries and :has is coming to Chrome. That's Chrome and Safari. So, now we've got to start inching it closer to the center of our radar as far as, okay, is it time to use this on a site? Then you want to be ready to use it in a production way when you make that decision, so you want to have at least a few instances of getting familiar with the API under your belt.

Dave: CodePen is - I don't know. This isn't an ad for CodePen. It's good. It's good enough.

Chris: Yes, it is.

[Laughter]

Dave: Once you have the CodePen, you have that because you don't always have the client project. The client project goes away. It gets handed off to various places and gets destroyed, frankly. It's just cool because that's yours. You learned that. You put it in CodePen. You now could reference that and recycle that.

I'm sure your sticky header -- what are you calling that? Showy-hidey? Scrolly-hidey?

Chris: It does have a name, doesn't it?

Alex: I might actually call it showy-hidey. I think it's trigger class on scroll - or something like that - is the name of the actual function.

Chris: Oh, look at you. Another adult move there naming it abstractly about what it's -- it has nothing to do with the fact that it's a header. It has something that changes classes when something happens.

Alex: Yep.

Chris: Uh, uh, I love it.

Dave: Not sticky header 1259BE? You didn't try that?

Alex: I think that was the first implementation was change on scrolly uppy-downy - or something like that. But then I was like, okay, no, let's--

Dave: But I'm sure your scrolly uppy-downy, you weren't just like, "Let me just pull down main and just get to work," right? It was like you built it somewhere else, right?

Alex: Yeah. I feel like, yeah, there was a CodePen first, and then that CodePen moved over into the codebase, and then, on the second time that I saw it, I was like, "Okay, cool. Let's go get that code that we made before and now abstract it out into a thing that we can just drop in as a function." Yeah.

00:41:27

Andrew: Yeah. I think starting out, especially the WordPress sites, getting started can be really tough and it's a bit of a learned trigger for me is that if I sit for too long sort of dawdling and not getting into some sort of flow state in building what I need to build, I'll close it all down, and I'll jump into something like CodePen. Sometimes I'll just throw up a Vite really quick, a Vite site, like one of their vanilla templates if I need it to be a little bit more like show me the hints and all that stuff.

Get out of that... WordPress, it's like a big intersection of, like, okay, there's going to be dynamic content, so maybe I should go build that content model thing and name all the variables.

Okay. Now I've got to populate it with some dummy content. Now I've got to export some images from the design.

I haven't even written any code for this thing! Why don't I just use placeholder images and content? Let me just focus on the front-end HTML, CSS, and maybe there's some JavaScript. But usually, it's just the CSS.

I think isolating yourself to just writing HTML and CSS, it can just unlock productivity. You can just go, and it's important to get into that state.

Chris: Hmm...

Alex: Yeah, the number of times that I'm stuck on a thing and Andrew is like, "Just go do it in a CodePen," I'm like, "Yeah, you're right. Let me just go do it in a CodePen."

Dave: It's like the eat your vegetables. Yeah. No, that's -- I mean that's the same.

I have a half-written blog post, but I've been starting to think of code in terms of junctions, like interstate freeway junctions, and all the imports at the top of your JavaScript file are highways converging. Then your exports are things branching out. If there are a lot of junctions in a file, operating on that is very costly. It's hard. It's expensive. You're just like, "What's going on?"

It's just like one of those spaghetti junctions like in LA or something like that. It's just like this is a mess. This is ten freeways all coming together.

Like you were saying, instead of operating on the freeway, let's take a step back, figure out what we're doing, and come up with a really good plan for what I'm trying to achieve. Then that should just -- you can make a more isolated change.

Alex: Yeah, and it makes it easier to do it sort of in that space where you don't have all of the stuff because sometimes we've--

I've made some things recently where sometimes I've made it. Then I go throw it into WordPress and WordPress has some other stuff that's happening in it. That messes with the code that I did. If I had tried to develop in that, I never would have gotten anywhere because it would have just been like, "Why is this thing happening? It's not working. Why is it not working?" Well, I've written something wrong.

But I can be like, no, I have proof over here that it works, so there's something weird in my system that is causing it to do this. And so, it's easier to start with the blank slate and move into the full version because sometimes you just run into things that you don't expect.

00:45:00

Dave: Yeah, like the other day. I was making position sticky. I was sticking something to the top, like a little logo-y thing, header, showy-hidey. But anyway, position sticky, but--

And so, I'm like, "Yeah. Okay. Cool. I'm good at this. I'm good at my job. I wrote it." Then it wasn't working, and I was like, "What's going on?!"

Well, it's that thing. If anything has overflow hidden - or whatever - in the parent, sticky doesn't work. You know? I was just like, "Dang it!" [Laughter]

[Laughter]

Dave: I know that. I've learned that before. But you know, because of the junctions now, it's like this component was working by itself, but then when I put it in another, like layout component, all of a sudden it didn't work. I just was like, "Of course, it didn't work." But you know.

Again, it's like I wouldn't know that the isolated change, if I hadn't made a CodePen about, like, why doesn't this work? Ten years ago, I made a reduced test case that was like, oh, position messes up sticky. Sorry. Overflow messes up sticky.

Alex: Yeah. I think the one I ran into recently was made a Web component and jQuery reads in the entire DOM tree and then spits it back out. Maybe it's older versions of jQuery or something like that, and so I put a Web component into a WordPress site. Suddenly, I was like, "Why is this--? It's not doing the thing. Why is it not doing the thing?" It's because I needed to--

Because of the way that jQuery was doing things, I actually needed to listen for a slot change event.

Chris: Slot change event?

Dave: Yeah.

Chris: Oh, man.

Alex: Yeah, I know, and I had to learn about that. I was like, "I have no idea what this is. This is news to me. Okay. Cool. What is this?" [Laughter]

Dave: Yeah. No, that one is -- that's a deep cut because it's just like, "Oh, yeah, if the slot changes, we can fire an event," but you don't realize that. It's weird.

Chris: It looks like -- part of what we thought about earlier, we were talking about APIs and now jQuery. I wonder how many of us (even if you haven't written jQuery in a while) could pass a pretty advanced jQuery quiz. You know?

[Laughter]

Chris: We should put one of those together.

Dave: Oh, no.

Chris: Deep cut... Because I bet your memory retention of jQuery is really high.

Dave: I bet.

Chris: No?

Dave: I'm good. I'm good for it. I'll ace it. Bring it. We'll do a video. That's a YouTube.

Chris: Will you? All right.

Dave: Give me a jQuery quiz.

Chris: [Laughter]

Dave: Interview me about jQuery.

Alex: Yeah. the amount of stuff that I keep up here, very small. I'm constantly referencing documentation any time that I have to interface with jQuery.

00:47:36

Andrew: What it needs to be is, is it jQuery or is it vanilla?

Alex: Yes! Oh...

Andrew: That will throw me because-- [Laughter]

Chris: Oh... Yeah.

Dave: I could not do that, actually.

Chris: Like .animate exists in both, but they're really different.

Alex: That's the other thing. I think, with jQuery, you can actually do--

I think, with jQuery, it's .for, and you can loop over it.

Dave: Mm-hmm.

Chris: Right. Right.

Alex: Then you could also do $selector.foreach.

Dave: Each.

Alex: If it's an array, you'd be able to loop over it as well.

Chris: I don't think you could .for in jQuery. I don't think that--

Alex: Was it .each?

Chris: It was only ever .each. Yeah.

Alex: Okay.

Dave: Yeah.

Alex: Once again, if I don't have documentation open, it's gone. It is just gone.

Chris: Yeah, but the funny thing is you didn't need .each that much in jQuery because there was a lot of that implied looping.

Andrew: Mm-hmm. Loop.

Dave: Oh, gosh. I miss that.

Chris: That got in your mind.

Dave: I miss that - still.

Chris: That was nice, wasn't it? You could just pass a selector and then just say whatever, like, "Change an attribute," and it was implied that it would change the attributes on everything that it matched without having to write a loop.

Dave: And adder also did a check to see if it has the attribute before you set it or get it or whatever. If you try to get an attribute that doesn't exist, the DOM just chokes. It's like, "I fell over. I can't do this. It doesn't exist."

But jQuery was like, "I got you, buddy. It's just undefined. Don't worry."

Chris: Oh, man. There are some great jQuery quizzes. Let's save that. Let's save that for some--

Dave: Content.

00:49:12

Chris: Andrew said he was just reading the Chrome 105 notes. That is pretty exciting. At least Chromium 105. Does Chromium version numbers match Chrome exactly?

Dave: Yeah.

Alex: Yeah.

Chris: It looks like stable cut August 23rd. Stable release August 30th, so we're 26 days (as we record). Less than that as you listen to this because it'll take us a little time to polish this up and get it out to the world. But probably, as you listen to this, we're within weeks or less of shipping 105, which is big because it's the one.

How many times have we said container queries on this show? Literally, stable Chrome is going to have it, which means that Edge is not far behind or identically released, which means Android Chrome will have it, which means it just drops in a whole bunch of places.

Normally, you'd be like, well, does that really matter? Because Safari won't have it - or whatever. But Safari is dropping it, too. Although, they haven't said exactly when. It's just really close to ready.

The big assumption is -- I don't know if anybody has ever actually said this, but macOS Ventura is about to drop, right? Nobody knows exactly super when, but it'll probably be October-y. Chances are the version of Safari that drops with that will have it. That's my guess.

Andrew: Mm-hmm.

Chris: Just like Flexbox and Grid and all that stuff, which somehow miraculously dropped together (on the Web), we're going to get :has and container queries super weirdly close to each other (as far as releases). That doesn't include Firefox, so I don't know what to say about that. Maybe they'll surprise us all and say it's ready in Firefox too. I don't know.

The beautiful thing about container queries is there's a pretty lightweight polyfill, so it doesn't totally rule out shipping them in production. But I'm curious, from an agency perspective. Do you think you're going to do it?

Alex: Yeah.

Andrew: Oh, yeah.

Dave: [Laughter]

Chris: Yes. [Laughter]

00:51:21

Andrew: These two features are going to change a lot about how we write our front-end code, and I think in a better way. And when I was talking about being ready to hit the ground running with features, I was really thinking about these two features.

There are some that you can sort of lag on that are a bit minor, but these are going to be a big deal, especially in the world of building design systems, which is sort of also a new thing that we're really hitting full force right now. Container queries on design systems solves a lot of problems around context and, like, here's a very modular thing but, hey, where am I going to put it. Am I going to put it in a grid? Am I going to put it--? Is it going to be full screen, full width?

It solves a lot of those issues. You don't have to ask those questions anymore. You just need to see what it looks like at a certain width. And no matter what context it's in, it's going to do that.

Dave: Yeah. Well, and even you can progressively enhance. Hey, remember that stuff?

Andrew: Mm-hmm.

Dave: But it's like, guess what. You get the mobile one. [Laughter] Sorry. Sorry. You get the mobile one, and it's going to look fine but the cooler one is on a newer browser. Done.

Alex: Yeah. I've definitely had conversations with our designers because that's sort of the bottleneck with all of this is that some of these things, you need to have designer buy-in for them with some of these new features where it's like, okay, I know that you're used to designing an entire page. But think about how this block should look at this size and at this size, right? Don't worry about the rest of the page. Just think about how that block looks at these two sizes.

Getting them thinking about it that way so that when they're using their design language for it, it translates to these new features. And so, that's sort of where we've started having those conversations with our designers but getting them on board with using, like knowing that these new features exist and that they can use them is the struggle (is kind of where we're at).

Dave: Well, and it takes -- I think Jason Grigsby is on it, you know, talking about design tooling doesn't really reflect. As good at Figma is, it doesn't quite reflect a squeezy browser, you know, the accordion of life, as I like to call it. You know?

Chris: [Laughter]

Dave: It's close. It's close. It's good. It's way better than it was, but it doesn't quite get us. It's not fully there. You know?

Well, cool. I do know we're coming up against a hard stop, but should we wrap it up?

Chris: Yeah. Yeah.

Dave: I feel like if we start another topic, like what's up with Nuxt 3, which I really wanted to get into--

[Laughter]

Dave: Because that's like 80% of all the entire Discord is just like, "Hey, guys. Bad news about Nuxt 3," you know. But anyway, we just don't have time for it, I don't think. Ugh! Anyway. Okay. I'm going to cut it here. I'm going to snap it here because, anyway, that could be the rest. We'll take it back up in Discord, but I guess just the standard outro here.

For people who aren't following you and giving you money, how can they do that? We'll start with Andrew.

Andrew: You can find me on Twitter, @walpolea. It's my last name, first initial. Then andrewwalpole.com. I think there's any way to give me money but, hey, you know, if your company needs a new brand, check out Traina, where we are, traina.com.

Dave: Nice. And you do some 3D printing on the side, so follow.

Chris: Hell, yeah.

Andrew: Yeah.

Chris: Andrew has 3D printed for me before.

Dave: We can see. You can't see this, listener, but he's got like three or four machines behind him, and I think you probably paused them for the show.

[Laughter]

Dave: Otherwise, they'd just be churning. Yeah, so I see the beds are filled with half-grown models. It's beautiful.

Okay, Alex, how can people follow you and give you money?

Alex: I am most places on the Internet as @fimion, and I stream on Twitch. I try to stream every Tuesday and Thursday. It hasn't been happening lately because I've been traveling, but you can find me there.

You can also find me on Enjoy the Vue, which is a Vue-based podcast where we sometimes complain about Nuxt 3.

Dave: [Laughter]

Alex: You can check is out there and give us a follow, @enjoythevuecast.

Dave: Awesome. Yeah. Wonderful podcast. Yeah, thank you all for coming on.

Andrew: Thank you.

Dave: Thank you, dear listener, for downloading this in your podcaster of choice. Star, heart, favorite it up. That's how people find out about the show.

I was cruising the reviews the other week, and anyway, thank you all for the wonderful reviews. They're really funny, and you guys inserted the word "tractor-beam" appropriately. I really appreciate it. [Laughter]

Then, yeah, follow us on Twitter, @ShopTalkShow, for ten tweets a month. And, yeah, join us in the D-d-d-d-discord, patreon.com/shoptalkshow. Chris, do you got anything else you'd like to say?

Chris: Oh! ShopTalkShow.com. Thanks. That was awesome. Bye-bye.