473: Brad and Ian Frost – From Meteorologist to Web Developer

We're chatting with Ian Frost who swapped out his meteorologist career to become a web developer alongside his brother Brad Frost. We talk about getting started learning HTML / CSS, and then Javscript, writing code as a team, navigating the front and back end in 2021, dictating tech stacks to clients, and dealing with turnover and tech changes with clients.


, , , , ,


Ian Frost

Web // Twitter

Meteorologist / web designer / developer who loves Pittsburgh sports, music, and life.

Brad Frost

Web // Twitter

A web designer, speaker, writer, consultant, and musician in beautiful Pittsburgh, PA. Author of Atomic Design.

Time Jump Links

  • 02:00 Meteorologist to web developer
  • 11:01 Getting started in HTML / CSS and then Javascript
  • 13:04 Writing code as a team
  • 18:27 Sponsor: Elastic
  • 19:04 Navigating the front and back end in 2021
  • 27:00 Can you dictate to clients vs doing whatever they want you to do?
  • 34:35 How do you deal with turnover and tech changes?
  • 37:46 Sponsor: Jetpack
  • 39:55 How's your confidence in new tech?
  • 51:28 Any tough moments in your dev journey?

Episode Sponsors 🧡


[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show with Click & Tap, the Pointer Event Brothers. [Laughter] I'm Dave, and with me is Chris. Chris, how are you doing today?

Chris Coyier: I'm doing fantastic.

Dave: Hey, who do we have in our studio?

Chris: Well--

Dave: Another set of brothers?

Chris: Yeah.

Dave: [Laughter]

Chris: What do you mean another? Did we do a brother show recently? No.

Dave: Brothers. No, you -- I was pretending you and I are brothers.

Chris: Oh... [Laughter]

Dave: But you know, it's fine.

Chris: We might as well be.

Dave: It's fine. We're not brothers.

Chris: They say brothers from another mother is what they say.

Dave: Yeah. Whatever.

Chris: Yeah. We have -- you might recognize Brad Frost. How ya doin', Brad?

Brad Frost: Yo!

Chris: Friend of the show. Been on before. Brad, your brother is on, Ian Frost. What's up, Ian?

Ian Frost: Hello, hello.

Chris: Yeah. This, I think, was Dave's idea for a show. It came from some talking stuff. I think a lot of you out there are going to be really interested in this. We're going to do a career transition show because that is exactly what happened to you, Ian. Right? Literally. Do I have this right? Weatherman?

Ian: Weatherman.

Chris: What?! Is that real?

Ian: [Laughter] That is real.

Chris: [Laughter]

Ian: That is real. Meteorologist.

Chris: Meteorologist.

Ian: It makes it sound better.

Chris: Yeah, right. It's like when I call -- like there are people that do finance, you know? I know somebody who went to Brown for finance, and if you say, "Oh, our accountant," that's not cool. You don't call finance people accountants. That's not right. You don't call meteorologists weathermen.

Ian: Nope.

Chris: Is that the same? Yeah. Okay. Let's start there because it's just an incredible different career. Some people are like, "I had a band in college and then I became a Web developer." Well, that's 92% of all Web developers.

Brad: [Laughter]

Chris: But--

Brad: Hi, there.

Chris: Yeah.


Dave: And that's the complete wrap-up, and so--

Chris: Right. Less interesting. And it's not terribly weird to find Web developers that had a degree in English or whatever. Dave majored in anime.

Dave: Yeah.

Chris: It's getting more common, not necessarily computer science, but that people go to a boot camp or something. But still, the generation of developers that probably Brad, Dave, and I are from are, like, your degree is -- pick something out of a hat -- really random, English majors, Philosophy, whatever. But that's changing a little bit. I don't think weatherman is even one of the cards in the hat - meteorologist. Sorry.

I guess the obvious question is, why give that up? That seems like a cool job. What led you to--? Just do your path. Do the five minutes.


Ian: Yeah. I went to Penn State University for meteorology, got a degree in meteorology, and then moved to outside of Washington, D.C. to be a meteorologist for four years. I started out working 10:00 p.m. to 7:00 a.m. shifts, which was fantastic.

Dave: Whoa!

Chris: Dude. Been there.

Ian: Not really. [Laughter]

Chris: The graveyard shift.

Ian: Exactly. I worked overnight shifts for probably like two or three years and then got promoted (quote-unquote promoted) to the 3:00 a.m. shift, which sounds even better. So, pretty much, I got sick of that and I also proposed to my now wife at the time, and we were kind of trying to decide where we wanted to live.

I'm like, "I'm not super thrilled with my company," and I decided to move to Pittsburgh. And so, for like two years, I think, I looked for jobs in my field. There's not a whole lot around here aside from--

Chris: Is it one of those jobs where you just go where the job is?

Ian: Yeah, it's super, super-duper specialized, so I ended up -- Brad, you and dad came down and moved me out of my townhouse I think the Wednesday before I got married. And then basically--

Chris: Wow.

Ian: Yeah, moved up from--

Chris: You're like, "I'm going back to Pittsburgh, job or not?

Ian: Yep.

Brad: It was maybe a month out from Ian's wedding. I was like, "When are you moving to Pittsburgh? [Laughter]

Dave: [Laughter]

Brad: Because whenever you get married, typically you live with your spouse after that. It was like right up before the wedding. I was in Germany at a conference. I couldn't sleep, and so I got on Facebook. Ian was online. I asked that question. I was like, "What are you doing? When are you moving to Pittsburgh?"

That's what kind of kicked the whole thing off because you were like, "I've been looking for jobs. I haven't been able to find any." Trying to sort of find a way to get over there. That's what led to--

Chris: Yeah.

Brad: --"Well, I've got a bunch going on with my stuff. If you want to come (if you're interested in this at all) to just help me out for a couple of months, just get your feet planted here, be able to be in town, which is easier than job search--

Chris: Yeah, and what was that like? Answer my emails or whatever? Was it like a professional assistant or something, or what?

Brad: I had -- you know, there's just content management chores. There's just stuff. You know.

Chris: Yeah.

Brad: You guys know this. There are a million things swirling around. It wasn't like, "Hey, I need you to be the lead developer on a client project," but it was just like, yeah, kind of tidying up emails, tidying up a bunch of stuff.

Chris: Yeah. Was it in your head, though? You're like, "What if, though? What if I could--?"

Brad: No.

Chris: No?

Brad: We set up a contract, like, we're doing this right, and so it was, Ian, a three-month contract, right?

Ian: Yep. Yeah, three months.

Brad: You're going to help me out for three months, get over, move to Pittsburgh, start your job search, and then be on your way.

Chris: Oh! Okay. Okay. How did those three months go? Obviously not terribly, right? [Laughter]

Ian: Yeah.


Dave: Sorry. Putting a timeframe on it, I feel like this was Web Design Day 2016. We were hanging out, Val Head and the posse.

Chris: I remember that.

Dave: I feel like that was the time zone, right? May-ish 2016.

Ian: It was a year before that, yeah.

Dave: A year before that.

Ian: Yeah.

Dave: Okay. Okay. Just wanted to get the timeframe for everyone. Okay.

Chris: We should go to conferences again. Wasn't that fun?

Ian: [Laughter]

Dave: Remember that, man? That was a thing.

Chris: Yeah. The problem is you have to think of something to say to get invited.


Dave: Quit doing that.

Chris: Cool. So, it was a three-month banger. At the end of that you're like, "Well, I didn't actually find a job." Tell me what -- continue the story from there.

Ian: It was more along the lines of I enjoyed what I was doing. By the end of that three months, I think Brad -- I don't know. I'm not going to speak for you, but I feel like you appreciated having someone to help you out with things. Yeah, it was pretty much just like the transition was taking a few Codeacademy courses.

Chris: Okay.

Brad: Yeah.

Chris: Let's do that then because you mentioned it. This was not entirely under Brad's tutelage. You trained yourself.

Ian: I mean it was guided. I would say Brad guided that.

Brad: Yeah. It was me telling Ian, "Go take these courses [laughter] like right now."

Ian: Yes.

Brad: Yeah.

Chris: Okay. Codeacademy then, that worked out well for you? Okay. You never know because there are a thousand choices, and I'm not even exaggerating that number.

Ian: Yeah, it was a mix of Codeacademy, reading A List Apart books, and just kind of googling.

Chris: Yeah.

Ian: I continue to remember Brad saying, "Google it. Google it." I would always ask him a question, and it's like, "Google it."

Chris: Yeah.

Ian: I really appreciate that, looking back on that now.


Brad: Yeah. Here's what really happened. It was like Codeacademy is a great place to just sort of get your syntax right and just sort of understand what Markup is, what CSS is, how to do all of that, and so I'm like, that's a good thing to just get that, get exposed to that, and I'm too busy to do this or whatever. But we did have -- I thought long and hard about what to expose Ian to first because there are so many moving parts to this.

The first thing that I actually had him do was make updates. Our uncle has a chiropractor website that was one of my first paying Web design gigs was my uncle's chiropractic website, which is like a ten-pager. You know what I mean? Just sort of no content management system, no whatever.

In between my first paying gig and when Ian joined, my uncle had brought on or he got the total snake oil treatment from some SEO guy.

Chris: Yep.

Brad: Who was like, "We're going to get you on the front page of Google." What they did was just annihilated his pages with all of this gross content, like a bunch of typos, a bunch of just sort of duplicated kind of like, "Pittsburgh. Pittsburgh chiropractor. Wexford chiropractor."

Chris: Yeah.

Brad: "Cranberry chiropractor," like basically all of the suburban sort of the things, just sort of littering the pages with that. And so, I was like, "This is great because all of this needs to go and that doesn't even really involve Markup, styles, or doing any real sort of Web development work," but it what it does do is get him familiar with version control, GitHub pushing and pulling, making updates to a site.

Chris: Hmm.

Brad: That and the Codeacademy stuff was like, this is a good intro to make a change, remove these words from a webpage, and then commit those changes and see them live on the site. That was the intro and that was the shallow end. Then we slowly got more into the deep end.

Chris: Yeah. Tell me, Ian. Did that feel good? Was that part of the thing that you enjoyed doing?


Ian: Yeah. Yeah, I mean I enjoyed the HTML and CSS part of it.

Chris: Mm-hmm.

Ian: The JavaScript part was obviously a bit more heavy-handed and a little more complex than those two. I feel like it was Brad (if I'm not mistaken) the Death to Bullshit site that we did that really taught me a lot about how to write JavaScript. Whether it was the best way to do it, it probably wasn't, but it taught me a lot on how to Google things and how to write for loops and all of that stuff.

I had had some previous experience with -- I took a computer science class in high school learning Pascal and Visual Basic and all of that stuff. Then I took a Fortran class.

Chris: Wow.

Ian: Then C++ in college, so I had had some experience with programming languages before, so it's just a different flavor of it, I feel.

Chris: Okay. Okay. Wow. That's great. But there was some actual enjoyment that came from-- [Laughter]

Ian: Yeah, absolutely. I had thought about possibly going into computer science and then -- -ish, -ish. Then I took a class in college and I'm like, "Eh, I don't know if this is for me."

Chris: Right. Right. You were taking the classes with what in mind? I don’t know how much Codeacademy you need if Brad is right there saying, "Just update our uncle's website," or whatever. Was the classwork and such to be like, "I want to work on bigger deal stuff than this and be more billable," or whatever? Was that in mind right away was, like, "What if we could bill for two people instead of one?"


Ian: I'd say that I just kind of wanted to get comfortable with it so that I could team up with Brad and our partners on projects to be able to write good code.

Brad: Yeah.

Ian: And Brad kind of helped guide the way with, like, how do we write good code together that makes us feel that not two people are writing it but just one whole team is writing it.

Brad: Yeah. So, yeah. The sort of ramp was really low-stakes stuff and then into side-project territory. That Death to Bullshit site was a perfect example. This is a site that I've wanted to make for a while but I just don't have the time to do this. The fun with that was the JavaScript that Ian learned was to make the most obnoxious, anti-pattern stuff. On the Death to Bullshit website, it's literally a flat HTML page. But then whenever you turn the bullshit on, there's a switch that adds all of these ads and carousels and parallax effects and stuff.

[Laughter] That was the first JavaScript that Ian learned how to write was this, but it was great because it was super-fun, super-low-stakes. No clients are going to yell at us. There are no other stakeholders, so that was a really good, again, onramp into that. It was kind of like coming out of that stuff whereas, okay, now maybe we can start putting you on some client work stuff.

To speak to the billable, two people thing, it was not that at all. It was really just kind of like Ian is going to be hanging out for a while. Maybe he could help me with a couple side projects. It was really after that that it was like, holy smokes! I'm actually just getting buried with client work and stuff like that and I actually needed extra help. And so, it ended up working out really well.

Chris: So, there was some serendipity that happened? Yeah.

Brad: For sure. For sure. Yep.

Chris: Like a big one landed in your lap and it was like, "Actually, why don't you do some of this?"

Brad: Yeah. That big one was about.com, if you remember about.com.

Chris: Wow. Is that project wrapped?

Dave: About.com is like ten sites now, right? Isn't it something like that? It's a big SEO play or something?

Brad: That was the gig. That's what we helped--

Dave: Okay.

Brad: That's what we helped them do, so the brief for about.com was basically we have this site that's older, literally older than Google. As a result, their Google Guice is insane because, "How do I change a car tire?" It's like, boom. Number one, about.com, "How to change a car tire."

Chris: Mm-hmm.

Brad: But then also, "Am I pregnant?" Boom, about.com, "Am I pregnant?" As it happens, back in the day, that's how that all went, right? These giant content farms, these big monolithic websites, and that's not how things work anymore, and so it's weird. You're not going to go to the same site to fix your car tire and figure out if you're pregnant or not. [Laughter] It's very strange.

Dave: I'm not going to get my kombucha recipe from about.com.

Brad: Sure.

Dave: Right?

Brad: But they totally have that stuff.

Dave: Yeah.

Brad: It's crazy.

Dave: Yeah.

Brad: That was the gig was, let's explode this monolithic brand and spin up these sort of content specific verticals, like these new brands for each of these sites and power that with the same sort of underlying design system and platform. That was, Ian, your intro to client work, which was a pretty -- [laughter] it did go from side-project to throw you into the deep end, I think, pretty quickly after that.

Ian: Yeah.

Brad: Yeah.

Dave: What technologies is that in? Can you say? You might not be able to say, but is it React? What kind of setup is it?

Ian: That was vanilla HTML, CSS, and JavaScript with some XML or something.

Brad: Yeah. Their backend stuff was Java, but what we were delivering was--

Dave: Okay.

Brad: --the sort of front-end Markup. But at that time, it wasn't yet like, "Here's the bundled up, consumable component library." What we did, I think, Ian, it was Pattern Lab, so mustache-faced still at that time.

Dave: Okay.

Brad: It was us delivering, like, "Here's the front-end Markup," and then they still had to do kind of a conversion step to get that into their Java-based back-end system, which isn't ideal these days. We wouldn't do that these days but, back then, I don't think that the dust was totally settled on a lot of the plumbing for how to create a perfectly encapsulated button and then ingest that into an app.


[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Elastic. Elastic enables the world's leading organizations to put their data to work using the power of search. Whether it's connecting people and teams with content that matters, keeping applications and infrastructure online, or protecting entire digital ecosystems, Elastic's search platform is able to surface relevant results with speed and at scale.

Learn how you can get started with Elastic's search platform for free by going to -- get this -- elastic.co/shoptalk.

[Banjo music stops]


Dave: Yeah. I'm curious. We talked about it a bit before the show. I think a lot of people are in that very situation. They can sling some HTML. They've maybe built a design system in HTML or they have one in Figma or a designer, a developer, or casual developer - whatever. In my experience, the needs of websites are just growing and growing and growing.

I think, Brad, you talk about this: bridging the front and the back-end or front of the front and the back of the front. We kind of need to broaden our skill set and be in that business where we build JavaScript systems or have the ability.

I think a lot of people are on that bridge, one side of that bridge, ready to -- "Oh, boy. I maybe need to go over." What was that like, your first, "Hi, this is React," or this is - I don't even know - Twig or something. It's just some kind of very dynamic sort of thing. What was that transition?

Ian: Yeah. Basically, we had another project coming up that they wanted to build it in React. Did we even take any courses, Brad? We did something. I feel like there was one course, maybe, but it was a lot of -- this was back when React wasn't well documented at all. I remember doing a bunch of Google searches and not being able to find anything.

It was just kind of like, "All right, let's just dive in and figure this stuff out." It was kind of like getting in, building some components, just buttons, just basic sort of things, and figuring out, oh, what's the best way to build this, this button? I think it was like me and Brad talking back and forth about, like, "What's the best way to structure this React component?" because at that time it was very sort of blurry as to what these things looked like.

Brad: It still is. It's super unopinionated, and you can do a million things. Yeah, from tutorial to tutorial to tutorial, you're looking at JSX or you're looking at a React component. You're like, "Is this even the same thing? Is this the same language?"

I remember that, and that's kind of a guess by design. As a result, you're like, "Well, how are we going to do this?" [Laughter]

Chris: What do they want? Does it sometimes matter? Do you tell clients what they want? You're like, "Okay, I understand what you're asking me. I'm going to give you a deliverable that you're going to love." Or do they come to you and say, "We want this. Please do this"? Is that too abstract of a question?

Brad: No. A lot of times it's, "Hey, we're re-platforming or rebranding." We often come in, in those sort of inflection points. "We're redesigning the thing, "We're rebranding," or "We're taking our old crusty ASP stuff over to a more tech stack," and that's where we come in at those seams. Then we help hitch our wagon to going, "Okay. What are you trying to accomplish? What are you trying to do?"

In the early days, up until Ian joined, it was, "Hey, we need a responsive website." I create Pattern Lab (along with the team that helped create that) to make that more efficient. As a result, that became, "Here are these components. They're self-contained. They have these different slots or dynamic bits to them, so you don't have to create a thousand buttons with different text labels for each. You just have a text slot or a text prop or whatever that you pass stuff into.

Over time, coming back to the React project, it was, "We're doing this in React," and so that became, we help shape, "Okay, so what we're going to do is stand up this standalone React component library that will be published and you will consume that in your application...."

Chris: They're like, "That sounds good." Right?

Brad: That's right.

Chris: Yeah.

Brad: Yeah, that's exactly right.

Chris: Did you do Storybook or did you hand--?

Brad: Mm-hmm. Yep.

Chris: Yeah, Storybook?

Brad: Yeah.

Ian: That was in the beginning days of Storybook.

Brad: Yeah. [Laughter] It was, and we had this great client project that they were like, "Storybook isn't doing what we want it to do." They're very bold and also didn't really know what they were doing.

They were like, "Storybook isn't cutting it for us," so our boy AJ created AJbook.

Dave: Good. Love AJbook.

Brad: We're going to use AJbook instead of Storybook for this project.

Chris: It wasn't just empirical or whatever, it was just worse?

Brad: That was the one where that was kind of like a startup-y kind of thing. It was a little lower stakes compared to some of the other work that we've done, which is like Fortune 500 companies. That was a good testbed for going through our growing pains with React, learning how that all worked. Then we were able to transition that into other projects.

Chris: Yeah. I remember it was not that many years ago, Brad. I do want to focus on Ian's story here, but I remember this so clearly.

Dave: It's the Ian show, not the Brad show.

Brad: [Laughter]


Chris: Brad fights with React, essentially. You're very public about, like, this is weird and hard. You know?

Brad: To this day, I still get a lot of emails from people that are like, "I'm in that world." I mean that's why we're all talking here. I think that Ian's story is my own story, for what it's worth. But Ian was even fresher than I was.

It was like, here's this thing. We want to use React, so we're like, "Okay, well, what does that actually mean? What does that look like?"

Ian: Yeah. I think that, at first, during that time I'm like, "What is this garbage?"

Chris: [Laughter] Oh really?

Ian: I can't use it. This is not what I'm used to. I feel like, with anything, any kind of change, it's just like, "This is crappy." Then as you dive more into it you're like, "Oh, this is cool. I can hit this button over here and this automatically updates without the entire page reloading." It's like, "I see the power in this."

Then the more you get into it, the more you're like, "Okay. I kind of like this," because I was in the same boat. I was like, "I don't like React. This is too weird." Now I'm like, "Oh, React is great. I really enjoy writing it," and I feel like we came up with a system that works for us that kind of organizes React components in a way that anyone who is into JavaScript, CSS, HTML can kind of understand. They're broken out a little more rather than globbing everything together and being like, "Here's your button," even though it doesn't look like a button.

Chris: Dave does client work as well. I'm curious. I've never really understood. I'm sure it depends in a million ways. Isn't it possible to do the kind of client work where you tell them what you do and they can buy it or not? Then, conversely, you work for clients and you just do whatever the hell they want because they've got a bunch of money and you want it. I'll fricken' write in Angular if you want. That's cool.

I could imagine. I'm picturing this beautiful Frost brother created Storybook full of masterfully created components and being like--

Dave: Hand-hewn, aged.

Brad: Artisanal.

Dave: Little elderflower.

Chris: Yeah. Right. You deliver that and a leather pouch with bourbon in it.

Brad: [Laughter]

Chris: But isn't that a product? I'm not comparing it to product work, but I could see being like, "We are a company. We make design systems. We use this tool to do it, and you're going to love it."

Or do you just be like, "I don't care. You're a big brand. I'll do whatever the hell you want me to do"?


Brad: Behind the scenes, we have a vanilla Frost brothers crafted codebase of this stuff. Now, here's the trick, though, or here's the thing. We get our work by way of design systems and I happen to be in there harping on about this stuff for longer than most. As a result, it's "Hey, we're giant org with all of this sort of tech sprawling around. Please help us wrangle it."

That's how our work comes in is basically like, "We have Angular. We have Angular 1. We have Angular 2. We have WordPress. We have Drupal. We have React over here. We have this stuff. It's a mess. Please help us."

That's how our work comes in, but very often it's less like the clients are shoving things down our throat, although sometimes it is that. It's more about, like, we're not often starting from scratch. It's not, "Please help us stand this up from the ground up." It's more of us coming in and sort of assessing what exists already, what's good, what's worth elevating to, "Here's how this company does things."

Chris: Okay.

Brad: We're kind of like a conduit for a lot of the work that's already happened at the organization. As a result, that's why we touch so many things and why Ian has had to learn Angular, React, Web Components, and so on and so forth just because we are trying to make this work at the organization that has already invested in a certain....

Chris: Yeah. You can't just be like, "Meh, I don't do Web Components. I do this, so goodbye." You know?

Brad: We could have done that, but we want to help people and get paid to do so. Yep.

Chris: Just knowing Dave as long as I have, it seems like Dave gets dragged -- you get dragged into all kinds of weird technology. You're like, "Whatever. That's what I do."

Dave: I've written Java before. I don't know.


Dave: Yeah, I mean we end up in the long-term relationships, and it's just like, "Well, we can design you the thing, and we can build the thing. We can also integrate the thing. We know how to do that," and so we end up doing a mishmash of all that.

I don't know. It's for better, for worse. You want that stuff out.

I'd be curious if you all have the situation where you build the handcrafted Frost brothers system, and you're like, "Here you go." Then people are like, "I'm not going to use that." [Laughter] Is there internal resistance? Is it just something you just have to be like, "No, no. Trust me. It's cool. It's cool. It's cool," or what?

Brad: I think what we do that is good (or great) is that we actually work with their teams rather than just kind of going off building this thing and then being like, "Here you go. You've got to use this." Then they're like, "Oh, well, we don't want to use it," or the documentation is not there.

I think we write documentation well, and I think working together with them, I remember working with United, basically working with their product developer to get the React stuff the right way. Make sure it works in the product and there you go.

Chris: There are no surprises. It's not like you show up one day with your package of components. They know what they're getting the whole time.


Brad: What we did, anybody can create components. If this was so easy, if that's really what the gig was, then we'd all just use material design because it's like, "Oh, there it is. It's already done. There you go.

Our gigs look like we come in, we talk to everybody--designers, developers, the CEO, you name it--about what's going on. What works well? What doesn't work so well? Then how do we craft a design system to make your organization better?

We co-create our design systems with our clients, design teams, development teams, and product teams. We actively partner up with them, so there's no hand-off, so to speak. It's a slow cross-fade of us seeing ourselves out the door and them taking the reins and taking ownership of the thing. That's what we like to do.

Sometimes we can do that in a project, but more likely we'll do three pilot projects or something where it's like me and Ian are burning really hot, helping them do a lot of the hands on work at the first project. The second project is more 50/50 split where they're doing a lot more of the work. Then the third project is like an 80/20. They're doing 80% of the work and we're just kind of there for support. Then we roll off after that.

It's great because we get to work with a ton of people, even though it's just me and Ian in a room together. But we get to work with loads of different people, loads of different tech stacks. Hear all sorts of opinions and stuff.

We get to go, "What's a difference of opinion?" because we try to be humble with this stuff where it's like, "Okay, if you're religious about CSS modules," which that is a thing, it's like, "Okay. Let's use that. We don't really care all that much. Sure, let's do this with the other people that have strong opinions, one way or the other."

Chris: I see. Their care-ometer was a ten on that particular thing.

Brad: That's right. As a result, we get to touch a bunch of things that other developers care about. We're like, "We wouldn't personally reach for that, but sure, let's do it."

Chris: Okay. Yeah.

Dave: Let's say hypothetically you made a design system sort of under the design umbrella of a company. Then You're on board with all the developers. They're like, "Yeah, let's do it."

Time happens. Those people quit. [Laughter] New people inside. They're like, "Uh, let's use Bootstrap and Material." What do you do? What do you do in that totally hypothetical situation, Brad, Ian?


Brad: Go into a dark corner and cry.

Dave: I did that... I mean hypothetically.

Chris: The same. Yeah.

Dave: Hypothetically--

Brad: Yeah.


Chris: Just to connect the dots to another podcast, I think that's kind of fun to do on podcasts. There's the Postlight Podcast. Paul Ford, Rich, and their gang over there have an agency as well. Their latest show is how to talk to billionaires, and they had a good, little quip in there about how the ultra-rich, when they buy a yacht, there is no yacht store. You can't just be like, "Give me the Firebird," or whatever, and it just arrives. It's not a thing.

The whole thing is like you talking to United about a design system. The whole thing is bespoke from day one to the 18 months later when the yacht is delivered. There's a meeting every Friday. They pick out the table, the wood, and the stuff. A yacht ends up being like a design system in that every single one of them is entirely bespoke.

Brad: Yeah, and that's a lot of the work. So much of the work is the human stuff because, again, Dave, back to your thing. It's like, why not just use Bootstrap or Material Design if all it is, is, "We need buttons. Oh, there are buttons."

Dave: Just to clarify, it was Bootstrap and Materials. I just wanted to clarify.


Brad: "We need these buttons. Oh, I like the look of that one, but I also like purple, so that one has purple. Let's--"

Dave: Because of mobility.

Brad: God. Right.

Dave: Yeah.

Brad: Yeah. That's lousy, especially if the hard work has already been done. It's like, yeah, that's a lot of just sort of like human stuff that comes in really making it go, "Here's specifically what problems we're trying to solve, and Bootstrap doesn't know what those problems are. Material Design doesn't know what those problems are."

At the end of the day, there's certainly commonality between all of these things, and so some of it is neither here nor there if you're talking about a button. But if you're talking about a flight block component, for instance, like being able to display the time, the date, the departing airline, and where you're riding, and to do that consistently across your entire product ecosystem, that's huge. Bootstrap doesn't have a flight block component or Material Design doesn't have it.

Dave: Oh, I have it on good authority Bootstrap does everything and has no....


Brad: Therefore, burn all of our stuff down and just swap in Bootstrap.

Dave: That's what I was told. That's what I was told.

Brad: Yeah.

Dave: Yeah.


[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Jetpack, you know the plugin that does all sorts of stuff for your self-hosted WordPress site.

I have not made it a mystery--that I'm a fan--I don't think. Right? I have it installed on all my WordPress sites. I love the features of it.

I love instant search. That's one of my favorites. It gives you this really good search experience on your site by doing - uh - nothing. It's basically a switch flip kind of thing and it's really nice. Then you've got full control over that search experience that's just way above and beyond what anything native WordPress could provide and with control. Just amazing. Anyway, that's just one thing.

I do have an ask. Maybe you've seen it. I'm asking why people don't use it, if they don't.

We put up a survey on CSS-Tricks. It's just a Wufoo form kind of thing. It asks one question, so it should take very little of your time. It just makes you pick from things that are reasons why you don't use it, if you don't, all the way included to, like, "I don't even know what you're talking about, Chris."

The point is to kind of home in on, like, if you hold any, do you have some baggage about Jetpack? What are your thoughts? Does it just not do anything you don't need? Is it too expensive? Do you think that it doesn't do things the way you want them to?

There are a bunch of answers there. Pick the answers you want. Then if you want to, follow up with why. If you really want to expand on it, use the form, but you can even write to me if you want.

I'm just curious because they're a long-time sponsor, I like what they do, and it's helpful for me as a sponsoree to know why somebody might not like the product.

I'm not just going to be like, "You're wrong!" because maybe you're right or maybe your opinion is valid or you have different things you're thinking of. Sometimes I think there are things that I could nudge people and be like, "You know, actually, maybe you were right, but you're not anymore," kind of thing, and that will just help me be a better sponsoree and it's probably helpful for them to know what's up with their product, too.

Thanks for the sponsorship. Everybody who has already submitted that form, I appreciate it.

[Banjo music stops]


Chris: Now it's 2021. Ian, let's say you had a brand new client that started next week and it was Svelte, right? I don't know how much you've used Svelte or not used Svelte. Would you just be like--?

Ian: Not at all.

Chris: None? Would you just be like, "Bring it, yo"? Is your confidence to that level up to that?

Ian: I feel like that's been my mantra for the past four years, probably. Yeah, it's just kind of like, "You're using Angular? Sure. We'll learn it."

I think a good piece of advice is to learn. If you're learning a new framework, learn that framework and learn its ins and outs, lifecycle hooks, all that stuff in React. Then once you have structured something good in React, then it's like, "All right. Maybe I'll try my hand at Angular," and not like it at first and then see the value in it. Or maybe I'll look at -- what? Is it Astro that just came out?

Chris: Delicious Astro. So good.

Ian: All of that stuff, so once you learn one framework, you kind of learn the common pieces of each one. There are some nuances to it, but yeah, I'd be like, "Bring it on." Why not?

Chris: Yeah. Isn't that the truth that there are all these different languages, but there are more commonalities than differences?

Brad: It's same stuff, different day, especially if what we're talking about is this front of the front-end stuff. Right?

Ian: Yeah.


Brad: At the end of the day, you've got text fields. You've got for controls, buttons, typography stuff, cards, and containers. That's it, so it really does -- you could sort of blur your eyes and look across all of these. Whatever. People are like, "Do you like Vue better, or do you like React better?" People that get all sort of foaming at the mouth religious with this stuff, just shrug your shoulders. They all do the same general thing.

I think it matters more -- and we're finding this a little bit more -- Ian, if you want to talk about this. The low-level components -- and we're increasingly doing Web Component stuff, which is its own ball of wax -- it's like the Web Component stuff is really good for front of the front-end UI components. But then there's the whole sort of React and friends state management, blah-blah-blah. The application stuff that still feels like it's not just going to be, "Oh, Web Components are going to be the future." It's probably going to be maybe Web Components for styling our buttons and getting our stuff working at a low-level UI level. But then plugging that stuff into these bigger framework ecosystems to actually orchestrate and make the apps go and work.

Ian: Yeah. Yeah, I think that Web Components are very powerful, and I think one thing that I did for a client (before we even started working with them) was basically take the basic HTML structure of a component -- actually a few components -- and then built part of their page with it in React, Angular, and Vue. Basically, use that same HTML structure across the board. Then put those side-by-side to show that, "Hey, this thing is the same button that's used over here. It's the same HTML structure that's used over here."

As long as you have that foundational HTML structure and good CSS conventions around that, you can get the same basics from each component with just using that - for instance. If you built a design system in React and you want to support Vue, if you have a solid HTML and CSS structure, that makes things a lot easier rather than dealing with style components and all of that fun stuff too.


Brad: Yeah. All you have to do is match the classes. Bootstrap is a perfect example.

A lot of our work is creating design systems that are meant to go and travel to different tech stacks across a company. Very rarely is it, "We'll all in on React," or "We're all in on Angular." Very often it's, "We have Angular, and this is actually really important to preserve. We have React. We want to preserve that. We have this other stuff in Vue. We want to preserve that. How do we make this one system sort of feed all of these things?"

Ian, as he's talking about it, he's created. He's sort of stood these things up as, like, "This is literally the exact same template written in three different frameworks. They look identical from a look and feel standpoint. The tech underneath them is all sort of different, but then the added magic trick that Ian has done now is gone, "Okay. So, actually, here are these three different frameworks, but that means you have to write, orchestrate, and maintain these three different frameworks over time. What I'm going to do now," and Ian just did this for a client and they were like, "Oh!" because he was like, "Now I'm going to rip this stuff out and pull this into Web Components and then swap out those Web Components inside of those other frameworks."

Chris: Hmm!

Brad: You could maintain those core UI components as Web Components and then feed those into the respective frameworks and it just works. You're like, "Ooh! Okay. That's nice," because now it's no longer--

Chris: Do you think there might be some future in that Web Component plus JavaScript Component combo?

Brad: I think so. I think we're seeing it. One of our clients right now is a Drupal plus React plus some Vue stuff off to the side.

Chris: You can share them then a little bit? Ooh...

Brad: That's it.

Chris: Cool.

Dave: Do you have troubles with the--? I hear the Web Component/React bridge is a bit blah. I don't know. Something about attributes and props and stuff get a little messed up, right?

Ian: Yeah. Yeah, it gets a little funky. I was telling Brad this the other day. I feel like Web Components is going in this direction and then everyone went over to React and Angular and all of that stuff. Web Components has just been crawling along a little bit and trying to learn from the other frameworks. It just doesn't feel like it's totally there yet, but I have a feeling there are going to be more and more people using that in the future. Yeah.


Chris: Probably. I've seen the struggle that you pass props. Every component has its own kind of props. Astro has its own little prop handling thing. Everybody handles props a little differently. Web Components don't care, right? They have attributes on the tag itself. Depending on what framework you use, they could get chewed up or not.

With Web Components, you've got to be like, "Please leave my fricken' attributes alone." You know? That's the big struggle.

Brad: Yeah. Yeah, there's a lot of that stuff. Vue and Angular are pretty smooth sailing. You just sort of drop them in and you're good but React (in how it handles events and how it does a lot of the stuff) there's a lot of tripping.

There's a good post recently that was like, "What didn't ship in React 18?" or something. Did you see this?

Chris: I don't recall.

Brad: It was this whole, like, "They're still doing their own proprietary thing," meanwhile there are all these tickets. There's been pressure to get them to adopt more of the Web Component model, and they're just shrugging their shoulders on it.

Chris: Oh.

Brad: I feel that, but whatever. That's all short-term hot drama. Whatever. Fast-forward.

This is what we've been telling our clients is, "We could do this," and this is the first thing that I feel like five, even ten years down the road, this is actually probably a safe bet, whereas, like, "Sure, we could build you your React framework now, but whatever. React will be new jQuery ten years from now, for all we know," but to build it using native Web technology, again, kind of feels good. It feels good.

Chris: Wow! Big words. I know Dave is kind of feeling the same way. You've been a proponent.


Dave: Yeah, well, and I'm in a Web Component community group with the W3C, but I think there are a lot of companies that are using Web Components for exactly the reasons you all are. They have a Drupal site. They have a Rails site. They have a React site.

Any component of a significant size is all of a sudden -- [laughter] You know. When you're in mergers and acquisitions, you don't get to control what stuff was built in. You just get this weird website and you have to graft it into your weird website and nothing goes together.

I think a lot of people, at least in these bigger companies, are starting to leverage that. Salesforce would be a prime example. They're a big company and they have a lot of different developers from all across the globe touching code and doing stuff.

I don't know. The discrepancy that can happen between two people's Angular code or two people's React code - or whatever - is massive. That can happen in Web Components too. But in theory, you have these building blocks set up.

Brad: Yep.

Dave: We're in good shape. But yeah, it's not perfect yet, like you were saying, Ian. Yeah, I think it's getting better.

Ian: Mm-hmm. I think, for low-level stuff, it feels really good. What I love doing is sort of stepping out, in general. If I have a blog, if you don't make websites and you're just like, "I run a company. We have a blog. We have this homepage. We have an e-commerce site. I want those buttons to look the same." That's a pretty reasonable request, right?

From a development standpoint, you go, "Well, it's kind of complicated." [Laughter] With Web Components, you're actually like, "Yeah, we could actually, literally drop in that same sort of button in those three environments, and you'll just get it." I like that. That feels good.

Dave: Mm-hmm.

Ian: Rather than going, "Well, we have to sort of set up these workflows and these processes." The graph that I draw to show how we orchestrate all this technology feels like that Always Sunny in Philadelphia, the sort of ransom note GIF. Yeah.

Dave: Pepe Silvia? Yeah. [Laughter] Yeah. Yeah.

Chris: That's a rough moment, it sounds like, or complicated. Along your journey, Ian, it wasn't all roses or whatever, as they say, right? Can you think of any kind of setbacks or bummer moments?

Ian: That same project that I started building React components in, a month into they were basically like, "We don't want to do React anymore. We want to do vanilla HTML, CSS, and JavaScript now," because I don't think at that time they really had anyone who was comfortable writing React. So, I basically had to rewrite components to be regular vanilla HTML, CSS, and JavaScript, as well as redo their reference site because I think we were using Gatsby at the time, so we ended up changing from Gatsby to Jekyll.

Chris: Whoa!

Ian: Then they wanted to change it again.

Brad: They were like, "What about Hugo? What do you guys think about Hugo?" We literally thought it was a joke. But they were straight-faced on the other end of the line. [Laughter]

Chris: You're like, "How much money do you got?"

Ian: But I think that's where I've learned the most. I started out writing jQuery and then had to convert all of that to vanilla JavaScript. I learned a lot there. I learned a lot with that situation.

Recently, I converted a React JS Storybook to React TypeScript. Those situations, you learn a lot from just doing that sort of stuff.

Chris: It almost sounded positive, though. A client throws a curveball and you manage the curveball. That's cool. You did it.

Frustrations and, like, "I don't think I can do this," or "Maybe this job actually sucks, actually." [Laughter] Or not? No? Okay.

Ian: No. I mean I don't think anything has been too, like, "Oh, I'm going to give up on this."

Chris: Mm-hmm.

Ian: I think a lot of times I'll just take a step back and be like, "I'll do this tomorrow," and then it pops into your head a lot easier. Yeah, there are times where you get frustrated. There are times where I've yelled at Brad because I'm just like, "Stop telling me to do this," or whatever.

Brad: [Laughter]

Ian: Then I'll walk out of the room and come back. It'll be fine, but yeah. There are frustrations with anything you do in this. As long as you're willing to fight it out, that's all that matters.

Chris: [Laughter] Yeah. Tell me about it.


Brad: I think, too, it's like the nature of our work is really, again, partnering with companies and organizations to help them do the right thing. That's pretty expressly the gig.

We often have a pretty good say in if they're trying to take a weird left turn off the tracks, we are actively involved in helping them not do dumb things. That's saved our butts a lot.

I feel like we've actually come off of now, I feel like, a few years of pretty successful work, which I don't know how many people could say that. I think that we've done a lot of things right and tried to protect ourselves and our clients from doing too many, too gnarly, hacky, gross things.

We're in the business of doing things right. I think that that translates to we're not having to hold our nose and do too many gross things, which is good.

Chris: Hmm. The nature of consulting is that they pay you for your expertise, so if they're not going to listen to you. I mean that gives you a little power on day one, right? That's the reason they're giving you money.

Brad: That's exactly it. That's exactly it. It's certainly a privileged position to be in, but it has carved out space for us to go not just do Angular, Ian. It's really like, okay, "How do we do this and do it right, do it consistently, and make sure that everybody is on board with it?"

It's not just doing the code part of it. I feel like it would be a shame not to mention this. Ian's gig has now shifted not just from his head down doing the work building the components.

This last project we just wrapped up with PPG was like he was taking the lead and training their whole development team and really helping them do it. He is now eating into my territory, which usually I'm the one that talks like a madman. It's kind of fun listening to Ian have to train people for a couple of hours on accessibility, API design, or whatever. It's been really cool to see him progress and take more of a leadership and an education role now that he knows this stuff better than I do. [Laughter]

Chris: Well, words of advice then for people, fellow meteorologists?



Ian: What's funny is there are actually a few people who have reached out, and they're like, "I'm a meteorologist who is now a Web designer."

Chris: Whoa!

Ian: It's kind of funny. I'd say my advice -- I hate sounding like a coach or something -- fundamentals. I think becoming strong in HTML and CSS, if you're front of the front-end, those are huge, huge, huge things when learning these new frameworks.

Become comfortable writing HTML and CSS and vanilla JavaScript. Learn things like ES6 and error functions and all of that stuff. Then maybe--

Storybook (now compared to what it was three years ago) it's easy to spin up a React Storybook and just play around and build a button, built a card, build a page in there. They have these starter kits with a button, a header, and a page built out for you. So, it's like, let's add some components and read up on that stuff.

I think that's a good way to become comfortable with working in these new frameworks, if you're transitioning from that vanilla world into framework world. That's my advice.

Brad: Just built websites. I've heard that somewhere.

Chris: Yeah. I wish you buy a T-shirt. One of these days.

Dave: Yeah. One day, you'll get a T-shirt that says that on it. Or it just says "Shop-o-maniacs" in the Hulk Hogan font, but we'll see.


Chris: One of each.

Dave: Breakaway tank top. Well, cool. Thanks, y'all. We should wrap it up. This is awesome.

Like Chris was saying, I think a lot of people are thinking about this career change. Been stuck in my house for a while. Might be stuck in my house again, so I might need a new career. I think it's cool to hear the story of evolving.

Getting to watch it in real-time, too, is kind of cool. Just like, "Hey, I'm thinking about working with my brother," or whatever. [Laughter] Then it's like, "Oh, I make enterprise design systems in React and TypeScript." That's a big change, so good job doing that.

For people who aren't following you and giving you money, how can they do that, Ian?

Ian: How can they follow me? I'm on Twitter, @frostyweather. Obviously, because I'm a meteorologist - a weatherman. @frostyweather on Twitter is probably the best way to follow me.

Dave: Awesome. Brad, how can people follow you and give you money?

Brad: BradFrost.com, @brad_frost on Twitter.

Dave: Perfect. All right. Well, thank you, y'all, for coming on. Really appreciate it. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. Join us over on the [techno voice] Discord, patreon.com/shoptalkshow. Chris, do you have anything else you'd like to say?

Chris: [Loud inhale] ShopTalkShow.com.