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

Welcome to Syntax on this Wednesday tasty treat. Man, I'm so used to saying hasty treat. On this Wednesday, hasty treat, we got another potluck for you today. And with us today is CJ Reynolds. CJ, how's it going?

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

was, underneath the, like, the garage overhang when the hailstorm started, and and she was just like, I'm not going out there. So I had to, like Yeah. Run out in the hailstorm and pick her up and, you know, cover her while we run back in. Yeah. Luckily, no damage. I should give a a a notice here. Wes is out because he's having or had his family had a baby.

So, yeah. Big big, congratulations to Wes. If you see him online, say congrats.

They just had their baby JS the time of recording. This was just yesterday. So, we brought in CJ. We decided we're gonna do a potluck. You may see him for a couple episodes here and there based on the time we're recording these, just because Wes is out.

So with that all said, if your code JS caused your website to be out, maybe your code had a a baby unexpectedly and your website went down, you might wanna know that. And to do that, you're gonna use a tool like Sentry to make sure that you have visibility into what is going on in the life of your Node. Because let's let's face it. These things kinda have a life of their own. They're, going off and doing stuff, and sometimes they break. And we wanna know when they break, how they break, who they're breaking for, when they're breaking, how many times they broke, and what are the implications of all that are. So if you wanna know all that stuff, head on over to century.ioforward/ syntax. Sign up and get 2 months for free. It's the perfect place to gain visibility into what's happening in your application.

Okay. With that long intro out of the way, we're gonna be doing a potluck today, which means that you submitted Wes. We give you answers. We've got a whole bunch of answers here, and some of these, we even went back in the vault. I found some questions from 2022 that were really interesting given the current timeline of things that we've been talking about today, and I thought we would sprinkle in some of those, but also it's just a good opportunity to get a new voice in here with, CJ being here. He has a different outlook on some stuff. So I I think these are episodes are great to bring CJ on for.

So, CJ, you wanna take the first question here?

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. And and it's funny. I I do actually personally write a bit of generic or even, like, complex type stuff. But, again, it's mostly when you get into library code or really reusable things. I think the most complex typing stuff I had to do was with our caching system because it it it you passed in a very specific list of different types of Prisma operations. You type in the query parameters, not like query params as we come to know them, but the parameters for the Prisma query. But those have to match up very specifically with which Prisma function you're even passing in in the 1st place. Sanity got really messy really quickly, and it it does it you can get into hell, fairly fast with some really complex typing stuff.

And another, like, really kind of weird thing I've noticed in the TypeScript community is that, like, the the answer to complexity oftentimes in the TypeScript community can be more complexity, which is like I I I kinda hate that.

Yeah. There yeah. So for those reasons, I do understand exactly where people are coming from when they talk about TypeScript to being complex. At the end of the day though, it does save my bacon more often than it does not.

So learning the complex TypeScript stuff can be useful if, of course, you're writing, especially types that need to be reused in that way. But I would I would personally invest the time to learn this stuff, especially because of how it can make your life a little bit easier here and there saving yourself.

But I think one of the thing that that does get lost on people sometimes with TypeScript is that TypeScript to me functions more of as like a fancy linter than it does Mhmm. A you Node, I I think some people are just like, if your TypeScript ESLint passing, then your code is bad. But in reality, it's just like it's an alert. It's saying, hey. There's a potential issue here. Not that there is an issue. There's a potential issue here. And as long as you're looking at it from that that perspective of, hey. It's it's alerting you to where things could be going, then that kind of takes the pressure off.

You can leave maybe potentially messy TypeScript situations JS long as you've tested the code and know that they work. You could throw some ignores or some any's on there, and, hey. I'll come back to this later as long as I know that the code works. But, again, at the end of the day, I think it should be viewed as a fancy linter.

I actually sorry. I'm a little bit rambly here, but I I was talking a little bit about this stuff, on Twitter the other day because I was getting into JS doc style typing, which JS, for those of you don't know, it's using TypeScript. So it's not not using TypeScript. It's using TypeScript, but you're typing your code with JS doc style comments. And, really, what I was really admiring about the JS doc style typing is that I can write library code. I can write my types and do all of that without a compile step, which just Wes you when you're dealing with a library and you have your exports and next thing you know, you Scott a build step, that just adds a whole layer of complexity Wes GitHub that, I could just point my package dot JSON directly to my source file instead of having to have a dist folder with generated types, generated JavaScript, and all that stuff. And I was admiring the simplicity of that. So sometimes when DHH talks, it's like, I think you're being a little little simplistic here.

He's talking about throwing the baby out with the bathwater in in terms of types. But other times, I'm like, yeah. Yeah. There it's there are there are certain points that he does make that I I agree with and other ones that I think that I I think are maybe a little bit too far in that direction. I think I may be in the 50% of that percentile there in terms of DHH to, TypeScript themes. I'm kind of right in the middle.

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

you ask for teammate help if your your org doesn't allow you to do that type of thing. But me, personally, yeah, there that when when you start really delaying, like, spending a whole day trying to fix types, that's when they get, you know, table flipping mode.

Yeah. Next question from Nicodemus.

This was an older question that I brought back from the vault, that we didn't answer at the time. It says, concerning the fact that we have SvelteKit, does Svelte with ASTRO serve any additional purpose? And I thought this was a better question now than it was when it was asked. Because when this question was asked, ASTRO was still a static site platform, and it's since grown to be a real more full stack platform.

Does Svelte with Astro serve any additional purpose? I think it does. Personally, I think there's value there. Astro does some things very well because they they have their whole islands architecture, which you could debate if islands is the right word for that. Either way, not gonna go there. I I think the things that Astro does really well is is that in simple situations, you have, like, a non hydratable path where it's just a static path.

It does that stuff in a way where JavaScript gets out of the way, And I like that about Astro. It knows when to tell JavaScript to buzz off and just to serve the app what it needs.

In addition, I do think Astro pioneers a lot of, like, really interesting techniques for, in general, working with your application.

I love the front matter business or Wes they're able to, store metadata about files or have script aspects of files within a file just by denoting it as as front matter. I think that's really great. Also, man, how how good is the Astra CLI in, just general tools around Astra? I think the the team is fantastic. So I do see this as a, a situation where they can both coexist and still be useful in different ways. That said, I'm mostly reaching it's funny. I I also put this question in here because CJ and I just had a conversation about this yesterday.

I I am reaching for SvelteKit 99% of the time because that's where I'm most competent, and I can get a lot of stuff done there very fast.

But if somebody were to give me an Astro site with Svelte, I would be stoked.

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,

JS that it's very similar to how Svelte does it in SvelteKit.

There are endpoints. So the concept of an endpoint, let's say, inside of your your page's directory, you you would have essentially a file that would have a Scott JSON.ts, And that .json.ts would reveal what that is route is going to be returning. It's gonna be returning JSON.

And they're just like SvelteKit.

You would export a git function. So you export function git. And then, therefore, anytime you hit routes to that path, that with a git request, it's going to return the JSON that you're returning from that function, which is exactly how SvelteKit does it. So Mhmm. Yeah. Astro folks, please correct me if I'm wrong. But as far as I know from going over their docs, endpoints are very, very, very similar to how API routes work within SvelteKit or endpoints as they're called there too. So I think they're they're very, very comparable.

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,

there are 18 characters between the I and the n. So I'm gonna be real with you, CJ. This is the most real I've been on this show. I did not know that. So thank you for giving me that. I did not know that was, like, an allied situation.

I I thought I pnpm n stood for something, and I never looked into it.

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

I gained comfort from when doing these show notes with Wes, and and I was a little bit anxious when doing the show notes with you at CJ with, is that when Wes and I do it, we're both spelling words wrong constantly. And when I read a word spelled incorrectly, I'm just like, yeah. That's fine.

Yeah. And so I was like, CJ, can I judge my spelling here? I'm gonna have to fix my spelling errors.

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.

I'm I'm glad you took that one. I've done no internationalization as, evidenced by my not knowing what meant. But, Yeah. Super interesting stuff. I I think that answers a lot of questions I have about it, so thank you for that. Next question here from Alan. And, again, this question was also from 2022.

Think this one is interesting given all of the recent changes in React land recently because I think I would have a different answer to this question in 2022, and I think my answer today is a little bit more relevant.

So the question JS, you've both mentioned a few times now how about 2020 two being the year people start to fall out of love with React. Side note, I think that, has been fairly prominent discussion.

Are you 2, especially Wes, now I'm gonna say especially CJ, counting yourselves in that group that are falling out of love with React, do you intend to phase it out of your work in the coming year? Okay. So I wanna answer this from the perspective as somebody who stopped writing React a long time ago.

So I I background here. I'm not a React noob. I started writing React in 2015, maybe before that, right when it was announced. It was, like, right when it was announced. We watched the, the the conference release of it in that day. You know, we were exploring options with React and and I was working mostly in Angular at the time. And it all felt very unusual to me. So I've been working in React a long time. I've released a ton of courses on React. I've built many actual production applications in React, React Native, you name it.

And I have stopped writing React since I picked up SvelteKit. And even before then, I picked up Sapper and was, like, into Sapper a bit. But when when SvelteKit dropped, I Wes, like, I rewrote my platform, which was level up tutorials in SvelteKit. I chose to write syntax, our syntax website in SvelteKit, and I just prefer the simplicity of Svelte overall.

So I have not worked in React in a long time.

So did I follow out of love with React? Absolutely. And I do wanna say, I I might not have never been in love with React. It might have been a Stockholm syndrome situation.

I Wes had to use it, so it was the thing to use. But now that there's other options, view svelte even solid, I don't think I would pick up React again anytime soon. That said, man, I think React is moving in a positive direction, which is maybe the first time I I I can say that in a while. I I think in the in the past, the direction that I Node React going was, alright. We have a bunch of issues. We're just gonna throw more hooks at it, and, it's just gonna increase the complexity.

We're gonna increase the complexity, but it's gonna solve issues that perhaps we we created.

I think my my beef my biggest beef with React is still virtual DOM. I prefer the real DOM.

But adding a compiler so we don't have to worry about performance optimizations.

Hey. I that's one of the top reasons I like working in Svelte. Never having to think about memoizing or use callback or any of that stuff was a huge huge bonus for me. I think the use hook does simplify things rather than having to think about which hooks I'm using all the time.

I think form actions are the right direction given that kind of literally everyone else has moved to form actions before React. So I think it definitely is the right type of API. I do like server components. I think being able to access the server that easily inside of a React component is a net win in simplicity overall.

So I think as long as React continues to move in the direction of simplicity, I'll be stoked with it. The reason why I'm not using React in 2024 with these things is that I like the real DOM. Node, gotta have that real DOM. Being able to use the real DOM is great. Granted, React added web component features, ability to use web components that kinda solve some of those issues, but still being able to write actual native DOM APIs without having to think about how the framework is gonna respond to it is a huge win for me. So the reasons I'm not writing React is, 1, the dom. I like the dom.

And 2, I don't like JSX. I feel like I take crazy pills when everyone talks about how great JSX is. I I straight I'll die in that hill. I do not like JSX. So I prefer Svelte. I I prefer that that situation. But what are your thoughts on React in 2024, CJ?

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,

more easily performant. Yeah. I I I a 100%, I'm with you. Yeah. It JS weird because, like, I feel like I have I gave up I gave up a I don't wanna say, like, I I gave up a a huge chunk of audience that I could have had on my YouTube channel, which is now Syntax's YouTube channel where you're watching this. But I gave up a huge chunk of that audience to move off of React. It's like Yeah. I yes. I could have stayed doing all React content all the time and probably gotten a lot more views out of it because of how many people are are viewing that stuff. But I just like you said, I never loved it. It's it wasn't it wasn't something I I really was passionate about. And, Yeah. I'm I'm I'm very content not writing React, and it's fine. The water's fine. Come on in. Yeah.

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

that Node is going to get something similar. Like, how does that feel to you?

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

yeah. Yeah. It's interesting. And it is funny with with Deno, there was, like, a point where it felt like, perhaps, you're recreating the package dot JSON just by Yeah.

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,

registry or pay for private hosting or whatever else. Yeah. Totally. It's, it's interesting for sure. Alright. Next question here from Daniel. Daniel says Vue. Js syntax looks almost identical to Svelte. Why would you prefer Svelte? Wes, I love your podcast. Thank you. Now, Daniel, this is the 3rd question, and I'm gonna say probably the last one that we had from the archive. But I do think it's interesting given where we're at.

Specifically, CJ just got back from

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

So I personally these are my thoughts. I use Svelte because it took 1 more step into the the direction of simplicity, than I felt like Vue did. Also, the virtual DOM was a thing with Vue. I know that there's some potentially changes there of which I'm not up on.

So, CJ, given that you just went to Vue Scott, I I'm more interested in your opinion on this answer than I am my own.

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,

Mob Yeah. X Yeah. Did a bunch of signal stuff. But, yeah, definitely definitely, View View is super early in that game.

Yeah. So they're they're early to a bunch of stuff. They just don't have as much press about it, and they're still cool. I would say give Vue a try because it's it's awesome. Yeah. And Evan Evan is some you know, someone I've been a huge fan of since the Meteor days. So when he he started Vue, I I started paying attention immediately. I'm actually in the Vue documentary. So I I'm definitely a big Vue fan. I just haven't been writing it since I picked up Svelte.

But it's it's fantastic.

It it's it's good. And and if if there Wes, like, a, I don't know, alternate universe, it does feel like, man, you really should be the number 1. And, you know, that that's just yeah. I that's where I'm at too. Alright. Hackerman hackerman 1337 says, hey, guys. Have you ever discussed leetcode type interview questions? I can guess you probably aren't fans of them, but I don't recall any discussions. I have done leet code interview questions before.

And me, personally, some of them I've done really well on. Some of them I've completely crashed and burned on. And the difference between me crashing and burning or doing really well isn't always necessarily if I could do the problem on my best day.

It's that some days, your brain just does not work as well as it does on other's days. And you get put into an interview or, heaven forbid, you get put into a LeetCode interview without being told you're going to be doing that ahead of time, which happened to me before.

And your brain is is just not there. I had an interview, CJ, where, it I was told it was just going to be a quick chat with a, their their technical lead. And and I get to this quick chat, and they're like, alright. Open up this website.

You cannot use docs, and here's what we're coding. And I was just like, can I just leave this interview right now? I don't wanna be doing this, and I don't want this job anymore if this is how you you're gonna you're treating me. So I do feel like it depends on how these things are presented. I think they can be useful. They're a useful filter at a a base level. I had a LeetCode example presented to me for the very 1st round of my Google interview, and it was probably very useful in them just saying, Wes. He can do this. Okay. Let's move on. But I I think that's where I draw the line. Personally, I think they're useful in a filter, but maybe not perhaps a definitive judgment on someone's abilities or skills.

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

LeetCode, websites. I did Coder Warp back in the day when I was, like, practicing this stuff.

And like you said, it is a skill onto itself because the one thing I noticed is that the more I did Coder Wars, the better I got at Coder Wars.

A Node Wars.

Code Wars. Yes. Code Wars. Yes. The bet the more I did the more I did Coder Wars yeah. The more I did Code Wars, the better I got at it. Yeah. But I don't necessarily know how much of that stuff I took with me past just being good at it. But there are ways that it can feel fun.

And I think the the more interesting thing about Node wars or any of these leak code things is not from doing the leak code stuff yourself, but looking at other people's solutions. Because, yeah, you can you can solve a problem. You can get it done and you can okay. I figured it out.

But then to me, I always thought the real learning came from when I looked at I it took me not even just lines of code, but it took me these different techniques, and I had to use several different things. And this person came along and did it with 1 method that I wasn't aware of. Oh, okay. Let me that that's great. I've they've now learned a new method. So, I I do think there are are there are benefits to doing that kind of stuff. But, again, it

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

having to spend too much brainpower. So Yeah. Sick. Cool. Next question here from Polygot wannabe.

I want to learn a different language other than JS and TS. My main stack would be still be JS and TS since I'm a front end developer. Ideally, the language would complement my web development in some other way. The main goal is to have a new language that I could use for web development or one that I could teach me concepts to become a better JavaScript or TypeScript developer. Which one would you recommend exploring? I think the answer here for me is Rust, not only because that's what I've done personally, but let me give you a a personal anecdote about Rust.

The the best thing about Rust beyond the fact that you you can, like, pretend like you're, you know, elite programmer, but because you're using Rust, is that the type system is so analogous to TypeScript that I got I got to be a much better TypeScript developer because of using Rust's type, syntax.

And it's similar enough to JavaScript Wes you can feel like you're picking up things that will be useful in JavaScript and TypeScript world. But it does give you a different outlook on writing software that is guaranteed to work. And the the the there that said, the Wes compiler, Rust will will not let you run your code if there is a tiny little issue with any of your types. And because of that, it can feel very frustrating to pick up. But in the same regard, it gave me a lot of perspective on writing good TypeScript because the type the types that you're writing within Rust have to be good or else your code does not run. So, yeah, I would say pick up Wes. And if you wanna implement stuff that you can actually utilize in your day to day web development world, Tori, which is the platform for building

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.

And I think I mean, I think with the whole .net world, there is there's jobs out there. That is something that you could I mean, there's jobs out there for Rust, but I I think .net is just bigger. I I could be basing them on nothing, but it it does it's definitely been around for a lot longer. So, man, that's pnpm area. That is a huge blindness that I have in this space JS anything related to c sharp, .net, Microsoft, anything is like Yeah.

Yeah. Never never touched this stuff for some reason. I don't know why.

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.

Yeah. I I think, and that that's all very super good. I think that all all tracks. I'm very much of the same type of person where it's not that I don't stop learning. I mean, it's my job to learn stuff. So, you know, for me, it's not my job to to make things other than maybe perhaps the syntax website. It's my job to learn stuff. So I I have a little bit of an out there. But, I think my advice to you is to bite off smaller chunks of projects when you're choosing to learn. I'm gonna shout out an example.

Shout out to myself. I recently did a fluid type generator in Svelte five, and I made this for two reasons.

The type scale generator that I used to use went behind the paywall.

And instead of paying for the paywall, I said, you know what? I could make this myself. It's not couldn't be that hard. How hard could it be? It it was, you know, 3 Svelte files that are not very large, and, you know, I only needed to do x, y, and z.

But, also, I wanted to be a little bit more modern in certain ways. So what did I do? I use this as an opportunity to learn the math behind fluid type. I learned it to use the math behind type scale in general, and then I also use JS an opportunity to learn new CSS techniques. I'm using viewport ESLint units instead of viewport with units. I'm using so VI units. I'm using really complex math and clamp to create TypeScript that works correctly. So I had to learn the techniques behind how you can utilize clamp in a way to have fluid type. It's more complex than you can imagine. I had to do math. I had to write functions, several linear algebra functions, who knows, for all this stuff to get this to work. And then I I got to learn some really neat techniques about line height that scales down as your font, size scales up. So there's a lot of interesting little techniques.

But at the end of the day, this was a small chunk. This project could be completed in it, for me, a day, less than a day. A nice little thing. I still got to learn things. I got to learn some interesting new Svelte five techniques. Now I've been working with Svelte five a bunch lately, but it gave me an opportunity to explore a few more things.

And at the end of the day, I had something. I got to push it out. Now I don't have to touch it ever again. It just exists. Right? So I think biting off smaller chunks for the projects that you choose to work on is a good way to make sure that you actually finish them. That that's my advice there for you. Yeah. Yeah. Completely agree. Yeah. Last question here from Eju Pasqualetti.

I'm so sorry about the pronunciation there.

You didn't give me a pronunciation guide. What am I supposed to do? Okay. Next, the question is, can you discuss code quality Vercel healthy pragmatism? Which JS, basically, how much time are you going to be spending on code quality, making sure your code is pristine Vercel, being pragmatic in how you solve problems and being efficient or those types of things. For me, I think the answer of this comes entirely down to how many people are working on this thing and for how long will this thing ESLint.

If this project exists for me to work on and it will exist for who knows how long, you know, I write it and then I'm done with it, use that that type scale example I I mentioned just a 2nd ago. I'm not really thinking about code quality. I am thinking about it to the extent that I have muscle memory, and I do things a certain way. Like, I'm not using Boolean state values. I'm using state machine type of, you know, status values and stuff like that.

I have just ways that I do things, but I'm not abstracting to hell. I'm not really sticking to these these hard naming conventions or things. I'm not having to worry about how other people are looking at this project.

So for me, I think it's important to know what is the lifespan of this project.

Are the people who are gonna be working on this 20 years down the line, are they going to need to have the systems in place, for this thing to work the same way that it does today, years in the future? So that that's that's my thought. How many people are working on this thing for how long? And then I can kind of adjust my slider in terms of how quick and dirty do I wanna be Vercel how clean, abstract, dry do I want to be. Yeah. Completely agree. And I think

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

but I get that. But yeah. Yeah. You know what? I you know, man, I I think that that point about the money stuff is really poignant because just in general, man, I used to work at a startup before I did level up tutorials and, well, it was kind of while I was doing level up tutorials. But I worked at a startup, and we had a very short runway to get a prototype out the door to search for investment. It was like, how can we get something that we can show off to show that proof of concept, this thing is cool, and it will work? And I I did it in, like, what, several several months, not that many months. And I I was the only dev on it, and I was just breezing through it as fast as possible to get something out the door.

When the Scott up collapsed because the founders of it were awful, they they eventually gave my code base to someone else to continue the project.

They were upset with me because that person who they gave the code base to said, Wes. This is a lot of prototype code and not a lot of application code. And they were like, I thought you were building us an app, and you built us a a product. Like, what we were building explicitly was a prototype.

You know? If if you would have given me more money and more time, we could have done it in a way to make this project have a longer lifespan, but that's not what we were building. So you you gotta know what you're building and and what the the, situation is there.

Definitely.

Cool. Alright. Well, that is an, that's an episode of syntax here. Let's get into some sick picks and shameless plugs. I know I I kind of, sprung this on you short notice, CJ, but did you bring a sick pick? And I should say Wes sprung this on you, by the way. What I'm not gonna blame Wes' Wes's baby showing. Baby? Come on. Yeah.

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

happy to.

This is, I I have a lot of sick pics. In fact, I've been I've been cataloging a whole bunch here, so I'll have a a bunch of really good ones coming up. So I'm trying to find the best one here. Here's a here's a good one. MacOS has a feature called quick look, where you hit space bar when you're on top of a file, and it pops open a quick look into what that file might look like.

This is pretty good, except for it feels like they made it 10 years ago and have, like, forgotten about it because it doesn't work with a lot of new file TypeScript, Wes m and web p, that kind of stuff.

It it's just missing a lot of features, in terms of modern stuff. So I have a repo here that I'm gonna be sharing with you, which is quick look plug ins. Somebody, compiled a list of all the best quick look plug ins, and you can install them all with 1 brew command.

But what this gives you is when you quick look at a code file, JavaScript file, you get syntax highlighting. You quick look at in a markdown file, it shows you the markdown rendered.

You quick look at a zip and it shows you the zip contents. Imagine that. Also, you get new new, image formats.

You get new video formats, so you can look at video formats. And there's an intense one called peak that's like a paid product that, like, basically, the quick look opens a mini little text editor, which I'm not using, but, it's kinda neat. I I didn't realize there was a whole world of extensions to quick look out here. And so I installed these the other day. And just an ambient thing in life that makes oh, you you quick quick look at a a web web p file. Oh, you can now actually see it. So that's great.

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.

Sony's Node, Xceva. We we the over the Yarn ones before, and we're like, the w x and oh, yeah. Yeah. Yeah. But there so I never I never actually paid much attention to, like,

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,

a widescreen monitor are my sick pics. Nice. I used to work on an ultra wide, and that was, like, my favorite feature in the world of it Wes the long, long timeline.

And Node, I believe it or not, CJ actually use the VisionPRO for this, which, I haven't talked too much about on the show, but I I I I am a VR kind of guy. I like VR stuff. So I I got the VisionPRO, and I you can make giant monitors. And so I'll I'll do that. And one of the main reasons I I use the VisionPRO as a secondary monitor is to get a giant ass monitor for, my timelines. Yeah. It yeah. Definitely definitely great.

Cool. Well, thank you so much for those. I I definitely, thank you for filling in, for for Wes here. Yeah. You never know when someone's gonna have a baby out of nowhere.

So

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.

Sick. And if you just wanna see any episode of Syntax on video, we are there. It's youtube.comforward/atsyntaxfm.

That's all I got for you today. Thank you so much for listening or watching wherever you are, and we will catch you in the next one.

Peace.