A bit of follow up from the last episode, getting your team on to the same tooling - and cool things in VS Code, import ordering, the new Chrome API eye dropper, and some YouTube thoughts and ideas.
Time Jump Links
Episode Sponsors 🧡
Jetpack’s performance features make your site lightning‑fast, while also improving your SEO and giving your visitors a better experience.
Free speed enhancements to rank higher on Google. Free global CDN to deliver content instantly. Instant site search to help your visitors find your products and content.
After working with thousands of startups, we’ve noticed that technical founders spend a ton of time building internal tools—which means less time on their core product. So, we built Retool For Startups—a program that gives early-stage founders free access to a lot of the software you need for great internal tooling.
The goal is to make it 10x faster to build the admin panels, CRUD apps, and dashboards that most early stage teams need. We’ve bundled together a year of free access to Retool with over $160,000 in discounts to save you money while building with software commonly connected to internal tools like AWS, MongoDB, Brex, and Segment.
We give you a head start with pre-built UI components, integrations, and other advanced features that make building from scratch much faster. To learn more, check out our site, apply, join webinars and much more at retool.com/startups.
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. Hey, Chris. How are you?
Chris Coyier: Fantastic. What's happening, man?
Dave: Well, you know, I thought we would start the show off with a couple of corrections. [Laughter] Well, actually not corrections. Addendums.
Chris: Yeah, advice.
Dave: Yeah, so we were talking. We riffed the last episode - or whatever - about, like, wouldn't it be cool if you could get style lint - or whatever - a little feedback like, "Hey, I'm using the CSS property, but it's totally not supported," or whatever? Was kind of riffing on an ideal tool, and a couple of people wrote back.
Maleque -- and I'm probably pronouncing your name wrong; I apologize -- was like, "Hey, there's a can-I-use extension in VS Code that you can use," so that's cool. So, it will tell you, like, "Oh, yeah. Checkbox in all these browsers as you're on the property."
Chris: Oh, I see how it works. Oh, that's a lot of information, though.
Dave: That's a lot, you know, and so then there's another one. Ryan Clements wrote in and was like, "There's a style lint extension for style lint no unsupported browser," so like you can fail a build or you can just warn, which I thought was kind of the cooler option. Just warn if this isn't supported, like, "Hey."
Chris: Yeah, that's kind of good, right? But even in the examples show a big warning about Flexbox and how it's not supported by IE 8.
Chris: And you're like, "Uh... I don't want that. That's going to annoy me the second I install it." You know?
Dave: Yeah. Yeah. I think both of them kind of had that, maybe. I need to verify because one is like, uh, yeah. I would need to drive them a little bit more to be like, "Yes, this is the dream." You know?
Chris: The first thing that crossed my mind is that it should use the browser's list thing. You know that thing, that auto-prefixer I think started, but other technologies use it where you say, "These are the browsers that I'm trying to support."
Chris: Then it uses that, and it looks like this does that. It's just unfortunate that their screenshot shows Flexbox. But if you had IE 10 or maybe even no IE support that it wouldn't show you that error.
Chris: I was more interested in the newer ones. I don't really care about that iOS 2 didn't support linear gradient or something. I don't care. But I do care about nuanced scroll snapping stuff or new gotchas that I'm less aware of because they've just changed over time.
Dave: Or even you can use appearance instead of WebKit appearance, or something like that. I always forget the rules.
What is it? The Firefox dev tools do this. I think other dev tools have started doing this where it'll tell you, "You actually don't need this." That would be cool, too, to have in your editor.
Chris: Yeah, the reverse can-I-use.
Chris: Like you have this in your CSS but you actually don't need it anymore.
Dave: Yeah, you put flex 1. You don't need flex-grow and flex-shrink. You put flex 1. Wouldn't that be cool?
Dave: Like this property was never executed.
Chris: Or that one you told me the other day about, like, you don't need WebKit overflow scrolling touch anymore - or whatever.
Dave: Oh, yeah. Yeah! Totally.
Chris: I was like, "Really?"
Dave: Obsolete, like a list of obsolete properties, that would be kind of cool.
Chris: Yeah. Hopefully, there are not that many of them. But when they're there, it's good to know.
Dave: Yeah. It would be cool, but I don't know. I'm kind of -- anyway, this was cool. Thanks, everyone, for sharing those. I'm glad A) I didn't have to go build it and B) it exists. [Laughter] I can at least see if my idea was fun. I don't know. I might try this style lint one.
Dave: Style lint is a mixed bag in, like, how mad it gets about you because it's like, "No nested selectors." [Laughter] And you're just like, "Dude, I'm going to probably have more than one selector at one point."
Chris: Yeah. I mean the point is it's configurable though. It's super configurable. I like style lint. I use it. Yeah.
Dave: Yeah, but 90% of it is finding the config that you agree with, sort of. Right?
Chris: Yeah, right, and so you probably start with an opinionated set. I think it has opinionated sets by technology, too, so you can have an opinionated set for your SCSS if you want that. You know?
Dave: Yeah. Yeah. Yeah.
Chris: Which is useful to me.
Chris: I had a bug yesterday, though, that this is just the waste of time stuff that can be infuriating. I used Prettier 2.0. In Prettier, you hit save, and then style lint was saying, "Oh, you've indented this," it was literally a linear gradient, "too far," like I want two space indents but you made it four-space indents, or something.
Chris: I was like, "Wow. Who cares. Why are you yelling at me about this?" But then I fixed it, and style lint is like, "Cool. Thanks. You fixed it," and then command-S and Prettier puts it back to how it wants it, and so your tools can fight each other in that way, and that's my least favorite thing about Web development, like, "Oh, y'all need to get along."
Dave: Yeah. You know I spent, I think, two weeks. I had some downtime between some projects, and I spent two weeks getting it perfectly set up.
Dave: I felt really good. I was like, "Hey, I did it. It's all functioning, all linting, all auto-formatting, all doing that," but it's now -- but then you jump to another tool, like Create React App or a Vue project has Vetur--
Dave: --and all of a sudden, your precious darling doesn't work the same because Vetur has its own little bossy pants.
Dave: Oh, well. But I do -- I don't know. Nuxt has a lot of this stuff built in. Again, I'm a fan of Nuxt here, Dave Rupert. I'm a Nuxt evangelist. They don't pay me to say that. I probably owe them money for saying that. But the out-of-the-box correction in linting and stuff is actually pretty dang good there, so I like it.
Chris: Cool. Does it ship with Nuxt or do you add it on?
Dave: Uh, yeah. It's all built-in, and then they kind of--
I'm trying to think what it does because you want to install some extensions into your editor, too, to make it all work lovely, right? You want the Vetur extension. You want the style lint and stuff like that. So, you kind of need all those running to get it to work out of the box, but it does a pretty good job.
Chris: Yeah. Isn't it--? We're in this -- like, what do you think about -- like what about your coworkers? Let's say you got it all working right. Supposedly something like style lint really doesn't care about VS Code. It's just a command-line tool, right? But really, it does matter that it's a VS Code thing because it needs to show the errors, you know, like the experience of coding needs to be there. Are you comfortable with telling your coworkers, like, "Can you please use VS Code, please, because this is part of the--?"
Dave: Yeah. Yeah. I kind of mandated that. I think maybe some still use Atom or something like that, but I kind of got everyone on VS Code. Then you know what? I did an extensions.json because you can have those .vscode folders - or whatever - where you do workspace files or settings and stuff like that. I did one where I made an extensions.json, and you can recommend extensions. And so, when they open up that project, they get a list of, like, "Hey, this project recommends extensions."
Chris: Oh, I didn't know you could do that.
Dave: Yeah. Let me -- I'll share -- tell you. I've got a project right here. Let me open recent.
Chris: I like that. That's neat. Yet even more reason why you should try to converge everybody on tools even though -- is that fair? You know?
We have somebody at CodePen now who is on Linux for the first time. Alex has played with it, but it's been no problem - none. They run it. It's fine. But they are on VS Code. But I wonder if there was some other editor they liked, would that be fine, or is that at some point going to cause problems? And, as management, you have to be like, "Can we please converge on a toolset, please?"
Dave: Honestly, I think that's why you have those big Java IDs, you know, like NetBrains and whatever. It's just like they added enough scaffolding or convention to auto-format your code, to find code, to cross-reference code - stuff like that.
I'm not saying we're all VS Code for the rest of our lives, but I think it has a lot of good, "Hey, team. If we're going to work as a team, here are all the things you need." You know? And that's probably kind of even back to -- what do you want to call it -- package.json lifestyle. We are in config-based development.
Dave: Everything has a config, and I have recommended plugins. You don't actually have to use the plugins. It will all get (probably) jacked up in loading or whatever. But I have plugins for ES Lint, Prettier, GitLens, so I'm just kind of advocating -- that's unnecessary, but it's just kind of like, "Hey, if we want to really see who wrote this last line," GitLens is awesome.
Sass Indented, maybe I put that there just to get my coworkers to indent Sass correctly. Style Lint, Vetur, and I put import costs just because I want to organizationally have that performance sort of mindset. Then Prisma, which we're using. That's just the syntax setup for the database ORM, I guess--
Dave: --that Prisma is.
Chris: Do you ever have trouble? Okay, so you're suggesting the things, but do they all work for everybody?
Dave: I think they all work for everybody. There's a chance. I'm sure you've been there where one program is just not working. Jest is kind of my big, like, noisy boy.
Dave: Jest is like, "Dude. This does not work and I'm flipping out!"
Dave: It's like, "Well, dude. I just opened the project, so it's probably not anything." [Laughter] You know? Nothing has changed. What's going on?
Occasionally, I'll have to disable Jest or something like that, which is less than cool. But that's an extension. Occasionally, people disable extensions and it won't enable. But hopefully, your pre-commit hooks, or whatever--
Dave: --are kind of sneaking in and catching it.
Chris: There are like three places these rules are enforced. One of them is, like, "Get it early in the process." I want the squiggles in my editor because I want to fix the squiggles.
Dave: Put squiggles when I write it wrong. Yep.
Chris: But if I miss the squiggles, the pre-commit hook should tell me about the squiggles so I can go fix them because I missed it. Then even if somehow my pre-commit hooks are broken, those then re-run again as continuous integration or whatever. Then those tell me about the squiggles. There are so many layers of all this.
It doesn't strike me as terribly fragile, but it does a little bit sometimes. That's why I was bugging you about, "Does it work for everybody?"
My RuboCop locally has been broken for a while, which is a little like Ruby-based (tell me if my code is wrong) thing.
Chris: It's neat because it can also do auto-fixing and stuff. It'll have opinions about white space because there are some things in Ruby that are fairly white space necessary. One of them is just like, you hit return in VS Code and it will indent the next line. Any editor will do that, right?
Chris: Not indent it further but stay at the indentation level.
Chris: But then if I hit save, then that line, that white space line actually isn't totally blank. It has two spaces in it. For whatever reason, our little linter is real mad about that. I can't even merge a pull request if there's a blank line with spaces on it.
Dave: Oh, boy. Yeah.
Chris: RuboCop (normally on a machine) would just fix it because it's considered a fixable rule, but it just doesn't work on my machine, and I cannot figure it out, and it's been broken for like a month. So, that's one of those things where it's like, it's not just as easy as saying, "Everybody install RuboCop," because it can break.
Dave: Yeah, and that's it, too. Occasionally, I have this issue where ES Lint would be pissed off. I'm like, "Well, fix it, dude." [Laughter] "You know it's wrong. You can fix it. You know I put something wrong."
It's like, "Dude, I can't fix it." Then I select it all, and I use the command shift P ... to say auto-fix. It's like, "Yeah, I can auto-fix this."
Dave: It's like--
Chris: [Angry growl]
Dave: --are you confused? Because you just told me (in the console, very loudly) that you could not auto-fix it. Then style lint is maybe -- my beef with style lint is it's very good at telling you what's wrong and what it's mad about, but it's not good at just auto-fixing - as good, maybe, as the other stuff.
There was a thing. It was just like, "Oh, man. You did not alphabetize your stuff. I expected this above this and this above this and that below this." You know? It's like, "Yeah, I don't care. Fix it." [Laughter]
Dave: It just wasn't as good. It didn't auto-fix as I had hoped, but you know.
Dave: Those are the issues, too, where I feel like I find out in the pre-commit hook, like, "Oh, no. Style lint was actually very mad about this," because I don't know sometimes. You don't know. Are you just slightly mad or are you fail to build mad? That's what you don't know. Or fail to commit mad.
Chris: They can be all a little bit different.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Jetpack from Automattic. It's a plugin for your WordPress site. I run it on all my WordPress sites.
It has a bunch of features packed into it that just do great things for your WordPress site, and a lot of them are optional, like if you want the backup stuff. You can buy that a la carte. If you want the instant search stuff, you can buy that a la carte. I use both of those things because I find backups to be completely non-optional when running a website. Got to have those for safety.
I think the instant search feature is amazing. It brings really powerful, cloud-hosted search to your site, so you get better search results, a better search experience, and it's just all offloaded from your own server having to deal with it. It's a really great feature. Just look at CSS-Tricks and search for something to experience what that's like.
But then, optimizing them, hosting them on a CDN is another layer of goodness on top of images that you need to be doing. Jetpack just automatically does it and serves them in the right format, too. Yeah, like a third thing. Really kind of tricky stuff to pull off.
In Jetpack, you just flip a toggle on and it does all that stuff, so that's huge to me that I don't have to think that much about my image stuff because Jetpack and WordPress are doing so much for me. Thanks for the support, Jetpack and Automattic.
[Banjo music stops]
Chris: You know one of my white whales with this kind of stuff -- this is pretty niche. I wouldn't say niche, but I don't know what people actually do -- is import ordering. Some of my projects (and I'm sure your Nuxt projects are like this) a lot of files have a lot of imports in them. That's a big chunk of every single component that you open is all of its dependencies from your pattern library and from wherever. There might be eight of them on any given file, on average, or something. That's what our projects look like, and there's no automatic. Prettier doesn't touch those things. They just sit there.
Chris: It's like, should they be alphabetized? Should there be spaces in the different things? Should it distinguish between things that are clearly from NPM and things that are importing from your project?
We've had endless talks about this, even though it feels like a waste of time. It's kind of like there's a VS Code plugin that does it, but that's no good because if one of us has that installed then every file they touch is going to reorder a bunch of crap and make a bunch of commit noise. You need to do it across your whole code base, then put it as a pre-commit hook, and then be done with it. That stuff has to be part of the flow. Otherwise, it's just noisy forever and that's unacceptable.
Chris: So, I just don't know. I don't know. I don't actually even care. The decree from me, essentially, is, "Nobody touch. Put imports wherever you want - at the top of your file. Nobody reorder anybody else's imports," because the order actually just doesn't matter. But it matters aesthetically and maybe code understandability-wise, but I don't want to see commit noise of people reordering imports because it's not done programmatically.
Dave: Hmm. So, you have a social rule, a process fix.
Dave: Do you think it's automate-able? Is there a dream automation?
Chris: Almost, close, but no cigar.
Chris: If Prettier did it - or whatever - and we could all install that because we use Prettier anyway, then good. Then we're done. We'll run Prettier across the code base one more time for those, commit that as one big commit. Everybody has Prettier installed anyway, so rock and roll. I don’t' know. I haven't looked (in a minute) if Prettier has a plugin for it or something. Maybe.
But I kind of like running stock Prettier, too. The things are like, "Oh, just add this plugin to Prettier." I'm like, "Hmm. Maybe not." You know? I don't want to--
Dave: Mm-hmm. Yeah. No, no.
Chris: But there are others. There's a VS Code plugin that does it, but it disagrees with the rules that run NCI. I don't know. I haven't. That's why I call it a white whale because I've tried like three times to get this going. Then I'm like, "Why?" This is not improving anything for us. It's just as easy to put one Slack message that says, "Just leave imports along, everybody. Okay. Bye."
Dave: [Laughter] Yeah. Code review it. Auto-paste - or whatever that stuff is called - where you're just like, "Hey, leave imports alone." Is it a money problem? Have you thought about commissioning a plugin or an extension or Prettier?
Chris: [Laughter] The problem is, I don't like bespoke stuff that much.
Chris: I like it when we use tools that everybody else uses, especially because there are so many touchpoints for a tool like this. If you commission it, I could imagine commissioning a VS Code plugin - or something - and somebody could really nail that. But like we said, that's not enough. It needs to be a pre-commit hook, too, and it needs to run in continuous integration, too. There are like three places it needs to run and that's a little touchy to the point where it's--
Chris: I don't know, but I see what you mean. I do like that as a solution. I should probably think about that more often, like, what can you outsource here? It's clearly work, but it's really well-defined work that's easy to pay somebody to do. That's valuable stuff.
Dave: Because sometimes you have these problems, right? Maybe it's just as easy as filing an issue on ES Code, the repo. But then you're waiting months, probably, to get it picked up. But maybe somebody knows how to do it easy.
Chris: Yeah, maybe. You were asking about integrations engineer the other day. You know how DevOps just became a job at some point even though it wasn't always?
Chris: Then other things did like performance work kind of has become a job. Is integrations engineer a new job?
Dave: Yeah. That's what I was thinking because Sarah Drasner has a post on dev advocacy, DX, right? In that thing, she talks about integrations engineers. Her perspective is sort of this, like, "Make your thing work on my thing." She was working at Netlify at the time.
Dave: It was like, "Let's get Nuxt on Netlify," so the integration for Nuxt and Netlify. We're integrating Next - sorry - into Netlify. I thought that was -- like, that's exactly what I'm talking about, but sometimes there are these integrations like -- I don't know -- CodePen interfaces with PayPal, GitHub, Twitter. I know you have those OAuth things. You have the payment things. You have -- I don't know -- maybe you're hitting some other service like SpeedCurve - or something - to monitor pages.
Chris: Right. Run your ax.
Dave: Yeah, ax or something. So, you have these integrations you're trying to hook up to, whether they're internal or external, like hitting some third-party service. I'm integrating with -- I'm trying to even think of a good example -- Airtable or Google Sheets or hitting these APIs to get this data to power this thing. I'm starting to wonder if it's sort of a specialized skill, somebody who knows how to 1) get it, the data and 2) knows how to get it formatted into good shape for your data and then where to store it efficiently on your data and maybe mockup a view for that integration, whether it's you hit a button to integrate that or you enter some keys or something on the client-side or you do an OAuth loop or something like that. Somebody needs to know how to do that.
I'm kind of like, is this something? Is this a job? If I want to add integrations to my application that I'm working on, which I do--
Dave: --do I need to hire an integrate -- can I hire an integrations engineer, somebody who does this? Like, "Oh, you need Algolia. I do that." It's like, "Awesome. I would love to hire you to do that because I don't want to spend eight weeks learning the Algolia API and all this crap. I've got other fish to fry."
Chris: Well, you know, who did I hear--? I wish I could credit the people I talked to. I was at a conference back, you know, before those exist, or whatever. They gave a talk about contract-based engineering. It was like kind of a cool idea. I'm sure this is just implied at some bigger companies - or whatever - but it was kind of like, "Here's an endpoint for our data. Okay. Here you go. It's in the Jira ticket - or whatever - Notion card. And here's what we expect back, like, from this integration." And it could be search results. "This is what we could use back from some kind of search thing."
Then that's a contract. You can hire somebody and say, "Here's our data. Here's the data we want back. Accomplish this card for money." You know?
Dave: Yeah. Yeah. Was it GRPC? Was that what it was?
Chris: Ah... I can't remember.
Dave: That's like a contract-based API thing. But yeah, it's like you define a little schema of, like, "Here's what I send." You say, "Here's what I want." Then those contracts have to agree. [Laughter] It's weird, but it's cool. Yeah, somebody who knows how to do that. You know what I mean? It seems like such a job, right?
Chris: Yeah, it does. If you were really good at it, I could see being very hirable for that. For example, yeah, you've done Algolia search before. Check. You've done single sign-on - or whatever - that kind of like enterprise auth stuff. Done.
Dave: Dude. Yes, I would hire. If somebody was like, "Hi. I know how to make your app work with Office 365, like Microsoft." It's like, "You're hired! Please."
Dave: I'll bring you in, at least to do that part. Go ahead.
Chris: Yeah, and maybe they could even tell you, like, "Before I start, if your data could look like this," [laughter] you know, "that would be better."
Chris: You know?
Chris: Probably half the battle is getting your app ready for the integration, not the integration itself. Yeah.
Dave: No, because if you start a contract with somebody and they're like, "Well, we have to redo the user table," you're like, "Yikes! That's a problem."
Chris: Yeah, or you have no infrastructure for running cloud functions - or something - and they're like, "Well, dude. Get on board. That's the very easiest way to do these type of integrations."
I think I mentioned in the Discord that one of the interesting aspects of integrations, like speaking with third-party servers that are not your own, is that you can't be particularly optimistic about the response that you get from third parties, always.
Chris: So, if one of those things is like, "Send an email," and for some reason, it fails, your code can't just be like, "Oh, well. That email didn't send. Meh-meh.
Chris: That's not acceptable for apps. You know?
Chris: It needs to be like, "I'm going to retry that in 60 seconds." And if that doesn't work, it can just never abort - probably.
Chris: There needs to be really stringent things on aborting. A lot of times, that's dealt with from a queuing server. You put a bunch of tasks to do (with third-party servers) into the queue and the queue plucks them off and runs them. But that way if there's a big problem, the queue just builds up. Not a big problem, but at least you don't lose the action.
Chris: It's not like, "Oh, this user tried to save their data to box.com," or whatever, "and it just didn't work." Well, at least it's sitting in the queue so when you fix the integration, it'll go through and get synced up. That type of work is a little bit specialized.
Dave: No, it is because that queue server, we had a thing the other day. We thought it was all working and then, guess what, we're getting a bunch of zeros back from the API. It's because the queue messed up - or something - or the server ran out of memory or something like that. And so, man, I need somebody.
Even that's the meta-level, too. If you know what kind of machine you need for this operation, too, that's actually pretty huge in the cloud computing realm. If you know, "Oh, you want to integrate with some spreadsheet, you know, Airtable? Well, guess what. It's kind of a memory hog because it tries to send you a ten-megabyte table. So, here's what you need."
Chris: Hmm. Yeah.
Dave: Yeah. Anyway, I think there's a market for this kind of role. I don't think it's defined yet. It's whatever. All these new job titles. Content strategist. It's like content strategist.
Chris: Kind of. Integration strategist, or whatever. Yeah, I like that. How many big apps are totally islands and they do nothing with any third-party? It's like none, right? Usually, at some point, the scale of an app begins to grow because of how it works with other apps. Eventually, it's like, "Oh, Notion is good, but it'll take them to the next level to have an API." Oh, guess what. Now they have an API. Or I wish this app worked with these other apps, so people work on a Zapier integration to get them connected, and that is like the keys to the kingdom. That's what gets them acquired - or whatever.
Dave: Mm-hmm. Well, I think that's it. I think maybe, historically, there was a lot of "not invented here" syndrome. You didn't get Microsoft big by cobbling together stuff. You had to make a piece of software. You had to make that.
But I think, now, since open-source is such a big turn, I think it's a lot about that's revolutionized programming. And so, now we're very comfortable borrowing stuff and integrating with stuff.
I think there's also maybe some wisdom in, like, if you're trying to move at "startup pace," it's actually maybe more beneficial to integrate you, Zapier, than to build your own queueing email, whatever, your own bridge service. You know?
Chris: Right. Right. And it'll get you trained right, too, because even your Zapier integration is an integration. They have contracts too.
Dave: Man. See, maybe that's it. I don't know. Some cocky kid who is just like, "I can probably do whatever you want with Zapier." [Laughter]
I would be like, "Okay. Tell me. Give me. Tell me more. What's your rate?"
Chris: Oh, that would be amazing if they say they do custom integrations, but really they just have a personal Zapier account and they just run everything through that.
Dave: Yeah. They just run like a boss through that. That'd be cool. I'm probably, yeah, doing things wrong. I probably just need to be a Zapier developer.
Chris: Yeah, maybe. Oh, that would be so cool. Sometimes I get a little dreamy over that, the people that just do WordPress only so that they are super-experts in that, or they just are Webflow developers.
Chris: They just do this one thing and they're great at it. It's just so obvious why you should hire them and under what circumstances.
Dave: Yeah. That's not in my blood, but that's very -- yeah. I've kind of given up on the "maybe I'm a specialist at something." No.
Chris: No, you're just not.
Dave: I'm just a generalist to a core.
Chris: [Laughter] Yeah.
Dave: I'll suffer the consequences. But it's fine though.
Chris: Yeah, I mean the podcast is the side product of that. [Laughter]
Dave: Yeah. We have a smidge of a generalist podcast, I'd say. [Laughter]
Chris: Oh, I'd say.
Chris: Yeah, we do.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Retool for Startups. Retool, retool.com, remarkably good tooling for building admin tools, internal tools, and stuff.
Retool for Startups is a special program that they're offering, so this is what they say. After working with thousands of startups, they've noticed that technical founders spend a ton of time building internal tools -- been there -- which means less time on the core product.
They build Retool for Startups, a program that gives early-stage founders free access to a lot of the software they need for building great, internal tooling. The goal is to make it ten times faster to build admin panels, crud apps, and dashboards that most early-stage teams need, so they bundled together.
It's a free year of access to Retool and then $160,000 of discounts for tools like AWS, MongoDB, Brex, Segment, you know, really popular tooling for building any kind of Web software, really. Use your Retool credits to build tools that join product and billing data together into a single customer view, tools that convert manual workflows into fully-featured apps for your team, tools that help non-technical teammates read and write to the database, and so much more.
It's retool.com/startups. That'll get you to the form to apply for this. There's some criteria for it, like you're less than five years old and things like that. Not you as a person, the company. You have to be over five years old as a person, I'm pretty sure. Check out the site, apply, join webinars, all that stuff - retool.com/startups.
[Banjo music stops]
Chris: Discord was popping the other day with a new Chrome API: Eye Dropper.
Dave: Mm-hmm. Mm-hmm.
Chris: I did not see that coming.
Dave: Uh, tell me about it because I saw the release notes, but I didn't really look into it. But it's kind of like a system-level eye dropper. Am I describing that correctly?
Chris: I don't know if it's system level. Is it really? No.
Chris: Because it doesn't -- I mean it doesn't look like the eye dropper that Mac OS offers.
Dave: Oh, okay. Okay.
Chris: But it does -- maybe it is, though, because -- I don't know. I use Figma and they have an eyedropper, but you can only eye dropper from inside the Figma window. But this eyedropper, I can -- pfft, I can go wherever on the screen and get the color from it. And so, doesn't that mean it has to be IO, like OS level?
Dave: Yeah. Yeah, well, was it Scott Jehl made it? [Laughter] He was like, "I made a new app," or whatever. It was just the input type equals color. Then it can select the--
Chris: Yeah. I keep meaning to blog that. It's so great. Yeah.
Dave: It's a data URL. [Laughter] I could probably read it to you, but it's just like data text/html;charset=utf-8 html title color picker end title input type equals color, and that's it. Close HTML. That's it, and it's an eyedropper. You can put it in your bookmark spot, and you get a color. Exactly. So, anyway.
Chris: Yeah, I love that. He's like, "What else can we do here?" It's pretty genius, really. Whatever. Then you just get an eyedropper. But then where does it go? Did he integrate a clipboard API? Does it plop it on your clipboard, too, or no?
Dave: No, it just goes to the input, so you'd have to read it. And it's only in RGB, but well, you know. That's fine.
Chris: Yeah. Well, a few more lines of code and it will work here. I wonder.
So, this eyedropper API is not part of input type equals color. It's just a whole thing.
Dave: Oh, really. Okay.
Chris: Oh, I don't think so. Is it?
Dave: Window.eyedropper? Hmm...
Chris: Yeah. Yeah. Yeah. Yeah.
Chris: It looks like Andrew put together a little hook: use eyedropper. Yeah.
Chris: He obviously writes React a lot. And so, yeah, you go new eyedropper. It's just like a totally fresh, new, totally API. Then you call eyedropper.open and it returns a promise, I guess, and the promise has the color.
But it looks like it returns a collection result, whatever that is, which has RGB, but it has whatever else, too. I'm sure you can get other formats out of it. That's cool. It's just kind of neat.
Because that's system level, then Andrew took it a little bit further and was just like, "I'll use Petite Vue and have an "add color" button that spins up an eyedropper. You pick a color and it starts adding color cards to a thing." He called it the Color Palette Builder.
Dave: Oh, wow.
Chris: It's got to be like the fastest color palette builder ever. And its output is like a chunk of CSS custom properties. It's like, wow!
Dave: Oh, my god. That's beautiful.
Chris: Forty-two lines of code for a very beautiful color palette builder machine.
Dave: I need -- you need Canary. That's the trick. That's the trick, I was going to say.
Chris: Yeah, because it's--
Dave: Ninety-five. Chrome 95 is the--
Chris: Yeah, and wasn't it just 93 that dropped? Canary is pretty far ahead.
Dave: I think 93 is in dev and Canary is up to right now. I think dev will enter whatchamacallit pretty soon.
Chris: Man. Chrome is always just smoking with these APIs. Probably the kind of thing that you wouldn't just drop in a production app and have it be absolutely core functionality, but certainly progressive enhancement friendly. Just offer a little color palette button if it's available, or a little eyedropper icon that allows you to snag a color real quick.
Dave: Yeah. Nah, I mean, well, and it's a progressive enhancement, too. So, you can just say, "If this API exists, you can just drop it in." That's cool. [Laughter] I don't know. Oh, man, I'm just using it now. It's great. This little demo Alex made is awesome.
Dave: Man, that's cool, and it goes anywhere on the screen. It's not just on the webpage. It's anywhere on the screen.
Chris: No, it's anywhere. I don't know how it gets that data, but it does.
Dave: Beautiful. Look at that. Look at the Web advancing. There you go.
Chris: When it's active, it's really -- you can do nothing but pick a color. There's no way out. I guess the escape key works, so that's the kind of good thing.
Chris: That's why it's nice to let the platform do this because it has little things like that.
Chris: I think they were already talking about the idea that you can't click anything, for example. It gobbles up any event because the event is selecting the color.
Dave: The color pick, yeah. Well, yeah, I mean that's intuitive. I mean, you know, yeah, if you wrote this yourself, it would be kind of a nightmare.
Chris: It would be longer than 42 lines of code for an entire color palette builder, that's for sure.
I think the concern was security. Could you trigger this on somebody in such a way that then you can't click anywhere on the website or something like that?
Dave: Yeah. Well, isn't it like you kind of have a--
Chris: It's probably like window.open where you have to click. It has to be a human being has to click. You cannot simulate the click. It has to be a real click.
Dave: Or a system-level screenshot. Like when you go into screenshot mode and you can't interact with the page - or whatever.
Dave: I don't know. I went down a rabbit hole to see because it was sort of with that whole only fans [laughter] breakdown - or whatever. I guess that's been kind of resolved. But I had read a huge problem for people who do that sort of business is screenshots of, basically, the goods that they sell, right? I was just like, "Is there a way to detect going into screenshot mode, like mouse focus or leave or something like that?" There's no way, unfortunately.
That would be interesting to have a Web API to be like, the person has disengaged with the page - or something like that. Then you could do filter blur or something on the photos to protect those people who are contributing their private images to the Internet. Yeah. Anyway. Politically speaking, it was just sort of a rabbit hole I went down just because I was like, "Is it even possible to protect images from being screenshot?"
But then people would protect tweets and then people would want to protect - whatever - blog posts from being screenshot, and maybe that's not where we want the Web to go.
Chris: Yeah. Yeah. I never like stuff like that, but there is stuff. If I download a movie on iTunes - or whatever - Apple TV, and I'm watching it on my computer, it is smart enough to not let me screenshot it.
Chris: I'm like, "Why?"
Dave: Yeah. It's weird. There are so many. I just want a GIF of this one thing from 30 Rock I quote all the time. I can't do it. I can't record two and a half seconds of 30 Rock.
Chris: How do people do it on fricken' YouTube? You know? Everybody has got, like, the ten best scenes in Lord of the Rings - or whatever. They have this amazing footage they just jam into their videos.
Dave: Yeah. Are they ripping Blu-rays or what? [Laughter] What are they doing? I don't know. Somebody has got it figured out, I guess - a workaround.
Chris: We have some time ahead of us. I think we're going to be -- this is early-stage stuff, but Dave and I are playing with some video stuff, and those will be dropping somewhat soonish.
Dave: Get ready. Fire up your YouTubes.
Dave: We'll see how that goes.
Chris: Yeah, there's not that much to talk about. It's just that it'll be like a little shorter and more focused version of this show. We're definitely not saying, "Oh, this is the new thing. We're just only doing this forever and ever."
We're just dipping our toes. Going to see what you like.
Dave: Do some pilot episodes.
Dave: Pilot episodes.
Chris: So far, I give it an A+.
Chris: It's been really fun.
Dave: We're having fun, and that's the most important thing in Corona times is have fun.
Dave: Oh, man. It's good. Well, that's the big news. We're dipping toes into video. It's fun because we're learning -- I'm learning a lot.
Even you and I, we were talking about thumbnails. Oh, my god. For what, like, two hours yesterday we were just like, "Here. Look at this video about creating thumbnails." Oh, no. [Laughter]
Chris: You did a lot of good analysis. What occurred to me is, like, we should do a video about the thumbnails because that's kind of our plan is to be like, it doesn't have to be about border-radius. We can have it be about anything that we're dealing with at the time. Certainly, a little meta episode about thumbnails could be really fun.
You did a lot of, like, competitive analysis. The one thing that's just fricken' true that probably we didn't even need to look up, but we'll just say it, is that you put your big old face on the thumbnails.
Dave: Faces get clicks, unfortunately. I don't know. I've got a face for radio, but what did I call myself the other day? Fat Dave Girl.
Dave: I'm Fat Dave Girl right now, and so I don't know. Yeah, it's kind of weird to put yourself out there, but there are all these -- I don't know. I think that's sort of the trick is you've got to have a face or a good action shot.
Chris: I've never done it, but what I want it is to be repeatable. That's the ShopTalk Show secret is that we do things that aren't insanely time intensive.
Chris: Dave or I don't have time to spend all day editing a video, so it was finding technology that allows us to shoot the thing, stop, and ship it, so it's a very small commitment.
You could easily get into a position where creating the thumbnail for your video takes as long as it does to shoot the video. That's not going to work.
Chris: It needs to be maybe not programmatic, but at least a pretty simple template, and so that's what I have together right now.
Chris: It's not doing faces, and I kind of feel like we should at least attempt the face thing. I don't know. Maybe not.
Dave: It's complex. Now I have an idea for an app, but anyway. I'll talk to you about that later. [Laughter]
Dave: It's probably just a CodePen because you could just kind of do it in CodePen, couldn't you? A face detection API - or whatever - or video with edges.
Chris: Oh, my god, Dave.
Dave: Then that's your top layer of the canvas. Then your back layer is whatever. You choose whatever. Then you have a text layer. Then you have a graphic layer that you can move around, right?
Chris: Yeah, dude, and you could have a little text where it changes the text and then also be able to pick it up and drag it where you want it, have little logos and crap.
Chris: Oh, my god. Don't make it as a CodePen. Let's do this $8 a month.
Dave: This is an app?
Dave: $8 a month service. No one steal this.
Dave: Enns, Enns, cut this out, quick! Just kidding. [Laughter]
Chris: I don't care that much, but yeah, it could be a CodePen, but it also could be there's so much clear value in it, like, why give it away?
Dave: If I can just walk up -- if I can walk up to a website and say, "Take a picture of me making a dumb, goofy face."
Dave: And I have my YouTube thumbnail.
Chris: A perfect YouTube thumb. Oh, dude. Yes. That would be awesome. Also, hit save, like save this basic template because I'm going to use it again tomorrow, probably.
Dave: Yeah. I'm going to do this again 100 times.
Chris: [Mind blown] This is great. This is it. We're going to make $50 on this idea.
Dave: This is tens of dollars.
Dave: Maybe ten zeonairs. [Laughter] It's going to just be wonderful. And ... if you want to just get in on this--
Dave: Just go ahead.
Chris: And Chrome, if you want to ship a green screen API, that would be cool.
Dave: That'd be cool.
Chris: So, you can just say, "Video element green screen equals the hex color of your green screen behind you," and it just auto clips what's behind it. That'd be nice.
Dave: Oh, we've got eye dropper. We've got eyedropper, Chris. We got eyedropper now.
Chris: Oh, yeah.
Dave: Select green screen.
Chris: Oh, that's a great idea.
Dave: Chromakey. We're done. We're done. We're done! Step one, you get the thumbnail.
Chris: Hold on. Chrome-- Can you actually do this on the Web? I bet you can because you could ship it to a canvas and then the canvas could look for that pixel and make it transparent, right?
Dave: Oh, yeah. I've done that. I know how to do that.
Chris: Oh, wow. Fricken', dude.
Chris: Good stuff. Anyway, we've got to shut down the show now because we have some work to do.
Dave: Yeah. We have to shut down the show. Yeah. We're heading into this JS party, Syntax versus ShopTalk Show. I've got the sweats. I'm ready to go, though. I've been reading MDN all night, so we're good. Let's go. Let's do it. We're going to do it. All right.
Chris: All right.
Dave: Well, thanks, everyone, for downloading this in your podcatcher of choice. Don't steal our ideas, please. My kids are depending on it, and I have a mortgage. [Laughter]
Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. Yeah, join us on the Discord, patreon.com/shoptalk for weekly fun. Chris, do you got anything else you'd like to say?
Chris: Oh, that's all. ShopTalkShow.com.