Potluck - The Value of TypeScript × Vue vs Svelte × Leetcode

It's good. It's good. Yeah. The weather in Denver is alright. I got got caught in a hailstorm yesterday, but today it's looking good. We had a situation where our dog

Yeah. Let's do it. So this first question comes from and they say, I don't use TypeScript much. I understand the value that it provides and I grasp the basics of it. But oftentimes, I see extremely convoluted examples of types on Twitter and I just think, wow, I don't wanna have that in my code.

For example, see DHH's tweet on May 9th. We'll link it in the show notes. Can I get by with a basic understanding of TypeScript or should I be able to handle these advanced and complicated use cases? And for all the audio listeners, if I could give you a a description of the tweet that was retweeted by DHH, it's just a really complex type union, for tuples.

And, honestly, I wouldn't wanna see this in my code Bos either. Like, this is this is really hard to grok, like, this kind of TypeScript code. And personally, I don't really ever write TypeScript code like this. So if you think about how we use JavaScript, like, 90% of the time, we're calling functions and we're accessing properties on objects. That's like, that is that is what we do on a daily Bos, and TypeScript really shines in that area. And so in my experience, like, that's that's my that's how I use TypeScript JS describe objects with either types or interfaces and then describe the arguments that you're getting into a function. In that way, anybody that's using your code later on is gonna have an easier time calling your functions because they're essentially documented with code. And then same thing, they're gonna have an easier time accessing those objects because those are documented with code as well. And Scott, typically, in my experience, if you're ever needing to reach for, like, generics or any of this, like, really, really crazy TypeScript stuff, It's kind of if you're writing more so, like, library code or, like, very generic reusable code.

And, yeah, most of the time, we're not doing that. That said, I have I have delved into generics, and and I will say it's it's fun. It's fun to get into some, like, complex TypeScript stuff and, like, feel like I Node what I'm doing. But, yeah, in my experience, most of the time, TypeScript is just there to document the code in a nice and easy way so that when other people come along, it's a lot easier to to jump in without needing to run all over the code base like we used to have to do before TypeScript.

Yeah. Personally, I just like to be pragmatic about it. I think that's something that took me a while when I first started using TypeScript. And I was honestly, like, it I was not the 1st to adopt TypeScript. Like, if you go back and look at some of the live streams that I would do, I was like, I would always reach for JavaScript for the longest time. But I think once I got over the hill of realizing there are scenarios where I can just turn TypeScript off and Yeah. Just do the codes that I need, it works perfectly fine for that. And, I think finding that balance, I think, takes a little bit, and before that, it can be super daunting.

I remember there were days when I would literally not get any actual features done because I'm just, like, trying to fight the types. But now I've I've did that enough times to where I'm like, alright. I have to stop myself. Like, if the types aren't working, I need to just get the feature working and Node back to the types. So yeah. Yeah. I I I know that feeling all too Wes. And and I think that is something that you do just kind of eventually pick up, or

Yeah. I would say I I I Node less about Astro than SvelteKit. I have a lot more experience with SvelteKit. And the stuff that I have used Astro for is typically when I know that I'm gonna have a static site generated from this. Like, I know that I wanna have a nice dev experience with, like, reusable components, but at the end of the day, it's just gonna generate a static site for me.

Can you talk about it or do you know a little bit more about, like, the API story there? Because in my mind, that's that's where I think about SvelteKit. Like, they have this idea of, like, have you have your serverless functions in your API folder. Like, does Astro have a solution for that? Or, like, what what do they do there? Yeah. So I'm gonna preface this with I have not used this, personally. But as far as I know, based on what I've seen,

Nice. Alright. This next one comes from Samwell.

And, they say, hi, Wes and Scott. I guess also CJ. Hope you guys are doing well. I'm curious on how you would handle multiple languages in a web app. I understand most front end frameworks have, I eighteen n support, but I'm not quite sure on the back end. For example, should an API return translated error messages? Let's let's take a step back and define I eighteen n if you hadn't heard of it before. But I eighteen n stands for internationalization.

And they did the abbreviation thing where in the word internationalization,

Yeah. I mean, us developers are lazy.

Internationalizing.

What's that? What? It's 8 syllables. I don't know. Last time I heard a 8 syllable warp, but, yeah, my 18 in is 3 syllables. So If you would see how bad Wes and I are are at spelling things in fact, one of the things that

No. Honestly, like, in in working with you now for the past few months, I I like it because it's like I mean, I worry about these spelling stuff, but sometimes you just gotta get stuff done. So Spelling is optional here at Syntax. Yeah.

Awesome. So, yeah, internationalization itself is the idea of creating an application that can be viewed in many different languages. So you could have an app that is written in a way where when an English user visits the website, it shows in English. When a German user visits the website, it shows in German. And, typically, the way that works is every single spot in your user interface where you might have some text, so think about, like, descriptions of form inputs, even placeholders on inputs, button labels, literally anywhere in your app that you have text, instead of putting that text directly in, you reference some key. And so every single piece of text in your app, you give it a label. And so the the example I have here is you might have a key called, in all caps, submit underscore button underscore label.

And every single submit button on your site references that key.

And then at runtime or at render time, when we're trying to turn it into a specific language, you have a dictionary that basically converts that key submit button label into a specific word. So in English, it would convert that to the string submit.

And then in German, it might do, absenten, and then you might have, like, a Spanish translation as well. And then if the key isn't present, you might fall back to another language. And so sometimes, a lot of apps these days might default to English and then parts of the app are translated.

But if certain keys didn't get translated, that would always fall back to English. So that's this idea of internationalization.

And I've worked on a few apps that have been internationalized.

And, it is an interesting dance when you're trying to return things from your API that need to be translated as well. And so I have, some pros and cons for doing it the 2 ways that that Samuel asked.

And, the first one is your back end can look at the accept language header. So every request that a web browser makes, it sends your preferred language along with it. And so your back end can look at that and say, oh, well, this user prefers English, so I'm gonna respond with English text. And, if it specifically, if it's an error message, it might literally send back the translated English error message in, like, a JSON response. And the pro for this is that your front end doesn't have to do anything special. Right? It gets that error response from the back end pnpm then it can literally just display the text because it's already been translated.

But a con of that is there's a potential for this to, like, get out of sync for for whatever reason. Like, if a user changes their language setting in the UI, but that hasn't changed what the server knows that their preference JS. The server might respond with a translated string that doesn't match what the UI is displaying, so you could run into that. And then the other aspect of this is keeping your translation strings in sync. So a a lot of times Wes you're when you're dealing with internationalized applications, you're using some kind of service that makes it so that nontechnical users can contribute to translations. Right? Because you're you probably have, like, subject matter experts, maybe they don't know how to code, but they need to be able to provide the translations for all the things that that show up in the UI. And so there are a lot of services where they can go in and see all of the things that need to be translated and then add their own translations. And there's also there's there's services that can do this in a community driven way. So if you have, like, a a community driven website, people can submit translations in that way.

But all that to say, if you're doing something like that, it can be trickier for your back end code to get access to those translated strings, like, it might need to make an API request or it might need to embed them in both the back end and the front end. And so you need to make sure that both of your your code bases stay in sync with those those translated strings.

And then the way that I've done it before, and I think is probably the the better way, is to just have your back end return error codes. So your back end literally doesn't return any text at all. It just returns, like, error code 42.

Then you have some sort of lookup table that says, well, error code 42 is this specific internationalization key. And then you look up that internationalization key, and now you can display that error message in in any language. And so for to the pros of this warp that all your translations are kept in the exact same place, all your UI translations, all of your error messages, all of those can live in whatever hosted service or translation file format that you use. And also another pro is your front end can reuse some of those error messages without having to duplicate them. So think about, like, validation errors and stuff like that. A lot of times, you have that validation text both in your front end code and in your back end Node. But if you consolidate that to your translation files, then it can be reused.

But a con of this, and probably why some people don't do it, is that now every error that happens, you have to look up that error code. So if let's say you're you're providing some sort of API and it returns, error codes, users of your API are gonna need to know that they have to actually look up that error code to determine, like, what it actually means.

So there's a couple ways to go about it. Like I said, I prefer the error codes just because keeping things in sync when you have lots of translations bouncing around both front end and back end can be pretty hard. So error codes kinda make it so that you can always have a a lookup table and always bring it back to what the actual errors are and and keep it in sync.

Yeah. So I too started writing React back in 2015, but I think for me, I was never in love with React. Like, I was always begrudgingly using React. Like, I taught React at a at a code school. I wrote React professionally for, like, over 3 years at a consultancy.

But all the time, all of my personal projects, I would do them for the longest time in Vue.

And then when Svelte came around, I really liked how it was doing things. So I would do things in Svelte but even even teaching like, I have a course on React. Like, I I still like, I I feel like at this point, like, we're React is here to stay. There's there's just, like, there's not much you can do without having to talk about how it's done in React or yeah. So React is here. Was I was never exactly in love with it, but I still use it, especially because so many people it's basically reached critical mass that you can't ignore it. So I don't think I would phase it out at all. And like you were saying, all the cool stuff that they're coming out with, I'm absolutely gonna stay up to date with it. Like, they're introducing the stuff that I've wanted them to for the longest time. Right? Like, simplify the code, less boilerplate,

Yep. So this next one comes from Tom.

And, they say, do you have any tips on how to best ship private packages via NPM? Currently, I'm considering just using npm pro and paying $7 a month for it. On the other hand, there is software like, Verdacio or Verdaccio, which could be hosted for, like, $3 a month on HeadSr.

Not quite sure what to pick in if Npm Pro might come with some limitations down the road if I wanna distribute paid software through it. Yeah. And I I have a fun story about Verdaccio. Have you ever used or heard of Verdaccio? Never heard of it. This is the first time I'm hearing about it. You can actually run it on your local machine, and you can basically treat it like an NPM proxy. And so before Yarn and before, like, NPM got faster at installing packages, I would run I think Verdaccio had a name change, but I forgot what it was called before. But I would run it locally on my machine.

And because it's just it's basically an NPM registry running on your computer, the installs would be super fast because everything would be cached literally on your computer. And then anything it didn't have, it would have to reach out to NPM.

So that that's an interesting use case for it as well. But the suggestions I have for this is to look at other options before looking at NPM Pro because, you may not know this, but one of the things you can do is install an NPM package well, install a package directly from a Git repo. So when you do an NPM install, you can specify, like, a a Git URL. And in this case, if you're if you're wanting to have things private, you can specify a URL to a private Git repo. But as long as anyone that's running NPM install or your CI system, as long as they have access to that repo, they'll be able to pull it from a private private repo. And so I I've worked in large code bases that do this.

It's fine. I would say version management is a bit trickier. Like, you can do management via, like, Git tags or Git hashes.

But that's one of the things that gets pretty cumbersome JS if all of your dependencies are private Git repos, then it's a bit harder to, like, bump the versions and stuff like that. But it is possible and it doesn't cost anything as as long as you have a way of hosting private repos.

And then the other option is to look at alternative registries. So you may not know this, but GitHub packages actually lets you host private Npm packages or private JavaScript packages. And they have ways of hosting packages for lots of other languages as well. And then also, GitHub has something. I haven't looked into it, but I'm guessing maybe, like, Bitbucket has something. So there are other ways of of hosting private packages that you don't have to use npm pro for. And I would say if your organization is already paying for GitHub Pro, like, if you're gonna have if you have, like, private repos or the pro version of any of these other hosted Git platforms, they probably have some sort of registry that you could use. And, basically, what you do is you have a an Pnpm RC file in your code repo that specifies the NPM registry. And so instead of npm I don't know the exact URL. But instead of in the URL to npm.com, you point it to the GitHub registry or some self hosted registry or whatever else. I will say, working at a consultancy, I worked with some enterprise applications, and they also used a thing called Artifactory.

And this has various ways of, like, hosting packages and stuff like to that too. But it's a similar thing. They all implement the npm registry pnpm. So as long as they can be hosted in a private way, you can you can install packages from them. Nice. How do you feel about importing packages from a u l URL a lot like Deno? Because I've I've heard rumblings

Yeah. I'm I'm on the fence. So I I did a lot of, Deno reconnaissance and, like, I built, like, a fairly complex app in Deno. And at the end of the day, I tended towards, like let's say you have multiple files throughout your app and they all need to depend on the same library.

If you're using the URL directly, dependency in, like, 4 different places. So naturally, to clean up your code base, you wanna consolidate that consolidate that to a single spot. So you end up creating, like, a modules Scott ts or modules dot JS file that export from that URL and then you import everywhere else.

So I'm I'm on the fence because at the end of the day, you're, like, you're crafting your own solution to basically get the behavior that you got with package.json and, like, the Node module resolution.

So

Having a depth Scott ts file where it it was basically, hey. This is a package .json that's just importing all your stuff. It's an interesting solution to this specifically, though, because, if you literally just need to reference a JavaScript file, you don't need a registry. You just need it to be hosted on a CDN somewhere. So in a way, that's, like, a much cheaper solution than even having to have, like, a private,

JavaScript here. It was ViewConf that you went to. Right? Yep. Yeah. So in in New Orleans, it's a good time. Yeah.

Sure. I'll give you a bit of my history with Vue, and then I'll, like, get on a soapbox and talk about how jaded I am that Vue didn't get more popular.

But I I so I've been using Vue as long as I I mean, like, maybe a few months after I started using React, I I picked up a few. And I actually I come from the Angular Node world. So I I have a lot a lot of older apps that I was writing, what, I Wes, 10 years ago at this point, with AngularJS.

And, at the time, Vue kind of felt like the the middle ground between AngularJS Wes, not the newer Angular stuff, but AngularJS 1 and then also like React. And that the syntax was somewhat similar to Angular, but you had the virtual DOM, you had a lot of the things that that React brought. And so, yeah, I've been using Vue for a long time. And then also, I took over running the Vue meetup here in Denver. Since then, we've transitioned to TypeScript, so it's more broader JavaScript. But I still love Vue and I still like, ESLint to the View I went to VueConf.

Yeah. I think your experience with transitioning from React to Svelte was basically my experience transitioning from React to Vue. Like, it simplifies things, there's less boilerplate, and so that's the biggest reason I was a big proponent for it for the longest time. I was just, like, why can't everyone just see how simple this is? Like, why why are we writing so much extra code with React? And then when Svelte came around, it was a very similar thing. It's like, yeah. This this looks somewhat like and, actually, if you looked at I don't know the exact version numbers, but if you look at Svelte what's the do you know what the latest Svelte version is? Is it I guess it's 4? It's 4. Right? Yeah. 5 before 5 JS the 1 the the it's in release candidate right now.

Okay. Well, correct me if I'm wrong in the comments, but I believe it was Svelte 2 looked exactly like Vue. Js. Like so the older Vue. Js had the options API with, like, the object and the data property and the methods property.

Svelte looked exactly the same. And then they they got, like, a simpler syntax in, I believe it was version 3, which JS interesting to see because then you saw Vue come along and introduce in Vue 3 TypeScript setup syntax, which also, like, simplified things.

I I'm just rambling at this point. I really like Vue. I feel like they they did a lot of things first, and it was just a a joy to work with for the longest time. And I think, lately, the reason I'm I'm choosing Svelte instead is probably because, it has a compiler and, like, it doesn't have a virtual DOM. And like you said, Vue is introducing a thing called Vapor, which will be opt in so that you can have more performant components that, like, don't use the virtual DOM. But it Wes interesting to see that Svelte gave us this less boilerplate, everything kind of built in experience, plus it was much more performant out of the box.

So, yeah, I I'm I'm excited to see all the stuff that coming out of, of Vue and also the contributors to Vue. That that was another sentiment that I got from going to VueConf is so, like, Evan, you also created Vite, and that's everywhere. Like, if you're doing something in the front end space, you're probably using Vite. And that originated with something for for Vue to to have a a faster build process and a faster, like, hot reload cycle. And then Evan's also working on a thing called roll down, which is written in Rust, and it's a like, a drop in replacement for roll up, but it's gonna be a whole lot faster.

So a lot of really cool stuff coming out of Vue ecosystem. And I think the also the sentiment I got going to VueConf is, like, Vue has just been quietly chugging along this whole time. Like, they they've been doing really cool stuff. Yeah. And they've been doing cool stuff and haven't got as much press, but at the same time, they've still been doing cool stuff and a lot of stuffs they did first. I guess this is the last thing I'll say on my soapbox here. But, like Yeah. Do it. Signals when when everyone started talking about signals, I guess it Wes, like, a year and a half ago, it was it was just, like, the craziest I I don't know if there's, like, a meme for this, but I'm just like, Vue has been doing this for years. Like, literally, they it wasn't called it wasn't called signals, but it was, like, fine grain reactivity.

And they've they they've been doing that since the beginning, and then they, I think I guess it was Solid JS that put the name on it. Maybe. I don't have the history of that. And Preact. Preact, we're big into signal. Solid,

Definitely. And I I think the I would hope that companies are getting away from these types of interviews just just because in my experience, knowing how to solve LeetCode problems is a completely different skill than what we do on a day to day basis. Right? So it's valuable, like you said, to Wes, like, does this person know how to program and, also, did they study LeetCode or LeetCode style problems? Because it's a it's a very specific skill set. So that's basically what you're testing. When you when you test someone on a LeetCode in interview, you're testing, are they good at solving LeetCode problems? You're not testing, are they good at writing software and, like, working on a team and and implementing features and communicating well and and all the other things that are important besides just being able to code real good.

So I completely agree. I guess, luckily, I have not had any Leakcode style interviews. A a lot of the the interviews I've had have been more, like, behavioral, but then also probably one of, like, the best technical interviews I ever had was they they dropped me into, like, a sample code Bos. They gave me an example ticket that would look like exactly what I would get on a day on the job, and they're like, let's work through this. How would you solve this? And to me, that was an awesome that awesome test because it's like, yeah, that's what we're gonna be doing day to day. So that's much better than just, like, trying to solve these kinds of problems. Yeah. I will say right right now, though, like, if you are a a student or if you are job searching, it is a necessary evil. Like, there are there are so many companies that use this as a gate that you basically have to know how to solve these kinds of Wes, or else you're you're not gonna get a lot of these jobs that, otherwise, like, you're doing other types of things there, but still, it it's something that you have to do for whatever reason. Yeah. I I don't know if you have any preferred

as an interview thing, yeah. Yeah. It's, yeah, it's iffy. I completely agree. I think one thing I'll add there is, like, especially if you're a newer coder, Node Warp is definitely a much easier on ramp. So if you look at LeetCode, like, it goes from 0 to 60 really fast. Oh, really? I know for a lot of people, it it makes them feel bad, like, oh, I'm never gonna be able to do this job. Like, this this career isn't for me or coding isn't for me. But Node Warp, specifically, they are they they start much simpler. Like, you can learn, like, basic language features, get more familiar with, like, built in methods and stuff like that before you're diving into, like, the the more complex problems. And the other thing I'll add is Leetcode has a a heavy, heavy lean towards writing performance solutions. But performance solutions are not always the most readable solutions or, like, the best solutions. And in the real world, you're writing code to communicate with other people, other developers. So typically I mean, sometimes, of course, most performance solution is what you want, but most of the time, you want something that other people can read and understand and and add on to without

desktop applications and now mobile applications with Rust and JavaScript web tech. You can actually build something that's cool with it. You can build a desktop app, and you can still use Svelte or React or Vue or whatever you'd like to use. Definitely. I can I agree? Like, I have a little bit of experience with Rust. But I think, especially in the world of web development, a lot of these build tools that we see are being written in Rust. And so that's act actually a good potentially bridge there is if you learn Rust, then you can also start to contribute to some of these build tools and other stuff in the front end space. I would say my choice here would be something like c sharp.

Oh. And yeah. And I I I don't know if this is a hot take or not, but I think c sharp is just a better TypeScript.

Like, TypeScript TypeScript is trying so hard to be C Sharp and was actually created by the same, author, Anders Helzberg. He wrote TypeScript. He also wrote C Sharp. And so that's where you see so much so many things in in TypeScript that that originated in C Sharp.

And, but C Sharp is a a statically typed language first. Right? There's there isn't all this dynamic stuff that you have in JavaScript. And so I also think that learning c Warp would make you a better TypeScript developer because it's like a a real static type system.

And and you can do a lot a lot of, similar things, like so they have the .net Maui project, which will let you build desktop apps and mobile apps all with c sharp.

You can build back end web APIs with, like, ASP .net and ASP .net JSON API. And then there's also Blazor, which I haven't explored. But that basically JS, like, c warp and they have, like, this custom template language, but it actually compiles into Wasm. So you're not writing any JavaScript, you're just writing this c sharp and, like, template language and then everything that would need to run on the front end actually gets compiled to Wasm.

So I'd say, yeah, def definitely check out c.

Yeah. But I I do agree that there's a lot more more jobs there. Not more, but there are jobs there because it's it's used in enterprise. Like Mhmm. We see a lot of, like, startups that, like, use JavaScript and TypeScript and, like, the the latest, in fashion tech, but a lot of, like, legacy code Bos and, like, bigger companies are are started a while back, so they they naturally chose .net and and c sharp and stuff like that. Word.

Alright. This next one comes from debug. I guess it's their name. Yeah. I have trouble with learning too much. Nope. This isn't a Michael Scott interview where my weaknesses are I work too much. I have chronic issues with not finishing a project because I learned something new. I currently only code as a hobby, so this isn't an issue. I'm excelling quickly at new things and learning, but not completing some projects. Is there a point that I should stop learning and start making? Yes. Right now. Now is the time. You ask the question right now.

But I think, potentially, I I don't obviously, I don't know your your workflow. I don't know how you do things. But for me, what helps is some sort of, like, project management tool. So, like, a a Kanban board or like a Trello board or something like that.

Because I can kind of lay out, these are all the things that need to be done. Here's what I'm doing. Here's what I'm blocked on. And you get a a much better picture of, like, what needs to be done so you can maybe make a plan for finishing that thing and, like, putting a nice little bow on it and and, not just, make new projects and forget about your old stuff. So, yeah, I would say some kind of project management thing might actually help. And I think in general, the best way to learn is to do. Right? So, like, you separated, should I stop learning and start making? To me, making is learning. That's how I learn most things is is by doing. And so if you can turn all of these little projects into or and they might already be your your way of, like, learning that new tech or or learning that specific style or, way of doing things. You can kind of, like, learn as you go, and then and then it's it's beneficial for both learning and also creating something useful.

software development is is basically just always that walking that line and finding that balance. And I think this kind of even gets to to the first question we talked about in terms of, like, how complex TypeScript can get. Because Yeah. A lot of times at least what I can see, some of especially some of the chatter on on on, x about TypeScript and stuff. It's like it just and also some of the chatter about React, now that I'm linking it all together, a lot of it just feels like engineering for engineering's sake. Right? Like, we have this, like, super complex, like, reusable thing, and and it's like, sure. Like, is this code gonna exist for a long time? Does it is it going to need to be expanded on down the line? Like, is it going to be need need to be reused in a specific way down the line? I think that's that's actually, like, a huge indicator of, how nicely written and and reusable and expandable should it be.

Because so a Scott of the the stuff that I've done for, like, side projects have have been on Coding Garden in my livestreams.

And for most of those projects, I kinda just treat it as throwaway code. Like, every now and then, it's kind of fun to do, like, engineering for engineering's sake, but if I'm just trying to solve a specific problem, I try not to think about as much like, well, is should I refactor this and remove the duplication and and everything else? But if I'm working on a project for a client and and it's gonna have a lot a long lifespan, I'm absolutely thinking about that as well. I think the the other aspect is depending on the kind of software development that you do, budget and timeline are some things you have to consider as well. Because if you're working at a consultancy and you have a super tight deadline, you're not gonna have as much time to write the most well crafted and reusable Node, like, you're gonna have to cut some corners. And so that just comes down to to business and and money and and economics.

But, personally, I like to be pragmatic about it, and I honestly am guilty of doing, like, engineering for engineering sake. Like

Oh, can you go first? I'm gonna just look through my Yeah. Quick. I can also

That's super sick. And thanks for bringing this up because I used to have these installed probably, like, 3 years ago on a laptop, and then I forgot about them. Yeah. But I just set up just set up a new MacBook, I'm definitely gonna install that. Those those are awesome. Yeah. For sure. I have I have a couple sick pics, but these these are just for, like, my workspace and workflow. First of all are these headphones. These are the Sony WFC CSS n.

headphones and headphone quality and stuff. Like, I was using just headphones that come in, like, back in the day when they would give you headphones in a box from a phone. I just, you know, I never paid attention to them. But I wanted to find some some good noise canceling wireless ones. These are great. The audio quality is awesome. I took them on my recent trip, and so the noise canceling on a flight was amazing. I've never had such awesome listening experience when a when on a plane. So they're they're about $100.

They're they're legit. And then the other desktop work area stuff is a widescreen monitor for editing video. I I guess I won't even mention the the version. Any kind of widescreen, I'm sure, would work with this, but, like, I was editing video just on my lap laptop screen for the longest time. I never really was a, like, Vercel monitor kinda guy. But the ability to see your timeline when editing a video on a widescreen monitor is actually really useful. Yeah. And, like, I could I could see, like, an hour, 2 hours without having to, like, zoom way in. So, yeah, nice wireless headphones and a,

shameless plugs. Let's go ahead, and I'm gonna plug the Syntax YouTube channel because CJ has been doing some incredible videos over there, and he's gonna be putting out some more. What do you got on the docket for us, CJ? Anything you can reveal? Yep. So it'll probably already be out when this episode comes out, but I'm working on a a recap of React Conf. So I'm, there Wes 2 days. It's like 16 hours of video, but I'm just going through picking all the interesting things, and I'll give you a a nice distinct recap of that. And then I'm also, working on building an app using some of the the lo fi tech that Scott and Wes talked about in a an app, an episode about local first apps. So those are in the pipeline.