603: Deno, React Alternatives, and Copilot Concerns with Triple Threat Josh Collinsworth
Josh (or Jsoh) stops by to talk about his work at Deno, recent blog posts on Copilot, why Svelte is awesome and React is not, Apple and PWA, and building word games on the web.
Guests
Time Jump Links
- 00:50 Introducing triple threat Jsoh
- 03:08 What's Deno?
- 06:59 What's Deno Fresh?
- 09:04 Sponsor: Join Elicit as a software engineer
- 10:25 Is Copilot leaving passengers behind?
- 19:13 How do new people learn in an AI era?
- 22:33 Why is React bad and we should use Svelte instead?
- 34:07 What is Vite really doing?
- 35:38 Fun little tools for your Mac or web apps
- 44:56 How mad are we at Apple?
- 49:51 Josh's word games
Links
- Josh Collinsworth
- Deno, the next-generation JavaScript runtime
- Deno Deploy | Deno
- Fresh - The next-gen web framework.
- I worry our Copilot is leaving some passengers behind - Josh Collinsworth blog
- How A Small Team of Developers Created React at Facebook | React.js: The Documentary
- Vite | Next Generation Frontend Tooling
- Screen Recorder for macOS. Beautiful videos in minutes | Screen Studio
- CleanShot X for Mac
- stitchy - crates.io: Rust Package Registry
- Raycast
- Home
- Squoosh
- RunJS - JavaScript Playground
- Quina - Menu
- Hondo - a word game in 100 words or less
- Home / PWABuilder
Episode Sponsors đŸ§¡
Join Elicit as a software engineer (9:04)
Elicit’s goal is to radically increase high-quality reasoning in science and beyond. As early as 2017, they pioneered process supervision, an approach to breaking down complex work for advanced machine learning systems, so that it remains transparent and controllable. Today they use language models to help more than 200,000 researchers each month. They just raised a $9 million seed round and are looking for exceptional engineers across frontend, backend, and ML. If you're an exceptional front-end engineer looking to build the next generation of AI interfaces with a modern tech stack (Next, Tailwind, Chakra), join them!
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--in the shed with a sick kid--Rupert, so it could be exciting. And with me is Chris Coyier. Hey, Chris. How are you?
Chris Coyier: I'm doing great. Thanks for having me, Dave.
Dave: Yeah. Well, welcome. [Laughter]
Chris: [Laughter]
Dave: You pay for the Riverside, so I think it's great that you can show up.
Chris: We split it up, though. Did you all know this? Dave's got the domain. I think the hosting is on Dave's credit card. I get some other stuff. We just... it's in the wash.
We have a special guest, though, this time. We refer to him as Triple Threat once in a while. Dave, who is it?
Dave: It's Josh Triple Threat Collinsworth.
[Laughter]
Dave: Hey. You misspelled your name in the chat, Josh.
Josh Collinsworth: I did.
Dave: Jsoh is the new name.
Josh: Jsoh.
Dave: Yeah.
Josh: [Laughter]
Chris: And it's not the classic. What I always do is Collingsworth. Do you get that a lot with the G in the middle there?
Josh: Constantly. Even when I was a kid. Any time my parents would have to say their last name, like on the phone or something, they'd be like, "No G. It's just Collinsworth."
Chris: Yeah. No G.
Josh: It's just one of those things. It's fine. I'm sure people misspell Coyier all the time, too, probably.
Chris: Yeah. I've got to go really slow, C-o-y-i -- because you can't rush through the middle. You've got to go... you can't go C-o-y-i-e-r. You know?
Josh: Yeah.
Chris: Then it's lost. You've got to go slow.
Dave: Mine really enhances my own lisp. It's Woopert. [Laughter]
[Laughter]
Dave: R-u-p-e-r-t, and then they're like, "Robert?" Yeah, missed. Yeah.
Josh: There's always that awkward pause where I say it's Collinsworth, and then I can tell they're kind of waiting for me to spell it, and so I just go ahead and do it anyway.
Chris: Mm-hmm.
Josh: It's 12 letters long, so I have to do it again. [Laughter]
Chris: If you're not following Josh, it's just his name that we've now talked about a bunch, so you're guaranteed to get it right - dot-com. A wonderful blog. Lots of great stuff there. Kind of a must-follow, I'd say. Well done on the blog. You're at Deno now, yeah?
Josh: I am, yeah. Six months about exactly now.
Chris: Oh, congrats! That's cool. Deno being one of the... What would you call it, one of the great JavaScript runtimes of our time?
Josh: [Laughter] Yeah. Yeah, there's a whole bunch of them out there now. Somebody was just posting about how there's like 10 or 12 or something. But yeah, Deno is--
Chris: Oh, juicy.
Josh: --one of the biggest ones. I'd like to think it's one of the best and simplest ones. It's been really exciting joining them and getting to see the inner workings and get excited and pumped up and get to kind of have a big impact at a little smaller company. I was at Shopify before that, and that's, of course--
Chris: Ah, huge!
Josh: Yeah.
Chris: Yeah.
Josh: Yeah, yeah. I want to say there might have been around 15,000 people at that company when I joined, so yeah. Yeah, it was easy to feel like a very small part of a very big machine. So, it's nice to be on a smaller team and kind of feeling like you're doing a little more to push the ship forward.
Chris: Yeah, that's cool. It always seemed very level-headed, Deno, to me in that, first of all, it was early notable because it wasn't... Isn't it--? I'm sorry for my ignorance here, but isn't it like the Node guy was like, "I'm going to start over because Node has problems, and I'm going to fix those problems"?
Josh: Yeah.
Chris: Yeah.
Josh: Yeah. Kind of like this is what I would have done if I had done Node today.
Chris: Right. That's cool.
Josh: He's actually... Ryan Dahl is not alone. There are a couple of other people, I think, at Deno who were originally working on Node as well.
Chris: Early days? Yeah, right on. That's great. And so, presumably, some of those problems are fixed. I think of it as the one where you can do ES imports from regular ass URLs.
Josh: Yeah.
Chris: I don't know why that's such a distinguishing feature in my head.
Josh: Yeah. URL imports are one big feature. The things that you can either explicitly allow or explicitly disallow, like read your file system, write your file system, access the network, access EMV variables, those kinds of things are a big one.
Chris: In other words, security.
Josh: Yes. Yeah. Sure.
Chris: Right, like I'm going to ship a function and be pretty sure that it's going to be safe because I never allowed file system access.
Josh: Yes. Yes, exactly.
Chris: Instead of it being implicitly allowed. Well, that's wonderful.
Dave: That's a good feature.
Chris: Then one of the things I like, too, not to be blowing too much whatever. I didn't plan to have the Deno show, but you know, we've got Josh on, so let's do it.
The model of it's so simple to be like, "Well, what are we going to do as a company? Let's do hosting, I guess." But in a really nice way in that we're going to not only just host it for you but do the global CDN version of it, which seemed like kind of the hard way to host a function, right? [Laughter]
You have a little bit of code. You want it to run in the sky. There's a CLI, right? You'd be like, "Shoot even my TypeScript file up to the sky, and now I have a URL that will run it from anywhere in the world." Deno can do that, right? Don't y'all make that really easy?
Josh: Yeah. Yeah. That is the deploy product that you're talking about there. Deploy is our sort of hosting infrastructure. Yeah, it's all around the world. It's hosted at the edge. You can do websites. You can do edge functions or Web servers or whatever you want.
The really nice thing about is it that, like you mentioned before, you can just have those ESM imports as a URL, so you don't have to worry about, like, if you were using Cloudflare workers, for example, you would have to make sure that you've got it bundled down to this certain size, and you had it compiled away and everything before you ever launched this thing. With deploy, you can just stand everything right on up there. You don't have those restrictions, so you can even run NPM packages and stuff. You can just do whatever you need to do.
Chris: Hmm...
Josh: It's a really great way to do things.
Chris: You're saying not worry about pre-bundling - or whatever?
Josh: Right. Yeah, exactly.
Chris: Yeah. Interesting. Cool.
Dave: I always thought that was weird, like when I'm compiling my server code. That was always like, "What am I doing here?"
[Laughter]
Dave: "What decisions got me to this point?" You know?
Chris: Yeah, there's some bad... you know, for old-school AWS lambdas, you had to make a zip.
Dave: Yeah.
Chris: You were like, "Hmm... Wow."
Dave: Just right click.
Chris: ...get better over time.
[Laughter]
Dave: Well, that's cool. Do you use Deno then full-time? Deno also has Fresh (right) the meta framework? You guys are almost down my entire list of what a new JavaScript framework needs.
Josh: [Laughter] Yeah. Fresh is mostly what I use because most of what I work on is Web properties, and then I do some work on Deno products as well. I don't know if we should disambiguate that Deno is a company and also there is Deno the open-source runtime.
Dave: Mm-hmm.
Josh: When we're talking about Deno as a product, as a JavaScript thing, that's the open-source runtime, and we often call it just "the runtime" just to kind of help us talk about it a little differently.
Chris: Hmm...
Josh: But at Deno, the company, what I'm using most of the time is Fresh. For listeners who might not be familiar with that, you could think of it a little bit as maybe a lighter-weight version of Remix just built on Deno specifically.
Dave: Oh, okay. It's more Remix than 11ty or something.
Josh: Yeah. Yeah.
Dave: Okay.
Josh: It's built to be completely server rendered. It has those nice things built in where you've got a form. It can work client-side, but it can also just do the basic HTML thing that servers have done forever where you actually handle it server-side, routing and those nice kinds of things.
Chris: If you ask for the homepage of a fresh site, is it just freshly server-side rendered every time?
Josh: That's a wonderful way to put it. Yes.
Chris: It is?
Josh: Yep.
Chris: I could be like, "I'm going to output new.date, and it will be the date."
Josh: You could absolutely do that. Yeah. Just host it at the edge - wherever you want. It's JSX, but we use Preact rather than React, so you get all the nice performance gains that come there. And it uses the islands architecture that I think Astro really helped popularize where anything you want to run client-side, you opt into. You put it in an island. Otherwise, it's just pure server-rendered HTML.
Chris: Hmm... Interesting. I see. That date thing, if you didn't make it an island, it would be wrong because--
Josh: Well, it would be whenever the page was loaded, right? Just like if you did it with PHP - or something.
Chris: Oh, okay. Right.
[Banjo music starts]
Chris: This episode of ShopTalk Show was brought to you in part by Elicit, that's elicit.com/shoptalk. If you're a front-end, full stack, machine learning engineer and you want to join a team that's AI-first in deploying language models at scale, look into Elicit.
We just had Maggie Appleton on the show not long ago. She's leading design over there. Just saying. Prett cool.
Their goal is to radically increase high-quality reasoning in the science field and beyond. They're building this AI research assistant. And they've been around a long time doing it. A lot of us have only been hearing about AI stuff for the last year, maybe two. But they've been around since 2017.
They pioneered process supervision. This means breaking down the work of advanced machine learning systems into smaller parts so that it remains transparent and controllable, even as the overall task gets too complex for people to understand.
They're helping right now more than $200,000 researchers every month. They just had a big seed round, $9 million. And they're looking for exceptional engineers to help work on the front-end, the back-end, the machine learning part of this.
If you're looking to build that next generation of AI interfaces and change how scientific research is done, check out elicit.com/shoptalk to apply. They're an especially great fit if you love tools for thought, end-user programming, or computational notebooks. Again, that's elicit.com/shoptalk to apply.
[Banjo music stops]
Chris: Wonderful. Okay. Fresh. Deno. Did that. We can circle back to it and stuff.
Dave: Yeah.
Chris: There's random news. There are some questions that Josh can help us answer. And the unavoidable, your latest blog post is kind of about the AI stuff.
I guess you could have predicted this coming, but there's starting to be a little research and pushback on the code that LLMs produce for us, so Copilot looms large in all of our minds because VS Code is so big, and it was free for such a long time. A lot of us kind of liked it. I think you even opened your post saying that you like it, generally, right?
Josh: Yeah.
Chris: But your post then goes on from there, and maybe you could walk us through it. Are you ready for that one? Let's do it.
Josh: Sure. Yeah. Yeah, let's do it. The title of the post is "I worry our copilot is leaving some passengers behind." I just noticed, as I started to use Copilot, it's super handy. I love what it does for me. But I was noticing a lot of times I felt like a goalie trying to keep bad code from flying by me into the night.
Around this time, I was also spending a lot of time in repos where I was coming in. Somebody else had written the code, and I was cleaning it up or refactoring it or whatever and fixing some mistakes.
I was thinking, "Man, there are so many developers out there in that situation who are just kind of doing this to get by, to get unblocked, to move onto the next thing, and they're just going to take whatever suggestion Copilot throws at them and not think any harder about it than that they need to. If it appears to work, it's going to be fine."
That's kind of how we got into this situation with accessibility on the Web in the first place. Obviously, a very dire situation.
I think that kind of the thesis of the post is that these tools -- I specifically talk about Copilot, but there are a lot of these similar tools out there now -- I think we have some data suggesting that now they are sort of lowering our overall code quality, which is not a great thing. As long as things still work, that's fine, but when it comes to accessibility, the difference between good code and bad code might be it working or not working.
If we're always using this tool and it's always kind of pushing that persistent pressure in that direction, we may be just sort of letting the already very poor state of accessibility on the Web just get even worse in that way that systems often work (very quietly, but no less maliciously) in the end.
Chris: Right. You have demos about even footnotes. It was like, man, a footnote is, sure, you've got to know a little HTML. But it's an anchor link up here that links to an anchor link down there, and then also in reverse. And it's like I didn't even... I wouldn't have even thought about using JavaScript for it. But I'm wrong because apparently a lot of people do because so many people do that it has become the way that Copilot (at least in your case because I'm sure there are a lot of what-if and what code it's looking at or contextual information) for you, constantly, would suggest click handlers, just inline click handlers just baked right into those HTML components. You're like, "Where the hell did you learn that, you idiot? That's a horrible solution?"
Josh: [Laughter]
Chris: I even saw some responses to your post that was like, "That sucks now but imagine this theoretical - I don't know - half-checked-out developer." The developer doesn't know any better. Really early-stage developer - whatever you want to call it - who is just like, "Yeah, well, it works."
The solutions do (big air quotes) kind of work, right? The click handler will get you down there somehow. Then ship it. Ship it.
Dave: In the most expensive, high-tech, failure-to-prone way possible.
Chris: Right. Now that's out there, right? That was accepted. Which theoretically can enforce the model further. I don't know. That's where my understanding lacks a little bit.
Don't some of these tools promise that they don't do that? They're like, "We're not going to train on what you do." - or whatever.
But yeah, you check that into your GitHub repo. It's public, open-source. It's going to get regurgitated by an LLM eventually.
Josh: Right. Yeah, something is going to see that. They can promise that's not going to happen. I don't know how much I trust AI companies' promises at this point.
Chris: No kidding.
Josh: But even if it doesn't get to that point, even if we aren't concerned about the acceleration of it, we're still in... I guess the effect hasn't compounded yet, but the effect is still there, right? We're still using this tool that's been trained on all kinds of bad ideas and biases. That is going to propagate. That's going to result in more of those bad ideas and more biases, even if it doesn't eat its own tail.
Chris: Right. Yeah. Even if it stops at level one here. What can you imagine the pushback being like? I think you do that in the post, right? You're like... I don't know. one is like, "We're all adults here."
Dave: My favorite was "AI will fix it." That was... yeah.
Josh: Which I think there is reason for optimism there, but I don't think that's probably going to be the total solution to everything. I've used AI tools, like I mentioned in the post, for my own accessibility issues. That's great.
But I think we've just kind of gotten used to not really having the same standard for so-called AI tools that we have for all other products. I think we maybe need to realize that we should be saying, "Hey, Microsoft. You're one of the--" Not to call out Microsoft specifically. There's Google and everybody else has these, but-- "You're one of the world's major companies. I'm giving you my money. We should expect that what we get back in return is not harmful." At a bare minimum, that should be the baseline, and it seems like, right now, there's at least a pretty strong argument to be made that that's not the case.
Chris: Also possible that what it tends to give you is (I've heard it referred to as) copy-paste kind of code. It's not going to look and see, for your existing footnote solution, or look to find the function that you should be calling that's some utility in your existing code base. It's like, "Oh, no. I've seen this before. I'm going to hand-craft the solution," because it's just not that smart yet, right?
Josh: Yeah. Yeah, well, it's not smart at all. It's just an extremely good statistician. Yeah, somebody (I think in the Discord) brought up -- maybe it was Alex -- they had seen where using Copilot a lot just kind of resulted in very not dry code because it doesn't know to go pull that function from where it exists elsewhere. It's just going to rewrite it right there in line.
Chris: Right. That's the kind of thing that it's easier for my brain to think that it's going to get better. But right now, it doesn't. But what if we could send more tokens and it got smarter about our own codebase and all that stuff? Does this concern then evaporate or not?
Josh: This part isn't really the concern that I have. If our code quality goes down, I'm not going to lose sleep over it.
Chris: Right.
Josh: As long as it still works, as long as it's still accessibility, who cares if you've got the same function ten times in that codebase. That doesn't bother me.
What bothers me is this pressure is literally making the Web a worse place for some people.
Chris: Yeah, it's the accessibility problem that's a bigger problem. Yeah. Woo!
Dave: Not to go too deep; do you ever worry about or think about, I guess, the bigger impact? I used an AI. I assume it was GPT-based, but I could just tag it in a pull request and it would go try to fix it. I just type what needed to be done and it would go and write a pull request. I think GitHub is working on something similar or they demoed something similar to that.
Chris: Kind of. [Laughter]
Dave: Cool. But the whole thing is, like, "You don't need junior devs anymore." You know? It's like, "Hey, that's cool as a person who wants to stay small and keep money in my pocket. But as somebody who wants a healthy industry, not having people coming in is bad. It seems bad."
How do new people learn? They just get really good at writing GitHub issues? You know? What?!
Josh: Yeah. Yeah, man. I think the three of us could go really far down this rabbit hole.
I got started working, I was a designer, and I just started toying with code to make myself more valuable and more likely to get hired. I remember getting so many opportunities to work on basic HTML pages or to customize WordPress theme styles and stuff like that. That's where I learned.
I think a lot of people kind of in our... We're all similar ages. We're sort of in that similar generation of developers.
Dave: The webmaster generation.
Josh: Yeah. Yeah.
Dave: Yeah.
Josh: We've got those little opportunities that gave us the skills to jump to something bigger. A colleague of mine at Shopify put it as the ladder is being pulled up behind us. The people in the next generation aren't getting those opportunities, and it's a scary thing. Where's the next generation going to come from?
But then you also have the same thing where it's like, "Well, lots of layoffs are happening. Lots of people who are developers need jobs."
I don't know, man. It's a complicated mess out there right now.
Chris: Yeah. You have to be careful with your own brain a little bit because it's easy to think of all the negative things and be like, "Holy crap. The world is on fire," you know, because you're going down that rabbit hole. Not you, but it happens to me, too.
Josh: Sure.
Chris: But then you're like, "Oh, yeah, but have you seen the free learning resources that are available all over the Web? We sure as hell didn't have that." YouTube is slathered in just amazing materials.
Josh: Right. Yeah.
Chris: There are universities that put out curriculum to walk you through this stuff, and it's free. Where is the next generation of developers going to come from? From that.
Josh: Yeah. Yeah. Who was it that posted a video game their five-year-old made?
Chris: Oh, yeah. That was Adam. Yeah, it's amazing.
Josh: Yeah. It's just wild. That's so cool.
Chris: Yeah, incredible. Hopefully, that stuff is okay. The one that gets me is the tinkering thing. Every device you get now, they don't want... intentionally don't want you messing with it. There's no res edit for the Apple Vision Pro - or whatever.
Cool. What do you want to do next here? Do you feel like we covered that, or how did you end up the post?
Dave: We can move on to a lighter topic. Josh, you hate React.
Chris: [Laughter]
Josh: [Laughter]
Dave: And you have built an online persona about being the biggest React hater-pants on the planet. You said you were using Preact earlier. That doesn't match what I know about you. And I know you like Svelte, so I don't know. Just throwing out an episode title. Why is React bad and you should use Svelte?
[Laughter]
Dave: What's the--?
Josh: Oh, man. A lot of problems with React do disappear when you're doing server-side rendering and what you send to the client is very light anyway.
For whatever reason, the two most historically popular posts on my blog have been anti-React posts where I just say, "Hey, guys. There are some problems here." Yeah, for whatever reason, that's me. That's become my reputation now. The other one is... Yeah, then the other ones are just about Svelte and how much I like it and how good I think it is.
Dave: I find it funny. Some of the criticisms are like, "What the author fails to understand is--" and it's like, "The author clearly hasn't done any kind of React."
It's like, "No, you work on Shopify."
Josh: Yeah.
Chris: Is Shopify all React? I didn't even know that.
Josh: Yeah. Yeah.
Chris: Because of Remix, right?
Josh: Yeah. Yeah. They are all in on React and React native for everything front-end. Yep. React and Ruby on Rails - still.
Chris: A lot like CodePen.
Josh: I think if I were to just kind of boil down my thoughts on it. It's just that the industry at least seems like it's standardized on React. It's the default choice. Default choices are useful but we have a lot better possibilities now than we did when we sort of converged on that default many years ago. Things have gotten a lot simpler, a lot better, a lot easier.
I think a lot of the decisions that we were made early in the development cycle with React have not paid off very well, have aged poorly, and it's like that XKCD with the tower of blocks, right? We made some bad choices in 2012, and we are still stuck with them.
Chris: Is it stuff like hooks? Is it stuff like--?
Josh: I think hooks are generally a good idea. Honestly, probably a lot of my problems are more with JSX specifically than they are with React. The performance angle is one thing. Well, I guess some of them are React, too.
For example, it's very dogmatic about one-way data flow. You just cannot ever have data going two ways. Svelte, Vue, and I'm sure lots of other projects, they do have two-way data binding, and it's extremely useful and it makes a lot of things very simple. But it wasn't in service to the problem that Facebook was trying to solve when they got React onto their front end instead of jQuery. And so, they made that rule to try to wrangle their data the way they wanted it. Now that's unavoidably shaped everything that's come after.
Kind of the same thing with every function only returns one element because it was all originally an argument to another function. These decisions just kind of continue shaping things all the way down the line.
Chris: Essentially, that's never talked about. You never hear somebody that currently works on React that will say, "This is actually dumb but we're stuck with it." That seems like a fair thing to say, like - I don't know - "We have this architecture that is so ingrained in it that we can't change, and I fully admit that the way, for example, Svelte does something is better. But it doesn't mean we're not going to keep working on React."
That seems like a fair shake but you won't hear it. I don't know. It takes a third party to point those things out, I guess.
Josh: I guess. I found myself wondering last night. To what extent does React as - whatever you want to call it - an entity, to what extent does it care? These smaller projects, they are really excited when a big company comes along and wants to use them, and really into making it into the shape that that company wants or help them or make them successful in whatever way they can. But if somebody comes along to React and says anything -- if Amazon is like, "Hey, guys, we want React to change," are they really going to be like, "Eh... I don't think so."
Chris: Yeah.
Josh: You know? "We think we're doing okay here."
Chris: That React documentary was wild. It does paint a picture of, like, they were born in this cauldron of hate. The second the world saw it, they hated it. People have hated it forever, and it's still been successful.
I wonder if they're like, "Oh, people don't like us? How surprising. They didn't like us when we were born. They didn't like us as toddlers. They don't like us as adults. We're just not liked, so." Yeah.
Josh: [Laughter] Maybe so.
Dave: Hey...
Chris: Yeah.
Dave: In my defense, because you're talking about me, I clearly remember saying it is very interesting because I was in mustache hell at the time. You know?
It's very interesting, but I want to see if it blows up in somebody else's face first. That's what I said.
Chris: [Laughter]
Dave: I feel like ten years later now, I'm starting to.... But--
Chris: Some of the early stuff was just like, "Look at this click handler right on an HTML element. That's awful." But it turns out they're actually kind of right about that one.
Dave: Now that's how you do it.
[Laughter]
Dave: Yeah.
Chris: That's not ... everybody followed suit there.
Josh: I think a lot of people were also like, "HTML in JavaScript? What are you talking about? I can't return HTML."
Chris: They were right about some things, not that they were first, necessarily, but certainly popularized it.
Josh: I think, also, a lot of the benefit that people see from React are benefits that you would get from any framework, like benefits from having a system and a system that helps teams work together really well. And so, I think maybe it's a little overvalued by companies or organizations or whatever that have only tried it because some of those benefits, they're not realizing extend everywhere.
Dave: Yeah. It was very Wild West in how you coded things. You had some jQuery that called a mustache. Maybe you had knockout stuck in there, backbone or something. It was all kind of pieced together how you did events.
I think Twitter popularized the whole event up, data down sort of thing. Everyone was just kind of making it up and doing a bad job, getting hurt by it, so React came along and said, "Here's a way. We made some controversial opinions, but here's a way to do it."
Josh: I think the lesson I keep seeing over and over is a bad system is better than no system. React was a system for a lot of people.
Chris: What about the Svelte thing is so appealing? I have so little experience in it. I think of the early stuff when it came out was like, "Why would you have to do a set state or something when you can just say var X=1 and then change that value and Svelte just knows what you mean - or whatever." It looks just like regular JavaScript looks."
Is that stuff still appealing to you, the little... or has it moved on? What is it about Svelte that's so appealing?
Josh: I think that's appealing, a combination of hooks and, as Svelte themselves put it in their five blog posts, realizing knockout was right all along. I think a combination of those are bringing it back a little more towards being more explicit about your state variables and how you update them.
But to answer the question, it's just the simplicity of it that is so delightful to me. It's very, very close to the HTML, CSS, and JavaScript that we're all used to writing just for the plain Web. In fact, Svelte itself is less of a JavaScript framework and more of just a tiny, compiled superset of HTML.
There's very, very little in Svelte that isn't already in HTML, CSS, or JavaScript. And so, that makes the syntax very familiar, very simple, and the way you do things in it requires so little extra code compared to how you would do something in a comparable framework. It's just very simple, and I appreciate that.
It also has stuff built that you might want like animations, transitions. I use it a lot for just prototyping ideas for games or interactions or stuff like that. Just having a built-in animation and transition library is amazing, and it has a built-in solution for scope CSS. You don't really have to reach outside for those kinds of things, and I really appreciate that.
Chris: That does seem classy, right? Those are the biggest needs - or whatever. Like, "Look no further for a styling solution. We gave you the best one. We waited for it to shake out. This is the best one." Scoping, I'm talking about.
Dave: Well, that's what... Vue has that same thing. You see people chasing their own tail on, "Well, we're using the new one now."
Chris: Yeah.
Dave: Vue is like, "Oh, we just use the one."
Josh: Yeah.
Dave: ...even cross my mind that I would use a different style scoping solution.
Josh: I just don't even bother not writing vanilla CSS anymore because, with that scoping, I get whatever I need and that's it.
Chris: God it is so nice. Love it. Yeah, the little Astro has it, too.
Josh: Mm-hmm.
Chris: I use it in the form of CSS Modules, which is the just slightly not as good version of scoping. You still have to kind of name a selector and then attach it specifically to the thing. It's not just regular CSS, like the scoping is, which is great.
Josh: [Laughter]
Chris: I've been looking into Vite and all its features because our new CodePen will be running stuff like Vite, so we have to be real careful of every single feature that it supports. It happens to have CSS Modules built into it, which is an interesting project. It didn't really occur to me at one point that it's just a spec, CSS Modules. It's not... You can't NPM install.
Josh: Oh, interesting.
Dave: It's not a library?
Chris: Yeah.
Dave: Oh, yeah.
Chris: There's no versions of CSS Modules. It just exists. It's a thing. If a compiler decides to support it, it just supports the spec of it. Pretty weird.
Josh: That's kind of wild.
Chris: All it is, it's ability to look at a CSS file and turn all the classes into gibberish. Then it turns it into an object that JavaScript can import. Then you use those gibberish classes to apply as class names. It's pretty simple at its root.
Vite supports it, too, in the context of Vue. If you really wanted to, Dave, use CSS Modules instead of scoped CSS, you can. Then you compare the two side-by-side, and you're like, "This is stupid," the CSS Modules approach. But why would Vite build it in then? I can't answer that. But it's interesting to see a project like that.
It seems just slightly less classy than Svelte because Svelte has made these stronger choices. "Now we just have this way of styling. I'm not going to try to support four different ones."
I don't know. I don't know. Vite is pretty big, though, so maybe that was a good choice.
Josh: I think all these projects are using Vite at this point, right?
Chris: Yeah. It's unbelievable how it was like the right thing at the right time. Just sucked everything up.
I still feel weird about it. I still feel like, "Oh, it doesn't actually... It's not actually... It doesn't actually build stuff. It just uses esbuild inside. And it doesn't actually make production bundles. It just calls rollup and rollup does the bundle." You're like, "What are you doing then?"
I get it a little more now that I've been looking it. It does lots of interesting stuff, but it's interesting how it didn't rewrite some of the biggest, hardest things that need to be done. It just uses other little tools.
Whatever. No shade. Great tool. It's a hard thing to market a product and get people to love it and use it. But it is weird when all the bucks, the open-source bucks that go to it and not the things that it depends on. Hmm... That's weird.
Josh: Hmm... #hotdrama.
Chris: Let's actually go light this time.
[Laughter]
Chris: Somebody wrote in and says, "I love little tools. These are handy, little Web utilities, max status bar apps, phone apps, plugins that do one thing, but they do it well, et cetera. It can be stuff like Itsycal."
That's a calendar that he has in his... Actually, I said "he" but it's kind of anonymous, so who knows what it is.
"It's a calendar with the week numbers in my status bar. Or a drop-over that lets me bundle a bunch of files together on my Mac, copy or share, and move them around."
Those are two examples of little tools that they like.
"For Web apps, it's those, like, HEIC to JPEG tools." [Laughter] "Or an asset compressor or a tool that generate a random color palette," that kind of thing in WordPress land. It's like SVG conversion tools or something that adds a CDN automatically, that kind of thing.
The question is, which we can round robin, "Do you have any neat tools like this? Any favorites?" Is anything coming to mind for you, Dave? Little tiny tools.
Dave: You know I'm a fan of the Sindre Sorhus--
Chris: Suite of--
Dave: Compendium. Yeah, suite of tiny Mac apps. It's great how he'll just come up with an idea and implement it, like in a day, and then put it on the app store. It's pretty impressive.
Chris: He's got one called One Thing that I think is cool. It's a menu bar app where you can write... you just write, like, "Call Mom," or something, and it puts "Call Mom" in your menu bar so you are forced to stare at it until you deal with it.
Dave: Yeah. Yeah. Yeah, it's amazing because it's just very focused on, "Hey, do you need to do this? Do this."
I'm trying to think of apps I have. Chris, you got me on this $80 Screen Studio, which is a little--
Chris: Sorry about that. A little pricy for a one-off.
Dave: Well, you know, and I already have CleanShot X from Setapp, which is a cool... Setapp... I'm still paying for that.
Screen Studio is just this really neat tool. It's expensive, I found out. But it's really neat for just catching a window, recording a window, and then zooming in. It'll zoom into your mouse, and then you hit stop. Then it gives you a little editor, like, "Hey, did you want to zoom in here? Did you want to put a background on it?" It's like, "Yeah. Yes, I do." "Okay, great." In five minutes, I have what feels like a full video, 10-20 seconds.
Chris: Yeah. It's really classy. It's super cool. It's really well done.
Dave: It does video overlay and all that stuff, too. I like that. That's maybe--
Chris: Yeah. It does little stuff that you'd never guess that you need, like it smooths out your mouse movement in the video. Instead of it being all jerky or something, the mouse is a little bigger. It's a little easier to see. Then it puts the mouse back where it started at the end of the video just in case you use the video for something that loops. It's not as jarring to watch the mouse jerk somewhere else. That's incredible. Good job!
But I don't know. That's not particularly little because it's... It's not big, but it's--
Dave: It's a big one. You know I'm thinking of little ones. I asked in the D-d-d-d-discord if anyone knew how to... had a tool for stitching images. Everyone was like, "I just usually open up Figma," and I found this one -- or somebody found it -- and it was called Stitchy. It's a Rust package, command line tool. I just drag the two images I want into a folder, and I say, "stitchy this folder."
Chris: Mm-hmm.
Dave: Or stitchy two images together, and it'll put them side-by-side or into a grid or into... I can say, "Do four images and only horizontal," so I can build little photo strips or whatever I want. It's cool. It does the job and I didn't have to open Figma. That's what I wanted in my life, so I feel like that counts.
Josh: That kind of stuff is all I use my design degree for anymore is just putting images together. A shockingly big one is when you have to sign an official PDF with your actual signature and you don't want to print it and sign it. Just forging signatures onto PDFs is a weirdly high percentage of the things I use my design skills for.
I don't know if either of these are built into Raycast or if I went out and got these as extensions. But one is a color picker, which is just up there in your menu bar. I find that's really handy to just grab a hex code that I need. Another is an extension that when you open Raycast, if you have a meeting on your calendar, it will put that meeting as the first item so that you can just open Raycast and go straight to that meeting.
Chris: Oh, I love it. That's really cool. I was going to say Raycast, too. Not itself because it's such a big tool overall, but I feel like it's gobbling up this market of small tools because, if you need a small tool, there's probably a Raycast plugin for it. Then it's built into this muscle memory you already have for activating and doing stuff on your computer. Yeah, Raycast rules.
Josh: Yeah. I used to tell everybody about Rectangle for moving your windows around. But now Raycast does that and Rocket for putting in emojis and stuff.
Chris: Yeah!
Josh: But now Raycast does that.
Dave: Speaking of Raycast, ShopTalk Discord member Keven Kipp made a Feedbin app for Raycast, so you can get your Feedbin inside your Raycast.
Chris: Gees!
Dave: It's pretty cool.
Chris: Really turned it... A lot of companies, they want to be a platform or an ecosystem or something. That's the kind of buzzword crap they'll put in their pitch decks. Raycast really made it happen. Really cool.
I was jealous everybody got their year-end Raycast thing.
Josh: Yeah. I nailed it.
Chris: I'm like, I used the crap out of Raycast this year. I didn't get mine. They just didn't email me one.
Yeah, like your Spotify one, except for it's like what apps did you open and crap. That's a genius idea. Anyway, yeah. I do still use a dedicated color picker, Sip, for some reason. Maybe just - whatever - to make my Sipapp subscription more valuable or something.
I have a clear ask for the world that nobody has ever been able to answer me on. Can somebody please, for the love of God, make a color picker than can pick in the new color formats? Can it grab an OKLHC color?
If you open a freaken sunset in an image on preview - or whatever app on your computer - and grab that orange, any color picker today will suck it back down into SRGB to give you a hex code or HSL value or whatever you want. None of them will retain that high-res value or - whatever - that P3 value of it. None of them.
It seems like free money, somebody. At least a little bit of it.
Dave: That sounds awesome. I would also like the opposite where it flattens it down to a named color....
Chris: [Laughter]
Dave: Any color.
Chris: Just smash it.
Dave: All the way down.
[Laughter]
Chris: Yeah, Web-safe mode.
Dave: To the nearest named color.
Chris: That would be great.
Dave: Yeah.
Chris: I love it.
Dave: Web-safe, yeah.
Chris: Nothing for a long time. Oh, delicious. I don't know if I have any other ones. I used to have an app for optimizing one-off JPEG and stuff. You'd just drag an image onto it and it would optimize it. But I'm just kind of off of it. I feel like--
Dave: I use the heck out of Squoosh.
Josh: Yeah, I was going to mention that. Actually, now that I look in my doc, I realize I was going to mention RunJS as well, which is just a little app that it just runs... Well, it does what it says. It runs JavaScript. You just open it, and you just get a little JavaScript playground. It's just a lot more convenient than popping open a console when you want to test something out or see if it's working or whatever.
Dave: Oh, I love this. I want this. I wanted this for a long time.
Josh: It understands TypeScript, so you can do all that stuff. You can set up your config however you like it. But I just use it a lot when I just need to get an idea out of my head, like make a function and make sure it works the way I think it does or whatever. Just try out a little JavaScript live.
Dave: It's so handy when you have an array and you're like, "I need to do something with it." [Laughter]
Josh: Mm-hmm.
Dave: You know?
Josh: Yeah.
Dave: It's going to be like four or five chains deep, and so--
Josh: Yeah. Yeah, that's what it's especially good for. You can just -- the thing I really like about it is you don't have to console. You can console log in it, but on the left is your code. Then on the right is your console. It will put the console log on the same line as where you called it.
Chris: Oh...
Josh: Or you can just say a variable. You can just say, "My var," and it will display to you what that actually is.
Chris: That's a little tiny sandbox, right? In your doc, essentially. That's cool.
Josh: Yep. I use it a few times a week. I'm a fan.
Chris: But it's not... There's no DOM, right? It's kind of like--
Josh: Yeah, you can still call document and stuff, I think, in it. But obviously, there is no actual HTML in there.
Chris: Nice. How mad are we at Apple about all this, like, side-loading - whatever?
Josh: [Laughter]
Chris: It was unbelievable. I said one day we'll wake up and Apple will have reversed their decision and we'll have alternate browsers on the Web. That day actually kind of happened. It was just tempered by the fact that it will only be in the European Union. But it's going to happen, right? We'll see how that goes.
Josh: Ah...
Chris: No idea how that's going to go. I was curious how ready those companies are. The fact that this happened, does that mean that Chrome is going to be submitted to the App store tomorrow, or were they like, "Okay. Now that it's allowed, now we'll dedicate a team to it"?
Wouldn't that be a weird job to have is to be ready... Have a version of Chrome just ready to go in case some law changed, though you're not sure it ever will? But anyway, they're a big enough company and probably have the motivation to do it.
So, maybe there'll be some version of Chrome. Maybe there'll be some version of Firefox. I guess that's about it as far as browser engines go, so those two will be available in the EU at some point. I don't know what the timeline is but, theoretically, that's going to happen.
Then as we're smelling that in the air, we're seeing other things come out. The news this week was, "Well, Apple always kind of had a little bit of a poor support of PWAs," right? Poor meaning that it was a little hard to even figure out how to add app to home screen from the Web. Then after you did it, how good actually was that?
Now all of a sudden, somebody has discovered that those apps that you've done that on -- I don't know if it was a beta OS or whatever -- you click to open it up and it says, "Nah. That's just going to open in Safari now." They're theoretically just punting on this whole idea of installable PWAs.
Josh: Yeah. I don't know. My thing on Apple, I love a lot of their products. I use a Mac exclusively.
It feels like they have invested a lot of money in Safari to appear supportive of the open Web while they are also doing this kind of thing in the background to kind of keep a lot of it locked into their little walled garden app store. It's a big company, so maybe people in that company just naturally have opposing sets of goals, or if it's more malicious than that and it is actually like, "If we invest in our browser, then it will draw attention away from this." I don't know what it is, but I've been making PWAs for a long time. For years, it's just been like, "This company is the one roadblock that I see. Everything I want to do, I can do everywhere except where Apple has dominion.
Chris: Right.
Dave: Yeah. You know what's funny to me is I think Apple is playing whatever legal, politics, or "You didn't say not to do this," right? Kind of like where's the line, defining the line.
Unfortunately, though, it's users who are sort of like getting caught in the gears of this little game, the lawyer game, the meta lawyer game. It's interesting to me that Apple would do that, but that's, I think, un-Apple-y to me that they would just kind of like, "Well, those people can just eat dirt, pound sand, or whatever."
But for me, what I can't get over, I feel like this is a huge thing for the Web if a company, any company -- Google or whoever -- was doing the same thing, it would be the same story. But it's like they are trying so hard to protect their garden that the Web is truly a threat to what they do. And so, wow! That's cool. That means the Web is very good, and we should all be very proud and very happy that something is happening. I don't know. Generally, though, I think more companies should get sued more often.
[Laughter]
Dave: It's probably my biggest takeaway from all of this is we should be suing everybody.
Chris: Yeah. The term "malicious compliance" has really entered the chat, hasn't it? It gets thrown around quite a bit with regards to all of this. And you really can feel it. You're like, "Okay. We're going to do the absolute bare minimum here to make this happen."
Dave: Yeah. It's like the no parking signs in New York or LA where it's like you can only park here on Tuesdays from 6:00 to 9:00 but without a permit from loading zone to.... You know? It's like the seven-mile-tall parking sign. Technically, you can't park here.
Chris: Not a lot. Not a lot. Haven't you, Josh, made a game that's got it through the Apple system that's largely just a website?
Josh: Yeah. Yeah, a couple of them. For just for funzies, I've made a couple of word games that are progressive Web apps. Their names are Hondo and Quina.
But I came across this project... Well, originally, I used a Google project called Bubblewrap. But lately, I have gone and used a Microsoft project called PWABuilder instead.
PWABuilder.com is just this website that walks you through all the steps you need to do to take a progressive Web app, make sure it's valid and everything, and then sort of bury it inside of an Android or iOS app. Then you can just essentially push that little website in Android armor - or whatever - into the app store and get it uploaded.
Yeah, both of those games are on the app stores. If I make another one, I don't know if I'm going to go to the trouble because it is a massive pain in the ass to go through that whole process.
It's not the technical stuff. It's not getting it bundled up. It is dealing with all of the things you have to check and all of the stuff you have to verify and sign and steps you have to go through and hoops and all of the disclaimers and all those kinds of things. Getting something into the app store, it makes me wonder how and why people ever do it. Why does anyone have an app?
Dave: It's system designed for a company of 30 people or 100. As a single developer, you're like, "You emailed me on Tuesday and said it had to be done by Wednesday?"
Josh: Mm-hmm.
Dave: I have to re-bundle this and set it up and click some buttons?
Josh: Yeah.
Dave: Yeah.
Josh: I've got tons of stuff. Quina has been in the Android store for maybe three years now, and I just constantly would, "Oh, we've taken it down because it violated this app store rule."
I was like, "But that doesn't go into effect yet. It doesn't go into effect for three months."
"Oops. Yep, you're right. We put it back up. But oops. Hang on." Next week, "You violated this rule."
Chris: Wow!
Josh: But the last guy said that was okay.
Dave: Wow. Didn't you get swept up in the Wordle clone big shoot-down, sort of, right?
Josh: [Laughter]
Dave: You were out before Wordle, I believe, but--
Josh: Well, yeah. Quina came out about a year before Wordle blew up. But the guy who made that is just way better at marketing than I am. I was just setting out to make a fun word game. You know I think the daily aspect of it--
Dave: Puzzle thing.
Josh: Yeah. Yeah.
Dave: Yeah. Yeah, that was the viral--
Josh: I think that was really the big deal. Yeah. It's a much more accessible game. It's a little simpler. Quina is a little more strategic. It requires a little more of a deduction, I guess.
Dave: Mm-hmm. Mm-hmm.
Josh: But yeah. I made another version of it with a daily puzzle (after Wordle came out) because I was like, "That's a great idea." I've actually been playing it on my own for the last few months because I just have fun with it.
Nobody plays my games a lot, but it's fun. I have a guy who lives in Australia and plays the game every day with his wife and his daughter. They all show their scores to each other. It's not just this game. They have a bunch of them, but he emails me every once in a while with a bug or a feature request. I'm like, "This is..." It's just so cool to know that I made this silly little game and somebody out there is having that kind of fun with it.
Chris: Yeah. That's awesome.
Dave: When you think about app stores and stuff like that, what would be a big difference to you to making this something you could do more often? I say that because there are some rumors. There was an intent to ship on Interledger spec in Chrome. Very interesting that that would come back as a non-crypto thing. I don't know. What would make you not have to upload to an app store?
Josh: [Laughter] I would consider just doing it as a PWA, personally. If you're trying to make money on it, maybe that's not a good idea. But you get pretty much all the benefit.
I wish that there was more support for app stores supporting PWAs as actual apps. I think Microsoft does this.
Chris: Yeah. That's what has this big smell, this PWABuilder. It's like, "Okay. I'm done. I did it. I made the perfect PWA." Now there are ten layers of BS between me and getting it to stores. Wouldn't it be nice if there were zero layers of BS? I guess that's what side-loading is, right?
I know that's just a way of getting an app on a phone that isn't necessarily through an app store, but PWAs seem like they would fit in that category. Wouldn't that be hell-a-nice if you could just go to Hondo.com and just click a button and have it woosh to your phone and there was no overlord in place? Like, I did that. You know? The argument against it being that then Bad Guy, Inc. can do the same thing.
Josh: Yeah. I know a lot of the stuff you have to jump through is there for legal reasons. You can't put a nazi app into the store. You can't put stuff for kids that shouldn't be for kids in the store. Those kinds of things, there are legal reasons.
Chris: What's funny is that you sure as hell can on your Mac.
Josh: [Laughter] Yeah.
Chris: Why is it so different?
Josh: Yeah, I don't know. Man, it's... I'm glad I don't have to deal with those problems. I'm glad I'm not the person on the hook for that kind of--
Chris: Yeah, it's just for fun for you.
Josh: Yeah. Security and stuff. [Laughter] People are a problem. You know? Any time you get people doing stuff, it's just bad news.
Chris: You'd think these big companies would have more... You go to this PWABuilder.com and it's claiming that the apps that do this are Facebook, Instagram, TikTok, Twitter, Glass. The main apps, let's say, do this. [Laughter]
Josh: Yeah.
Chris: You'd think they'd be--
Josh: Or at least they've done that for something in their company - at the very least.
Chris: Yeah, that's true. This could be totally BS. I have a feeling the Facebook app is probably Swift - or whatever - right?
Josh: Oh, yeah. Yeah.
Chris: Yeah.
Josh: They've got a team for that, I'm sure. But you could do this if you were a small company and you just needed to get your thing on there. PWABuilder is a very viable option.
Chris: Yeah. That's good to know. I wouldn't consider any other way, honestly. It made my whole career doing Web stuff. The Web has been an awfully smart choice for so many things I've done. I'm not going to rewrite this thing that's already a website in something else when a website should work absolutely perfectly.
Josh: Yeah. While I've got you in-person and we're on the topic, I just want to reiterate my request to make CodePen a PWA so that I can have it open as its own app in my doc.
Chris: Yeah.
Josh: I think that would be really cool.
Chris: Okay. Maybe.
[Laughter]
Josh: It's not actually all that hard to do, I don't think.
Chris: No. Yeah, I think getting those basics in there should be not a problem at all. It's just the spirit of it is offline support. At least I think of that stuff, and that stuff is much less trivial for us.
Josh: Yeah, that's true. I mean you don't have to do that, though.
Chris: Right.
Josh: That's like--
Dave: Offline.html, yeah.
Josh: [Laughter] Yeah.
Dave: Yeah.
Josh: Most PWAs do that, but you don't have to.
Chris: No, but if you are offline then and you open up the CodePen app, how acceptable is it that absolutely nothing works?
Josh: Hmm...
Chris: Because we are so far and headed even more intentionally towards, we're going to use our server power and expertise and dev ops abilities and everything to just lean into doing as much awesome server-side stuff as we can.
Josh: Hmm...
Chris: Whereas that's different than... It's a little bit of a differentiator between something like stacklets, for example, which is really cool, have put tons of engineering effort on to. I want to run Node on your machine. You can spin up Next.js in the browser... Literally, in the browser. Nothing else. It can process that way. That's really cool and interesting in some ways, and we're not headed that way.
We're like, "Yeah, we're going to run that stuff for you, too, through highly efficient server usage." If somebody had it in their doc and they opened it up, I just don't want there to be any expectation that you can be offline when you do that. It's not just syncing and stuff, which has its own challenges. It's actually just using the app.
Josh: Mm-hmm.
Chris: Still, could be done. I'm not saying no. I'm just saying it's the server-side stuff that gives me pause.
Josh: Yeah. Yeah. I'm just saying, think about it, man. I got my little demos. Yeah.
Dave: Offline HTML, and then you give it TV mode with the few Pens in there.
Chris: Yeah, it could be like if you're doing something with no processing whatsoever, make that offline. Gosh, even that, Dave, where we're headed. I'll give you a demo later. It's still doing interesting stuff to your document to make it ready to ship, for example.
Dave: Mm-hmm.
Chris: You know we're going to be... This new version of CodePen, it's going to be easier to build a website. Hopefully, we'll be able to support stuff like Fresh and stuff over time. That's the point of it is, like, "Use whatever. We've got your back." But there are certain things that then we're responsible for doing.
For example, you make a Pen, and even if it's just HTML, CSS, and JavaScript, then you click a button and deploy it. Right? Okay. Great. But then you make some changes and you deploy it again. Now it's somebody's responsibility to break the cache on those assets.
Whose responsibility is that going to be? It's going to be ours because we're going to take that on because that's the point of a product is that it helps you do the things that you want to do.
The way that we're planning doing it in that little example is kind of cache-busting strings and stuff. That's something that again has to have... Even though it looks like no server-side processing whatsoever is happening, it is because we're going to process that. We're going to do that for you, like get those cache-busting strings into the final processed output. Fingerprinting, as it were.
That's just a tiny example. But it's like, man. But does that mean it will never be offline? No, we've talked about... What's the fancy thing that makes WAZM - or whatever?
Dave: Yeah.
Chris: Can you bundle all the crap up as a binary, essentially?
Dave: As a WAZM?
Chris: Deliver it and have it run offline? Yeah. Not tomorrow, but maybe.
Josh: [Laughter]
Chris: Then do WAZMs and PWAs hang out? Is that a thing? Probably.
Dave: Potentially. I think it's just like an asset. Yeah. Next week. I expect next week.
Chris: Next week, yeah.
Dave: That'll all be delivered.
Chris: We're known for our speed.
Josh: My whole dream is just to... I just want to be in CodePen and hit command-tab and go to my browser. That's all I want. [Laughter]
Chris: Right.
Dave: Well, I think we will have to wrap it up. I think we're at the hour mark. So, Josh, thank you so much for coming on the show and blessing us with your triple threat design, code, and writing knowledge. Yeah, for people who aren't following you and giving you money, how can they do that?
Josh: Thank you for having me. JoshCollinsworth.com is my website. I think all my links and stuff are there. I'm privileged enough to not need money. Go play my word games if you're into that kind of thing and have fun with them.
Dave: The word games are fun. I'll vouch for that.
Chris: They are.
Dave: All right. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show.
Follow us on Mastodon this time, and then head over to patreon.com/shoptalkshow. Join us and Josh in the D-d-d-d-discord. Chris, do you got anything else you'd like to say?
Chris: Oh... ShopTalkShow.com.