Is JSDoc Better than TypeScript?

You're listening to Syntax, the podcast with the tastiest web development treats out there. Strap yourself in and get ready. Here is Scott Talinski and Wes Bos.

Welcome to Syntax, the podcast with the tastiest web development treats. Today, we've got a show that I've actually been keeping notes on for Probably a year now, and it is TypeScript via JS doc or typing your code in JS doc instead of using TypeScript.

And I've been keeping notes on it.

I got some really good blog posts. I'm going to call those out right away. Go to the show notes and take a look at the blog posts that are in there. However, it popped up a couple of days ago that Svelte is converting its entire codebase away from TypeScript into JS stock, and People started freaking out about this. It sounds much worse than it actually is, and we are here today to explain to you What JSDoc is, why you can still do almost everything in JSDoc, why you can still use TypeScript with Svelte, all of that good, Good type of stuff. This is not a Svelte show. We're just specifically talking about

JSDoc and TypeScript. How How are you doing today, Scott? Oh, I'm doing good. I am I got a new roof, which, you know, that was that was a long time thing for us. Wes, our roof is From the nineties, and it it had, like, a whole ecosystem up there. In fact, we we had the roofer come up and take a look at the roof, and he was like, Well, the leak could have come from literally anywhere on this thing.

You you have, like, moss we had, like, a whole bunch of moss growing on our roof. I mean, this thing was just, like, It it looked like yeah. I wouldn't I would have been surprised if there was, like, a whole forest on top of there at some point. I mean, it was just like this wild, wild roof situation. So we we were Prepared, but we we got a lot of rain, and it started leaking. So we had to expedite that and get a new roof. And sure enough, we've had a lot of banging and dogs barking for the Past couple of days, so I am feeling clear headed because there's not constant constant noise going on right now. And also, like, rid. To to get back onto the actual topic here and topic at hand, the JS doc stuff.

One thing that I think was really interesting about all the discourse Around this JS doc stuff when it comes to Svelte specifically is that TypeScript haters used it as an opportunity to say, LOL, TypeScript sucks. And then TypeScript, like, it like, people used it as a as a means to further their own points and arguments, which really have nothing To do with what the actual situation and outcome was. It's mostly just that, Authoring a library ends up becoming easier with JSDoc, and shipping that library becomes easier with JSDoc than it is with TypeScript.

You still have types.

Types are not going away in Svelte. Everything's still fully typed. Everything is typed. So, rid.

TypeScript haters, f off. We're we're not talking about that. That's not that's not what's going on here.

Yeah. That's rid. It's still fully type and type safe.

So let's start with what is JSDoc? So JSDoc is rid And it's been around much longer than TypeScript. I remember I Google I Googled I interviewed at Google probably 13 years ago when I asked them, hey, what do you use for JavaScript? They say, oh, yeah, we use JS Doc to Type all of it. So the way that it works is that when you write a function or a variable or anything, really, You create this special structured comment structure above your function and you define like you would in regular TypeScript.

You define what the inputs the outputs are.

You define what the different types are. You can create your own types. You can We'll talk about what you can do versus TypeScript, and it's pretty impressive that you can do all of this type of stuff. In fact, in many ways, JS Doc is even more powerful.

There's a lot in JS Doc that you can do that TypeScript does not allow you to do. We're gonna talk about that as well. Yeah. I wanna know before we dive into maybe some of the specifics around the type stuff, but rid. What is your history with

JSDoc? Because JSDoc is not new, and it's not like a TypeScript.

Rid. It didn't exist as a TypeScript thing even or even a JavaScript typing thing. It was a way to to have documentation for your code and to have your code automatic. Like, I remember meteor docs, not meteor specifically, but, there were meteor projects I'd been using that Automatically generated all of their docs because of JSDoc, and that was my 1st introduction to JSDoc is this thing that people used.

Yeah. I remember early on being sort of confused by what all this stuff was.

For both. But rid. I think at the time that I switched to Versus Code and Versus Code started consuming those, you would hover over a method and it would Tell you what it was. It'll give you a description. Sometimes it even gives you examples, and you go, oh, this is nice. How do I add this to my own? And you realize, oh, Like literally anybody writing any sort of JavaScript can just pop a little comment above their functions and bing, bong, boom, you start getting better rid. Documentation, better autocomplete, all of that good stuff without having to to really opt into anything.

Yeah. And people could should generate full on doc sites. I I found a post from 2016 here. J s doc first, u e doc, first docs, first doco. It's like this this was a thing that was a big topic for a little while and mostly for TypeScript as a way to define what's going on inside of your your code. And largely, I I remember reading code bases that had these docs and feeling like, dang. This take this stuff takes up a lot of space.

But Yeah. As a consumer of it, I'm always happy to have it, But I never wanted to write it myself because I was always turned off by just how much space it took up. But it I think it's one of those things that as a rid. Aging programmer, the older I become, the more I love that verbosity. I love all of that stuff as opposed to before I was like, man, keep my method name short, keep my classes name short, don't have, like, short comments, all this stuff. And I'm just like, give me all the info instead of that. It's just maturing here. So why is Svelte moving away from TypeScript to JSDoc?

There is a really good YouTube video of Rich Harris being interviewed. I link it up in the show notes here.

And he basically said Svelte itself is compiled, right? Rid. And then the Svelte compiler needs to be compiled from TypeScript to JavaScript, and they were finding it kind of frustrating to, Both build times, which is something a reason why we need a faster TypeScript type checker and compiler, rid. As well as if something broke, they had to follow the source maps both through the Svelte compiler, As well as through the Svelte code that they were compiling, right? You see how that can be could possibly be a bit of an issue.

And he he straight up said, like, don't freak out. This is for library authors. It's less beneficial if you are building an application, which is really funny because, like, rid. He wants to get away from the entire build step, which is funny because Svelte itself has to have a build right. It is. It is a compiler, but you got to understand there that there's 2 build steps involved and it can slow down. And then you got Source map's not connecting properly, and they said he was just spending way too much time debugging and trying to follow the trail of

rid where the actual error was happening. Yeah. It it all you know, it still sounds like a nightmare. It sounds like a modern JavaScript nightmare,

rid. So let's go into the next section here, which is why is JS Doc better than TypeScript? So there's a couple benefits to it. First 1 is that you can type non TypeScript projects right away. So If you are I find myself doing this all the time. I've been using TypeScript for a couple of years. I jump into an older project or I jump into something that is not a TypeScript project And I say, oh, it didn't catch the fact that that was the wrong type or, didn't autocomplete.

Like, you know how you can, like, hover over top And this is any and you're like, what? What properties are on this object? You know, I want that type of thing, and you can just Quickly write a little bit of JS. Comments above the code that you're writing and you automatically get all of that autocomplete. So being able to get All of the benefits of TypeScript in a non TypeScript project is a major benefit. And I'll say right now as well, We're going to the next section is it is TypeScript.

You can do all the TypeScript things in it. And sometimes you could do more,

and which is which is neat. Yeah. So what, You know, to to piggyback on that, you you just basically get the TypeScript experience without necessarily a lot of the TypeScript Tooling that you have to do.

You can get the TypeScript tooling as well going on, but, like, just out of the basics here, if you start Typing things with JS. Your editor will give you those tools like you mentioned. And those tools, once you get those tools By using TypeScript, it's some such a big part of the reason why people say once you start using TypeScript, you can't go back because You really get comfortable always knowing what everything actually is, what the implementation is, where what the property values are, what what is expected here from this. And once you have that, even if you're working in JavaScript, it can be very frustrating. And so having the ability to have your editor just be like, alright, Here's some j s dot comment. Let me parse that out and let me I got you. Right? That can just be such a nice experience to have if you don't have access to TypeScript and compiling or running this through ts node or whatever.

Another benefit is you can literally just copy paste it anywhere. I've talked about this in the past where I built a better touch tool shortcut where I can copy TypeScript and paste as JavaScript Because sometimes I'm pacing into the console or sometimes I'm pacing into some REPL online and it doesn't support TypeScript. You know, like If you are pacing something somewhere, it's sometimes frustrating that you okay, I got to run this through some sort of a compiler first and then strip the types out of it. Or even worse, I gotta

delete by hand all of the Yes. I just like select and delete just to get this thing running to try it out to debug a problem that you're probably already having. And at that point, you're probably not, Super excited about the work that you're doing because it's maybe in a frustrating situation.

So, yeah, just take some of that out of it. Right? And and no compile step Is a big deal as well. Not only is it faster to work in. Now granted, we're all running a build compile step in many ways, but like a compile rid without having to even strip the types is gonna be faster no matter what. Right? I mean, if it's just straight up JavaScript being loaded via ESM or whatever, It's gonna be faster. You know, like, Brian Brian LaRue has been, tooting the, the horn of No compile step for so long. And at 1st, I was like, yeah, but we gotta compile. And now, like, the longer I get into that, I'm like, oh, well, maybe we don't have to compile everything.

That's what I prefer Svelte, which is a compiled framework. Yeah. So that that's part of what Rich Harris said in the video. He's like, everybody

rid Has a compile step. You know? I'm not going to leave the compile step anytime soon, but I can understand the logic behind it being more simple without it. It's true. It's It's even just with,

I'm doing demos in the browser and you can import ES modules straight from a URL. You can use Import and export, like the fact that that works straight away in the browser without having to need any sort of compile step is pretty amazing. So I definitely see that. The next rid The next one we have here, and this is probably the biggest one to me, is that you can type things that you can't type in TypeScript, and you can get a lot more rid So the biggest one is in TypeScript, you have no way to specify What a function throws.

So if you have a function that will throw an error and you catch it, The TypeScript will always give you the error typed as unknown because it has no clue at all what the type of a thrown error is. Right. And that's really frustrating, especially if you have made this beautiful error type and it has a stack trace in it. It has a message. It maybe has a reasoning like it has all the information about the type of error that you want to throw.

You have to write a type guard to make sure that it is in that before you can actually go ahead and use the properties in it. With JSDoc, you can rid. Define in throws. So all the properties in JS Docs start with and that's above your function. So you can say like returns, param, param2.

You can define what they all are, but you can also define throws.

And then you can say, Okay, well, if this function does throw, this is the type that it will throw, and it's so much better than having to

rid. TypeGuard every single time an unknown error. Yeah, man. TypeGuard ing in error is just like one of those, like, Find my like, the thing that I Google the most or or go to be like, alright. What what again is this attacks for type guarding? Yeah. Throw yeah.

Or even just like the docs.

Like if you want to know, Okay, well, I'm dealing with this thrown error right now.

What do I have to console log the thing to see what's in it? Yeah, you know, like there's there's no Type hinting in TypeScript for a thrown error, but you can just hover over top of the function, look at the docs for it real quick and say, oh, okay, this throws a Not found error. Yeah. Totally.

Another interesting thing that I can do that TypeScript straight up can't do with that. I was surprised that nobody talks about this Is that you can type an entire function, its return type, the function itself, all of the parameters with a one comment above that function that could be imported from somewhere else. And this is something that I hit SvelteKit all the time. I'm sure other people are gonna be hitting it with actions and, Next JS, but essentially, what you have is in in Svelte. You have a a load function that loads the data. Right? That load function gets all this stuff. But if I want to type that with TypeScript. I have to export const load is equal to a function, and then type that, and then type rid. The re well, I guess you're typing the function itself at that point.

But the problem with that is that, like, Man, all the examples in the documentation are just export function, whatever. Anytime you're copying and pasting stuff, you gotta constantly convert it to an export const. You gotta then type stuff yourself, whereas if you just have a full function and you want that entire thing typed, you can drop that one line comment rid above it and not have to worry about assigning it to a variable Yeah. And then have that variable be typed. Yeah. I'm always so conflicted on that because

When you have a function, you have to specify the input parameters types and the return type.

And rid. If you put it in a variable, then you can type the whole thing. You can type the inputs and the outputs, but you can if it's just like a regular named function. It's so frustrating. So like and I want to do the function export function, especially if it's something that is rigid, like an export handler that is Svelte or React or whatever is expecting.

But then I hate putting them in variables, but it's easier to type.

I wonder if TypeScript will ever

fix that because that would be really nice. I know. It was like a a year and a half ago. I was like, rid. Feels weird that there's not a a way to do this in TypeScript straight up.

And Yeah. Yeah.

Next 1 we have here is rid. Fram function and return descriptions.

This is something I love. So Love it. Even if you have TypeScript, Sometimes it's helpful to add a description to what a function does or what a function is expecting. Sometimes the name of the function or the name of the parameters is not enough, rid. And you want to be able to write a little bit of documentation for what happens. So you can, In JSAQ, you just put a dash after you describe what your params or your return types are, and that will pop up when you hover over top of it. Sometimes people in.

Like let's say you have a show ID, right, where the syntax website, rid. You wanna get a show by show ID. Show ID is a the number. Right? So are you just going to say pass me a number? That's kind of annoying. Right? I guess you could also pass you could also, like, name the parameter show ID. So someone would know, okay. It's a number, and the variable is called show ID.

But wouldn't it be nice if you could say it's a show ID and here is a description of it? Sometimes people even go as far as just aliasing number

rid Do something like type show ID equals number. Right? There's a lot of things there too. You know, I think about the level of tutorials website. When I initially modeled the database, rid. We were coming from a YouTube importer. We are importing from YouTube, and we had a playlist ID. The playlist ID identified directly with the YouTube to playlist ID. But as time went on, we started calling our internal playlist in the database playlists.

So you'd say playlist ID, and rid. I I couldn't tell you how many times I went to say, oh, let me grab that playlist ID to look up in the database on our database, a playlist, And they would say there's nothing here. I'd say, well, why is there nothing here? Oh, this doesn't look like one of our IDs. This is a weird long string. This looks like a YouTube playlist. Oh, this is the YouTube playlist ID. And so, like, instead of being able to, you know, have to remodel my database or do a migration or something, you could have had a little descriptor that says, this is the playlist ID and for the YouTube playlist ID. It returns the YouTube playlist ID, not the actual one. There's also some really interesting little extra, features like, being able to describe something as deprecated, which will strike through in your editor. In that, I couldn't tell you how many times that comes in handy for me. You use a method on something and it strikes it right through in your code base and you say, oh, wait. Shoot. I'm not supposed to be using this method even though it exists, but you can't necessarily get that without these neat. Js doc types. Also examples,

being able to rid have code examples directly in it. I was using the Deepgram, which is the audio to text engine that we're using for the new website, and all of their documentation or all of their methods have JSDoc examples. It's so good because you just rid. Hover over top of it. You can copy paste an example or you can see here's several different ways that you can do this type of thing. You don't even have to go to the docs For that, you can just see an example by hovering over top of it. So that is super handy.

Other otherwise, we have fire, Which will describe that a function can fire a specific event. You could type the event, see, which is links to documentation rid. Or to do if you have something that needs to be done in a function, you can put a to do in there, which is rid. A little bit past the

scope of what TypeScript is. Sure. But, man, is that handy? It's handy. All of the It's handy because it gives you more information when you're actually authoring your code. And I really do like the c because if if my TypeScript Hover when I'm hovering over something, it gives me a link to documentation or, like, I'm confused about something.

You know, Prisma does this really well where If I wanna see something in the documentation where it says, hey. By the way, this thing can't do this or whatever, I I click on the link and it takes me right there. So being able to have Links to documentation directly in your editor like that is a very nice thing. You can also

inline link tags.

So you can say at C and then you can link up like a Stack Overflow issue.

And then somewhere else rid. You can say, alright, see this at link. It's like a templating language almost. It's why I do this a lot is if you do something a bit weird, someone might say, Why are you doing it this way? And it's like, oh, because there's an edge case that happens every now and then.

And by putting A link to a Stack Overflow thread or blog post about why somebody does it.

GitHub is probably more common.

That is Very nice to be able to to point people to. Totally.

So, let's talk about how it is TypeScript Because that's the big part of the argument here is that, oh, LOL, it's not TypeScript. Types TypeScript's bad. Whatever. But at the end of the day, It's a different way of interacting with TypeScript, and it is TypeScript. It's even supported by TypeScript themselves. Rid. Right? So Yeah. At the end of the day, the JS doc style typing is TypeScript. It's just a different way to interact with TypeScript. Yeah. So,

rid. Spoiler, Svelte is still written in TypeScript.

It's just written in JavaScript with types via ready.

There's a page on the TypeScript docs that show you how to do everything, as well as Austin Gill and What is it? Fetch blog. What is this guy's name? This guy has an awesome blog post.

Stefan rid. Bumgarner.

But link it up. Rid. Basically, they have really good blog posts about like, all right, well, how do you do this in TypeScript? How do you do that in TypeScript? So you can still type check your code. You can still make sure that your code is 100% type safe.

You can still generate .ds files, which is rid.

Those files are generally what libraries ship so that you can Get access to the types for a specific library. You can import them. You can use them in your own process.

You can still import types via comments. So this is really handy is if somebody exports a type from a library that is a D. Ts, You can still use the import syntax inside of JSDoc to import it. I use that a lot specifically for rid Vite config files that are not in TypeScript. Mhmm. If you want the autocomplete, you can just use the little import comment

and you get full autocomplete inside of it inside of a JavaScript file. Yeah. And if you're if you're using SvelteKit at all, I know. Like we said, this is not a Svelte episode, but they they have that all over the the code base and the examples and anything like that where you just where you could see the comment At type import, and the import happens right there. So it's not like you're always having to define types in a larger elaborate ways rid. You can import with a one liner directly atop your function. Like we had mentioned, it is really a nice easy way to type an entire function, Which, honestly, I I kinda prefer that that syntax, that ad type import directly above a function than all the other junket in the way. Generic still work,

So no problem there. A lot of times people are saying, oh, yeah, but what about generics? But what about one of the ones that I found was function overloading.

Function overloading in TypeScript is if you have maybe 2 different ways to use a function So you could pass it a string that is an ID, or you can pass it rid. A number and a callback function. You know, like, it's the the function signatures are totally different. However, the logic inside of it, Sometimes this is like, oh, we still want to maintain backwards compatibility, or I just want to be able to be able to use it a number of different ways. Function. Overloading as you describe the signatures 3 or 4 times, and then you can say, alright, these are different. Those are called overload. Sometimes rid. You hover over top of a typescript error, and it says plus 9 overloads. Yep. And that means that that function can be used 9 different ways.

And the way that you're using it is you goofed it up some possible way out of those 9 ways. So it kind of works.

I found a couple of blog posts about how to do it, But it wasn't one of those things where I go, oh, wow, that's great. It was one of those things where I was just like, oh, yeah, I guess you could get it to work. Rid map types, type aliases, decorators, conditional types, all of those things work as well. So it's actually quite amazing that rid I was try I I tried really hard to find spots where you could not do things.

Rid Even enums. I was like, oh, enums. Enums is, like, the weird one in TypeScript because it's it's data and types in one. You know? Like, everything else in TypeScript stripped at compile time, but enums are converted to these weird objects.

Even those you can do.

In fact, I prefer the object way of doing it anyways. So it's pretty impressive.

Yeah, it is. It is. It's, It is just TypeScript.

I you know, I saw I've been seeing so many threads about this because I obviously follow so much SALT stuff. But, you know, there were people who were asking Rich What specifically is, like, the biggest downside to using JS doc in this situation? And his answer was just the verbosity, the how verbose it is to write. Yeah. The amount of code that it takes is maybe a little bit more. It does maybe hide a little bit better considering its comments, but it still rid. Picks up more space, I'd say. One thing I do like about the fact of how this stuff lives outside of your code in a little bit more of a way would Would I mean, it doesn't always, but sometimes, is that it it with TypeScript, when you get into Typing parameters of a function. You'd get to type in the return. You're throwing in generics and then the mix. What you're often left with is something that is Insanely hard to read. I remember during our last live show, Wes, one of the examples you gave me to say, hey. Where's the bug in this code? Was essentially a type function, and it wasn't even that crazy of a type, but the type was so intense. I was like, I don't I don't let me go line by line and try to read this thing. And I was Trying to find it for bugs, but if I was just looking at that function in general, that syntax, if if we're being entirely honest, has never it. Really sparkled truly with me in a way that I'm like, oh, yeah. I love the syntax. It always just kind of been a necessary evil for me to get the power of TypeScript. I was talking to Dimitris.

So I met him. He works for Zeta, which is a new database company.

And I was talking to him and I used data to test out the embeddings on the new syntax website.

And I was like, oh, he's like, he's getting feedback on it. And I was like, when I Hover over top of a type rid From your library, it's like 8 generics deep. And I don't know like, just tell me this is a show document, not like Zeta document angle bracket type of whatever.

So sometimes these libraries are so heavy on generics because they have to be able to adapt to anything.

But me, the developer, I just want to hover over top and say, oh, That's a show document, you know, and a lot of times people generate types for that. I think Prisma does that as well. Instead of making everything generic, Just literally generate the types for me and not make everything a generic. Yeah. Yeah. That's

a interesting thread. Here here's a couple more interesting threads here, in just because, again, Twitter dialogue, and this has been intense. So there was an interesting dialogue about Converting your projects.

And, Sunil Pai says, I think type, I I was thinking how hard would it be to make a type Script a transpiler that instead of stripping types, converted it to JS doc comments and saw instead. This would solve this, relatively neatly. And it does seem like a really interesting idea. And then Rich posted a library t s two j s doc, which he said that he believed some people in side of these Svelte team we're using to help convert code. And so I just wanted to link up this little package here because it has 47 weekly downloads.

So, this is a little scoop here in case you're looking at doing this type of thing or you're interested in JS doc. I Don't have experience using this tool, but it seems like it does at least some of the the the more annoying aspects of converting a code base if you want to do that for whatever reason. It seems like it it can do some of that stuff for you to at least help with that bit, If you're trying to get into the JS Doc style syntax,

it's true. Like, if you are trying to click through to the source of something. It's broken. You want to figure out what's going on? Don't send me to a D. Ts file. Send me to the actual source. And then if that's compiled source, then you don't see the types in line. So it might even be handy for library authors just to run their code through this.

So their source has JSTALK.

Yeah. It's it's very fascinating.

The whole thing is It's a world that I would like to get into more, but I just I'm writing TypeScript right now, and I I don't really see that necessarily changing anytime soon. And also there's a whole conversation to be had of what about the TypeScript as comments proposal for JavaScript, And how does that fit in here? Because if we end up getting to write TypeScript in quotes in actual JavaScript code in the same syntax we're running right now, Like, maybe you're just straight up as a user better off keeping all of your stuff in TypeScript code and compiling for now, at least in this sort of way. I guess For library authors and for people like this felt core team, that's a completely different conversation than people consuming TypeScript. But, rid. Again, it's something to think about.

So I was just gonna ask you that. Like, are you gonna stop writing TypeScript? My answer is absolutely not. I No. At the end of the day, rid. I prefer the TypeScript syntax for all of this, and I use what's called the mix and match approaches. When I need one of those things that I talked about, when I need to be able to have better descriptions for what a function returns or if I need to be able to type What a function throws, you can sprinkle JSDoc on top of TypeScript, and the TypeScript compiler will be able to understand it. Versus Code will ingest it and give that to you.

And it's really handy to be able to simply just add a description to your existing TypeScript, Hover over top of something and I can see the examples there. So that's kind of the approach I'm using going forward is TypeScript. However, I will add JS doc sprinkled on top when I want it even further.

Svelte has a TS config file, right. Like, it still runs TypeScript compiler all of their code through that because they need all of the type checking and the type output, all that good stuff. Yeah. Yeah. Totally. It it you know what? I'm not shipping code as a library author, really. You know, I I've dipped my toes into making some libraries and stuff here and there, but

Let's face it. I'm I'm more of a actual site app developer than I am. Implementary. Yeah. Yeah. And then that's my 9 to 5. So, Largely, the benefits are not so much there. Like, the benefits could be away hover over this Method, and it gives me some some internal docs.

But oftentimes in an internal project, like, I know the code because I wrote it from start or it's rid. Painfully obvious what this does. It doesn't need a ton of extra handholding. It's not a multifunctional library that can do different things in different use cases. So for me, I'm probably going to remain just writing straight up TypeScript code for the foreseeable time. But like you said, rid. There's no harm in sprinkling some JS doc on top of there if you want some more documentation information.

Alright. So we just got a bunch more resources in the show notes. Make sure you click them rid And see you can sort of visualize what we're talking about here.

Let's move into some sick picks. You got a sick pick for me today? Sure. Yeah. This is actually a very funny thing that, Courtney and I just started watching last night on Netflix, and we were like, put it on because we had nothing else to watch. We're at that that phase in parenting where, like, by the time the kids go down to bed, we're both so exhausted. We're like, I just put some on TV, you know? Yeah. So, we we put on oh, man. What is this called? Let me sorry. Let me Google it so I don't mess it up. It's a show about mermaids, rid which is not my typical, I'm not a like a mermaid enthusiast.

I don't even care about mermaids. Rid. But the the name of the show is called the merpeople, and it's about human beings who work as mermaids and mermen rid. To swim in tanks and do performances and shows.

And it turns out there's this big subculture of people, and it's rather fascinating. It's like, Woah. The whole thing is really produced well, but to learn that there's this whole subculture of people who Spend a lot of money to buy a fancy tail and can hold their breath underwater and do, you know, ballet and underwater, activities and Do it at different shows, and some of the life stories are really interesting. So if you're that type of person who gets into docuseries that dive into people's lives, and you can Kind of follow along, see how these people are are advancing their Mer careers or things like that. There there's Moments in this documentary series that Courtney and I are are both shocked that this exists, laughing because it's it's truly funny in Many ways not like I'm not not laughing at them, but just funny in general.

And just the, the dive into these types of sub subculture. I kept thinking, like, Wow. They they can get funding for this, but breakdancing can't.

You know, like, in any other ways, it it's it is Pretty low budget in many ways. And a lot of these people are doing it just for you know, they're doing these massive feats to drive across the country just to Do a small performance just simply because they love this this art form that they're doing, and I gotta say, I love that kind of stuff. So if that interests you at all, Mer People goes what is this? CNN says merpeople goes fins in with mermaid enthusiasts.

This is actually a really funny thing. So sorry. A little side here. One of the merpeople in this documentary is so committed that every single thing he says is some sort of a, Like a pun. He'll be like, let me swim past you here for a second. Like, alright, Guppies. Let like, listen up. Like, the way he talks is like every single thing Is fish connected or water connected? And you're just like, man, this guy can't turn it off. This this this guy is a merman. He has He has built into him. I'm going to sick pick,

the Ryobi cordless soldering iron. So A couple of years ago, I picked the TS eighty plus, which is a USB powered soldering iron, and it's tiny and it's super handy to just to bring around with you.

And I like it. But sometimes I just want, like, a bigger one because I just want a little bit more heat. I want it to just be a little bit more portable.

So I also a while ago, I got I saw it at Home Depot for, like, $25 on sale is the Ryobi cordless soldering iron. I actually have it on my desk right here.

And it is so nice to not Whenever I do soldering, it is so nice to not be chained to plugging it into the wall, because generally when you're soldering something, you have to go somewhere and do it. Whether you're rid. On an ATV or I'm sitting at my desk here, and I don't I don't like having cords attached to hot things that can fly around the room.

Rid Yeah. We talked about the hot glue gun being a a, like, a dylan thing too. That's that's a thing about people like to hate on Ryobi tools, but they have so many rid Weird things like the soldering iron and the hot glue gun. Even if you don't have Ryobi batteries, just buy a converter online because Ryobi has rid. So many cool things. And I bought this thing. It's fantastic. I realized I probably got it. I'm just looking at it on the Home Depot website right now. The reason I probably got it for $25 is because the new one allows you to adjust the temperature.

Mine does not.

So that's probably why I got it on sale, but rid. It's fine. It works. It works very well, and I find that it's faster to whip this out for larger items. And then I bring out the little TS 80 plus for

little micro stuff. I you know, my only beef with Ryobi is that color of green yellow. Awful. So heinous.

It is like the worst. You look at what your website, and their website header is in that color. I'm like, you guys couldn't have picked a different color? You couldn't you went all in with this color? You couldn't have somebody be like, I don't know about that color, man.

And, like, I feel like when they picked it, it was, like, 10 years ago. It probably looked cool, But, like, it did not age. And, like, they're committed now. Like, that's their color forever. It's their color forever. It looks so washed out and bad sometimes. Yeah. I had a Ryobi,

like, one of the very 1st gen electric leaf blowers that wasn't any good. Like, my electric leaf blower now kicks, but, like, when they first came out with them, they were it was essentially like A reverse dust buster. I mean, it was so late. Weak. Yeah. Yeah. Totally. So yeah. But it always looked like that thing was left out in the sun because of the At least at least nobody will steal it because they don't wanna be embarrassed by having such an ugly tool.

There's a a guy on IG that we, that I showed you a little bit ago who, like, does a lot of 3 d printing stuff. And he buys a lot of tools. And what he does is he'll, like, take the cases off of all the tools And then spray paint them white so that they're all white because he just likes all of his stuff to be white. And I was thinking, yeah, maybe that's a use case where I'm not going to do that because I don't have the type of commitment there. But, like, I didn't really hate the green enough. You could paint a line. I saw a guy,

Boy, he took apart his all of his DeWalt stuff, and he boiled it in water with a little bit of rid Paint thinner, which don't boil paint thinner if you don't know what you're doing.

You probably must start to see probably lose a few brain cells. Yeah. That's a good one. Yeah. He boiled it with paint thinner. What that did is it opened up the plastic and then he poured Rit dye, which is Have you ever dyed like a shirt or something with with written dye? Yeah. So he did that and he it, like, dyed the plastics, like, dark black And it, like, it doesn't come off. It's amazing.

And I was like, oh, maybe I need to do that with my robe. I don't care that much. Yeah. People love too much time sick. They're doing that. It does. I you can't argue with the result. The results are looks sick. The process looks sick. Yeah. I don't know about that one. It's just well, it's a scroll stopper. I think he did it because it's a scroll stopper. It is. You go, oh, what drill is that? You know, and it's not like, oh, it's a red or whatever yellow.

It's like a different color. Maybe I should find a really funny

color and dye all my stuff. Yeah. I would say if that is like if you're if you're trying to make it big on IG And you do want that. That does make no longer gonna wanna do it. Yeah. That's true. Yeah. Whenever I see something, I don't know what happened. Like, oh, who knows what's going on there? Rid. Shameless plugs, Wes. I'm going to shamelessly plug century@centurydot IO Sentry is the working code happy customers tagline right now. And and, honestly, they they Do so many cool things. It's hard to talk about any individual thing. But they they added some AI features into their general issue stuff. So now if you click on You're having an issue or a bug. You know, it's just like instantly this thing popped up, and it's so fun because I feel like that way with Century all the time.

You know, now now I probably have they're not just going to pop up for me anymore, considering I'm an employee there. But as a consumer of this product for a long time, Things would just pop up, and you say, oh, man. They're doing so many cool stuff. But either way, they have this really neat experimental AI solutions, button now. Since you might get lucky, but then again, maybe not again. This is experimental.

It's an OpenEye generated solution. Basically, what it's doing is passing your bug and context into, what I would assume is GPT something, and it's gonna return a potential solution for you, which if you're solving a bug to to to Spin a wheel and potentially get an actionable solution out of this thing is pretty sweet in my mind. And, I've I've found myself to to actually get good results of that. The the time it works best is when you have less generic issues. You know? Cannot read x of undefined. It's gonna tell you whatever. But it's not going to to pinpoint.

Typically, you're better off just looking at the stack trace and stuff like that for those. But I found this tool to be really neat rid. And, like, a a really nice little addition to the project to say, hey. Now you can use the powers of AI to potentially help solve your issue as well. I'll shamelessly plug all my courses westboss.comforward/courses

for a list of everything I offer. If you do buy 1, there's a bunch of free ones on there, but if you do buy 1, use coupon code syntax for $10 off.

Thanks everybody for tuning in. We'll catch you on Friday.

Rid

Peace.

Head on over to syntax.fm for a full archive of all of our shows.

Rid. And don't forget to subscribe in your podcast player or drop a review if you like this show.