494: WYSIWYG Follow Up, Open Source Maintenance, Micro-Frontends, and Fleet vs GitHub Copilot vs VS Code

Dave's got some WYSIWYG follow up, thoughts on maintaining open source projects, what role do you assign clients in WordPress, what are micro-frontends, using HTML to author web components, an update on Coil, and Fleet vs GitHub Copilot vs VS Code.


, , , ,


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:38 WYSIWYG Follow up
  • 07:34 Open source Maintenance
  • 18:18 Sponsor: Backlight
  • 19:42 What role do you assign clients in WordPress?
  • 24:56 What are micro-frontends?
  • 34:05 Why don’t we use HTML to author web components?
  • 48:36 Sponsor: Shortcut
  • 49:25 Fleet, GitHub Copilot, and VS Code
  • 56:41 Coil update

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 Rupert and with me is Chris Coyier. Hey, Chris.

Chris Coyier: Yeah. What's up, dude?

Dave: Oh, you know. Remember last week, we talked about WYSIWYG for like 45 minutes? [Laughter] Remember that?

Chris: Oh, no. Actually, I do remember because I made fun of you a little bit because we talked about Quill. Was Quill the good one or the bad one?

Dave: Quill was the good one I was using. Yeah. I was into Quill. I had a few issues. Remember? Like the ULs and the LIs were all weird?

Chris: Oh, yeah. That's right. To do a nested list, it was like, "I'll just add a class to the same level of ULs," which didn't seem like the most ideal output. Although, I am curious. If you ask for the HTML that Quill produced, was it right then and it just so happened that inside the editor--?

Dave: No, it was not right.

Chris: Oh, okay. No, it was not.

Dave: Yeah, so when it outputted HTML without the styles they had was just a--

Chris: It was even worse, huh?

Dave: It was just a flat list. You know?

Chris: Yeah.

Dave: Anyway, I got into a bind. It was the version that supported the tables plugin was version 2, but the version that had the correct OL and UL stuff (but not the nesting, just OL and UL themselves) that's on 1.3.7. The change hadn't gone up to the 2.

Chris: Oh, so they regressed? Yeah, okay.

Dave: Ugh. And then I was just like, "Man, this is not going well," so I deleted it. I deleted the branch and I went to a fourth or fifth. I looked at every single -- I went on GitHub. You know how GitHub, people put up those awesome lists?

Chris: [Laughter] I know. What is up with "Awesome Webpack!" or whatever?

Dave: Yeah. Yeah.

Chris: And it's just lists of stuff. Yeah.

Dave: Sometimes, it's not actually awesome. But no. [Laughter] I found probably the least awesome "Awesome List," Awesome WYSIWYGs. [Laughter]

Chris: Uh... [Laughter] Yeah, and then there was a hundred of them because we've mouth blogged them on this, on here.


Dave: CK Editor, FKC Editor, Tiny MCE, all these things, and I just went through it, man. And I went to--

Anyway, so Quill is on there. But there's this one called Slate, which looked pretty good.

Chris: Oh, yeah. I remember that one.

Dave: Slate is kind of cool and extensible and stuff like that. It has a lot of good stuff.

Chris: So, you've given up on Quill, and now you're shopping.

Dave: I'm shopping. There's Trix from Basecamp, which is kind of their take on the editor.

Chris: Okay.

Dave: You know how Basecamp has mixed reviews. [Laughter]

Chris: But if you use it, though, you can't talk about politics in the text area.

Dave: Yeah. If you blog politics in the text area, you're out. You're done. You just pack up and leave.

Then there was another one. Jodit looked actually kind of good. I don't know. Then there's Draft from Facebook, but it's all in React and stuff like that.

But I ended up going with this one called Tiptap, which we talked about in Episode 486, 489 - whenever we talked about WYSIWYGs.


Chris: It seems pretty beloved, because you were doing this journey in the Discord a little bit. Then when you mentioned Tiptap, everybody was like, "Oh, yeah. The good one." [Laughter]

Dave: 488 is when we were talking about it. Yeah. Yeah, people were like, "Oh, yeah. That one is great." I'm like, "You should have fricken' told me."

Chris: [Laughter]

Dave: But anyway, Tiptap is based on ProseMirror, which we love ProseMirror because it's a sister of CodeMirror. Right?

Chris: Yeah.

Dave: But it's kind of a wrapper around that.

Chris: Yeah, it kind of has the bus factor of one thing going on, though.

Dave: ProseMirror? Yeah, but I feel like--

Chris: Still... I don't know. CodePen has been in that bucket for over ten years now, so going well.

Dave: Right. Right. Yeah, and maybe this thing, like, no one knows how to work on if something goes wrong there. [Laughter] But it is kind of a -- I just think, anyway, there are a lot of people involved. There's a big community. This one has 54 issues, not a thousand issues - and stuff like that.

Chris: Hmm.

Dave: Let me just--

Chris: Anyway, it looks good. Right? But you had a checklist, though. It's got to - I don't know - be a text area, and so you can bold and italic.

Dave: It's got to be a text area.

Chris: You wanted tables because that was--

Dave: Tables was sort of critical.

Chris: And image uploading. That was a big one, right?

Dave: Image uploading, and Tiptap does not have native image uploading yet, and so you have to go to a gist or somebody did it in a-- [Laughter]

Chris: It has APIs that support it, but it's just not a first-class citizen?

Dave: Right, because the way they do it is just, "Give us a URL and we can put an image in the image component," so it's up to you to figure out how to make the modal or the uploader or whatever you're doing to get an image URL.

Chris: Okay.

Dave: I wish it was more out of the box for dummies. But maybe it will be one day with a fricken' dialog in the mix. You know? Maybe it will actually--


Chris: It's also not free, it looks like. Yeah?

Dave: Uh, well, it is free, but then if you want to -- they have a new-new version coming out with some pro features, and so you can get into that. I couldn't even tell you what a pro feature is, but it's usually multiple concurrent users, so more of a paper doc or a Google doc.

Chris: Yeah, but that's a ProseMirror thing, too. It's not like they invented that. What is it? It doesn't even say. They have all the prices, but they don't say what the features are.

Dave: Here. I can maybe find one for you in the docs. I'm very familiar with the docs now. But one thing that is nice is, like--

Chris: Oh, here are some upcoming features: emoji, annotation (that's good), block style (which we talked extensively about. That's cool), collapsible content, showing invisible characters. Okay, so they have ideas, but they don't look like they're done yet.

Dave: Yeah, unique IDs for, I guess, editors and stuff like that. Anyway -- or even maybe blocks and stuff like that. Yeah, it's kind of actually morphing. I've seen block editor treatments.

We're not going to do that. We just want the WYSIWYG, but I ended up on Tiptap. I thought the listeners would want to know.

Chris: Sure.

Dave: It is pretty great, actually.

Chris: What are the chances that next week you're going to tell us it's another?

Dave: Don't curse me!


Dave: Mr. Dave went through his backlog and he needs to move on to other junk, so--


Dave: Real fast, so anyway, it's good enough and I made an issue for the image uploader. That'll be done by me in Q2 2022. We'll figure it out later, but I want it. It's just like it'll happen later. [Laughter]

Chris: Yeah. Fair enough. It looks like it can support it. Maybe by then, you can pay the 22 pounds and somebody will have written it for you as a pro plugin.


Dave: I actually have been thinking. Today, even, as we're recording this, Sentry is putting on this GitHub open-source maintainership thing.

Chris: Okay.

Dave: This experience with Quill actually has me thinking about it because Quill has 1,000 issues, 78 open pull requests or 1,000 open issues. Then if you go to the insights and look at the forks, there are like a thousand open forks.

Chris: Whoa!

Dave: It's just because somebody found a fix and they had to fork it to put the feature in the thing.

Chris: Yep.

Dave: A lot of people are--

Chris: And they have to keep it on GitHub because they probably NPM pulled directly from their fork.

Dave: Yeah, so there's a sign there are some maintainership problems there. Anyway, Sentry is putting on this GitHub maintainership webinar thing with a panel with a bunch of people. I'm really interested in that because this whole experience has me thinking about how do you do maintainership and why is it not taught? You can't go to github/learn and learn about maintainerships. You can learn about how to spin up new repos, how to spin up GitHub actions and charge yourself more money -- [Laughter] You know? -- SSH keys, but you don't learn effective issue management.

Chris: Right.

Dave: Effective community.


Chris: You could have this whole thing and learn deeply about it and how to manage it in the best way, but you might as well say upfront, "Oh, yeah, and the hourly rate for that, Dave, is zero dollars and zero cents. So, just do that in your free time while you're trying to manage your career too."

Dave: Yeah.

Chris: That's the thing that blows my mind. It blows my mind that it exists at all. I know that's sad, so I'm kind of a crappy person to talk about this. But I would never, never--

Dave: [Laughter] I would never open-source a project.

Chris: No! I just wouldn't. I would do what Tiptap is doing, maybe. I would say that's open-source, but I have a very clear and strong money plan for this thing. And I would do better than Tiptap. Sorry, Tiptap, but I would say that there's a very limited free plan and the pro plan unlocks all the stuff that you actually want, because there has to be money or I'm out. I'm not going to sit there and baby your little issues for no money. It's not happening. It's just my personality.

Dave: Well, and I think that's part of it too, right? How do you effective monetization, not like we need to monetize open-source so much? But just how to get supporters. Are there tips and tricks? What can you do to get supporters? Are there feature breaks? Are there support systems?

Chris: Yeah. Also, what works and what doesn't? Because "Buy me a coffee," as cool as that little app is - or whatever - and I know people like it, that's not doing it for anybody.

Dave: No.

Chris: You know what I mean? What works? Well, you can look at the big dogs. Look at Automattic. All their work is open-source, and they make a billion zillion dollars on the things that they do. Right? It can work if you really knock it out of the park. But there's a lot of space between Automattic and - I don't know - your open-source React slider - or whatever.

Dave: Right. Does every open-source project need to be a company? Does 11ty need to be an LLC that has [laughter] a chair and five co-chairs?

Chris: Maybe. Maybe it does, though, because that one is big enough and long last enough and at the foundation of enough websites that that one probably kind of does need that kind of governance.

Dave: I feel like we've seen monetization moves in the past, large JavaScript blogs [laughter] who shall remain nameless. You're kind of just like, "What's going on?" This seems to be impacting the product in a different way, so I don't know.

Chris: Mm-hmm.

Dave: I don't know. I just want to know what's the effect. Then even like why doesn't GitHub help people? They're like, "Hey, this project is really popular but very poorly maintained. Maybe we could send some people over to help them maintain it," or get it on the rails, like, "Here's our three-day crash course to get a new project up and back to healthy."


Chris: Do you get the sense? We didn't actually hear anything from Quill or anything, not that people monitor ShopTalk Show for news alerts here or anything. But it does seem to me still, and I'm about to -- I felt guilty about this, and now I'm going to feel even more guilty about it. It feels like Quill is in one of those kind of sad state kind of things. I'd love to know if they think that's true or if they've just completely stopped caring or if they really care and they actually think their project is going fine, thank you very much.

Dave: Well, what's interesting is it looks like it has two core creators/maintainers. They're all tied to a product called Slab, which is kind of like a Notion notebook-y product, a project management kind of tool.

Chris: Okay. That's good. Right? We open-source the thing that our product uses, and we care, actually, a little bit more about our product, but hey.

Dave: Right, and so that's good as long as that company stays alive, or as long as these guys still work at this company.

Chris: Yeah.

Dave: It's in use, but the needs or the desires of it are probably very tied to the business goals that that business is going through. I thought (in my consumership), I just was like, "You know what would help me is a roadmap." Maybe you could just use GitHub projects and show, "On our way to version 2," or milestones or something, and just show what features are going in version 2. Are they underway? Are they in progress?

That's the thing people look at, too. They're like, "It looks like V2 is never going to happen," so it would be cool to communicate visually or issually or whatever -- however you want to do it -- how far version 2 is to being released.

But they're probably actually doing all their stuff in some other--

Chris: Yeah, and it's a little difficult to say stuff like that. I understand the hesitation to not announce what's going to happen. I think a lot of people's lives are like, you know, any given Sunday, you could have a huge burst of energy and be like, "I'm going to finish this."

Dave: Mm-hmm.

Chris: "I'm super into it right now," or your car breaks down and you're like, "You know what? I hate that project. I'm just going to never work on it again." That could be one day of change in your life.

Dave: Again, it would be cool if there was some education - or whatever.

Chris: Then tell people that.

Dave: Just tell people you don't want to work on it anymore. [Laughter] Tell people you think you shouldn't use it.

I'm going through that with my little jQuery, like, "You know what? CSS does this now, so maybe don't use this. Don't use FitVids. Don't use fit text."

Chris: Oh, yeah. FitVids is out now that aspect ratio is all the way dropped.

Dave: I'm just like, "You know, let's just deprecate it. Say goodbye and put a little notice on there."

Chris: Mm-hmm.

Dave: "You don't need this anymore. Rip it out of your codebase."


Chris: Right. I agree. I'm not saying anti-education, for sure. I think that's true. I wonder if the weight is harder between certain scope of projects?

Dave: Yeah, definitely. This was a WYSIWYG. Probably thousands of users - clearly.

Chris: Yeah.

Dave: It's got thousands of forks. How do you manage all those expectations, a thousand people? Is there something?

I was talking to Zac Leatherman about it. Maybe we should get open-source maintainers on the show and talk this out.

Chris: [Laughter] I know. I actually have some guest ideas and some stuff in the works, so it's not the Chris and Dave show. We had a little run there because we had to but, next year, I'm sure we'll get the guest train rolling again.

Dave: No, but I was talking to Zach Leatherman a little bit. I just was like, "I would love to know how you manage 11ty."

Chris: Mm-hmm.

Dave: He was like, "Well, one, I deprioritize new features as much as possible. Say no by default. That's number one. Number two, every project needs Peter deHaan," who is a QA at Mozilla, but probably he's running project management, basically, or something, or issue management or something.

Chris: Okay. Yeah.

Dave: Kind of volunteer, again, or paid. I don't know his life. [Laughter] Anyway--

Then his number three is he's like, "It's annoying most companies won't donate and they need to be sold on something," so kind of back to your thing. It's like if a company is going to invest in it, they want to make sure they're getting something in return. They want to make sure they're getting a kickback, a feature set, a new thing. You know? Otherwise, companies won't commit dollars to fund the code that they're using on their entire marketing site. [Laughter]

Chris: Hmm.

Dave: I think that's it. There's this three-part thing. How do you solve the scope of the project? How do you solve the issue management or project management or QA? And how do you solve the funding of this development as well?

I don't want millions of dollars to work on FitVids. I think that's stupid. But I think of the accessibility project. It would have been a lot easier if I could have bought months of my time to go work on that - or something like that.

Chris: Yeah. Yeah. Yeah, I could see when somebody is feeling down. Then it feels like just an absolutely broken system.

Dave: Right.

Chris: Yeah.

Dave: There's a really good -- I'm blogging all this in my blog post that I never release. [Laughter] Jacob Thornton's 2012.js talk, "What is Open-source and Why Do I Feel so Guilty?" That's the best talk.

Chris: It's a good one?

Dave: Best talk on open-source I've ever watched, and I watch it frequently, so it's kind of like a history of open-source. Then it's just like, why is this such a drain on my soul, my lifeforce?

Chris: Oh, God. That makes me sad.

Dave: Well, yeah. Right? It's not fair. It shouldn't be that, right?

Chris: Right.


[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Backlight. That's backlight.dev. It is no joke the most impressive tool I've ever seen for working with design systems. It's really worth checking out.

Here's one way to frame it. Let's start in reverse. What's the best thing possible for a design system? It's that ending moment where you have this beautiful design system and it's published to NPM. Anybody that wants to use it -- particularly, people in your organization -- NPM install the thing and use it. That's done.

Backlight totally helps you get from starting the thing all the way there. At kind of its core, it's this in-browser IDE for your design system, so you can look at your design system, reference it, see it, and know it's available. It's just great. Anybody can do it, look at it, and use it. But you can also work on it in there, too, because you can see the code in there, edit the code, and work on the design system in there, too. That's just all amazing, to begin with.

Then before it goes to NPM, it's a Git repo, too. They're not even trying to lock you into anything here. These are all industry-standard tools that we're using. It just helps you get one started, work on it, talk about it, work on it with your team and, ultimately, even get it to NPM. It's just this amazing full, end-to-end system for design systems that you really need to check out. It's absolutely impressive.

Thanks for the support. A brand new sponsor, backlight.dev.

[Banjo music stops]


Chris: All right. Well, I mentioned Automattic. We have a question, a quicky WordPress question, from Fredrik Eklund. "What role do you assign client users on WordPress websites? Do you give them admin or editor or whatever?"

In WordPress, admin, and probably most apps, admin is usually the most powerful role, except for owner if there happens to be an owner role. Usually, that's even up above and beyond admin.

WordPress has lots of roles. Four or five, I think, out of the box.

Dave: Yeah. Guest, admin, author.

Chris: Yeah.

Dave: Is there an editor?

Chris: Yeah, editor is one, for sure. I think, for example, an author can create a post but not publish it. An editor can edit their posts and publish, probably.

Dave: Mm-hmm.

Chris: Yeah, so if it's a client, I mean there's no one answer to this. I would think a lot of people give admin because it's like, "Hey, it's their money. It's their website. Why would you limit your own client's access to the thing?" it's probably better to give them admin access and educate them rather than try to block them from doing anything.

I could see the editor role as being pretty good, too, because it might prevent them from breaking their site so much, but editor is pretty powerful. They can still change content a bunch.

Dave: I think they can even install plugins and stuff like that, at that level.

Chris: Yeah.

Dave: Right?

Chris: Perhaps. You know what? I would say I use this and have used this plugin. There's some kind of user role editor plugin for WordPress that allows you to invent new roles.

Dave: Mm-hmm.

Chris: Fine-grain change the permissions. I've used that for a long time just because I like that kind of fine-grain control.

I don't know what to say, Fredrik. Probably admin if you're not worried that they're going to break the site, or editor if you are worried they're going to break the site, or maybe even author, or maybe even no role [laughter] if you're really worried they could break their own stuff. There's no one answer to that, I'm afraid.

Dave: Yeah.


Chris: You probably know that. I would take a moment to mention, though, that this is an interesting topic that I think is probably underserved of why WordPress, not that I continuously need to dredge this up. But the fact that they have really nice auth and role management is a pretty big reason right there.

Then if you're going to pick, like, "Oh, I'm going to pick some other stack just because I think it's more modern and hot," I totally get it. I pick modern, hot stacks sometimes, especially when it's just me and I can rock that. But when multiple people are involved, the fact that you get auth, no-brainer auth, and fine-grain permission control for people to do things on the website is no joke. That's great. That's great.

Dave: Huge. I mean, and it mostly works out of the box. You have to kind of work hard to break it, to give something to somebody. Yeah.

Chris: Yeah. And there are password resets, and you can customize those. Yeah. Oh, you want to have social auth too? We can do that. Or login with WordPress. Design the login page. It all just works, and that kind of thing is not to be discounted.

Sure, there are other auth products out there that are pretty neat-o too. But they're going to be more work. They're going to be more technical debt for you, and that's just a tradeoff you're going to have to think about. Yeah.

Dave: Yeah, or they're bolt-on. As much as I like Auth0 or something like that, it's like, "Cool. Now I've got to bounce out to this Auth0 website. Then it'll send me back," or whatever.

Chris: Yeah.

Dave: I would say definitely the people who sign the checks, make them admins just because if that relationship goes sour, you want to be like, "You have everything you need, my guy, so good-bye." But also, it's just theirs. Make them the admin.

Chris: Yeah.

Dave: If somebody is just going to write, if it's just a group, I would make "author" the default role. Then if somebody is just, hey, they're in charge of the publishing schedule of the content, like the content manager or something like that, make them an editor. Just give them the power to do what they need to do.


Chris: Yeah. I had forums on the site for a long time, and then the roles got all twisted up into that because you can be a moderator and different form stuff in there with bbPress. I'm sure BuddyPress has its own roles and stuff. I love that, that plugins can tap into that and extend it and do stuff.

Here's another one. Rafael Ferrand, "Hey, guys. Love the show." Thanks, Rafael.

Dave: Thank you.

Chris: Love you too. "Lately, I keep hearing about micro front-ends. What is it? What are the benefits and advantages/disadvantages kind of thing?"

I haven't heard that word in a while. It had its day in the sun maybe a year or two ago. People were saying micro front-ends a lot. I think it had to do with there's a little part of the app. It not only is built independently, but even as so far deployed independently, I think.

Dave: Mm-hmm.

Chris: Maybe you're on the weather widget team, and you get to make your own tech choices and do all your own stuff and ship it to the website totally independently. It doesn't have to go out with the rest of the entire website.

Dave: Yeah.

Chris: I think some people like that and certainly some companies benefit from that. But I don't see it as having taken off as a trend in 2021, nor do I see it taking off as a trend in 2022.

By the way, weren't we going to do a show like that? I think we should do that.

Dave: Oh, yeah.

Chris: One of those, like, what's going to happen in 2022. If you want to write in and tell us what you think is going to happen.

Dave: Let us know.

Chris: That would be neat.

Dave: Yeah. You know how when you go to Amazon and every page of Amazon looks a little bit different? Like it was coded by a different department that doesn't exactly talk to each other?

Chris: Sure.

Dave: Perhaps a six-person team, a two-pizza team. [Laughter]

Chris: [Laughter]

Dave: Created one page and a two-pizza team created the other page. That's what I think of when I think of micro front-ends. It's just very disparate experiences.

I think there are degrees, sliding scales of granularity you can do there because you go to Apple. I think each department in Apple kind of has its own department. They kind of do things a little bit differently. But I do think their store product, how they sell things, is all unified. But if you go to the human interface guidelines, that looks different. The docs or something like that, that's slightly different, but the same design language.

Chris: Mm-hmm.

Dave: I'd just say, I think, in order to make a micro front-end work, you need a design system, like a series of components that can deploy every single micro project a micro back-end can consume to spit out a front-end in a consistent fashion. Then it won't be consistent, but you need some sort of toolbox to do that.

Maybe that's even as simple as a shared Tailwind config or something. People are going to write their own things. But anyway, I think you need a consistent design system in place before you approach the micro front-ends. Otherwise, you're going to get--

Chris: It's going to be a danger - danger, danger.

Dave: Danger. And I've even seen the islands architecture, sort of like every--

Chris: Yeah. I was going to bring that up, too. Slightly different, but similar, I think.

Dave: Slightly different, but it's just like every -- like the header of your website is its own island. The sidebar is its own island. The footer is its own island. Maybe those are maintained by separate teams entirely. Your page just sort of stitches up these islands or these components together.

Chris: Yeah. Right.

Dave: That can be good or bad.


Chris: I think what got mixed up with micro front-ends is that there was this -- I don't think they shied away -- whatever the proponents of it were -- from saying that one of these micro front-ends could be in React and the other one could be in Vue. That's fine. Who cares? Those teams can make those things.

Old-timers like me, we're like, "What?! Absolutely not."

Dave: Yeah.

Chris: But they're like, "Whatever, old man. The times are changing. Some of these libraries are only 30K. Who cares?"

Dave: Mm-hmm.

Chris: I was like, "Well, I don't know. I just do care, still. Convince me otherwise."

They were almost to the point of they're almost like iFrames. You know? [Laughter]

Dave: Mm-hmm. On your website. Right?

Chris: I think they maybe stopped short of saying literally iFrames, but maybe not sometimes. They're like, "Yeah, maybe sometimes," but that's not. Imagine the header team being constrained to an iFrame. Not going to have a dropdown hanging off of that sucker.

Dave: Yeah.

Chris: Anyway--

Dave: Yeah. No, I mean I think that's part of the -- I don't know.

I think there's this dream state among programmers. This is what I call Hawaii. This is what I call it. I call it Hawaii.

Everyone doesn't want the monolith because, "Oh, that's the big, slow monolith. We've got to have the distributed thing."

You're like, "Okay. Cool. You want just a bunch of people doing their own fricken' -- you want the confederacy. You don't want the federal where it's governed. You want the confederacy where everyone does their own thing."

Chris: Hmm.

Dave: Then people are like, "No, no, no. We want it beautiful, fully isolated, separated, encapsulated, but they all work together in unison."

It's like, "You want Hawaii. There's only one Hawaii, man." [Laughter] There are maybe two, three Hawaiis out there, and these islands, to get them to work together is very difficult. It's not just that easy.

Chris: I see. Yeah.

Dave: Hawaii. People want Hawaii.

Chris: Yeah.

Dave: Everyone wants Hawaii.

Chris: Maybe the islands architecture works in that way. I think that more and more frameworks are starting to pick that up as, like, "This little piece of your app might have some JavaScript in it, but it's all kind of like scoped, and it's not an iFrame."

You know how Astro has, "Only load this island when needed"?

Dave: Yeah.

Chris: It has not only the tree shaking and kind of -- What's the other thing that goes along with tree shaking?

Dave: Bad code...?

Chris: Only load it when you need it?

Dave: Oh, like a conditional loading? Yeah.

Chris: Right, and that sometimes is like, "Well, what's the URL? If it's not on that page, then don't load that JavaScript."

But it can go farther than that. It can go, "Is it visible even if it is matching that route?"

Dave: Mm-hmm.

Chris: Is the browser idle? Then can I load it? That type of thing. That type of stuff, I believe, is what has been come to be known as islands architecture.

Knowing that they're all on the same page then doesn't free you up to write in eight different frameworks. Ironically, Astro does help you write in multiple frameworks. Usually, when you're doing that, the best practice is that all the JavaScript is being stripped away. It's just a different way to generate HTML. [Laughter]

Dave: Yeah.

Chris: I know that's a lot to digest there, folks. Yeah. Rafael, I'd say that micro front-ends is not a trend that's super caught on. Dave listed out the caveats pretty well to it there that you better have a pretty strong model in place before you even start thinking about that.

Dave: Yeah. I think you need it, or else it's just chaos.

Chris: Mm-hmm.

Dave: Then every project, every micro, every page of your app you hop in to work on is fully fricken' different. No thanks.

Chris: [Laughter]

Dave: This one is with Bootstrap. This one is with Tailwind. This one is in Adonis. This one is in -- no way.


Chris: It's one of those things. You know how Jeremy Keith talks about there are two classes of tools? There are tools that help the developer and then there are tools that ultimately get shipped to users.

Dave: Mm-hmm.

Chris: Something like jQuery, that ended up being user-facing because it literally has to be downloaded by users.

Dave: Mm-hmm.

Chris: It's a different class where he would consider Sass just a developer-only facing tool because we use the tool, but what ultimately goes to the user is CSS. The user is not influenced by the tool. Even though - whatever - it kind of is a little bit because, for example, you could write some gnarly ass Sass and ship some gnarly CSS to users. Then it's like, "Hey, well, Sass really is affecting users," but that's just a caveat. I think he's right on, generally, with that distinction - in a way.

Dave: Mm-hmm.

Chris: In that some of this is related to that, in a way, that micro front-ends is something that's just for you. That's just for your organization. The users do not care, so you've implemented this thing that, at best, is going to be level with not doing it. But chances are it's going to hurt the user experience because it's going to be all disheveled and loading extra crap it doesn't need to load and all that stuff.

You've pushed that to the users. You pushed this crappier experience just to solve some internal debates just because you were sick of having too many meetings or whatever. [Laughter]

Dave: It happens more often than you hope. Then, too, it's like, "Well, the offshore team, "or, "the vendor said they could do all the pages for us, so we're just going to outsource it to them." You know? Like, "We're going to cut a corner here." Those pages come back weird and different, so what do you do?

Chris: Yeah. Well, let's just keep beating a dead horse here. I've got an interesting one that's been on my radar a little bit since the end of November, I would say.

Dave: Mm-hmm.


Chris: It was bram.us, Bramus Van Damme's excellent blog. Really has a bead, I think, on lots the most interesting tech front-end stuff is happening. This was back the end of November, he blogged this.

It was an article by Florian Schulz: "Why don't we use HTML to author Web components?"

Dave: Mm-hmm.

Chris: I figured Dave probably read this one. It just seemed interesting to me. Once in a while it takes me a minute to even understand why it would even matter. I'm like, I don't know. We have Web components. They seem fine. Why do we have to constantly talk about this?

The way he lays it out is like, "Yeah! Dang it! Why can't we do that?"

For example,

Dave: Mm-hmm. Mm-hmm.

Chris: I'm just saying it for you this time.

Dave: From my perspective, it's surreal this article exists. It's like we've come full circle. Like, "Man. Why don't we use HTML to author Web components?" [Laughter] Wouldn't that be cool?

Chris: You're like, if there was only a technology that had HTML templates in it, but it could also link up CSS and run its own scripts and stuff. [Laughter] You're like, "Oh, like HTML?"

Dave: You know those cool single-file components everyone is using in all their damn projects?

Chris: [Laughter]

Dave: Yeah. Wouldn't it be cool if we could just fricken' use that? Huh? Wouldn't that be cool?

Chris: Use that. Yeah, it would be cool.

Dave: Then just use a really awesome, fast static site generator to import crap and stitch it all together. That'd be heck cool, man.

Chris: It is a little weird that this exists. It reminds me of, like, doesn't that seems simpler? Doesn't that seem easier? Doesn't it seem more natural, more ergonomic? It reminds me, in WordPress land, the advanced custom fields. I always feel like it's amazing to me that advanced custom fields' way of building a block is like, "Oh, just make a PHP file, and then that can be a block."

I'm like, why isn't that the WordPress way of doing it? Advanced custom field is the fancy React format. No, it's exactly flipped. If you want to make a native block for WordPress, you've got to B.Y.O. Webpack.


Dave: I think I'm old enough to understand Webpack was good for a time. It served -- it still serves a very good purpose for bundling. For years, it was, "Bundle all your JavaScript. Less requests is good for the user."

HTTP2 comes out and it's like, "Well, that's not exactly true, but bundle all your stuff. But then split it up intelligently so you're only loading what you need to load on the page." You know?

Chris: Yeah. yeah. What do we think the next evolution of that is? Can you see a world where it really actually doesn't matter to bundle?

Dave: I think it's -- well, yeah. I think some people are doing it. Some people say that they're just doing HTML imports from Snowpack or Skypack or something - whatever. Sorry. ESM imports.

There's so much in this question. I think the Node ecosystem, NPM, we over-microed to where it's every single function in our project is a file. Like left pad, for example, or Lodash, all of Lodash.

Chris: Mm-hmm.

Dave: These are little functions that would make great language features, but we've outsourced it to either these really big portions or these really small portions. I don't know. I think this concept that Astro was touching on, Slinkity, and stuff going, like, "We can have JavaScript, but we're actually only going to ship the stuff we need. Then on top of that, we're only going to load it when we need to load it." I think that's kind of the future. I'm bullish on that.

We kind of went overboard on everything needs to be in JavaScript and everything needs to be split up and micro and everything does one little, tiny job. Then we get into the language, and now we can import one piece of a whole package. Then we can shake that out of the package. That can only be done in a compiler.

If I say import debounce from Lodash, all of Lodash, I don't get debounce. The browser is going to load all of Lodash. Maybe these hosting platforms need to help split up things - or something like that. I don't know. Maybe there's a tool, like an NPM style thing, that can intelligently code split for you, so if I say import Lodash or debounce from Lodash, maybe I can just say Lodash debounce and it'll cut me Lodash debounce, or something like that.

Chris: Yeah.

Dave: You know what I mean?

Chris: Yep. Yeah.

Dave: Like a tighter scoped something. I don't know. Maybe that's exactly what Skypack did, [laughter] so Pika.

Chris: Well, you could load one dependency, but that one was pre-bundled. It didn't then trigger 80 more requests. Yeah, I believe that is what it did.

Dave: Yeah, but that said, the new news, like Vite and stuff like that, they're big for me in terms of developer productivity because I don't just get error on line 10,000 of bundle.js. I get error on line 2 of my component JS.

Chris: Yeah. Yeah, the fact that it does--

Dave: Source mapping correctly.


Chris: It's not really site maps, but yeah, exactly, but does it in a way that that means that the next SSG or site builder or whatever doesn't have to. You just let Vite do it. That means they can punt and just be like, oh, okay. So, we're going to use Vite. Vite means that we don't have to do our own bundling or anything. We don't have to deal with imports in our own way. We don't have to write our own hot module reloader. We don't have to build our own SSR (server-side rendering). We don't have to worry about how fast things are because Vite is worrying about how fast things are. We have a nice error reporting thing with source maps.

When you make it, if you were to decide to build the Dave site generator product, you could just say we're going to use Vite, and all that crap is already done. All I have to do is invent all the little sugar on top that makes my thing cool. Right?

Dave: Yeah. Yeah, that's a big deal. I like the posture where you're like, I actually don't want to do all the bundling and stuff now. Vite is just like, "We're just serving you the JavaScript now. We'll serve you 10,000 modules. We're not doing all the bundling now. We only do that in production."

The environment you author in and the environment you deploy in are different, but maybe there are some tests or tools. Maybe you only test with the production bundle or something. Maybe there are tests or tools or something to smooth that gap.

Chris: Mm-hmm. Mm-hmm. Yeah, I have a link in my notes here. It was an article from Matthias Capeletto who is patak.dev, linking to the Vite ecosystem, which is a very, I'd say, long blog post, but it's not really. There are a lot of logos and stuff. It's trying to show you all these tools that relate and how they relate to Vite, so whose shoulders did we stand on. Who is doing work similar to this but is different? What frameworks does Vite support? What frameworks are leaning heavily on Vite? What are the plugins involved? How does CSS get involved? It's just this huge--

The blog post is called "The Vite Ecosystem," and I thought it was really well-done. While I was thinking about this, I'm like, "I should go look. How long--?" Vite seems so new. You know?

Dave: Mm-hmm.

Chris: April 2020. So new. To have a blog post like this that's every major tech term in all of JavaScript-focused front-end development is here.

Dave: Yeah.

Chris: In a year and a half. Wow.

Dave: Yeah.

Chris: Really a blaster. It reminds me of stuff like VS Code where it's just like, "Oh, Microsoft made a thing that we can use?" Now 100% of developers use it. [Laughter] One hundred percent is a little extreme but pretty much, you know.


Dave: Yeah. Well, yeah. It's a weird, rapid adoption, sort of. I think Vite -- Evan is a very smart person. But I think it just came at the right time. There was the Webpack 4 to 5 migration was kind of tough, I think, for people. Then I think people were just like, "Man, this could be faster." ES Modules hit. It's ubiquitous.

Chris: Yeah.

Dave: Boom. Maybe this is--

Chris: Yeah, it just hit at the right time.

Dave: Kind of a confluence.

Chris: And had good pedigree.

Dave: Good pedigree. Honestly, if Dave Rupert had invented Vite, it would not be as popular because I'm not a JavaScript - whatever - [laughter] superstar - or whatever.

Chris: Nah. You have enough pedigree, though, if you wanted to do something like that. And it was actually good that you'd have just as much of a chance. Maybe slightly less.

Dave: Well, I'm not going to give something away for free. I'm going to charge dollar-dollars, you know?

Chris: I know, but Evan is another example of somebody that's got it dialed in, right? He's got the money flowing correctly to the point where it's not a problem. It doesn't seem like, anyway.

Dave: No. No. Well, and I think there's, too, a lot of Chinese companies use it because he's of Asian descent. They talk about that in that Vue documentary. I don't know if you -- I forget who does those. Honey?

Chris: Oh, yeah. Honeywell or pot?

Dave: Honeywell Dew? Honeypot? Anyway, it's a really good documentary. It took off in Asia, and a lot of people use it. I think a lot of big companies use it, and they give back. I think there's a better culture, and you'll see that. I've talked about it on the show before.

Every Vue project has a little, "How to support this project," banner at the bottom.


Chris: Yeah. What do you think about the fact that -- so that's great that Vue benefits from it and Vite probably, by extension, are included in that - or whatever - but that some of what makes Vite fast is ESBuild. That's underneath the hood.

If you have $1,000 to give, as a company, do you even think about giving some of it to ESBuild, too, or do you just give it to Vite and hope it trickles down? You didn't even know that that was built on that? I'm sure Vite uses other stuff, too. This is just kind of one example of a thing. At what point do you dig into what dependencies the other thing uses?

Dave: Yeah. No, that's a really good question. I think if you're leveraging it directly, you have more -- your responsibility is to support the thing that you're leveraging directly. I would probably support Tiptap over ProseMirror. That's who I'm thinking about giving money to. [Laughter] Although, I would give money to ProseMirror in hopes that it would either trickle down or something happens at the ProseMirror level, Tiptap has the foundation or the organization financially to absorb that change, like a breaking change or just that developer closes or deletes the project. Maybe Tiptap is like, "Cool. We'll assume maintainership because we have the funds," or something. I don't know.

Chris: Yeah. I don't know if that's a discussion in open-source or not or how big of one it is. What if your thing is so fundamental to hundreds of projects but you just are bad at marketing or don't have anything set up correctly? There are all these projects built on top of you making bucks, but not you.

Dave: Mm-hmm.

Chris: That would suck.

Dave: I think that's Henry Zhu from Babel. He's talked about that very openly. He's like, "Babel is on every website."

Chris: Yeah. Here's me alone. j

Dave: I'm struggling. [Laughter] He said that before. I think they have a modest group and funding and stuff like that, but he was telling me one time TypeScript came and was like, "Hey, here's a super pull request to support TypeScript in Babel."

Chris: Mm-hmm.

Dave: He was like, "Cool. Who is going to do it, because that's like three months of code review or whatever? I can't just merge this. Now I have to come up with a plan. I have to come with a merge strategy."

Chris: Yeah.

Dave: "I have to test it. I have to verify." Maybe Microsoft ended up ponying up bucks.

Chris: I don't know.

Dave: Did Microsoft pay Babel? I don't know. I think, for me, I need an editor. I'm going to probably give money to Tiptap. I give money to Nuxt and Vue already.

Chris: Mm-hmm.

Dave: I give money to 11ty. My open collective is all open for you guys and sponsorships or whatever. I really try to give back as much as I can.

Chris: Yeah.

Dave: It's not in the tens of thousands. I could probably give more, but I think consistent money is a big deal, so I'm trying to give consistently to different projects.


[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Shortcut. Have you ever been really happy with your project management tool? Most of them out there are either too simple for a growing engineering team or too complex for anyone to really want to use.

Shortcut (formerly Clubhouse, by the way - a name change) is different. It's built specifically for software teams. It's fast, intuitive, flexible, powerful, and many other nice, positive adjectives - happy.

Shortcut features include team-based workflows, org-wide goals and roadmaps, tight VCS integrations, keyboard-friendly interface, integrations planning. Sign up at shortcut.com/shoptalk. What a nice URL, shortcut.com/shoptalk. Get two months free - very generous of them. Thank you.

You shouldn't have to project manage your project management.

[Banjo music stops]


Chris: Yeah. I mentioned VS Code quick. I don't have anything to say about this yet, but I'm interested to see if anybody got their hands on Fleet yet. That seems to be the next one that just has any chance of giving VS Code a run for its money.

Dave: A shakeup.

Chris: That's JetBrains' new thing. It probably will, unlike something like Nova or whatever, which I think is actually pretty good and getting better. It's Mac only and people just hate that.

Dave: Hate Nova?

Chris: They hate that it's Mac only.

Dave: Well....

Chris: Yeah, and it's like, "Whatever..." I don't know. What do you say about that? But now as the leader of a team where people actually are using different computers and stuff, it is nice to say, "Can you please use VS Code, everybody, please? Because then we can put tooling and such inside of it such that we all share."

And so, I couldn't be like, "Except me. I'm going to use Nova." Then the tooling is just a little different. Not all the same stuff is supported.

Our Apollo GraphQL validator machine thing, it's definitely not in Nova. [Laughter]

Dave: Right. Right. Right. No, and that's, as I get further into it, it's just like, do all the plugins work? I really need ESLint and CodeLint and all that stuff working so I don't have to redo a bunch of work.

Fleet looks great. I have such baggage [laughter] from my JetBrains' life.

Chris: JetBrains phase, yeah.

Dave: My former client life there, so I don't know. One thing that's nice is, oh, it looks like it has multiple people editing. That's kind of fun.

Chris: Yeah, VS Code can do that too, but it looks a little cleaner.

Dave: This looks a little better, yeah. But the code completion in IntelliSense and IntelliJ, that stuff is, I think, better than even Microsoft does it. It could all be built on Microsoft, but it's pretty good. I think there are reasons to use it.

Chris: Right. That's what JetBrains people say, right? How much it helps you with your code is just way good. Although, we'll see how much GitHub Copilot changes that.

Dave: Mm-hmm.

Chris: That's not going to work in JetBrains, presumably.

Dave: Right. Right.

Chris: People are singing its praises lately.

Dave: Dude, I mean it's kind of cool. You can just walk into a repo and hit dot, and you're editing it. That's kind of sick. With your theme and your plugins and stuff going.

Chris: Yeah. I mean the AI thing.

Dave: Oh!

Chris: The auto--

Dave: Oh, Copilot. Yeah, yeah. Sorry. I was thinking Code Spaces. Yeah, Copilot. It just tells me what to code. I don't actually use it.

Chris: Yeah. How good is your auto-complete if it--? I do use it.

Dave: Okay.

Chris: I think it's kind of cool.

Dave: You like it?

Chris: Uh... I mean, yeah. I'm still in the weird getting used to it because then I had a weird phase where I was into Tabnine for a minute. But I can't really -- whatever. I have thoughts.

Dave: Mm-hmm.

Chris: But they're not fully formed, so I'm not ready to talk about it yet.

At one point, I blogged (a couple of years ago) on switching code editors. I feel like it still holds up because it's kind of like what is it going to really take to pull somebody off of something that they really need? I was talking about it personally, but it felt pretty extensible to other people, too. There's some baseline-level stuff that would get you to switch. It's got to have some feature that you think is better, that you're excited to even try. Why would you even try it if it was just going to be like, "Oh, this is just exactly the same"? Why bother then?

Dave: Cool sidebar.

Chris: Is it faster? Does it look better? Yeah.

Dave: Cool sidebar. That's it.

Chris: Does it have some stuff? And that nothing can be too obnoxious, right? You're not going to get massive adoption if it's so different, if there are too many different things. Then you'll be like, "Oh...." You know you might get some die-hards that are into it, but it can't be too different. I feel like VS Code wasn't that different than Atom, Sublime, and stuff that you could switch and it was okay.

Then plugin architecture is a big deal. Everybody is different. You need an open way to be able to change things.


Dave: Yeah. For me, I was a big Atom fan. I like Sublime Text, but it always felt Java-y to me.

Chris: Hmm.

Dave: But I liked Atom. It was kind of slow and couldn't open big JSON files. [Laughter] That's fine, but we figured it out. But then I was hesitant about going to VS Code. But then a lot of stuff is integrated into VS Code like your terminal and then your terminal, you can hit F5 (or whatever it is on Mac) and start a server. You're starting a server, and then you can do step-in debugging. I thought that was cool (that you couldn't do on Atom - you probably can now).

The built-in terminal was cool because I just saw my problems in my code editor. I didn't have a separate window.

I ended up just liking it more.

Chris: Yeah.

Dave: I don't know if I like the look and feel of it more than Atom or anything, but this Fleet--

Chris: It does feel like it could use a new coat of paint? Doesn't VS Code get a little corporate-y?

Dave: It's getting a little tight, right? Getting a little corporate-y, but what's neat about JetBrains' thing is having Git right in the -- like it's files Git history, or whatever, in their little file panel.

Chris: You don't do Git anything in VS Code? I feel like it's maybe not super first-class citizen.

Dave: Well, I have ten extensions. I have Git lens. I have the GitHub.

Chris: The pull request one?

Dave: Pull request. I use commits to stage files sometimes.

Chris: Mm-hmm.

Dave: I feel like some of that stuff could be better, like commit splitting and stuff like that isn't good. Merge, merging in VS Code is actually awesome. Although, the words are always weird, like approve change, approve current. You're like, "I don't know which one is which." [Laughter]

Chris: Why is that so hard? My god. No Git tool makes that 1000% clear.

Dave: No. It's like accept head, accept remote.

Chris: Yeah.

Dave: It's even worse. "Accept current and accept head," you're like, "Dude, which one is the good one?" [Laughter]

Chris: I think ... says, "Accept theirs or take mine," or something, which is like, "Oh, man. That makes me even more confused. They're both mine, kind of."

Dave: Yeah. I just want it to work. Then you get to the end of the big merge and there's 700 of those dash things or whatever in there, so you can't win. Merge conflicts are never a win.


Chris: [Laughter] Nope. Just because I have one last one on here, we'll do a fast hard-stopper here. I just want to mention it real quick because Ryan Filler wrote in and said he added Coil to his site, which me and you have done years ago at this point.

Dave: Mm-hmm.

Chris: It's kind of a little Web monetization API thing, which I feel still begrudgingly bullish on, like, "I still think those APIs are a good idea." But now it's years and years later. There doesn't seem to be a whole lot of movement on it. Anybody that's ever used Coil knows that you make about a quarter a quarter. [Laughter]

Dave: Yeah.

Chris: As in $0.25 every 3 months. It's very light as far as what you're going to earn on it. But the point of it was more like this is going to get big. Should this actually drop in browsers? There's competition and the world of it expands a little bit. But it just hasn't happened, so I just don't know what to think about it.

I don't think anybody should run off doing this because I feel like it just does not have any momentum at the moment. Really slow. Maybe if everybody did run out to do it, that's the momentum it would need, so there's some chicken and the egg stuff happening there, but man.

But here's what I was really getting at is that the only way you can get your money out of Coil is to attach it to a wallet, right?

Dave: Mm-hmm.

Chris: You have two choices, and even the two -- it used to just be one -- there's an online bank thing called Uphold, and there's an online bank thing called GateHub. It supports them both. You're probably going to end up picking Uphold because it supports way more stuff.

Dave: Mm-hmm.

Chris: There's that. I still have my Uphold account. Money comes into it. I think, by default, it's XRP or whatever, but you can kind of pick. I think I have mine in USD, so it comes across in literal pennies and all that.

But now, if you're going to tiptoe into the world of crypto and stuff, you've done it because that's what this Uphold wallet pretty much is, is a crypto wallet.

Dave: Mm-hmm.

Chris: I don't know if you can buy through Uphold or whatever, but at least it's going to hold onto your stuff. I just don't know. I think it felt shady to Ryan a little bit, like, "Oh, in order to even get your money out," then it's like a real bank, so you've got to cough up your social security and wire it up to your actual bank.

I think it's all pretty much legit, but it does feel a little bit like, "What am I doing here exactly?" [Laughter]


Dave: Well, and this is the crypto world, man. I've been - whatever - following it. [Laughter]

Chris: Yeah.

Dave: I downloaded a fake stock simulator. I'm simulating my crypto investments, and I've lost a bunch of money - fake money.

Chris: [Laughter] I know.

Dave: It's great.

Chris: I even have a little crypto, mostly thanks to this Uphold thing that we've talked about before, and I'm fricken' way down, too, man. I've been at it for years, and I'm down.

Dave: Yeah.

Chris: So, how's that for you?


Dave: I'm not even counting the 200 XRP I lost in my migration to Uphold.

Chris: [Clears throat]

Dave: Anyway, yeah, I think this whole crypto thing, decentralized or whatever, so you have to plug in your MetaMask to go to your Coinbase to go to your Uphold to get into the--

Chris: Oh, that's so -- there are literally hundreds more.

Dave: Yeah.

Chris: It's the most complicated thing.

Dave: If you want to sell something on OpenSea or your Foundation or [mumbling]....

Chris: I'll tell you. I've been playing with this a little bit more, too. I use -- the soup for mine has been Tezos (is the coin). What is that one? Yeah, Tezos, T-e-z-o-s. It's the one that's a little bit like Eth, but is like -- I can't speak super intelligently about it, but is more ecologically cool, right?

Dave: Okay.

Chris: Right? I get some Tezos, and that's one because I have to pay attention to this because of the CodePen community is generative art.

Dave: Mm-hmm.

Chris: A lot of NFTs are bought with crypto, which are--

Dave: Generative art. Yeah.

Chris: Yeah. Right? Whatever, so fx#.xyz is a big one that's all generative NFTs, but I think Tezos is the main money that you need to use that one. Then there are a couple of others. You can have your own soup of websites, literally, because I've even gone so far, Dave--

If this means we have to stop being friends, it's cool, but I own an NFT now.

Dave: Whoa! Whoa!

Chris: I got one of those ones.

Dave: Dude, I've got questions.


Chris: And I'm looking at the docs for making an NFT because I'm like, if it's all based on this Tezos thing, this boring coin that nobody is getting rich on, that just happens to be the foundation of these NFTs, it doesn't seem so bad to play with. You know?

Dave: Mm-hmm.

Chris: Just gambling fun, adult little project. The docs are kind of fun. I'm like, "Wow. I could build one of these," and it kind of makes me want to try it just from a fun, exploratory kind of vibe. I don't know.


Dave: Yeah. Did you read Robin Sloan's NFT story?

Chris: No. I mean I know that we talked about them based on the Web3 thing that he wrote.

Dave: Yeah.

Chris: But it's not--?

Dave: He wrote notes on Web3, which is a really good post, but kind of the predecessor to that was he minted one of his stories or something - a book or something like that.

Chris: Sure. Yeah.

Dave: Then he found out how much carbon he just burnt. He was like, "I just basically just burned a barrel of oil in my front yard." I don't know.

Chris: But then he probably put it on OpenSea or something? That seems to be the big one. Which is only Eth and Eth is just verifiably bad. But there are other ones that don't use Eth.

Dave: But it gets better, dude. Yeah.

Chris: Well, I agree. It's not better, so don't use that one. But what if everything you ever did was all on Tezos? Hmm? Maybe not as bad then? I don't know.

Dave: Yeah. I don't know. Don't talk to me. I'm a wet blanket.

Chris: [Laughter]

Dave: For me, it's like--

Chris: Yeah.

Dave: Oh, man. We don't have time for this. It's digital--

Chris: No, we really don't. I've got to go.

Dave: This digital scarcity, I don't believe in it. You know what I mean? I believe the Web is for everyone. Injecting this world of digital scarcity is just dumb. I don't know. Bullshit.

Chris: Can you see how to some people -- and I admit I'm not bit by it and, like, "Oh, I'm all in on it. I'm changing my avatar."

Dave: Sure. Sure. Sure. Sure.

Chris: But that you've got different docs open. There are these tools, you're connecting them together, and you're starting to understand how the red little lines go together. There's an element of exploration to it that evokes literal fun.

Dave: Oh, yeah. I could understand that. Yeah. My thing is it's not--

Chris: Good for the world? Because that's probably true.

Dave: Yeah. I just think the long-term--

You and me, it's like, "Oh, you want to talk to Dave Rupert? You've got to buy my NFT. I minted Dave coins and you need Dave coins to listen to my podcast and whatever." I don't like the--

It's like everyone has a Patreon is now like everyone is a commoditized item or every JPEG is now commoditized. I just don't like that. That seems silly.

Chris: That's a very healthy attitude.

Dave: Far away from where I want to exist in life. Then people are always like, "Oh, the artists get rich, though. You know? People made it rich." The story behind that is probably not that. It's probably, "He gave his friend some money who bought the thing and he bought it back."

Chris: Hmm.

Dave: It's just a stunt. You know what I mean? All these big sales are just stunts, frauds. But it's not illegal because it's unregulated.

Then you get into -- I'm not saying NFTs aren't worth anything, but then I saw this thread from this artist girl. Her stuff is getting minted without her permission, so she's having to spend all her life -- days--

Chris: I honestly feel like it's mostly that.

Dave: It's mostly that. She has to spend her life chasing down and copyright threading and whatever, getting takedowns.

Chris: Yeah. I can't even get into it, but we could talk offline about what--

Dave: Copyright stuff? Oh, sure.

Chris: Little stuff that affects CodePen in a way, but I really have to go. I'm so sorry. Super hard-stop edition.

Dave: We'll wrap it up. Thank you, dear listener, for downloading this in your podcatcher of choice. Join in the drama next time.

Chris: Yeah! [Laughter]

Dave: All right. Be sure to star, heart, favorite it up. Follow us on Twitter, @ShopTalkShow, for 16 tweets a month. Head over to patreon.com/shoptalkshow - speaking of giving us money. [Laughter]

Chris: Yeah.

Dave: To be our friends. But anyway, Discord, it's fun. There are a lot of people in the Discord, and they're a lot of fun. Chris, do you got anything else you'd like to say?

Chris: Oh, ShopTalkShow.com.