459: Talking Web Components, ES Modules, Using OAuth, and Digital Art

Dave's prepping for a talk at An Event Apart about Web Components, and we're answering questions about OAuth, and talking digital art.


, ,


Chris Coyier and Dave Rupert in silly sunglasses and a sign that says Shawp Tawlkk Shough DOT COM

Chris Coyier and Dave Rupert

This episode is with just Chris & Dave, ShopTalk Show's hosts. Chris is the co-founder of CodePen and creator of CSS-Tricks, and Dave is lead developer at Paravel.

Time Jump Links

  • 00:51 Speaking at a conference
  • 05:55 Dave's talk on Web Components
  • 13:11 Sponsor: Jetpack
  • 16:26 Reaching for Web Components in production
  • 19:19 ES Modules is out
  • 26:45 Any recommendations for using OAuth?
  • 27:27 Sponsor: Around
  • 41:28 Dave's art

Episode Sponsors 🧡


[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave.

Chris Coyier: That's right, eh.

Dave: With me is Chris. Hey, Chris. How are you doing today?

Chris: I'm doing pretty good.

Dave: Yeah.

Chris: Through the power of asynchronous recording, publishing, digital life. Someone might be listening, you know, have this show up in their podcatcher while you're on stage at An Event Apart Spring Summit.

Dave: That's right. We have a live show, and so if you are listening to this now, you're maybe too late.

Chris: Mm-hmm.

Dave: But I will be at An Event Apart. I'm talking about Web components, like right this minute, so that's exciting.

Chris: Yeah. That's Monday, April 19th when this show drops, if all goes well. Then the 20th, we have our little ShopTalk Show live, so that should be fun. I don't remember if it's actually going to come to this podcast stream as well. I think it has in the past, so maybe look forward to that, but that's cool.

I know it was a minor source of stress for you, like any other conference talk can be. When you give somebody a yes, that means you've got to come through.

Dave: Well, yeah, and I mean, I guess, yeah, we could behind-the-scenes some conference stuff here. But you get asked in, like, November, "Can you do a conference in March or April?" You're like, "Yeah! I like you guys. Let's do it."

Chris: Of course.

Dave: Of course.

Chris: The distant future of March. I have nothing planned.

Dave: March is 100 years away from right now, you know, like I can't even imagine. Even then it's like, "Okay. Yeah. Great. I have a client project hours just got scaled back. I have time. This is great. Let's go. Let's go."

You kind of have to, right? Kind of pitch. With a lot of conferences, sometimes they'll reach out and say, "What do you want to talk about?" and stuff like that. You just kind of have to hypothetically anticipate where you're going to be in four months, five months, or six months in Web time. I knew I was going to be messing with Web components--I already was--and working with OpenUI and the Web component group and stuff like that.

Chris: It seemed like a natural fit. It still does, doesn't it?

Dave: It still does, and yeah. It was good, but what I didn't know was March was going to be one of the craziest client months of my whole entire life, and I was going to get the Moderna shot that took me out for two days. It was hard to summon the hours to put together a talk. I think it came out really good and I tried to do a good job. But, yeah, it was tough to find the time.

Chris: Right, because it's not just writing down. There's research, and there's making sure that you're delivering it in a coherent, cohesive story.

Dave: Yeah, because there are docs, right? If you want to find out about Web components, there are a hundred thousand places you can learn. Is it up to date? You don't know. You have to learn the hard way.

Chris: Yeah. Your conference talk can't be, "Here, read the docs. Okay, bye."

Dave: Yeah. [Laughter]


Chris: You need to bring something to the party. In fact, that's the number one reason I reject an article on CSS-Tricks. I got one the other day that was like, "I want to teach you how to use Storybook for your React components."

I'm like, "Okay. That's an article. I get that that makes sense in your head as an article that you could write. But the Storybook website does that." They have docs and they go beyond docs. They have tutorials.

This would be maybe okay for CSS-Tricks if you just looked at it at a glance. But it's not right. I can't keep that up to date over time. I will never do as good of a job as the website will.

Maybe your article is great, so in that case please send it to me because maybe you have something in mind that brings something to the story. But usually, the pitch is so light. It's just like, "I'm going to do that," and then I always write back and say, "Do not just replicate the docs. That's not useful to me. I really need to feel you as a developer in this writing and bring something to the party that is not available in the docs."

Dave: I use--

Chris: I mention that because your thing about Web components, right? There are lots of resources. What did Dave bring to the party?

Dave: Well, I was going to say, with that, like Storybook, yeah, how to install Storybook is not a compelling article but, "Here are ten Storybook add-ons we're using." You're getting the top ten jQuery plugins, but here are ten Storybook add-ons we use to--whatever--deliver accessibility. That's an article. That's an article I want to read, or something like that.

Chris: Yeah. Rough edges stuff is good to me, like, "Oh, we manage state in this weird way and it really needed to have that reflected in Storybook, but it was difficult. But we got past it and here's how." Hey! There you go. That's the article because it does double-duty then. It lets you know about Storybook. It can cover the basics of how and why to use it, and it can go that one step further and talk about something tricky.


Dave: Yep. That was sort of my -- anyway, that would be a good one. For me, in this talk, looking at the Web component landscape, a lot of Web component education just drops you into the JavaScript, the element. It's like class, my element extents LitElement, blah-blah-blah. You know?

Chris: Mm-hmm.

Dave: For me, and this is people I've talked to like CSS people and HTML people and accessibility people and JavaScript people, even, over [techno voice] Discord, I asked this question too. Are you using Web components, yes or no? If not, I'm curious why or why not.

A lot of people who I think would like Web components, they're CSS people, they like HTML, they're not using it. I think that's because all the education comes from the JavaScript angle right now. You're missing the whole CSS people and you're missing the whole HTML people, and that's a huge swath of the Web. WordPress is 40% of the Web or something like that. You're missing out on a huge group of developers when it's JavaScript-only education.

Chris: Okay. Well, that's a big point.

Dave: I took it from the Jeremy Keith's pacing layers of the Web. I don't know if you've seen that. Jeremy Keith has a talk called--

Chris: Some things move fast. Some things move slow.

Dave: Exactly. Exactly. TCP/IP doesn't move that fast. HTML doesn't move that fast. CSS moves a little faster than HTML, but 2021 is a hot year for that. It moves a little bit faster, but then you know JavaScript is just Jeremy.

It's all over the place squiggly-wiggly. It's a lot to keep up with. It's like fashion. You have to keep up with JavaScript. CSS moves a lot slower, and HTML moves even slower than that.

Chris: Do you think that's on purpose? It's not like they sit around like, "We're going to move HTML slow."

Dave: Yeah.

Chris: There's no cabal that decides that. It just is that way.

Dave: Well, hmm...

Chris: [Laughter] Sorry. Controversial? Okay.

Dave: Mr. Dave, has some opinions. Thinking about what happened with the picture element and everything there, I think there was a lot of brake pumping, unnecessary brake pumping from the W3C or the working group maybe specifically.


Chris: It does seem hard to gather up any enthusiasm. Speaking of Jeremy Keith, he had this idea about, you know the Web share API? We've talked about it a little bit before.

Dave: Yeah. Yeah.

Chris: It's pretty compelling, I think. I think it's a very good and underused API because of just how lightweight it is, even in the JavaScript version of it, and how great of a sharing experience it offers to users. It's like the best possible sharing experience.

Dave: Yeah.

Chris: Wow! That's compelling. Right?

Dave: Because it hits the native layer and it'll show you the apps that are installed on the native system for sharing things.

Chris: Jeremy -- I think there is some nuance to this, but it's like why even need JavaScript? Why do I have to execute JavaScript in order to tap into that? Couldn't this be moved down to the HTML level? I believe the proposal was a literal button element of type share.

Dave: Mm-hmm. Mm-hmm.

Chris: Which... I don't know enough about backward compatibility and stuff to know what the implications of that is but, at first glance, it seems okay to me. It seems like, yeah, yeah, that's cool.

Dave: Let's go.

Chris: Button type equals share, and all it does is fire up the native share thing and it falls back to a button. You know?

Dave: Yeah. Yeah. Type equals camera. Request camera access. Type equals microphone. Request microphone access.

Chris: Right. That seems kind of cool to me. I wonder. Again, from the outside, I would assume those are going nowhere fast. Nobody is going to do that. I don't know why, but they're just not going to. [Laughter]

Dave: There is some nuance, right? I've discussed this with some people. Especially--I'm going to throw them under the bus--Safari. They seem very apt to introduce something like an attribute or a property or a value.

Chris: Metatag.

Dave: Right, or a metatag, kind of these sort of -- you think of CSS properties. They just shipped WebKit fill available as 100 VH replacement or whatever.

Chris: Right.

Dave: Just because they wanted to or they could. They didn't even ask anyone. They just put it out there. I'm just using them as an example, but I think browsers, it's easier to ship a value.

Chris: Like a modification than a whole thing.

Dave: Yeah, it's easier to ship ENV vars or a value, a custom value, or even a custom thing like Switch, the switch statement or something like that. It's easier to ship a new value than it is to ship a new attribute, which would be like a new CSS property like--I don't know--

Chris: A new CSS property.

Dave: Yeah, a new CSS property or even an HTML attribute or something like that. Right? Than it is to ship a whole element with a whole API and stuff like that. I think the Web has not shipped elements for a very long time. Main. Detailed summary.

Chris: Right. Didn't you call them spicy divs at one point?

Dave: Spicy divs, yeah.

Chris: The last thing we got was spicy divs.

Dave: Yeah.


Chris: Yeah. I don't know why all that is, but okay. So, maybe then an argument -- not an argument, but a part of this is that you don't need to ship new HTML elements because Web components now exist. So, if you want a button that fires up a share thing, just make a little Web component for it and have it do that.

Dave: Yeah.

Chris: Now, that doesn't solve the JavaScript angle because, in order to even instantiate the component at all, JavaScript needs to run.

Dave: You need JavaScript. Yeah.

Chris: Yeah. That's at the core of your HTML imports thing. I know we've beat that thing to death on this show, but I feel like I get you more and more, over time, that you literally cannot use Web components, period, not even a little bit without JavaScript.

Dave: Without JavaScript, you can't even--

Chris: Otherwise, it's a span that does nothing.

Dave: It's a span that does nothing. A lot of components--your navigation, your header navigation--they're pretty static components. Wouldn't it be cool to just ship or have a concept of maybe like static components that could just be HTML or something like that, but we just don't have it. So, I don't know.


[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Jetpack. You know Jetpack. It really helps do all kinds of things on your self-hosted WordPress site.

The core plugin of Jetpack does a bunch of stuff. But if you've been kind of paying attention to this Jetpack world, I think you know that they've been kind of breaking stuff off to make sure that you're only paying for things or using parts of it that you know that you need or want to pay for.

For example, Jetpack search, their instant search thing--I'm bullish--I think it's a great product. It just makes WordPress search super good, it does it in a way that you have control over, and it does it in a way that there is an add-on, and it's great. I would use that on any site, but it costs money. So, Jetpack Search is its own product and it's dependent on how much stuff there is to search on your site. You can go check that out.

This is about another kind of breaking off of something. They now have this plugin called Jetpack Boost. You can just Google it and you'll get right to the WordPress plugin repository. You can see about it.

As I talk here, it's in pre-release. It's saying, "Do not use this on production sites until they release 1.0." By the time you're listening to us, it might be in 1.0, so feel free to use it at that point. If you go to the plugin page and it's still talking about pre-release, then test it on your local site. See what it does. See if it's doing useful stuff to you and see if you want to. Then wait for that 1.0 release to push it out to prod. But it's worth testing now.

I've been installing it and testing it. It looks pretty cool. There are some things that the core Jetpack plugin can do, little turn switch features that make your site faster, like lazy loading images. That's built into the Web platform now, but this is all Polyfilled up, does it nicely, and does it the WordPress way so that images that are below the fold that can't be seen by a user on a page, the image doesn't load at all. That is a huge performance boost.

Now that's built into Jetpack Boost. So, if you're like, "I don't know. How would I incorporate that into my site?" Don't worry about it. Install Jetpack Boost. Turn on that module of this plugin and it will do that. That comes right over from the Jetpack core plugin, but there's other stuff in this plugin.

It launches with three modules that are new. One of them, the most impressive to me is the critical CSS. Critical CSS is this idea that the only CSS that's loaded right away--and by right away I mean inline right into the head of the document--is CSS that applies to what you can kind of see above the fold of a website. So, it's this minimal, very minimal set of CSS that comes in the first packet of when the website arrives, so it's like there is no delay waiting for all of the CSS to download to render. It's just this, like, cheat code for getting your website to render much faster.

How do you generate critical CSS? Well, it's super hard, in my experience. It's like a tricky hard thing to get right. This plugin does it for you with all kinds of magic. In order to work for the first time, you'll see a progress bar. It's analyzing your site and figuring out what it needs to do and how to generate this critical CSS. Then once it's done, it's ready to go and you can use.

Very compelling. Tricky thing to get right. Perfect kind of thing to trust a plugin to do. That's Jetpack Boost. Check it out.

[Banjo music stops]


Chris: Okay. Well, are there any other kind of points you wanted to share from the talk itself? Just being friends and colleagues here, I was able to get a little sneak peek access to what you were talking about.

Dave: Yeah. Yeah.

Chris: I was a little more compelled than I was in the past. I am in that boat of so many other people is I don't really -- I especially don't use them in production. I've played plenty. I've written about them. I've thought about them. But I tend not to reach for them in production. That might change, I think.

Dave: The one thing realized (making the talk) -- I maybe said this in a recent episode, too -- they were proposed in 2011, but implementation didn't land until 2013, 2014. Safari didn't get anything until 2016. Firefox in 2018. Edge didn't get anything until 2020 when I shipped Chrome, like switched to Chrome.

Chris: It's only 2021, as we know.

Chris: It's only 2021. I honestly feel like if you were using Web components before, you were in that early adopter fanatic phase [laughter] of things, you know. You're maybe an early adopter. But I think now we're starting to see adoption happen and a lot of the people who are -- a lot of the people who are using Web components right now are very big companies who have these systems that need to go out to different platforms: the old Java app, the new "Rails app," the WordPress site, the marketing site, the static 11ty site for the one-pager event section, the React app, the Vue app. Every department gets to choose their own tech stack, so whatever. I think a lot of companies who have these very distributed team systems, they are having success.

That said, React, Vue, and everything, those are great choices. Those were kind of the only choices until last year. [Laughter]

Chris: Right> So, as long as we've been talking about this, the real starting line for this game, we just crossed, really.

Dave: Yeah. No, and I was ready in, like, 2014 to switch to Web components. I was like, ooh, this is maybe kind of compelling. Then HTML imports got yanked. It was just like, well, that's not fun. [Laughter] Then even that, ES modules is kind of finally out.

Chris: Yeah. We've been hitting that hard on this show too. Isn't that part of the story for the deliverability of these things? I'm excited about it in the same way as Houdini, in a way, is that you don't actually have to know that much to be a consumer of a Web component. You can just be like, "Oh, that thing does this?"

I think you bring up an image swiper, which is a great little thing. I have a Gutenberg block that does it, thanks to Jetpack. I think maybe Jake Archibald built one at one point as a demo.

Dave: Yeah.

Chris: It's nice. It's a great example. That is a little tricky thing to build.

Dave: Mm-hmm.

Chris: Particularly to get the accessibility and all that right, but it's also not that weird. It's two images. You slap them on top of each other with Z index and positioning.

Dave: Before, after, slider. Sure. Sure.

Chris: Sure. Then there's a vertical bar down the middle that you can grab with your mouse and drag, so that draggability has certainly some JavaScript you're going to have to write, and all that. But in no world should anybody have to write that from scratch. It's like somebody has done this before. It's not that unique to your app.

Now, the story, as a consumer, to use that, is import image slider from blah, which might even be some CDN or something. Then you drop image-slider in your HTML. Probably drop two IMG tags in the middle of it. Now you have an image slider. Wow. That's an awesome usage story of advanced componentry. That's really truly compelling.

Dave: Yeah.

Chris: And it doesn't matter if you're using Angular, React, Vue, or nothing, or WordPress or anything. It's irrelevant to that.


Dave: Well, and that's what I think is cool because, right now, over in the [techno voice] Discord, it's like, "Oh, I want to use a WYSIWYG." It's like, "Oh, here are Pros Mirror and Quill." Then it's like, "Oh, but I'm in React." It's like, "Oh, crap. Let's find the React flavor of that," or the React version. You know?

You have to find the flavor for your technology, right? Hopefully, somebody has already written the adapter that shoehorns this thing into your thing, or Flickity - we were talking about yesterday.

Like, oh, well, how do I do Flickity in my React app? Like, oh, well, let's brainstorm some ideas how we can get that working.

I think Web components kind of can come along here and say, "Just use the Web component." [Laughter]

Chris: Yeah.

Dave: The script tag goes somewhere in your vendors and then you just say two up, whatever, image one, image two, and hopefully we're done. But React is kind of a special story right now.

Chris: Yeah. Yeah, we don't even have to get into that, necessarily. Yes, very compelling. The reason I brought up Houdini too is because it can be like that and your JavaScript can be like, "Oh, pull in this Houdini module," and now all of a sudden, with one line of code, now you can write background cats or whatever and have cats in your CSS.

Dave: Right.

Chris: You're like, the usage story was gorgeous.

Dave: Yeah. Yeah, like it's -- yeah, I mean it's the one-liner -isms. I don't know. If you have a one-liner, you have an adoption story.

Chris: Right.

Dave: It's just one line of code.

Chris: Very. Always compelled by the one-liners.

Dave: You know people are like, oh, NPM install whatever -- cats. NPM install cats can you'll get cats on your webpage.

Chris: Yeah. It doesn't count. Native one-liners count. [Laughter]

Dave: No, but that was the story. But then, low and behold, you have to do like 10,000 things to get cats to actually run and bundle in your app.

Chris: Mm-hmm.

Dave: I think we're getting closer, edging closer (here in 2021) to include the script tag for cats or NPM install cats into your bundle and then you're done. You actually have access to the cats and you just say background cats. You don't have to do 22 divs nested to get the cats to show up.

Chris: Right. Right. Right. A lot of things coming together for that. This really compelling thing of Web components, still, after all this time, is the encapsulation thing. I think you argue that the Shadow DOM is kind of a bummer name. I think it sounds kind of cool like, "Oh, Shadow DOM."

Dave: Well, it's--

Chris: But the coolness is not goodness.

Dave: It's an opaque term from the outside.

Chris: Sure. But you know what can't do that? Vue, React, Angular. That is a platform thing that is totally unique to Web components. Well, I mean, I guess SVG has it. Maybe you can fire up your own little Shadow DOM if you want to. I'm not sure what implications are there.

Dave: [Laughter]

Chris: That's unique with this no-in no-out kind of capabilities to it. I know there are lots of caveats that we've talked about on the show before, but that is compelling and a reason why these things are going to matter over time that just is cool.

But I remain bummed out that it doesn't give you any of this. You have this checklist of stuff that it doesn't give you, like they were totally -- even though it's so JavaScript focused, totally unconcerned about re-rendering and state and lifecycle and all this stuff that perhaps should have been learned from all these different JavaScript frameworks/libraries or whatever that exist today.

It's like even if you just had one, I could see the adoption being way higher than it is now. I'd be like, "Oh, here is the Web component's blessed way of handling state," or whatever. "Here you go."


Dave: Well, the good news is, all that stuff is being discussed--

Chris: Yeah.

Dave: --in the working groups and stuff like that. There is a context API; Google, Adobe, they're working on it, so that's actually kind of cool.

Chris: Yeah. I learned some things, too, that I didn't know, that there's kind of -- I mean there's already basic lifecycle methods, but there's one that's like connected attribute changed or some crap like that?

Dave: Yeah. Connected callback attribute change callback, and then you have to observable attributes as a static.

Chris: Right.

Dave: Basically, you set props. It has props.

Chris: Right. A prop change, so now you should do something about that.

Dave: Mm-hmm.

Chris: That's kind of good, you know.

Dave: Yeah. Yeah, it's a little more manual, but I think that's where frameworks can come in and ease the burden. The difference between using Lit and writing a Web component like Vanilla is so different. It's like casual mode versus hard mode.

Chris: Hmm.

Dave: Because it's like, "Oh, they just called it render," as opposed to document get element by ID template, my template, you know.

Chris: Enter HTML.

Dave: Attach shadow root - blah-blah-blah. It's just render. [Laughter] And so, there it is. You didn't have to do some--

Chris: Yeah.

Dave: Whatever Kungfu query selecting.

Chris: Sugar matters.

Dave: Yeah. Yeah, sugar can matter here.


Chris: Hmm. Let's do a question. We've got one here from Andrew Smith who writes in.

"On some of my more recent projects at my agency, I've noticed an increase in using OAuth for user login." That's not exactly a new tech, but a classic stable of Web stuff.

Dave: Mm-hmm.

Chris: "I assume that this is because it's easier for new users to get up and running quickly, meaning they don't have to enter any repetitive information or remember a new login." Again, OAuth is that sign-in with Google.

Dave: Mm-hmm.

Chris: Sign in with -- you know, it doesn't have to be one of the major services. It is the underlying technology. But, generally, people are talking about sign-in with X large service that you probably already have an account with.

Dave: Mm-hmm.

Chris: Facebook, Google, Twitter, Apple - more and more. We saw one with Slack the other day. As a matter of fact, I'm going to do his right now, right in the middle of Andrew's questions.

There is a sponsor around--

Dave: Around.

Chris: High-five, Around. Thanks for sponsoring ShopTalk. I think this is the first of a series of sponsorships they're going to do with us. Dave and I are on this thing. Around is nice.

Dave: Literally, we're on it right now. [Laughter]

Chris: Yeah! We're literally recording this show with Around. It's a video chat app, and the most noticeable thing about it right away is that it's not a big rectangle on your screen. It's these little circles that are kind of zoomed in and cropped to the person's (you're talking to) face. It's so more out of the way than you're used to with video chat that if around only was this, I would still use it because it's super nice, I think.

Dave: No, because I can look at my desktop and look at all the show links and show notes, like I have going on here, and then I just have these floating heads. It's our floating heads.

Chris: Yeah.

Dave: It kind of takes out that Zoom fatigue a bit.

Chris: It does where Dave is looking at my entire office right now. I can just sense the beams of--

Dave: Judgement.

Chris: Yeah.

Dave: Cable management...

Chris: Yeah, Dave's Eye of Sauron is over. Yeah.

Dave: [Laughter]

Chris: It's like, "Oh, my God. My plant in the back is so dusty. He's probably noticing that right now."

Anyway, he won't notice that not only because is it generally smaller and this little thing, but because I have a super red to orange filter over my face, which just looks kind of cool, but also means that it's obscuring some detail behind me. It adds an element of fun while being this kind of functionally useful bit.

Dave: Mm-hmm.

Chris: Really cool. That's just describing Around. It's for Mac. It's for Windows. IT's for everything kind of thing. But you're not giving anything up by using it. It's not like just that but then it doesn't have screen sharing, or it doesn't have chat, or anything. It has everything that you need. It's like a full-featured video chat client thing but with all the stuff you need.

Switching over to it, you know, not all software is like this. There is no learning curve. You're just like, "Oh, this is how it works? Okay, well, that's better. Moving on."


Chris: I love it. Just to pick one more little thing, I like how chat works. You don't need a chat room in a video chat app. You're already chatting. But it doesn't mean that it's not there. It just means that they've rethought it a little bit. Now you can write a chat message and it appears right below my little head, which is probably--because I've been on, hmm, ten billion video chats in my life--a link.

Dave: Mm-hmm.

Chris: The number one reason I use chat for is I just paste a link and I want you to click it. Now, in Around, I paste that into the chatbox. It appears below my head. I tell people to click the link and then we're done, so a very smart thing.

Anyway, thanks so much for the support. We'll tell you more features about them in future shows, I'm sure. It's a pretty nice little software.

The reason I did that in the middle of Andrew's question, they use OAuth to log in. Sign in with Apple. Sign in with Slack - all that. I chose Apple. I tried to have a mental list of OAuth providers that, if I see any random combination of them, I know which one I used because I have the list. I put Apple at the top just because, whatever. I have a trust for their security model, in a way, even though sometimes I regret it because there are a lot of extra hoops with the Apple login, but here we are.

Dave: I agree.

Chris: Yes. [Laughter] A lot of, like, -- anyway, "Trust this browser," and all that.


Chris: Okay, so Andrew writes, "While I think this is great, my app needs to create its own set of users. But with OAuth, there are three, four different possible ways to sign up, including my own sign-up form." It sounds like Andrew is not just doing OAuth. You can also just sign up with a login and password if you want to.

"Now what? How do I manage all these access tokens and figure out which user might be which user when they log in one way and then another way, and all that? I've looked at resources for best practices regarding OAuth but, at the end of the day, they usually just end up pointing me to use some paid service because, of course, OAuth is just the underlying technology." If you want to add Auth, there are companies that are trying to ease that burden for you and it sounds like Andrew doesn't want to do that. What do you think, Dave? Have you built some Auth recently?

Dave: Yeah. We are literally building one right now.

Chris: No kidding?!

Dave: For my stealth startup.

Chris: Yeah? What'd you go with?

Dave: We're just building it. It's not done yet, but I think it's just like NodeJS has Passport and Passport is like an authentication system.

Chris: Yeah.

Dave: But you can just do OAuth stuff through that. That's one way. We're also existing in this framework that has an OAuth thing but it's probably Passport under the hood just with their own API.

Chris: Is it free? Is it an open-source thing?

Dave: Passport?

Chris: Yeah.

Dave: Yeah, Passport is. Yeah, but the thing is you do a handshake. That's how OAuth works. I put in my Google credentials and it fires off a request off to Google. Google says, "Okay. This might be the right person."

Chris: Yeah.

Dave: I forget what the actual steps are, but it's like, "Are you actually--?" So, I will give you this guy's public key, or whatever, and then you tell me the token you think you're supposed to get back. Or you sign this and then I'll go fetch the actual user's token, which is just a 32 character string that identifies this user somehow. Then I'll send it back to you. Then, once you have that, you can actually log them in from there. You say, "Okay. I have user ABCDEFG123."

Chris: Yeah.

Dave: I'm going to go look in my database for user ABCDEFG123, see who has a token like that, and then I can say, "Oh, that's Dave. I'll show Dave stuff now."

Chris: Right.

Dave: You're doing this if you run your own authentication system, too. On Rails, what did I use on Rails? I forget. There's a popular service for it.

Anyway, I built my own services and stuff like that. You probably do want to have your own service, but I think the idea here is, there is some fatigue for signing up for stuff every single time you go to a damn website. I do it because I like the security model of, like, "Well, if my Google account gets hacked, they don't get access to my budgeting app. They don't get access to my Notion."

Chris: Sure. You just password manager it anyway, right?

Dave: Yeah, I'm going to do that anyway. I don't do it that often, personally, but I think there's some value there for that.

Chris: I think you're probably going to see a higher amount of signups per day if you offer it, though.

Dave: Mm-hmm. Yeah. Yeah, because it's basically just like they're already logged into their Gmail. If you think of the world in those terms, they're already logged into Facebook and they're already logged into Gmail, like dot-com. Then, yeah, just use their session. Then they show up to your app and they just click "Log in with Google" and Google is like, "Are you sure?" You're like, "Yeah, Google. I'm sure I want to log into this."

Chris: We should have that one on CodePen. It's so stupid that we don't, but we have Facebook, which nobody uses.

Dave: Well, Facebook shot themselves in the foot there. [Laughter] But it's all the intent too, right? If I'm making a photo-sharing app, I'm going to put a Facebook or Twitter button on there, a social login button because the next thing I'm going to ask them to do is share the photo out on Facebook or Twitter. You know what I mean?

Chris: Yeah, right, so you might as well have that connection going already.

Dave: Yeah, you get the automatic integration. Another one that's popular, enterprise apps, hooking into some company's active directory. Guess what. You're going to use OAuth to do that.

Chris: Yeah. You mean single sign-on?

Dave: Yeah, single sign-on crud, and so you use OAuth to just verify to whatever single sign-on service, like, "Oh, this email address is at ParavelInc.com? Great. I'll just go ahead and assume it's the Paravel instance of that application."

Chris: Yeah. Yeah, that's kind of cool.

Dave: Yeah.


Chris: Just to explain a little bit how we do it at CodePen because it might be relevant to you, I don't know if we're dumb or genius or somewhere in between for doing it this way, but we still do all the OAuth kind of dance.

Dave: Mm-hmm.

Chris: We don't deal with all the token stuff. Another thing that you get back is the email address of the person who logged in.

Dave: Yeah.

Chris: All we do is just match.

Dave: No, that's true, too.

Chris: You cannot go into CodePen and say, "I would like to de-authenticate Google from CodePen. I think you could do that -- well, we don't have Google to begin with, but you could go over to Twitter and de-auth the Twitter CodePen connection. We don't use it for anything. Go ahead, you know, because the next time you log in, it'll just be back then and you'll just have to authorize it if you happen to use the Twitter auth thing.

It's just so dumb that it's smart. We don't have to build any UI for it. We don't have to do anything. All it does is just, you auth through the provider, we get your email back, we match it to an email in our thing, and that's it.

The minor downside, which this comes up almost never despite many hundreds of thousands of people using it a day to log in, is that you can't have -- you can't use login with GitHub and have a different email address on GitHub than your email address in CodePen. It has to match. If it's not then too bad. Then just use the normal login then. You can't use the social auth login. But nobody ever bitches about it.

Dave: Yeah.

Chris: It's fine. It's so lightweight on our side, and it means that we can do this thing where the login or sign up buttons, they do the same thing.

Dave: Mm-hmm. Mm-hmm.

Chris: If you click the wrong one or you're on the wrong page or something, it doesn't matter. It just attempts to log you in with what we find. If we don't find anything, it's like, "Oh, we don't see you. Would you like to sign up or not?"

Dave: Mm-hmm.

Chris: Very cool. Works fine.

Dave: Yeah. No, that's a great point. You maybe don't even store that token or whatever.

Chris: Wow.

Dave: You just store the email because that's part of the handshake. You come back. You get a token, which you may actually want to store in a cookie so they can reauthenticate later - or whatever. But you basically get the user's email, basically, is all you need.

Chris: Mm-hmm.

Dave: You're like, "Okay. Google verified that this is the email."

Chris: Right.

Dave: "So, let's go. We'll find--

Chris: It seems fine. To this point, it works so well, I'm like, "I don't even remember what the deal with the tokens is. Screw the tokens. I don't care."

Dave: Yeah. No, you might not even use them, honestly. That's the other point. Why would you pay somebody to do this? Why would you pay a service for this? Because you're not managing user data.

I just literally read about a Facebook. Somebody basically scraped Facebook by entering every phone number ever. That's a problem. Storing user data is a bummer and a liability. So, maybe you pay somebody to do that for a while. Not to overpitch, but Netlify has a really generous plan for their Netlify identity stuff.

Chris: Oh, right. Yeah. That's cool, isn't it? Yeah.

Dave: I don't know. I'm not a salesperson, although they should put me on the payroll. It's like maybe 1,000 users for free. If you're over 1,000 users and not making any money, you maybe have to rethink things. But if you have 1,000 users, you should be able to pay $1 (or whatever) a user to keep them logged in. I don't know.

Chris: Yeah. Even that is probably expensive. It's probably more than we charge. Although, I don't know. I haven't looked at it. We just do our own thing and it costs us zero bucks, other than technical debt.

Dave: What is it? Not oauth.com but what's the auth...?

Chris: I know what you mean. Isn't it like Octa does it, don't they?

Dave: Yeah. Oh, man.

Chris: The big OAuth one, though, what is it?

Dave: Is it Auth0, Auth0 is what I'm thinking.

Chris: Auth0, that's right.

Dave: That's right. Okay, so Auth0 is pretty cool. Also, they handle the user experience. You don't have to create your own login forms and stuff like that.

Chris: At some point, you'll either need to build a UI or have some strategy for looking up your users.

Dave: Mm-hmm.

Chris: Know that. At least you then get that in Netlify or in Auth0 or something.

Dave: But you can kick that can down the road a little bit. You know what I mean?

Chris: Sure. Probably not the most expensive thing you do.


Chris: You bought some art recently, didn't you?

Dave: Oh, yeah! I've been building out the bookshelf. You can see it here on Around.

Chris: Very clean.

Dave: It actually is immaculate because I'm in a tiny circle.

Chris: I'll do it. I'll do it for the radio people. There are some books. They look organized. There are some vertical. There are some horizontal. You've got to break up the eye a little bit. There are some action figures because how do you know you're a nerd if you don't have some action figures there.

Dave: Mm-hmm. There are some trophies my company gave me based on weird things my clients have said to me.


Dave: My favorite is, "You the only dev'r I know." That was a text from a grownup or a DM from a grownup asking me to do something.

Anyway, so I have this thing here, so I'm doing the office. But I had some cool art come through. Monica Dinculescu -- sorry, Monica. I can't get your last name, even though I've tried 15 times -- @notwaldorf on Twitter, she has a new store open where she's doing art, which is maybe her pandemic habit or whatever, but she's doing algorithmically generated art.

Chris: Mm-hmm.

Dave: It's really pretty damn cool, and so I just saw it and I was like, "I want it. Buy," and I bought it, so that's great. Then my friend Rob Weychert (you might know him as Windhammer from the air guitar circles), he puts together zines occasionally, and he's doing these explorations on form where he wrote a Python script that'll just basically take some instructions and print out every variation of whatever zigzag lines or something like that.

He basically goes deep on finding every variation of something. It's cool, so he made a zine about that. He sent me one and it's just awesome.

Chris: Zines are the coolest.

Dave: I'm going to maybe make one, but we'll see one day.

Chris: Really?

Dave: Yeah.

Chris: I have this -- of course, my desire to be meta into it is almost stronger than to actually do it. For example, you know I have a history in print.

Dave: Yeah, and ceramics.

Chris: Yeah. I have just learned about it. I'm sure many print nerds long knew about these things before I did, but I was just learning here. It wasn't part of my history so far. There's this company called -- I'm going to probably even say it wrong -- Riso.

Dave: Mm-hmm.

Chris: They make these duplicator things like a two-color thing. it looks like a photocopier, but it has literally print rollers in it. Meaning, you can layer color in a way that you couldn't on just an inkjet or something. An inkjet, it's one pass. It goes through all the colors on it. It comes out all over the place. But when you have rollers, you can lay down the red and then lay down the yellow on top of it, or whatever, and get kind of cooler effects. That's very zine-like.

Dave: Mm-hmm.

Chris: It has that kind of like home printing press quality to it, although this would then allow you to kind of do it at a higher scale than you could if you were just silk screening at home or something. You could make a run of 1,000 a little bit more practically but still have that really cool look to it. Of course, I have this tab open for like two years now where I'm just like, I'm going to buy one of these things. I'm going to get one.

Dave: The whole Riso machine.

Chris: Yeah, but just so that I could help other people with their zines instead of having to actually design one myself.

Dave: Mm-hmm. There's actually -- let me see if I can find it. There's a company that will let you print a magazine on a Riso lithograph kind of thing. I'll see if I can figure -- oh, Newspaper Club, I think is what it's called.

Chris: Nice. Yeah. Surely, someone has monetized this already.

Dave: NewspaperClub.com. It's basically, yeah, you can do broadsheets or tabloid prints and stuff like that.


Dave: Do you remember Mike Montero, angriest guy on the Internet? [Laughter] He continues his streak. He made his -- here, hold on. Let me go to the zine section of my bookshelf here. He made this Ruined by Design, but in a printed zine format.

Chris: Hmm.

Dave: What's interesting about this, part of the reason I bought it, I think it was printed by the same company who printed Maximum Rock 'n Roll, the punk rock zine from way back, so it's pretty cool. Here's Rob's zine. Yeah? Yeah?

Chris: Oh.

Dave: It's very nice.

Chris: It is.

Dave: And it has all these kind of art forms on the inside. It's pretty cool. You're not seeing this on the audio podcast, but here's this one, Chris. This is a copy of Wimp Killer #2.

Chris: Nice!

Dave: The zine I did in high school with my friend Mike Rice.

Chris: Aw, Wimp Killer, I love it.

Dave: And you're muted. I can't hear you but hold on.

Chris: Wimp Killer.

Dave: Yeah.

Chris: That's the best. I love it.

Dave: Yeah. So, anyway, we did comics. It's pretty good.

Chris: Yeah. Yeah. I dabbled too. I had some friends. We collaborated on comics with. I'll dig them out for you someday.

Dave: Yeah.

Chris: Someday, I still laugh at them. Can you look at it and still be like, "That was actually funny," or do you cringe?

Dave: I don't know if it's cringe. I think there's a lot of cringe in here. I was in a bit of a pro wrestling phase.

Chris: [Laughter]

Dave: Uh, yeah.

Chris: Fair enough.

Dave: There's a detention slip from my friend Andy. The offense was running in halls with pants down screaming, "I'm a leprechaun." I don't know. That stuff is funnier in high school. It probably doesn't translate to ... human.

Chris: No, but sounds like he was making you smile, so that's worth it.

Dave: Anyway, it's just -- anyway, these -- it was fun. Good memories of going up to Kinkos at 3:00 a.m. to scan copies because that guy was chill and other people weren't.

Chris: Hmm, that's cool. I'm attracted to the esthetic of digital art almost always. If there is some element of randomness to it but it was clearly built as a system and the person who did it was clearly thoughtful about it, they put interesting parameters behind it.

Dave: Mm-hmm.

Chris: Usually this digital art isn't like, "Computer, do 100% random anything you want and look at output." It's not noise. It's usually like, "I've designed this thing, but it turns out that randomizing it is actually interesting. That each iteration of it is then cool."

I'm looking at Monica's store here and she's got a top-down view of a record player. You're looking at the top of a record, but it's very stylized. The grooves in the record, you don't see every groove. You see a selection of grooves and their different angles and at different places on the record and different colors and stuff. That type of thing to me begs for randomization.

Dave: Mm-hmm.

Chris: Like, what color should it be? Where is it placed on the record? That kind of thing. You can imagine and I, just of course, think of CodePen. What a perfect place to build that kind of thing.

Dave: Yeah.

Chris: You'd hit some kind of button and it makes a new version of that record that's random. To me, that randomness, even if you take one cap and then print that one, which it looks like Monica has done here, it's almost cooler to me when it's left digitally so that, each time someone sees it, it's more random.

Dave: Well, this record player thing, it's actually, you enter your birthday and it'll put the planets in the alignment they were on the day you were born.

Chris: Oh, that's incredible.

Dave: Personalized to you, so there's cool stuff you can do. You bring in variables into art, and so much of this is programming art or code is poetry. But for me, it's just like, "Absolutely," is the answer.

Even artists, I think of Andy Warhol who was just a weird dude, but an artist, nonetheless. His stuff is pretty basic, but he figured out a formula. His art was formulaic. He'd come up with a formula and then he'd do 10, 20, 30 pieces, and then industrialize that, do 5,000 prints or whatever, just to -- well, he made a bunch of money. He made a grip of cash, but he industrialized art in a way that other people didn't, but he's just figuring out the variables he can play with in a space. I think that's programming. I don't know. That's CodePen too, like, turn your CodePens into printed art like Monica.

Chris: Yeah. Good job. We'll have a link to that in the show notes, of course. Maybe we'll leave it at that this week. Huh, Dave?

Dave: Yeah, we can wrap it up. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show - even ten years down the line or whatever we are. Yeah, and follow us on Twitter, @ShopTalkShow, for tons of tweets a month. Support us over on patreon.com/shoptalk show and join the [techno voice] Discord because it's a fun place to be.

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

Chris: [Deep inhale breath] ShopTalkShow.com.