378: RapidFire Q&A on Podcast Sponsorships, npm Dependencies, and Front End Developers
Chris and Dave open up the mailbag and answer your questions in an return of a classic RapidFire episode. How do you know if you're a senior developer? How do we handle sponsors in WordPress?
Guests
Chris Coyier and Dave Rupert
Time Jump Links
- 00:39 How do I know if I'm ready to become a senior/lead developer?
- 04:33 Do you have any struggle when handling sponsors in WordPress?
- 12:28 Sponsor: Backlog
- 13:23 How do you go from a single design comp down to a responsive implementation?
- 18:48 How do I grow my podcast audience in a efficient yet valuable way?
- 34:58 Sponsor: Netlify
- 37:17 What have you found is the best way to keep the front-end developer and back-end developer roles separate?
- 42:27 How come when installing dependencies in a project (npm install), there are always like 38 warnings and 3 errors in the terminal!?
- 47:49 What is up with Customized Built-in Elements?
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier.
Chris Coyier: Hey! Absolutely. Just Dave and I this week. We thought we'd do a RapidFire show or answer as many questions as we can, anyway. Let's just get into it. We have Rachael N. here asking kind of a classic question that we have had a number of times over the year and it's a hot topic in the industry, which is, "How do I know if I'm ready to be a senior or lead developer?"
Rachael says, "I get recruited for these positions all the time, but my impostor syndrome gets the best of me. I have turned down two different senior role offers because I'm just not sure if I'll live up to their expectations. I love Web development. I feel like I understand the entire lifecycle of making websites. I freelance in my spare time. I've been programming professionally for about three years total."
I don't know. Is she ready? She asks us, when did we know we were ready to be a senior developer? Did it just happen, sink or swim?
Dave: Hmm. Good question. Am I a senior? I guess, technically, being the loan developer. [Laughter]
Chris: Yeah, well, we both work at such small, little companies that we just never get the title, really.
Dave: Here's what I was going to say. Take it, Rachael. Take the money and F'in run. Just cash -- get the money while you can.
This may be silly, but these are so poorly defined.
Chris: Oh, for sure.
Dave: I think you should just get the title and move up from there.
Chris: Hell, yeah.
Dave: This is capitalism Dave talking, but I definitely agree with you.
Chris: Do you want it, Rachael? Yeah? Then take it.
Dave: Yeah, but there is this, like, it's so poorly defined. We tried to define it on the show a couple, few times. I think we had a panel of, like, what is a senior developer, right?
Chris: Yeah, and I love that. There are things I think of that I still really like, like, a senior developer is a force multiplier. Absolutely love that one. It means that it's not your skill, necessarily. It's your team player-ness and you're lifting up everybody around you.
I know you're partial to the rising tide lifts all boats kind of concept. That factors in with people, too. If you're the one standing in a room that's making everybody better because you're there, that's a senior developer.
In this case, that doesn't matter. It does. That'll make you a good senior developer, but you're just trying to get the job at all.
If you've got people offering you the job, you're a listener of ShopTalk Show, people are trying to get you for this, and you want it because you're into it, clearly, if you're freelancing, it's your job and, yeah, you're living this stuff, then live it. Do it. Take it. End of story.
Dave: Yeah. I think this is yours, Rachael, Rachael Ann. I don't know if your last name is Ann.
Anyway, I think that force multiplier is a really good thing. Do people come to you with questions? I think that's a good, personal metric. If you're in a team of ten people, do people say, "Rachael, how do I do this? What's the best way to embed an SVG icon?" or something like, and you're just like, "Oh, yeah. I know this one"? I think that's where, at least in this situation where it's very loosely defined, I think that can work out for you.
If you work in an organization where it's very strictly defined, you may have to climb the ladder quite a bit. You have to maybe be an engineer 1, and engineer 2, and then a senior engineer.
If it's not strictly defined, just take the title. Get it. I hate to be that -- [laughter] -- I hate to be that ruthless but, I think, at three years, if you've been doing this job, people are probably starting to ask you questions and stuff like that. I think it makes a big deal and you could probably do that.
Chris: Heck yeah. Igor Benic writes in. I think he's working on a WordPress plugin for handling sponsorships of podcasts or at least sponsorships.
Dave: Yeah.
Chris: I think it's specifically podcasts, so a pretty niche thing but cool. He wrote in. He was kind of doing data research on us, which is fine, but we'll just do it on the show instead.
Dave: Yeah.
Chris: "Do you have any struggles when handling sponsors? Do you have a process between the sponsorship request, the purchase, and moving them onto the site from there?"
I thought it would be an opportunity for us to just explain how we do it, in a way. We have a page on the site that just says, "Hey." It's ShopTalkshow.com/advertising. There's a link in the sidebar to it, I'm sure. We just charge a price for them and you can buy them.
You don't buy them through us. You buy them through a company called Syndicate Ads, which is like a child company of a company called By Sell Ads. Now, that's the self-service way of doing it, meaning you can just look at a calendar, pick off a date, and buy it. We work with them because, hey, they offer that service and that's cool.
What makes them particularly valuable to me is that they then take over the wrangling of the advertising, meaning that they communicate with the person who bought it, get all the content together, and then let us know when that content is ready to go. We use it, produce the ad, and put it on the site. That's great because that's a lot of emailing and just back and forth stuff that I'm not that interested in doing.
It's funny because we work with direct sponsorships, too, because that's probably the way we sell half our ads. It's not direct through a calendar like that but through a packaged deal that we hand put together for sponsors and sometimes podcasts are a part of that. In that case, I am happy to communicate and make sure that that messaging is perfect for the whole package together -- that kind of thing.
It's work. Igor is asking, what kind of technological solution could be useful here. There may be things that ease the process here, but I'd say mostly it's just work and you've got to do it. It's email.
Dave: Yeah, it's email. It's a lot. People can book shows or whatever, like, "Oh, I want these four shows in August," or something like that. We can do that, but there is some risk involved on our part. There's a chance we miss a show. Somebody breaks to arms or somebody has a kid. You know?
Chris: Right. Right, right.
Dave: This stuff happens.
Chris: You know what's funny? Out of all these years, we've never had just me or just you do the show, ever.
Dave: I think once.
Chris: Once?
Dave: I think once you had to do it because I might have had a kid or something.
Chris: Oh. Huh.
Dave: I think there's just one show or two if you count the guy who hacked your website.
Chris: It could happen, though, and I don't even mind if it does. If it happened next week, so what? It happened. You know?
Chris: Right. Right, but in the grand history, we schedule and then we try to get sponsors into those shows. Our podcast editor, Chris Enns, he helps out a lot managing that and selling some stuff too.
Chris: Yeah, it's funny. There is a little bit more to the process, right? Once they're sold, scheduled, and it's clear what the advertiser wants, because sometimes they say, "Here's a script;" you read the script. Sometimes they want you to just totally spitball it. Fine.
Dave: Riff.
Chris: Talking points is probably the most common, like, "Here's some stuff that's important to us right now and riff off those." Great. I don't care. Honestly, of all three of them, I don't mind. I have no preference between any of them.
Dave: Some want you to send an MP3 to them to review to QA the spot read.
Chris: That's true.
Dave: That's okay. It's tough when it's on a tight deadline.
Chris: It is. The worst time, I think I had to do one four times, once. By the fourth time, you're just like, "Okay." [Laughter] You know?
Dave: Mm-hmm. [Laughter]
Chris: Is it you or me or what? But then, I remember it distinctly. I think I smiled my way through the fourth one because I'm like, "You know what? This is the job. This is what I sell. I sell an advertiser being happy with their spot. If they're not happy, that's me failing," so I just damn did it.
Anyway, there's just not a lot of….
Dave: We also -- well--
Chris: What's that?
Dave: Well, I was going to say, we try to make sure the company fits our ethos of a show, provides value to the listener, and provides value too.
Chris: Right.
Dave: We don't have maybe 100% approval or thumbs up/thumbs down, but I can remember situations where we've had to kind of be like, "Yeah, we're not going to do this company."
Chris: Yeah. Yep.
Dave: We've tried to keep it in the wheelhouse.
Chris: We have first right of refusal, for sure.
Dave: That's stuff, too. If you're designing software specifically for Egor's case, just because somebody clicked--
Chris: Who did we say no to?
Dave: I can't even remember, but it was Squarespace.com. Have you ever heard--? [Laughter] No--
[Laughter]
Chris: No, I don't mind Squarespace, but whatever. That's a complicated story.
Dave: Yeah.
Chris: If it was political in nature, I'd probably say no. Why go there?
Dave: Yeah, out of the wheelhouse of what we're trying to do.
Chris: Yeah.
Dave: If it was -- I don't even know what -- yeah, political in nature would probably be a probably not, stuff like that.
Chris: Just any kind of known company that looks like it sucks. It's surprising. It's not always big names. Sometimes it's something you haven't even heard of and they sell janky fonts or something. You look at their homepage and you're like, "That doesn't look right." [Laughter]
Dave: Yeah.
Chris: You're like, "Nah."
Dave: Fonts and workout supplements.
Chris: Yeah.
Dave: You're like, "Wait a minute."
[Laughter]
Chris: You know there is some technology. Yeah, we should. But real quick, the concept that you don't. Like on our show, your ad will be integrated onto the MP3 forever. Have you seen the technology where it injects them dynamically upon the server request of what gets played?
Dave: Yeah, that's wild too. They can buy out almost like an ad impression, right? Yeah. No, I think that's probably the future of podcasting, if I'm going to say. That's probably the future. I think that's kind of what Stitcher does, right? Stitcher will be like, "Hey, you want to be on our network, but we're also going to run an ad in between your podcast and your friend's podcast."
Chris: You know one of the reasons it's the future is nobody cares about the perpetuity thing. I feel like that should be so valuable.
Dave: Oh, yeah.
Chris: When you're offering an ad that gets permanently embedded into content forever, you'd think, like, "God, that's something. That's a permanent link. That's got to be worth 10x, I would think." I just don't feel advertisers are thinking that way. They're just like, "Oh, I just want some clicks. I just want to buy some impressions," or whatever. You're like, "Well, okay."
Dave: Yeah. Yeah. Yeah, I mean you'd think it would have value too. I have so many podcasting advertising deals, like, to this day I pay for products I heard on Digg.com, Netflix, GoDaddy.
Chris: Oh, it works.
Dave: These are things I heard and I still am a member of these things 12, 15 years later. To tell me podcasts are not -- I feel like they should be 10x the value of normal advertising and I would love that for everybody.
Chris: Yeah. Hey, let's play an ad right now.
[Banjo music]
Chris Enns: This episode is brought to you by Backlog. Backlog is the perfect task management software for any team. If you're not familiar with Backlog, I'll give you the URL right upfront do you can check them out. Backlog.com/shoptalk.
Developers and tech companies know the importance of organization and efficiency when it comes to collaborating on a team. What makes Backlog the perfect project management software for your team? With Backlog, you can create tasks, track bugs, make changes, give feedback, and have team conversations right next to your code. It integrates with tools you use every day like Slack, Jira, and Google Sheets.
Take your work on the go using top-rated mobile apps available on Android and iOS. Do all this and more with one easy to use tool. Create great products from start to finish with Backlog.
You can try it for free for 30 days at Backlog.com/shoptalk. Our thanks to Backlog for sponsoring this episode of ShopTalk Show.
[Banjo music]
Chris: [Laughter] Why not, you know?
Dave: You fell for it.
[Laughter]
Dave: You walked right into that one asking that question, so hey.
All right, Tyler Williams writes in, "I work on a team of designers who usually hand us designs built at 1920x1080. Our product owners reasonably want everything to be responsive. I can make 1920 breakpoint pretty spot on and I have a good grasp of basic document design and styling. I can choose a smaller viewport, say 320, and shrink it down to one column."
Chris: Whoa.
Dave: "The in-between has inconsistencies and I get reasonable, constructive feedback that the comps don't match the implementation on things like medium PDI screens. How do you go from single design comp down to responsive implementation?"
Chris: That's an interesting situation. I think there's not enough detail about who you're working with and what the workflow is to get there. You're saying you have these giant comps; 1920 is huge. Is there a column down the middle there? Are they designing the super-duper widescreen?
My widescreen is wider than that, but 1920, my God. That's way too long for a column of text.
Dave: A big screen.
Chris: It's a big screen. Then immediately the next thing you make -- you're just handed that and then you make a 320 out of it with no comp at all? You're making some choices there, bro. You know?
Dave: Right. Right, I mean this is where I would probably call yourself a designer.
Chris: Hell, yeah.
Dave: You're responsible for--I'm doing some quick math--1600 pixels of riffing.
Chris: [Chuckling]
Dave: That's a lot of riffing. That's a lot of design that happens in those 1600 pixels and you're definitely right. The middle breakpoints, like the tablet or even just large, old phones, like the 550 pixels wide, that's where it gets so weird and it's so ugly and it's so bad.
I don't know. There are a few things that I would maybe say is, one, I think it might help if your designers let go of pixel perfection. That's easier said than done because a lot of this is just playing the averages in trying to make it as good as possible but, also, ensure flexibility so it does scale up the 1600 pixels of scaling.
Then the second thing is, I would start mobile-first and work up to the big. You're maybe doing that already, but just make sure your code is growing up and not shrinking down only because I think it's a lot easier to code a website, to grow a website than to shrink it down into one column.
Then the third thing I'd maybe suggest, and I'm kind of blanking on it, but I would try to figure out a way to work with your designers more in real-time, like sharing production builds and be like, "Here is this. Pull it up on a phone or a tablet and give me some feedback," or take screenshots. I do this a lot. Take screenshots, post them in Slack, and be like, "Hey, this is looking weird at 728 pixels. I could use some direction."
Be very collaborative with your design team if possible. Maybe don't solve one layout. Try to solve multiple layouts like, "Hey, this sidebar view doesn't quite work, so how would the sidebar view work at 600 pixels or something?"
Chris: Yeah, I'm still just very caught up on the idea that somebody tossed you a 1920 comp and expects you to just invent exactly every breakpoint in between that. It's like, "Really? Not even a small comp? Nothing?" That's cool; that's a lot of trust, so if anybody has any problem with the choices you made along the way, then they need to get more involved.
Dave: Yeah. Yeah, exactly.
Chris: That's not design to design one thing and just be like, "Read my mind. Every size permutation of this should be whatever I would do if I had time, but I don't." [Snickers] Come on.
Dave: No, in the year 2019 here, assuming this episode goes out on time, we've got to be thinking mobile-first. The 1920 comp is dated, so maybe demand a mobile comp first to say, like, "All max-width is set at 600 pixels and you tell me what to do after that." [Laughter] I don't know. I think you've got to be concerned about that, too. In the year 2019, we've got to be a lot more mobile. Yeah.
Chris: Yeah. We were just talking about podcasting. We can probably talk about it a little bit more because Frederick Weiss wrote in. It was a little while back now, but Frederick is on the podcast Thunder Nerds, one of the creators of that.
Dave: Oh, yeah. Yeah.
Chris: I've been on that show. Frederick says, "I believe that I run a podcast that provides value to the community, yet I'm not getting the visibility that I'm looking for. How do I grow my audience in an efficient yet valuable way? There's Google ads and other places that I could advertise, but I'm not sure if those flavors of display ads are right for me and authentic enough for our message. How can I get Thunder Nerds out there?"
Yeah, that's a tricky game. If your end gain it to sell ads, that's a losing battle to buy ads to get audience to sell ads to. You're not going to win that game. The house has got your favor there.
Do you have some numbers in mind? Do you just want it to be a bigger show? The goals seem a little bit vague to me because all you said here is that I'm just not getting the visibility I'm looking for. It's not for lack of trying. I can obviously tell. I go to the website now; 227 episodes. Holy cow! You're doing great that wise.
Dave: It's a lot.
Chris: It's not through lack of effort. The website is fine. You're on all the platforms. It doesn't seem like you're doing anything technological or content wrong, too, because it's a lot like other podcasts, it looks like, like ours too that has some big names of tech people in it. You're even leveraging their audience, too. I am kind of curious what's happening there.
Dave: Yeah. I think I have a blog post in my draft folder about what I think makes a successful podcast. I think there are two core components. One is consistency, and sometimes to a fault. I think having a weekly schedule is maybe more important than having really, really good content, if that makes sense. Being delivered every week and showing up in people's podcatchers is probably the most, like on a consistent cadence.
Chris: That's funny you put so much value in that. Could you go into that more? Why do you think that's such a big deal?
Dave: If I only check in once a week or let's say the average listener has five drives, to work and home from work or something.
Chris: Mm-hmm.
Dave: A podcast like ShopTalk is an hour-long, so that's like a drive there and a drive home, or something, let's say. Right? They're going to listen to five podcasts a week.
Let's say we don't show up on week two, right? Then we're like, "Oh," but then, week three, we come out with two episodes or something, we batched them weird, or whatever. It's not a routine. It's not like, "There's ShopTalk. Every Tuesday, I listen to ShopTalk on the way to work," or something like that.
Everybody is different, but I'm just kind of like the baseline for me is, you've got to show up consistent so that you're a familiar face, you're reminded, you have to be digestible or good enough content. Make sure you're not going too long. Make sure you're honoring people's time. I think that's very important.
Then, number two, I think, honestly, a lot of the podcasts, if you look at large [ones], a lot of the successful podcasts are based on a previous success, if that makes sense. ShopTalk probably rides the coattails of CSS-Tricks a bit. Just like CSS-Tricks was a success, we're kind of riding that.
Syntax.fm--
Chris: Yeah.
Dave: Wes and Scott have killer courses. You look at Gimlet Media, all of those is because they worked with This American Life before that, which was an NPR show back when you could only listen to one NPR station at a time.
Chris: Yeah, all these comedy podcasts for people that are just funny anyway, so they get a show and they do that.
Dave: Right. Right.
Chris: I think that's almost always the case, almost always. Maybe that's the issue. If I poke around at your site, Frederick, I hope this isn't too personal, but your personal website is actually very nice and seems fine. It's like my thing is, I have some Java or whatever, but I do this podcast. Maybe can you throw a blog on that personal site and do that too, so the podcasting just the whole pie. It's not like everything you do. You're known for your writing, you have videos of you speaking, or something that it's not just the thing, especially for a niche show like Web tech like this. This is the smallest thing, I would think, Dave and I do.
Here's another trick. You could just stop caring if you're successful or not. We're certainly not betting the farm on this podcast. It's like a nice, fun thing that we do, but I do it because I like talking to Dave.
Dave: [Laughter] Aw!
Chris: The beer money doesn't hurt.
Dave: Thank you, buddy.
Chris: [Laughter] Yeah, but you know what I mean.
Dave: Yeah.
Chris: It depends on what your goals are. We keep our goals low. [Laughter]
Dave: I do another podcast with my friends Dahn and Zach. It's about videogames. It's called
Would I love more people to listen to it? Absolutely. Could I hustle some more and broadcast that? Probably a bit more.
It's sort of this thing. It's like, what are you wanting to get out of it? What are your goals? What would be the results and what you're looking for? I think, for us--
Chris: Here's another one. I like that too but, even when we started this one, looking around we were like, there's an awful lot of just interview, just like, "We want to know the story behind the person," kind of thing.
Dave: When did you first figure out you were creative?
[Laughter]
Chris: Every podcast is that and you know why? Because it's interesting. It's good. The interview format, the reason it's ubiquitous is because it's kind of a good format. You get a good guest on; it can be an amazing show. But everybody is doing it, absolutely everybody, so it's not a way to differentiate yourself.
The people that you get--I don't know--don't ask me. This is general advice. I've told my same exact story a million times. In fact, now when I get an email about interviewing me, I almost always say yes because it's flattering, it's fun, and might as well, but I'll almost always put something in the reply email that's like, "Listen. I have told my middle class, white boy, growing up privileged in America story a million times. There's nothing interesting in there. Maybe it's interesting to other people more than me because I've told it a bunch of times, but I'm telling you, I can tell you about how I went to college for ceramics. It'll be interesting for 30 seconds, but it's not the bedrock from which a great podcast is built. [Laughter]
Dave: Yeah. Yeah.
Chris: What is, is break a story. You know what a good story is. Break a story. Find some interesting tech nugget, even if it's a story somebody else has already told. Now, I see this happen on big podcasts all the time. Somebody will publish a great book or something and they'd do a podcast that the story is just kiped from the book. You're like, rude.
Dave: Yeah.
Chris: But it's such a good story that they did it anyway because it might be how people are…. You know what I mean? Do a little journalism. Find a juicy story. That's what gets shared around.
Dave: No, I mean there are a lot. I think you could even go in and what are people talking about? We want to talk about what people are talking about right now, or something. Chris and Dave don't do a good job or something like that. Find your angle.
Chris: I know there's a good example.
Dave: What is your spin that you can put on it? There's reasonably the Ladybug developer podcast.
Chris: Oh, yeah.
Dave: Which is for women doing a podcast. That's awesome. I love that because it's a different voice than what the average voice is in podcast land. That's for women developers coming around talking about things. I think that's great. We need more of that.
I also think it's okay, like, what's your spin? What's the flavor? Just establish that. Establish that formula. Maybe you add something different.
We started this podcast. We had a soundboard. Not a lot of development podcasts had a soundboard when we started.
[Mystic chimes, crackling]
Chris: Mmm. This is a good, hardboiled egg.
["Law & Order" opening sound]
Dave: It's dumb and gimmicky, but straight up that's something people remember.
Chris: Yeah.
Dave: A lot of people did not like our gunshot sounds, and that's why we don't do those anymore.
Chris: Along that side, edit it. We've never done that. We have an editor, Chris Enns. He does a great job. But I mean edit, edit it. You know? We've never tried that. One time, we tried to do it and we ended up failing and scrapped the damn thing. It was like, get clips and edit them together. Have a post-process in which you're bringing to life the story that you're trying to present, which is different than like we do, which is, we hit record, we hit stop, and Chris does the levels, puts the ads in, and smooths some stuff out.
It's not editing in that sense of, like, you're a director of this podcast. Obviously, it's a lot more work, but that's what makes a beautiful podcast. It's been on my mind for YEARS, Dave.
Dave: Sometimes I'm like, "Hey," like you read a blog post that's really good or whatever. Sometimes I'm like, "Oh, man. Could we pay the person who wrote it to read it?"
Chris: Yeah.
Dave: Could we, for $10? Then we're going to put it on our podcast. Then we're going to kind of stitch it together in a theme, sort of like this American Life.
Chris: Ooh, and then you have segments. How fascinating?
Dave: You have segments.
Chris: That's a great idea.
Dave: Then you hop on there, and you go, "Hi. Welcome to the show."
Chris: Yeah.
Dave: "Today, we're talking about websites, how they impact us, how they move us, how they change the world. Our story, in three acts," you know? You just make a formula, and then you have three people just read their blog posts.
Maybe it's an edited version or just part of it or something like that. Maybe they read it, and then maybe act two is you kind of interview them about it. Set it up, have a musical break, and stuff like that. We don't have musical breaks. Maybe we do right now, Chris.
[Upbeat music]
Dave: All right. We're back! [Laughter]
Chris: You know what the JS Party did? They do interesting formats sometimes, I think, is pretty cool. Episode 87, they did "Websites Should Work Without JavaScript. Yep? Nope?" which is great.
[Laughter]
Chris: I listened to it on my way to work and they split into two with a moderator and then had to debate club each other.
Dave: Ooh!
Dave: Two people were assigned that Websites should work without JavaScript and two said, "Oh, that's silly. JavaScript can be a requirement." It was fun because it wasn't necessarily their personal opinion. They were assigned to advocate for that position.
Dave: Love it. I'm going to download that right now in my podcatcher of choice.
Chris: It was fun and it gets better as it goes on because, in the beginning, they have to make very broad opening statements. I think broad statements is too hard when you're talking about the entire Internet. [Laughter]
Dave: Mm-hmm. Yeah.
Chris: Later on, it gets more nuanced and "What would you do in X, Y, and Z situation?" It inspired me. I have an article I'm working on about it.
Look at how great? Just that interesting format really was a good listen, interesting voices. It's got me writing a blog post about it. It's a little bit better than, "Hey, where did you go to college? When did you know you wanted to be an actor?"
Dave: Well, and I think there's also something, too. You want to be active in communities. I feel like you could just hop on our Web dev and just be a familiar face answering questions, or stack overflow, or whatever. I hate the term "build an audience," but that's basically what it is. Just go and do things. Be a familiar face.
I think Twitch is probably the next frontier here. We were talking about it before the show. I'd love to start a Twitch. I just have to get my clients to buy in on it.
Wouldn't it be cool? I don't know. You have to make sure you're contributing as well, like you're putting out blog posts or answering questions on our Web dev. Whatever. Be a familiar person and then let people find your podcast. I think that's a very important thing in life.
Maybe our Web dev is too big. Maybe you need to just be in our /Vue or our /React or something.
Chris: Perhaps, yeah. Niche it out a little bit more.
Dave: Don't do it bad. Don't do a bad guy and don't be a sleazeball self-promoter but be there; be helpful.
Chris: Yeah.
Dave: Then I think you have to kind of be a known entity. Not saying you're not.
Chris: It works both ways, too. Can you imagine a blogger being like, "Oh, nobody is reading my blog posts"? It's probably because I don't have a podcast yet. You know? [Laughter] Well, eh, but it's both. What if you had both?
Dave: What if you had both? Do both. Do both. Yeah, it's like we said in an earlier show. "I wish I had a $7 thing or $9 thing somebody could buy. Wouldn't that be cool if I had the blog and the podcast and the thing to sell?"
If I just cold-called, changed my name and everything and just was like, "Here. Buy my course," no one is going to buy it. You've got to reach out and talk to people. Share opinions, share what you've learned, and stuff. It's old Web stuff, I think. That's what I'd say.
I think that's general advice, not specifically for Thunder Nerds because it is a good podcast. You could also write into another podcast and ask them about your show. That's another trick to build your audience. [Laughter]
Chris: There are a lot of tricks we haven't figured out, so just know that not all of that was directed at Thunder Nerds, necessarily. It was just kind of general riffing.
Dave: Growth is hard. Growth is hard. I think we, more or less, had the same numbers for a long time just because people go in and out.
Chris: Yeah, we're still pretty flat, really. It's not like we're in a super growth phase, really.
Dave: Yeah.
Chris: You see podcasts that just kick-off and they just blow right past us because they just do something a lot better than we ever did.
[Banjo music]
Chris Enns: We've talked a lot about Netlify Build before, the Git workflow for Web development where you can build, deploy, and manage modern Web projects super easily with Netlify. They just launched something new they're calling Netlify Dev where you can run their entire platform right on your laptop or your desktop, I suppose, too. You can preview it all: site generation functions and edge logic. Imagine the productivity boost of being able to locally test your site generator, API integrations, serverless functions, and edge rules all in a single development server. That's Netlify Dev, a powerful way to build and test modern Web apps on your local machine.
With one simple command, you can install Netlify Dev to use on any project. That'll spawn a fully local environment of Netlify Dev that automatically detects and runs your site generator, makes environment variables available, performs edge logic and routing rules, and compiles and runs cloud functions. The extra bonus is that you can even stream that live, so Netlify Dev takes hot reloading to a whole new level, allowing you to actually stream your dev server to a live URL, which is great for collaborative development. You can now share your work as you work and get instant feedback. I could be working on my site. I could have it open in a browser, open on my phone, see the changes live as they're happening, but you could also have it wherever you are in the world open on your browser or on your phone. Whenever I update something, the site will update, and you'd be able to see it.
Netlify Dev automatically detects common tools like Gatsby, Hugo, Jekyll, React Static, 11ty, and more, providing a zero-config setup for your local dev server.
Netlify has faithfully replicated their powerful edge logic engine in WebAssembly so you can locally test all the same rules before deploying them to their global infrastructure. You can write cloud functions in modern JavaScript adding needed dependencies. Netlify will compile your functions as AWS Lambdas and deploy them as full API endpoints.
Local testing works too. It all comes with Netlify Live, a hosted service that continually runs your dev command just like you do locally, watching for changes. The result is an instant preview you can share with your entire team with live updates as code and content changes.
Like I said at the beginning, Netlify Dev installs with a Netlify CLI. Create new sites, set up continuous deployment, and push new deploys right from the command line. Netlify Dev is just the beginning. Take your local developments to Netlify Build, power collaboration through Netlify's Git-based workflow with deploy previews, branch testing, and more.
Check out Netlify Dev at Netlify.com. Our thanks to Netlify for sponsoring this episode of ShopTalk Show.
[Banjo music]
Dave: The next question, an audio question, our favorite kind of question here on the ShopTalk Show, Zach Handing writes in.
Zach Handing: Hey, guys. My day-to-day involves writing all the semantic HTML, CSS, and JavaScript for our client projects. Then I hand my code to one of our back-end developers to integrate into whichever CMS we're using. Typically, it's Sitecore or AEM. My question is, what have you found as the best way to keep the front-end developer and the back-end developer roles separate while avoiding maintaining two completely separate code repos? Thanks.
Chris: I didn't expect that to be where this was going. You're trying to work less together?
[Laughter]
Dave: We don't like each other.
[Laughter]
Dave: Maybe it's like they want to keep working on the front-end, you know, without all the legacy back-end stuff. Do you do anything like that?
Chris: Hmm. Yeah, I mean I'm just trying to wrap my head around it. Zach does HTML, CSS, and JavaScript, does that first for whatever reason and then says, "Here you go, back-end developers. Make this thing work in the CMS." He wants to keep doing that, it sounds like.
You've got to start somewhere and you can't just keep all your code on your computer, so what do you with it? Do you have a repo that's called myproject-fed or something because it's just the front-end part or what? I don't know.
Dave: Brad Frost had a post recently, "Front-End Design, React, and a Bridge Over the Great Divide" kind of talking about Chris's great divide or kind of what we learned here on the ShopTalk Show. Anyway, he's advocating for things like React, Vue, Angular, or whatever you have kind of being the bridge between the design tool and the markup, like the pristine markup and then the back-end integration.
The idea here is, somebody can take your React front-end code, make some minor modifications, and make it back-end ready -- if that makes sense. They can just plug it into the back-end. Where maybe you're using dummy data in the designer experience, you can just plug it into the back-end. This makes a lot of sense to me. This is sort of where we're going in our code, design systems, and things like that.
Would it be great if you could just do HTML with HTML imports? Yes, it would, but you can't, so you're kind of looking at the JavaScript to leverage that into everything. That might be a solution for you.
Chris: Kind of tricky. Delivering a design system, that's just kind of the root of it, right? If you build that, it'll be useful wherever.
Dave: Yeah, and I was going to say, Tyler Sticka on the Cloud Flour blog--and I'm live googling here--he had an article. Cloud Four is doing design systems, PWAs, and things like that. He had a really good post. I think I really like it, but it's tips for portable patterns.
Chris: Hmm.
Dave: I'll drop a link in the show notes. He kind of organizes his codebase like a React, Angular, or Vue project where you make components and those are in components folders. Then inside whatever component buttons, you have a button.css, button.js, and a button.handlebar. He just has the template, the JavaScript, and the CSS needed to render that component.
I find that to be a pretty good way to do it. That way, everything is pretty self-contained. You're separating concerns, but you're also bundling up components. You're kind of doing component-driven design. Take a look at this.
For me, this is kind of what I've been trying to do and it was very much like, this is how we're doing it. Then if they implement it in React, AEM, or whatever, they can do whatever. They can modify the patterns but, if they see a change to whatever, pattern.css, and now to change to pattern.handlebars, then they know, "Oh, this is a CSS change, not a markup change, so I can just drop that file." Maybe that helps.
Chris: Christian Noll says here, "How come when you're installing dependencies in a project, like NPM install, the command line might spit out a thing that says, like, 'Thirty-eight warnings and three errors,' in the terminal, even at high profile project repos? Doesn't anybody have a stable group of dependencies? Should I be nervous about this?"
Dave: Uh, this is a good question.
Chris: It's NPM warning you, so they do their own audit, right?
Dave: Yeah, NPM Audit is a thing. It's like security warnings, like these are known vulnerabilities. These packages, they use Snyk or something like that to find out, like a package vulnerability database of some kind. Man, I had 16,000 the other day.
Chris: [Snickers]
Dave: I think it was Jest, like Jest the testing framework.
Chris: Right. Yeah.
Dave: I'm sure they've patched it since then. But, man, 16,000 vulnerabilities; that was pretty serious.
I have seen, like when you install and it's like, "Error. Couldn't install," whatever -- some plugin skipping. [Laughter] Have you ever seen that where it tries to install something?
Chris: It just fails and it just doesn't?
Dave: It just says, "Ah, I'm skipping.
Chris: Hmm.
Dave: Skipping, but then the project still works in compile, so it's like this weird, optional dependency or something. I've never really understood that.
Chris: Yeah. I don't understand that, necessarily, either. Also, a lot of times -- so just for the core of it here, I feel like if you run that audit fixed command, in my experience, it just fixes all of it. Then it changes some version numbers in your packaged JSON and Lock. You just commit it and you're back to normal. The only reason you're seeing them is because whoever has that repo just hasn't done that in the last week or so.
Dave: Ah. Yeah.
Chris: Maybe sometimes they're more serious than that but, usually, not. I feel like I've seen this a million times. I run the command. It upgrades some dependencies. Ship it.
Dave: Yeah, this is so weird. I didn't know you could do optional dependencies but, yeah, there's a flag, "No optional," to skip optional dependencies.
Chris: Is it like if it uses--?
Dave: I see it on Windows because it tries to install FS events, file system events.
Chris: Oh, which is not a thing.
Dave: Which is a Mac-only thing.
Chris: Yeah.
Dave: Some things try to use that and they are built off of that, but it's so weird. Anyway--
Chris: Fascinating.
Dave: I don't know how you specify an optional dependency. You know what I mean? I have dev and -- anyway.
Chris: Yeah, I don't know. Yeah, because there are a bunch of different types, right? We went through all this while we're still, after all this time, developing some NPM feature set at CodePen. It's just a hornets' nest of difficulty, of course, but we'll get there. Anyway, there are dev dependencies and dependencies, right? Those are pretty clear.
Dave: Mm-hmm.
Chris: The idea is--
Dave: I understand that.
Chris: Yeah, that one is clear. But then there is another kind, right? They're not optional, though. There is like a middle kind. I forget what this one is called.
Dave: Test?
Chris: No.
Dave: Test goes into the dev, I think.
Chris: The truth is that people get them wrong all the time. It kind of like doesn't matter. Even pretty big repos just have the wrong stuff in the wrong section.
Dave: I will tell you, man. I will never forget the day I wanted to get an NPM package counter package. I NPM installed package counter, or something like that. It installs a whole bunch of stuff. At some point, it starts recompiling Sass for, like, a command-line utility that just counts the number of packages in a folder. I just was like, "Oh, man. I'm out of here. I just wanted you to parse my package-lock," or something. "Just give me a rough number," but it started recompiling Sass, and so I just quit out of it.
All this to say, somebody had some dependency in there that triggered another dependency that didn't need to be there. Dependencies are rough.
Chris: It's a peer. That's the one I was thinking of, which is just like--
Dave: Peer dependency.
Chris: Yeah, it's like tangential. Maybe even -- what's an example of a Dave jQuery plugin? Fids or something.
Dave: Fids, yeah.
Chris: You might put jQuery as a peer dependency because it needs jQuery, but it's a peer, you know. I don't know if that's a good--
Dave: Okay.
Chris: It doesn't need jQuery to run to execute, or it kind of does I guess, so maybe it is. It's a tricky one, but I think of it as just something else that you probably need to go with it, but it's not necessarily a dependency.
Dave: Hmm. Yeah, that's wild. Whoa!
Chris: That is definitely misused. [Laughter] So, good luck with that.
Dave: Yeah. Oh, I can't even. Yeah, I guess live here on the podcast, I'm trying to be like, "When would I use that, exactly?" That's tough.
Anyway, well, is that our last question?
Chris: Let me read one more. I'll just pick one off of our Trello integration here. Why not?
Evan Minto writes in, "I can't remember if you've talked about this, but what's up with customized built-in elements? Chrome 67 recently enabled them and Firefox is working on an implementation, but Safari seems fundamentally, permanently opposed to them." Do you know he's talking about? What's a customized built-in element? Like a Web component?
Dave: Yeah, like the "is equals syntax" on custom elements.
Chris: Oh, right, right, right.
Dave: Like button is my button and you add a bunch of behaviors and bind a bunch of stuff.
Chris: You get all the benefits of button and you can write your own JavaScript and stuff to it?
Dave: Yeah. Instead of your top-level -- it's basically like the top-level wrapper of this is going to be a button and then I want you to modify.
Chris: That sounds awesome.
Dave: Create a Shadow DOM instead of the button and do everything. Do everything inside of the button.
Chris: I could see how it feels scary but also cool because that means it's stopping people from implementing their own buttons.
Dave: Yeah, and if you think about audio or something like that, audio is a podcast player, or something, and that has the 1x, 2x, 3x buttons or whatever.
Chris: Mm-hmm.
Dave: You could think of that, like these would be ways to extend native elements and even use the Shadow DOM to give your own UI or select is custom select, like I'm going to take a select box and make it my own thing. These are kind of common use cases for that.
Yeah, Safari has, I think, said, "No, we're not going to let you customize native elements. Sorry."
Chris: That's funny, isn't it? If two browsers like it and, not only like it but, agree on it and ship it, that's enough for a Web standard, right?
Dave: Mm-hmm.
Chris: Then it can move along the spec process and be finalized. At that point, does Safari just say, "Oh, well. I guess we lost this one. We have to implement it"? There are no laws around this stuff. They can F'in do whatever they want, right? It would be kind of in bad taste to just never do it once it's a standard, right?
Dave: Right. Yeah, really, I mean at least for the Western mobile Web or whatever, that really throttles what we can do that they just say, "No," and then it's like, well, we don't get it until next year, maybe. Maybe we'll get it next year. They don't tell us what we're getting, but maybe we'll get it next year.
Chris: Remember we've talked about on the show, which I haven't been able to get out of my mind, really, is all the awesome stuff Chrome does. In a sense, I think you called it DDOS'ing Firefox on features.
Dave: Yeah.
Chris: Because they just can't keep up. Then sometimes they're just kind of dropped in Chrome, although this is a very nuanced thing. I just saw one the other day, or today maybe. Where did I see it?
It was like a native content or contact picker for the Web. You know how the Web payments API is native in-browser payment stuff, so you could save credit cards in your browser and then the browser can ask for that data. It's securely transferred over, which is really, really cool because it just reduces a lot of checkout payment problems. Every browser in the world has saved passwords, right? Why doesn't it save your credit cards too? Then you're about to check out and just go "whoop," and just send it all through.
Now, it doesn't just drop your credit card data into a form because who knows what's happening there. That's scary. It's an API that handles all the scariness. Cool, so this looks like, in vein of that, a contact picker. Why can't the browser have an API that attaches to your native contact picker and has all the security stuff built-in? I can pick Dave Rupert from a list and maybe his address auto-fills or who knows what it does with that data. It looks pretty cool, you know.
It's just like, where did this come from? Was it a spec first or is this just the hordes of people working on Chrome just be like, "Hey, this would be cool. Let's do it. Here you go"?
Dave: There's been a lot of talk lately, but some of these are because these features are made because somebody needs it. A company with a big enough name needs it.
Chris: Yeah.
Dave: Why do we have CSS Grid?
Chris: Some big company wanted it.
Dave: Because Microsoft needed it for Windows 8. Microsoft needed MS Grid for Windows 8 and MSN.com and then, I think, Bloomberg or something was like, "We'll implement that," or whatever, "in Chrome," or something like that because they wanted it.
A lot of these features exist because somebody wants them.
Chris: That’s good, right? I don't know. I'm sure there's nuance to it, but I feel like I've heard that said in the past. That's where we want ideas to come from. Needs, real needs.
Dave: Yeah. WebKit has this wet floor. Have you seen WebKit Text Reflect, or whatever?
Chris: Yeah. Yeah, yeah.
Dave: Or Box Reflect where you can create this shimmery wet floor. That's all from Apple marketing in the early 2000s or whatever.
Chris: Yeah, right, but it's behind not a flag at the time, and it was a dash WebKit.
Dave: Vendor prefix.
Chris: A vendor prefix, yeah.
Dave: Yeah, but it's in some other browsers too, and so we have this now.
Chris: That was the problem with vendor prefix is people started using them and then, all of a sudden, you got Firefox being like, "Well, I guess we have to implement your frick'n WebKit prefix because enough people used it; we had to for compat. Wow!
Dave: Anyway, I think, for me, yeah, it is good. These are meeting actual needs. For me, it's also not. I don't know. It's just like one company wants it so they put it in the browser. How do we get Apple to be like, "Yeah, I actually want Web components to work"? [Laughter] I think they said that to the custom elements V2 or whatever, which is what I think is syntaxes. I think Apple basically said no to it, and so now it's dead. Is all of Web components now dead because Apple is shutting down?
Chris: Maybe.
Dave: It's not dead. I'd hate to be dead. Dead is a strong word, but it's severely hindered.
Chris: Yeah.
Dave: Now we have to undo or, I guess, re-figure out what we're doing here. Yeah.
Chris: It's dangerous territory because if there is perfect implementations in all of Chromium-based stuff and Firefox, then developers start being like, "I'm just going to use this. I don't care," which is dangerous territory.
Dave: Yeah. Mm-hmm.
Chris: It's also dangerous territory for browsers to just be like, "No, I'm putting my foot down so hard on this thing that I just will never do it." It's dangerous. It tiptoes into browser war stuff. If browsers totally stop being friendly with each other then, God, save us all.
Dave: There has been some talk. I've heard it in a couple contacts, but I think I mentioned it before. Mike Taylor from Mozilla, he spoke about something Mozilla had to implement because IE5 implemented something and then KHTML conqueror, which then Safari was built off, also implemented it, and so Chrome has it. Then it ends up, IE made this weird thing called window.event, right? It's weird, but it's basically the current event that's happening in the window right now, like a click. Window.event will say, "This click event."
It's so weird, but people started building off of it, off of a non-spec for IE. Then it got into Safari and everything. It doesn't work in Firefox. They have tons of issues, and so they go out to fix it. They fix it, and they ship it. Then it takes down confluence, just takes it out, and just wrecks Jira or whatever. They're like, "What the heck?" Now they have to have an if statement in Firefox so, if confluence then don't do this.
Chris: In the browser, they built that in?
Dave: In the browser, yeah.
Chris: What?!
Dave: Shipping this feature, this non-standard Web platform feature that's now kind of a standard.
Chris: Can't they just put window.event back or whatever? They didn't want to do that?
Dave: Well, there's a bunch of logic. Usually, it's like a WYSIWYG editor or whatever that people are using. They'll go check on it and see how many times they hit this threshold or whatever. Yeah, basically, fixing the platform bug broke websites because they relied on these, "If Firefox, do something else," or something. Anyway, it's dumb. It's messy.
Mike Taylor was kind of just pitching. He was saying, like, "No one at Mozilla is actually thinking this, but what if we all reset and fork off of Chrome? What is life like? What did we win? What did we lose?" maybe that's a good place to end the podcast but I've been thinking about it.
Chris: [Laughter] Just cut to black?
Dave: Just cut to black. Fade out to black.
I've been thinking about it because it's like, "What do we lose?" I mean there are people who are like, "I had it," and I totally get that. But it is sort of like, "What if we just reset? What if this is the new 1991 where we all fork off of Netscape or something like that?" Maybe this is the new 1993 and so we reset and then we kind of go from there.
Chris: People get to compete on browser features? I'm always so attracted when a browser drops a feature that's not a Web standards thing, it doesn't affect how websites are rendered, but it's just a super cool browser feature. It's like a UI thing, a helpfulness thing. It changes how it remembers your history or helps you do something on the Web. You're like, "Awesome! That's totally what you should be competing on. Love it!" You know? [Laughter]
Dave: Edge, for me, is that. I like Edge mountains more than Chrome. All respect to the people who work on Chrome who are listening to this, no doubt. [Laughter]
The Edge stuff, I like how it looks more. It's better looking to me. The dev tools theme is better to me. There are half a dozen things that I'm just like, "That is better than what Chrome looks like, and so I'm going to use Edge."
Stuff like that, that's cool. Brave is another Chromium thing. They're like, "Oh, you get a crypto wallet," you know?
Chris: Yeah!
Dave: You can visit website and donate to them.
Chris: I just signed up for that thing.
Dave: I think that's really dumb.
Chris: I've still got to figure out how to--
Dave: You did?
Chris: Yeah, the Basic Attention Tokens or something.
Dave: I want to hear how many bitcoins you have by the end of this because I just don't see that being a feature that people will use. Anyway, it's just interesting.
Chris: Oh, I don't know. I don't know if that one is going to win, but Bruce Lawson has got me trying -- I'm about to go off on a tangent, but to check out coil.com, like a spring but a coil. It's whatever. It's just yet another one of these micropayments from the people that look at your thing. You sign up and you pay them $5 a month. Then it distributes your $5 to the websites you visit that are monetized in this way, which will be like 0.001% of the websites.
I put it on CSS-Tricks. But Bruce had me convinced because they're pushing for it to be a Web standard, literally a Web standard metatag that you put on there. You put a wallet ID on it that's also a standard that these online banks can implement. Then it won't just be a Coil thing. It'll just be anybody who wants to build a monetization system is built off of this Web standard. It works like there's a document object in the DOM.
Dave: Yeah.
Chris: There'll be thing off the end of it called document.monetization, and so you test for it in your code. You say, "Does document.monetization exist?" It will if the metatag is there and it's doing its thing.
Right now, this happens through a browser extension that you have to install, but it works in the way that they think the Web standard should work, so I've got it installed. I have a paid account as well. Then you wait for an event because it doesn't happen right away. It has to do some crap to talk to the bank and prove that you have funds and all that stuff. It takes about two seconds, which I find way too long but, you know, such as it is right now. You'll get an event and then document.monetization.started will have a value of monetizing, not monetizing, or whatever. There are some standard values.
You can tell totally anonymously whether somebody is paying you or not on the site. I can't tell who you are. I just know that you're giving me some money, some micropayments. For example, it's trivial for me to write a feature that just doesn't show you ads.
Dave: Yeah.
Chris: Or I could put a secure download link to my e-book because you're monetizing.
Dave: Yeah. You have window.monetize. You could say, "If window.monetize, do nothing," or the monetized one or whatever.
Chris: Yeah.
Dave: "Else, put ads." That's cool.
Chris: You have all kinds of information about it, too, that happens as part of this document process. Yeah, it's cool. They're hoping that. They're just the company that started it, but they're hoping to make it a Web standard and then just compete against everybody else.
I was like, fine, I'll sign up for it. I've made a few bucks so far. Fine. I mostly just think it's interesting. It's not replacing anything. But if it becomes a Web standard, that's a big deal. Look. I'm signed into my little account right now. I've made $7. Seven bucks to me isn't that much money, but it's not that bad.
Dave: No.
Chris: There are parts of the world where $7 U.S. goes a lot further than in the United States.
Dave: Oh, man. I only make $20 on my ads. I don't know what that equals per view for you, but that's good money.
Chris: I think it's cool.
Dave: Compared to zero dollars with somebody running an ad blocker. You know what I mean?
Chris: Google has got a thing too called Google Publishers or something. It's the same kind of concept. There is this Brave attention token thing. I'm going to put them all on my site if I can. I think you've got to be invited to the Google one, but why not? Why not play this little game for a while and see who wins and see if they can all agree on a Web standard? I think that's good for the Web.
Dave: Yeah. No, I like this. I might sign up and become a member. Why not? This is what you want to support, right? Five dollars a month, $60 a year, I'm supporting the Internet and publishers, and it's pretty cool.
Chris: Yeah, at the moment, it's kind of Coil focused, so you've got to play that game a little bit, but it's nice. It's nice software, as far as I can tell.
Dave: Yeah.
Chris: It helps that a guy like Bruce Lawson is the guy telling me about it. I have some trust for him that goes a long way here. If I just got an email about this from any old random person, I'd probably have been like, "Um, I don't know."
Dave: From Turd Buckman.
Chris: Yeah.
Dave: If Turd Buckman, Silicon Valley entrepreneur--
Chris: I might look at it and be like, "This looks nice, but meh." But you have a friend and a long-time Web standards advocate like Bruce telling you, then you do add it.
Dave: No, that does. This actually seems--I don't know--more interesting to me than the bitcoin thing in Brave. Those could also be the same thing in two years when this gets standardized, or whatever.
Chris: Yeah. If one of these wins, you better believe the rest of them are going to just hop on the Web standard, I would think.
Dave: This would be great. Yeah, I think this is good. Yeah, I don't know. I like it. I would love it. I don't know. We definitely need a new monetization system on the Web and, hopefully, this gets us there. Who knows?
Chris: All right.
Dave: Well, speaking of money, be sure to hit that subscribe button and that like button on your podcatcher of choice. That really helps us out. Head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. I forgot to mention our Twitter, @ShopTalkShow; tons of tweets a month. Chris, do you have anything else you'd like to say?
Chris: ShopTalkShow.com.