What Happened to Remix. Worth Using Axios? Client Only Next.js?

Welcome to Syntax. Today, we got a potluck episode for you, which is got some really good questions. One on, like, where does HTMX fall short when you need to, like, hop to the ESLint, and what's the best approach to that? Should you be using Next. Js for a website where you don't want the back end stuff, or should you be reaching for something like TanStack or, React Router seven? Accessing third party functions inside of a node module that doesn't export them, how do you do that? Database hosting compared. Axios.

Someone's mad that we're we're hating on Axios, so we're we're gonna fire back at that. And finally, media queries. Should you be using the Chrome DevTools, like, phone sizes in there? And, also, how small should a media query go? All of that and more.

Welcome. My name is Wes. I'm a developer from Canada. With me JS always is Scott. How are you doing today, Scott?

Hey. I'm doing alright. Back in action here. Feeling feeling pretty normal. I don't know, if you revealed to the audience what happened about my Yes. My accident. But yeah. Yeah. I'm all good, man. I'm, you bumped your noggin. Well, tell us what happened. You you were carving up a mean sash? Yeah. Yeah. Yeah. You know what? I I've been I've been snowboarding a long time, like, since I was in the sixth grade maybe, so I'm super experienced. And, yeah, I just I was just riding and, woof, you know, landed in a way where the the back edge caught my board on a steep edge, like, super steep edge. And so because of the fact that it was so steep, when you catch your edge like that in snowboarding, it really just throws you. It can throw you hard. Right? And and Yeah. I wasn't prepared to catch my edge. So when I caught my edge and I was on a steep thing, what it did is it threw me back. But since the incline was I'm I'm not kidding. It was it was steep. What it did is it caused my body to fall kinda like like a whip. You know, you whip a towel. Yeah. And that whip just ended with my head slamming in the back, like, the back of my head into the ground, which was pretty hard. And, my helmet flew off, and and then I was just like I I didn't get knocked out, but I was just on another planet for a bit.

And it was, yeah, it Wes, you know, I've had concussions before. So the moment that I hit, I was just like, oh, this is bad. I'm in I'm in trouble here.

And, I I just needed to, like, take a moment to, like, you know, get myself back to normal. But I actually wanna tell a story about this. This is, like, pretty new. I was on the chairlift be like, earlier on in the day, and a I was talking sometimes you just get into conversations with people on the chairlift.

And I was talking, with this guy sitting next to me, and he stopped me halfway through. And he was like, is your name Scott? And I was like, yes. Are you Scott Zelinski from Syntax? I was like, yes.

His name is Brian, Brian Dunn.

What a cool guy. He he I I ended up riding with him for three or four runs, and he he took some video of me hitting some jumps and stuff. Just a a a cool Node. We just chatted the whole time. But, because I was riding with him, luckily, when that happened, he was right there and was like, let me let me, like, ride down with you. Like so I just, like, rode very slowly, and he followed me. So he made sure I got to the bottom, and then he would, you know, texted me and was like, hey. If if you can't get back to Denver, which I honestly couldn't, that he would, give me a place to stay out there and stuff. So Oh, man. Shout out to Brian. Yeah. Brian, was just really incredible. I ended up having a friend, drive me and the kids back because my kids were in a lesson, so I couldn't even drive. I was I was that out of it. So I had to have a a friend drive us back and had the ER and stuff. It was it was a a massive bummer. So if if you Node that, like, I'm not a % with it, I'd like this is my first episode back from some getting a little bit, but I'll, Oh, yeah. I'll fill in.

Yeah. Right. Totally. Yeah.

Wes we'll get ready to put the little buffers the circle over top of your face when you're When I'm just like,

yeah.

Alright. Well, let's get on into it. We got lots of really good potluck questions.

We'll say real quick, please keep the potluck questions coming. Go to syntax.fm.

And in the nav, there's a button to ask a Wes, submit it, and we'll answer it on a future episode. So first one from Ringo Starr. Hey, guys. Long time listeners, but I will disagree with you in this one. It's about Axios. I don't get why you rag on Axios so much. It's a central library used in every project. I don't care if Fetch has an OLED TV built in. I will still use Axios. Here are some reasons. One, interceptors.

You can always attach tokens to the Wes. So what do you do with Fetch? I create a wrapper to attach my token. Not everyone uses cookies for that, etcetera, etcetera. See, this this is kind of interesting JS if you are making repeat requests to, like, an API endpoint and you want to automatically attach something like a custom header or a a token via, like, an authorization or a bearer header or simply just tacking on a API key onto a get Wes.

That is a really nice feature of Axios Wes you can just sort of sort of set default. Right? Number two, errors.

Axios will throw an error if it is an error. No questions.

Mhmm.

That's fair. With fetch, is it an error or is it not? You gotta make sure, and and don't forget to throw. Number three, custom instances. I can create as many custom instances as I need. I never need to pass the full URL like fetch, so I can set a base URL and stop thinking about the route just as intended.

And he goes on to say the the away double away for for JSON response. Yeah. That that's certainly a thing. That first the reason why we'll say this real quick. The reason why fetch has a double JSON response is because the response is not always going to be JSON or text. It might be a streaming response.

You might want to check the status of the response before you go ahead and parse out the JSON.

There are lots of different reasons for that. Not to say that you can't use Axios for that.

We we even did an entire episode on this. Like, why would you still use Axios? Because Mhmm. I certainly understand why. I I took the position of there are many use cases for Axios.

Interceptors is another really good Node. If you want to if somebody, like, sends out a, a fetch request, you might wanna intercept that and make sure the token is valid or you wanna make sure that they're logged in. If not, you wanna redirect them. Lots of really good use cases for it. However, most people think that the entire library wait is not worth it JS well as the fact that an Axios request and response is not a standardized web request and web response.

And when we're dealing with things in the web and in Node. Js, having your requests to go fetch things be primitives of web request and web response so that you can use them the same across all of your projects and that you can pass them into other projects. Like, for example, Shiki JS, I was working with last week, and they use a Wasm instance to highlight everything.

And if you want to load the Wasm file from a different source, you simply just need to pass it a a web request. And how that web request isn't made, it doesn't matter. Right? There's there's many different ways that you could create a web request. So I'm a big fan of Axios and all of the features. And I think if you are doing any significant project, you certainly want to reach for something that is a little bit more like Axios or build something.

But I feel like every time I I hit a project that has Axios in it, like the OpenAI, I'm not sure if they still use it or not, but, like, the the stack trace, the console log, having to access the data, that's a little bit of a pain in the butt. You know? Axios, by default, uses HTTP dot request and then XML h t d p request. And now if just in the last, like, six months, they finally added support for fetch inside of it. So you couldn't use Axios on CloudFlare workers for the longest time, and I love it. I think it's a very important piece of technology. Just like jQuery, I think it's time to move along.

Yeah. Yeah. You know, I I'm one of the reasons why it could be saying that, like, I rag on it is because I never used it. So you can't, like, build a habit for something or, like, really see the benefits or something that you never used. And my my, like the way that I've always done things, at least since I've been making a lot of Wes, is with fetch or fetch polyfills or anything like that Wes that's just the way I've done it for so long that it it feels, like, natural to me. And before that, I did most things with, oh, man, like some kind of RPC system like MiniMongo or or some of these other things that were out there. So for me, it was just like, oh, well, fetch is just the way you do it, and I worked around its limitations, and that never really bothered me too much. Mhmm. But, yeah, I think it's just a I never got into the habit of using Axios, so I never, thought. But I, you know, I I guess I didn't know anything about those limitations that you mentioned either. I I think also, like, if you think about tooling and whatnot that will inspect

fetch requests, that's that's another big one.

There are some alternatives out there. Wes I o r. I don't know how you say that.

That's a very similar pack similar API. It's not a drop in replacement, but super tiny, three KBG zip. So has no problem throwing that in your in your package. Or, Kai, k y, from Sundre Sohrhas, similar package that has the whole idea

of interceptors and defaults and and base names. Nice. Yeah. Totally. Alright. Next question is from Mark Volkman. Shout out to Mark. In show eight six eight, Scott commented on how HTMLX is great until you decide you need some client side functionality.

Alpine pairs very well with HTMLX and provides exactly that. It is commonly used in HDMX, and I show many examples in my HDMX book. Shout out to Mark and his book. I have one of Mark's books on salt, so shout out to Mark. I guess my question is whether Scott feels that isn't sufficient.

I've yet to see a case where it isn't. So here's largely what I mean when I'm talking about what h t m x is suitable and not suitable for because I think it's just building different types of things.

HTMLX is good if you have a server and a web based UI that are tightly coupled in a way that the server is going to be returning HTML.

So the UI and all UIs that are associated with this server need to be accepting that same HTML.

So it works in the best case scenarios where you have an application that probably only has one UI, unless I I I would be interested to see where people are using, HTML back like a back end for HTMLX with multiple different UIs because with HTMLX, the server returns straight up HTML. Right? So the UI always has to accept that HTML that's coming in.

So it's good for that. What it's not good for necessarily is applications that need a lot of client side support, not via, like, interactivity, not like click this, move this around, but things like working with local data.

So let's say you're working with a local first situation where that data lives on the device on ESLint, that data is stored as JSON, right, or it's just stored as data. And HTMLX, again, it works best when HTML is being swapped in and out. But if you have that data coming in as JSON into your application, you need to parse and distribute that data into your application. And that's where something like React or or Svelte or Vue, in my mind, just makes way more sense for this type of thing. So HTMLX doesn't make sense for applications with a lot of local data, which is a lot of what I'm working on right now. It doesn't also make sense if your, API, needs to support lots of UIs, like a mobile app and the, Wes app and maybe something else, maybe even a desktop app or something. And maybe some of these are web based tech and maybe some of them are or maybe the UIs for these things are totally different. Because in that case, if the UI is different, the HTML coming in from the server isn't gonna make a ton of Right? Or you're gonna have to implement a ton of different server endpoints for all of the different scenarios. Or if it's a native app, you're not even dealing with a a HTML here. So the HTML is great for, web applications that need to swap out HTML in a way that makes sense with, like, one client per server. And, I think that in in that case, it works really well. I got no no complaints there. But, that's that's a situation where I'd see that. HTML kind of falls apart.

Yeah. I think Alpine is really cool. We had Caleb on the podcast to talk about it, and it works great. Server rendered web apps.

And if you do need client side functionality, you can sprinkle on JavaScript with that with, with Alpine JS.

Also common in the space is inertia JS. You know, you serve a render, and then you can pick it up with React on on the client side. We have Aaron Francis coming on, talk about Laravel Fusion, which is kinda interesting where it's like you build a in this right now, it's just Vue. You build a Vue app, but you could put PHP tags in the Vue app, and that that will run a lot of that that server side.

I think that those are all JS interesting approaches.

I just don't like having to switch my templating language or switch whatever it is when I decide this is server, this is ESLint, which is why I'm I'm a big fan of of React Vercel component approach or any literally any JSX or similar views felt library where, yeah, I can I can write this thing server side, but I can also just switch it to client side if I need to? And I'm not going to be switching any type of templating language from from one to another.

That makes Wes much sense. And, you know, I think the types of folks that really don't mind that approach are people who have been doing that for a while or have always written their templating language server side. Right? They're using Yeah. What is it? Like, EJS or,

one of those? Blade or or anything like that. And and that makes sense. There's there's lots of not everybody is building a full stack JavaScript application. Right? There's Yes. I would say most people are not doing that, and they don't have that ability. They they wanna build just a clean JSON API and then either return something on the server, some some templating, or they wanna do it totally on the client.

Yeah. There are I'm sure there are ways that you can use, JSX like things, or even probably JSX as a server side templating language for something like HTMLX. But at that point, I'm just like, give me the whole thing in one platform. Right? Yeah. Give me the just the self that that is the server side and the client side, whatever I need. I know you're working with JSON in some situations instead of HTML. I mean, other instances, there JS HTML. But, yeah, I I I just take the thing where, like you said, one templating language for the whole stack, and let me differentiate what's client and server. The tan stack approach to that, sometimes JSON, sometimes HTML,

is beautiful because your API endpoints can either return JSON or it can return a component, which is so so beautiful to me because, like, yeah, I can return the data that is needed for this piece, or I can just return the entire templated thing out. And it's simply a matter of switching, returning the raw data or a component that has that data.

Wes, well, shout shout out to Mark's book. I didn't realize he had written this, but it's called, Vercel Driven Web Apps with HTMX, from the programmatic programmers. So certainly pick that up.

Mark is a very smart guy.

Next question from Pontius. Hey. I'm starting to dip my toes in the local first water, and I'm tempted by the zero type of solution that Scott has been raving about Wes you bring your own database. However, I haven't had to deal with databases in a very long time, so I feel very unfamiliar with the current landscape. How do you guys host your databases these days? Is something like Supabase overkill when you have a sync engine on top. Ideally, I'm looking for something that is simple to set up and Sanity, but as long as I don't have to SSH and reboot Yeah. Every other week, I'm not that fussy. A free tier would be a big bonus.

Cheers. Yeah. This is kind of an interesting one because in the range of databases, you can go all the way to one side, which is literally a Linux server that you have a database installed on, and you can fire it up. Right? You install MySQL or Postgres or whatever, and you you're up and running. And then sorta in in the middle, you have these, like, services platform as a service that will offer you standards, MySQL, Postgres, something like that. We're thinking about, like, Neon or, what why am I blanking on what we use for syntax?

PlanetScale.

PlanetScale.

Services like that Wes, like, they'll give you a proper MySQL Postgres database, SQLite database, but they will host it for you. They'll scale it for you. They'll allow you to branch it. They'll allow you to fall back and roll back and all that. And then in on the very end of the spectrum, you get something like a, like, a supabase or a firebase or or whatever Wes it's you get so many features, but it's like you're building on top of that platform.

So what do you what do you think is the best approach when you're you're doing local first, Scott?

Yeah. It depends. You Node, it depends on what you want and need. But for me personally, I I've kind of gone in this direction where, like, my zero sites right now are mostly using Neon, but Neon has some quirks. It does connection pooling, which can be quirky.

Just the other day, I was running into some really obnoxious error, and it was because I copied the, pooling connection string instead of the non pooling connection string. Okay. Just just by chance, I just didn't see that checkbox. And because of that, you know, I was like, say, you caused me some pain. So, you know, there there's some definite quirks with the fact that it is kind of like a distributed database platform, but Neon is great. There is a good, free tier that really is pretty great. Neon has some deficiencies, though. There's no, like, automated backup system with Neon for some reason. I don't know. Oh, really? Haven't had it. It's it's weird. They're like, we have branching. I'm like, well, what about, like, the just let me have, like, a backup every day kinda thing. No. We got branching. Alright. But so what how do you how do you back up your your database then? You run a, like, a script

to to dump it or what?

Yeah. I do, because that's it. And then I'll I'll have it at a regular interval.

Yeah. But yeah. That's it. Well, that's a must have. That's

for me. If I'm paying for a database hosting service, the one of the reasons I'm doing that is because I'm scared I'm going to lose everything.

I know. I know. It's like Wes I I had my MongoDB set up for, for the level upside, I was just like, what's the most frequent interval I can have this backup for? Because I'm so paranoid about, data loss. So Yeah. Yeah. So, you know, I I do host things on Neon. PlanetScale is good, but there's also, again, some some quirks there, but it's a it's a great platform. These are these are kind of, like, things that are gonna be hosted for you. And, basically, you click go, and they give you a connection string. And that's great. That's it. If you are doing zero sync, it needs to be Postgres, and PlanetScale is just MySQL. So, Neon would be the the choice for that if you're choosing between the two. There's also some other options. You can honestly, you can host your own with Coolify if you want, but I'm not that I'm not that adventurous. I'm gonna say that. I'm not gonna I'm not into hosting my own database infrastructure, especially on, like, a a VPS through a managed thing. I'd just be so worried about losing data. Scott, typically, I know, like, many other people have the chops there to manage their own databases like that. I'm usually gonna run to a service. What I'm doing right now, Wes, is I'm moving my, HabitPath database to AWS right now. And yeah. Typically, that's the type of thing I don't wanna do because AWS has I was I was actually trying to show Courtney just how many, services are under AWS, and I was just, like, scrolling through that list. I was like, you wanna you wanna see why I'm stressed out about this AWS stuff? Let me just show you all these dang services I'm looking at right now. And she was like, holy cow.

But I'm doing it via SST, which is really dead simple.

So if you use a system like SST, which plays very nice with Xero. So, Pontus, if if you're doing something with Xero, check out just doing the whole thing in SST. I might publish some videos on that because I've been doing it. You can get your database from there. You can get your sync server up on there. You can get your UI hosted on there.

Everything in one fell swoop. You can haul I'll have it as infrastructure as code. But there's there are options for hosted, database hosts. So if you just do, like, hosted Postgres, systems, I'm sure there's other services that we didn't mention. The ones I've used, Neon,

now moving things to AWS myself. But, yeah, that's pretty much it. You know, one thing I really liked using a platform as a service for is they would let you know when there are slow queries, which is is another thing because, like, if your web app is being slow, part of that could be that you have written a a poor database query, you know, a weird insert or a weird query on something that doesn't have an index.

And I always like, like, a platform as a service that would tell you. However, this is a sponsored ad. We I was gonna say You are going to want to check out Sentry because Sentry has slow database query, and they will let you know when things are starting to get slow. It's nice. We can go into the syntax dashboard.

And, like, for us, we had we had something that never had an index on it. And, like, just over time, as the site got bigger and bigger and bigger, the query started to get slower and slower. And it one day, we got an email being like, hey.

This thing is is slow. Like, not like, we got an email from Sentry. Like, it alerted us. Like, oh, man. I should look into that. And I I went in and I added index, and you immediately see the query just drop off inside of your Sentry. So if you're running Sentry on your app like you should, maybe maybe you don't need a platform as a service because that's that's one of the big things I was using it for. Check it out. Sentry.i0/syntax.

Yeah. And you can like, by all means, you don't have to do one of these fancy services. There's a lot of hosts and hosting platforms that will just have Postgres offered, even Heroku. Right? Super simple, that type of thing. And another thing that we didn't talk about is, like, your database being close to where your web app JS, because that is a potential

for slowing down your app. If your your code is running in one spot and your database lives somebody somewhere else, there could be latency introduced there.

Totally. Yeah. Next one here from your number one fan from Estonia. Nice.

Do you by the way, Wes, you ever see the movie Encino Man?

No. No. Haven't seen movies.

Okay. Well, it's from kid you know, from kids, from when we were kids. It's Brendan Fraser JS like a he's like a caveman, and they lie and say he's from Estonia. It's ridiculous.

Either way. Brendan Fraser is either. Yo. That's not true.

That's just the way I them. Brendan Fraser.

He's Tarzan. He's in he's the mummy. Well, he wasn't the mummy. Tarzan. Never seen the mummy.

Bro.

No. I don't I don't think this is a movie star.

I, like, really feel like you're you're playing a prank on me, but I I will go with that. No way. Tarzan, is that, like, Jumanji? Is that the same movie? Oh. I also didn't see Jumanji.

Yeah. Yeah. Yeah. Okay.

Hi, guys. Love the podcast.

Question about front end frameworks. With frameworks like Next. Js, it seems like it's expected or at least strongly encouraged to implement the back end part in Next. Js as well. But I always prefer to have a separate back Deno. An express server like Node that has all the endpoints and logic. So I can point all my different front end applications to this one Vercel. A custom front end, an internal admin front end, maybe a mobile app, etcetera.

So all I need for my customer facing front end framework is just the components, but I don't need API routes there. All I need is a framework, is SEO support out of the Bos. And if it would be React, that would be a big plus.

Is Next. Js then still the best option, or is this overkill? Remix sounded good, but based on your recent episodes, it seems that Remix is dead, or are there other options you would recommend? Yes. So, you know, I think that is a a thing. Right? I think a lot of people work like this. And in that case, right, it doesn't necessarily make sense to necessarily implement everything in Next. Js. You could have your whole separate back end as API routes within Next. Js and everything, including the UI app that is Next. Js, could still use those API routes that are hosted in that same application. But if you want a separate API that you can scale on its own and, deploy on its own and stuff like that, then, you know, possibly, you'd be looking at, right, hosting your own API. And in that case, sure, you could use Next. Js as the front end and get all that stuff. Right? At least server side rendering and those types of things. You could also use something like Astro, which is a great solution for that. In fact, if I was working in React, I would probably pick the TanStack or I'd pick Astro.

So those are the two options that I like the most in the React ecosystem.

I don't honestly even know the status of Remix these days, but I would have said that Wes a good option as well. And in reality, you don't even have to get that deep with it.

Vite and React has the cable Could you say that again? I said Vite and React. I didn't say Siri. What are you talking about? What's my watch talking to me about? So in reality, I think Vite and React on its own JS a pair can also do server side rendering in a much more minimal setup, and then you can use React router, get server side rendering, without a big old platform that is doing all the stuff that you're not gonna need or use anyways, and that could be an option as well. What is the best option? Well, I mean, the best option is whatever you're you get comfortable and proficient, but a lot of that stuff should work. You can you can build apps like this, without issue. Totally.

I I think if you are wanting to build your back end totally separate, there's still value in choosing a a framework.

I probably would not say to use Next. CSS, certainly, because Next. Js works the best when you are doing everything the Next. Js way.

That is a lot of your back end and front end.

Your back end code could simply just be fetching your data and and talking to your back end API, and and sometimes that is beneficial because you don't have to if you're doing everything server side or most things server side and you're doing it all via server components, then you're not you don't have to fuss with, like, auth or rate limiting or API keys or or anything like like that because you just have, like, a trusted system, which is your Next. Js application talking to your your trusted other system, which is your your API endpoint. But I probably would say reach for TanStack start or reach for React Router seven. So Remix is officially dead, meaning that they took all of the features and they moved them into React Router seven.

So Remix is not dead, but they have pushed all of the features back into React router seven. And that's because if you wanna build, like, a full fledged application, you really have to start with the router.

Next. Js is a router.

React router is a router.

TanStack start is essentially probably 87% TanStack router, and TanStack query together.

So you gotta pick something with a strong router and then also something that is really good at doing either static rendering, like prerendering, or something that is good at doing server rendering. And those that I just talked about are are probably a good approach. I did on Friday.

I've been trying to I've been moving my,

Next app or Yeah. My,

my Gatsby site. I moved it over to server components, and I moved it over. I used Next. Js because that was, like, one of the only ones that supported server components at the time and and still is. And then I've been trying to host it on, like, Cloudflare, which is its own set of challenges.

And there's a really good adapter that that Cloudflare is working on. It's called OpenNext. JS, but it just, like, kept hitting all kinds of it it's not there yet, and that's not any shade on the adapter. It's just, like, it's just early, and it says that.

So out of frustration, I was like, I'm gonna try use Waku or Waku. Here yours Japanese. How do you say that? W a k u. You're not Japanese, but you Node, Waku. Okay.

Waku. So, like Waku. You Node you know, Waluigi, Wario? Yeah.

Yeah. Waku. Yeah. But yeah. Okay. Well, come on. I think Waku. Okay. So Waku is

essentially Next. Js without the Next. Js features, the specific features, meaning that it's a Vite and Deno based React Vercel component framework.

And I moved over everything in probably, like, three or four hours, because I had built everything on on React server components. And it it's largely a a static content based website, but I was I was pretty happy with it as well. So that's I'll probably throw that one in there. It has a, like, app router kind of idea, but you can also use dynamic router. There's nested layouts.

There's tag deduping.

It's it's a really good good approach. I think I'm gonna go with it, but I think it's a bit early for me to say that.

Yeah. Neat.

Yeah. I'd freaking love Vite and Vite and Deno. They just got rid of all so many, like, Webpack issues I was hitting. And it's because I was doing things not the Next. Js blessed way Yeah. Because I was coming from Gatsby. I was trying to, like, shoehorn my, like, content into the Next. Js way, and then I just kept hitting all kinds of issues all the way down. So I'm pretty happy it was Wacko right now.

Nice. Yeah. That sounds neat. Can't wait to hear about it. Next one from

Paige Niedringhaus.

Hey, Wes and Scott.

It's been a while, but I'm back with the next question for you. Paige always has some of the best questions.

This one is more advertising and podcast hosting focused. I've been running a front end news focused podcast with two of my friends for the past year and a half. Ours is called Front End Fire.

And recently, we had email from a company called Bos Sell Ads asking if we'd be interested in advertising for their dev focused clients on podcast. Yes. I am very familiar with with buy sell ads. Before Century acquired Syntax, you had different episode sponsors. Did you ever work with a ad platform group like this or work directly with all of your sponsors? And what do you think of working with something like this? I feel a bit skeptical, but I would love your opinions on this. Yeah. This is an interesting approach. So when we were selling ads for this podcast, the best money you could make on this was when you were to talk to them directly. Mhmm. People who want to sponsor a podcast that is developer related, They're not selling underwear or vitamin gummies or things like that Wes they simply just need a warm body, and they will convert a specific amount. Some of these, like, big podcasts that you hear, Athletic Greens and and whatnot, they have that whole journey figured out, and they know that they can simply just put in 20,000 Yarn. And out the other end, they can sell 400 boxes of gummies, and and it will make sense to them. With developer stuff, it's a lot different because they they were not paying for, like, oh, I'm gonna sponsor the podcast, and I'm gonna make a whole bunch of money. In most cases, that was not the the case. In most cases, people that were sponsoring were losing money, but they were doing it because it was first of all, it was Scott and I talking about it, so that was some some goodwill to it.

Scott and I were familiar with their product. Like, we'd often go on calls with them and and get a little Deno, and and and us understanding their product somewhat deeply was was worth the money for them because then maybe we we'll talk about it, and it will pop up.

What we've figured out we had all kinds of people being like, we will sell the ads for you on the podcast, and we'll take 25%.

And, unfortunately, that I don't think that works very well in the developer space because of for the reasons that I I had just said. Bos sell ads is pretty heavily in the developer space. You probably remember them back in the blog days.

You used to have a sidebar with a grid of eight little squares on it, and there would be a whole bunch of little ads in there. Node they have sort of the whole Google Ads type of thing where they will try to place the best ad on there. They are a they're a very good company, and if there is somebody I would work with, I would I would say buy sell ads. But I think at the end of the day, you're not gonna be making a ton of money, having another company try to go out and sell it. It's it's all about the relationships and talking with the people who wanna sponsor your podcast because you can ask them, hey. What do you wanna get out of this sponsorship?

Yeah. Totally. I remember back in the day, like, getting buy sell ads to approve my blog was, like, such a goal of mine. It was like I mean, this would have been, like, 02/2011.

I was just like, if I could just get buy, sell ads to, say they would like to work with me, then I'm gonna be in in it. You know? So I I haven't worked with them or or done anything with them, especially lately. I did eventually get accepted to buy, sell ads, but I always had a good opinion of the the company. But, again, I have not worked with them. But I I think you you nailed this question, so I don't really have too much to add here. Yeah. I I had it on my blog many, many years ago, but

you need to get some serious traffic to make any kind of money on display ads, especially in the developer space Wes I think I think the stat is, like like, 60% developers have ad blockers turned on. Mhmm. And and probably the other 40% is just mobile traffic or people don't know how to install an ad blocker on their phone.

Yeah. Yeah. Right. Alright. Next question here. Thank you, Paige, by the way. A nerdy pilot. Hello, Wes and Scott. Longtime listener. Big fan here. I'm an airline pilot in my mid thirties. I've been dabbling with code for many years, but nothing professional yet.

In two years or so, I may lose my job to a medical condition, so I'm ramping up my efforts at becoming a professional software developer.

I doubt my aviation credentials, a degree in license would hold any value in the tech sector. Thankfully, I can afford staying unemployed while studying full time for a few years. With these conditions, is it reasonable to work towards and expect landing a senior level tech job straight away? What path would you recommend to best prepare for the inevitable? Thanks for running an awesome podcast and peace. You know what? I'm I'm skeptical that you would be able to land any sort of, senior level tech job specifically because there's a lot of on the job learning that happens with, like, how processes work in different Sanity teams, different size organizations that it's difficult to just get online, especially because everybody runs things a little bit differently.

So to get that experience that they would want in someone in a senior role, it's sadly not the case where, in my mind, you can't just study and get there. Typically, you're gonna have to start more junior than that, which is it's tough to hear because you're already such an accomplished professional. Right? Yeah. Not to say that you can't.

I I just I know that people hiring and especially with hiring being tough right now, I think people are gonna want someone who's had that organizational experience before locking someone down in a more senior role.

So, you know, what what can you do? I think the end of the day, you need to get as much real world as experience as possible.

So maybe that means taking on a a part time job.

Maybe that means, like, if you can put some hours into freelancing or running your own business, so that way you're not coming at this with, I'm a this is my first time as a dev job trying to get something a little bit higher, that you have some actual, on the job, like, real training. That's the tough part because there is so much of this that is taught through, you know, being passed down or something like that. You just don't get from from online stuff. I think for you to spend a few years of downtime in the best possible way,

you need to start build an app. Build something where in three years from now, you can look back on it and say, I used to be a pilot.

I stopped due to medical things, and I built I built this thing for three years.

I learned a ton building an actual real application rather than just a couple silly little little apps, and you have your GitHub is full of a to do app. And then you can like, you're gonna learn a ton about that if you you can find something to build. So whether that's you have a problem in the aviation world right now or or whether it's you even find somebody who's looking for a technical cofounder, there's a lot of people out there with stupid ideas of stuff they wanna build, so be careful there. But they're at the same time, there's a lot of people with really good ideas, especially with all the AI stuff going on right now. You Node, there's there's somebody working in plumbing or surgery wait times or, LED manufacturing.

There's somebody in that who's like, man, we have this problem that would be so cool if we could fix it.

And I have this great idea. And if you can sort of pair up with somebody like that to try to build something for a couple years, it's gonna be amazing experience.

And then you can also like, when it does come time to actually getting a job, you have this amazing business that you said, I built this thing. I understand.

And and you could that that's huge for for somebody hiring.

Yeah. I I think that's such a good point. You could always, like and and like you said, build with what you know. You you have this aviation background.

Surely Mhmm. You have experienced things in your time working professionally that, like, you know, rub you the wrong way or are just like a jagged edge that you get caught on. You know? And so maybe find how to smooth those edges with an app you could write. And who knows? I think the the fastest track at that that point to getting, a senior dev role or moving into a place of that would be to build something that somebody else wants Yeah. Have it get acquired. But that's, you know, obviously very difficult.

Alright. Next one here from broccoli boy sixty nine.

Hashing passwords is a waste of time when you can just a base 64 encode them. Do you agree? There's literally no difference. And I read that base 64 encoding is 100 times faster than hashing, so it's better performance obvious win. Alright. Broccoli boy Hold on. Before you even answer this,

this is a a bait question. Is it not? I've

you know what? When I first read this in the the show notes, I didn't read it as a bait question. And now that I'm reading it out loud and I think it might be due in part to the the the username broccoli boy sixty nine. That's the username I used on one of our last YouTube videos JS Wes interesting? Where I made a fake I made a fake, TikTok question, and I made the username broccoli boy sixty nine. Okay. Well, that's very funny. So whoever is is baiting you, I hope this is a bait question. For the softball.

Yes. Thank you for the softball. But if if this is not a bait question, you need to listen up. Okay. So the word encoding should be the clue here that this is not a good idea.

Encoding implies that it can be decoding. You can encode and decode something. If you can decode a password, there is no point.

That doesn't make it secure. If if you could decode it and you you let's say you encode Bos Sanity four Node a password, you save it to your database, somebody else could just decode that thing, there's the password. It's the same thing as storing the password in plain text.

Hashing is one way. It is irreversible.

You cannot unhash something.

It's the equivalent of, oh Node, splitting up the, you know, the password written on a piece of paper into fine dust that you could never reassemble. So hashing is one way. Encoding is two ways.

And even if this isn't bait, if it is bait, whatever, if you're out there and you wanna know how to securely store your passwords, it always needs to be one way Vercel.

Because if you can de encrypt or, de encode any of these things, then it's it's you might as well just not maybe not. Might as well just insert in plain text. But the reason people do it in hashing is because it's irreversible, and you cannot unhash something. So Yeah. That's why broccoli boy sixty Node.

That's actually a good explanation of the difference between encoding and, like, what what did you call it, encrypting? Or, so

and encrypting can both be two way, but hashing is one way specifically.

Yeah. Absolute. Okay. Because my daughter came to me the other day, and she was like, I'm being a spy.

And she's like, I'm writing these letters where a is equal to four and b is equal to whatever.

And, if you have this secret key, can you figure out what I wrote on it? And I was like, girl, let me tell you about, encoding and decoding.

And I was like, you're you're kind of in yeah. You're encrypting things right Node, and unless you have the key, I was trying to explain to her. I'm like, this is what computers do, where if you wanna keep something private, you you encrypt it, and then you can only get access to it the other way when you you decrypt it if you have access to the key.

And she didn't seem to think that was very cool. But I was gonna say the moment the moment you say, that's how computers work, she's gonna be like, alright. Great. Great. Thanks, dad, so much. I I always try to do that with my son when he's, like, talking about Minecraft, and I was just like, let me tell you about this real life thing. And he's just like, alright. We can talk about Minecraft again. Oh, man. There there's a couple,

like, known common encryption decryption ways. When we did the the t shirt giveaway for Syntax, we gave away the codes in so many different formats.

Yeah.

And then, unfortunately, people just plugged them in chat g p t and and decoded them immediately.

So it wasn't as fun as I would thought, but I I it was there was, like, a whole world of of different encryption, approaches for just, like, simple letters that you can you can decrypt them.

Even just like the there's, like, a letters off by one if you were to write all of your text and then just shift the letters in the alphabet by one.

Kinda interesting world.

Jonathan Bell, next question JS, what is the best way to leverage a functionality that's encapsulated inside of a third party package that is not necessarily intended for external consumption? I'm working on a project right now at work where we'd like to use the output of some of the functions contained in the third party package, but those functions are not exported via the index.tsorpackage.json.

I ended up downloading the entire package into our project and imported it directly via file path. However, this feels wrong. How have you solved this in the path? Yes.

I've done this many times where you just simply want access to one of the piece the utilities that live inside of a library and not the actual end result.

Mhmm. And you often have to go spelunking in your node modules folder to to sort of find out what it's using.

Ideally, they would either put that functionality in a separate utility package that you could Npm install or or export it just as as a nice utility.

So what I would do in this use case is I will use PMPM's patch package.

So simply just patch the package and make it an export so I can then import it. And then when I make that patch, I also will send a pull request upstream to the the other package that has done and say, hey. Love the library. I would love to be able to access this directly. And almost always to say, oh, yeah. Absolutely. And then merge it and publish a new one. If it's just, like, doesn't doesn't work, you know, it's it's too different, there's no problem just simply bringing it inside of your, inside of your repo. Download the whole thing. Stick it in a folder. Copy paste driven development is sometimes the best and simplest approach.

Yeah. I just recently did that in my, Xero Svelte package. There were some utilities that were in the Xero Node repo, and I just wanted those utilities. I just grabbed that folder, dragged it into mine, and said, oh, you're mine now because they didn't export them. Right? So you can you can just straight up do that. So Mhmm. Yeah. No. Nothing wrong with that. Yep. Especially if it's like a a monorepo as well. You can stick that thing in its its own package,

fork it. You know? Sometimes in the quest to make everything reusable, you add a lot of complexity, and sometimes it's ease sometimes just easier to copy paste it, put it in your project. Yeah. Totally. Alright. Next question from major release. How do you keep track of package library browser updates, new features, breaking changes?

It seems like I'm always randomly stumbling upon them, but I'm definitely missing a lot of stuff. Is there some type of system to keep me aware of new updates and changes and also things in the work. So, yeah, this is tough because it's different for everything, especially when you're talking about packages and libraries. Right? Because if everybody was just using conventional commits and using SemVer, you you theoretically, there could be, like, an one interface to make sure you're getting all the updates, all the change logs for everything. But everybody publishes a change log somewhat differently or not everybody, but a lot of people do.

And it makes consuming change logs difficult.

So for me, if if it's a project that I deeply care about, like Svelte, I'm like I'm I'm reading their blogs. I'm watching their things. They're like, here's what's new. Right? And that's what I gain what's new. But I also know that minor releases for Svelte are almost never going to I mean, like, literally, almost never going to break anything. So I'll just yellow update those or whatever. I'll find a blog post if there's new stuff I wanna be aware of.

As far as, like, other libraries, like, something that's in active development right now, like Deno, anytime they publish a change, I'm literally going to their website. I'm clicking on change log, and I'm reading the change log. And I'll do that for a lot of libraries, especially if it if it's a major version, especially, I'm reading the change log because there's almost always a if it is a major version, a breaking changes section, you have to be aware of that kind of thing. TypeScript obviously helps a lot here, because with TypeScript, if things change in your code, your TypeScript is going to fail. That can save you right there and at least can identify new things or where things have changed if maybe you didn't look at that change log. But I haven't personally found, like, one system for making sure I I'm up to date on everything.

Browser stuff, new features, that's maybe a little bit different.

We're just kinda tapped in. I'm more or less not super paying attention to every browser release, but watching for large shifts or I follow, people like Jen Simmons who post about what's new in Safari, when Safari gets an update, those types of things. So it is a little bit about, like, curating that feed. It is tough to stay on top of all of this stuff, but especially for major releases or or even, like, feature releases and stuff like that, I do tend to go directly to the source. Look at the change log. Many times, those change logs are in the the repo itself under releases. So, yeah, that's what I do. Yeah. For me, we have a whole Node, ep syntax dot f m four slash four twenty five on updating project dependencies and sort of different approaches

for it. But I will do I use a package called n c u or npm check updates.

Yeah. And I'll I'll make it like a like an actual commit where I upgrade everything in one go. So SemVerse is three releases. Right? You have one point two point three, and that's major, minor, and, and patch. I'll just patches, I just upgrade YOLO, whatever.

Minor, I'll sometimes check out the documentation if it's something that is in active development, to see if there's any new features that have been added. And then major, you don't see major releases all that often. Almost always, there's going to be a blog post or a GitHub version release that will collect all of the commits or or all of the breaking changes associated with that one. So that's kinda how I go about it, and I don't spend too much more time past that trying to search out what what has changed because it's stuff changes all the time. It's it's kind of kind of like a full time job.

Yeah. It's different if you're working on a big team, big project. You're gonna be doing one of these things at a time. You're gonna be making sure you know exactly what's included in everything and and all that stuff. So yeah. Wes guess it also depends on, like, how important that dependency is. You know? Like, there's there might be something that is so core

to your app that you're gonna you're gonna check out every single little point release to see what has changed, and there might be something else where it's like, I'm merging class names. You know? Nothing no new feature or or breaking change could possibly happen in this. I'm not too worried about it. Yeah. Cleaned up typescript types or behind the scene heat headlights. Yeah. Yeah. Phil Deshant says, do you use the mobile device preset in Chrome Firefox developer tools? Do you happen to know why those presets are always so out of date? In general, do you find these mobile viewports modes to be useful? I don't use them that often. The only time I use them is when I need to make the browser small enough, but I don't wanna make my dev tools smaller because the the mobile preset in the browsers is simply just changing the viewport size and width of it. And it's there's a couple other things where it will try, like, emulate touch and and whatnot, but you're not actually getting if like, mobile devices in the browser.

So you're as long as as things look good, and you should be making sure that it works on every single pixel all the way down to whatever your minimum is going to be. So I have never really been like, that's a bit weird. Why do they not have x, y, and z device? Because it's it literally should work on every single device out there.

I don't think I ever look at the, like, drop down and be like, oh, that's not working on the Asus ZenBook Fold

properly. Let me get that working. Yeah. I'm the same way. I I never look at the presets.

And and for that part, I'm I'm typically using polypane if I want to Yeah. Have a bunch of different ones to see exactly how they look because it's you can see a lot at once. But in the reality Mhmm. Today, there is no standard device sizes. There just straight up isn't.

There's every single device size under the sun, so you kinda gotta support it all. And, yeah, sure. You can fire it up in the the latest iPhone,

major variance to just confirm that it works on those. But at the end of the day, there's so many phones and whatever. You should really have it be tested and the whole gamut. Yeah. I think the only time those might be useful is if you're working with aspect ratios. You Node, you wanna do something when you're at a specific width. Because a lot of times, if you put your phone into, landscape mode, you you can find a lot of, like, bugs where people are just assuming that the width of the thing and you have unlimited height, but the the constrained height is often a a thing to take into consideration as well. So maybe that is is a use case. One question I have for you is, like, what's what's a minimum breakpoint these days? You Node, how small should you go? It used to be three twenty. Are we still going down to three twenty? I'm not. Yeah.

No. I I don't know, honestly. I don't know what SE is $3.75.

The current one? The iPhone XR is $4.14.

$3.03 20? Are we still doing $3.20? That seems that seems pretty small.

Yeah.

Yeah. Does my website look good at $3.20?

That's a great question.

Does

what does our website? What does our websites look like at these various sizes? Yeah. It looks good. I I think I've I put it there, but I I also wrote that CSS four years ago. Let's see the syntax one that says three twenty.

Yeah. It looks good.

It works. And I think that's that's, like, something to say about the approach you have to responsive design. You know? Don't think about your website in terms of six different break points. Think about it as, like, fluid.

And then and then at once things start to get tight, you know, you kinda cling to one of your one of your break points. I'll I'll I will tell you one thing on my personal website is I threw break points in wherever I wanted.

I kinda regret that. You know? I was just like, well, I'll just make it look good.

At 342 pixels, it starts looking funny. I'll change that. And I kinda wish that I picked, like, a handful of a little more breakpoints like we did on the the Syntax website.

Yeah. I, you know, I I typically do pick a handful of breakpoints, but it is it is interesting now with CSS Grid, Flexbox, those types of things where you can have little bit more variability in things like your your grid columns. Like, I don't have to define my grid columns at every breakpoint. I can give it an ideal. I can give it, like, a, you know Like a min max maximum amount of columns. Auto fit. Yeah. Correct. The auto fit kind of stuff where I find myself yes. I do use absolutely use breakpoints, but I find myself using them way less than I did five years ago for sure.

Next question from Komondor.

I wonder if this is Komondor is a a big old version of my dog, the Hungarian Puli. So Komondor.

Good day, legends. When working with designers or agencies, if you receive a design that's ugly or has poor UX UI, do you give feedback to them or just let it be and implement it as they've designed it? This is a tough one and something that I've experienced personally.

You know, I I worked at a job that I loved.

I was a senior developer at a small agency, like a 12 person agency. We're getting new projects. I had direct feedback with the client and the designers. We always worked very closely together so that if there was a new technique, the designers knew about it right away. And, like, they were really early on things like responsive design and even icon fonts and SVGs or new types of CSS. They were, like, early on it. And then I took a new job because the pay raise was massive. It was a big old pay bump for me, and it was a larger agency.

And the very first design comp I get handed is one in Photoshop, and this was well past the days of people were well onto vector based design at this point. They were using Sketch. Figma wasn't in out yet, but Sketch Wes, like, the hot tool at this point.

I got handed a, PSD with, like, rasterized icons that like, the icons weren't even rasterized well. They had, like, you know, missing pixel data here and there.

It was just like something straight out of, you know, 02/2009 era web development. And this JS, like, the very first site design I get, and I'm at this new job. And I'm just thinking, oh, I made a big mistake. I took I took the money over the job happiness here, and I'm working at a place where this is the type of comp that I get. And the very first one, I implemented his design, but I did it I did it without telling anybody. And I just did the, vectorized based icons, and I improved a lot of stuff about his design. I basically made his design a lot better, and I submitted that. And I did not talk to the designer about it. I'm not I don't think this was the right idea. I don't think this was the right call. But, I the way I saw it is if he cared so little about this design that he's not even gonna he's not gonna check, or he's gonna see the way that I implement it and be like, oh, that looks pretty good. I did a good job. In reality, what you should be doing is you should have a relationship with the designer, if possible, where you can give them feedback back and forth. A lot of the best jobs I've ever had were like that Wes you had that direct feedback. If this is a freelance thing and the client has signed off on the design, the client says, this is what I warp it to look like. It's now being passed to you. You Node? Sometimes it just makes sense to knock that thing out and move to the next one. Right? Collect the paycheck. Other times, if this is a longer term arrangement, maybe it's a designer you're gonna be working with again in the future potentially or a longer term project, I think it's absolutely best to try to have those conversations, not in a way that, hey. You're doing things wrong or whatever. But, like, sometimes designers and people who specialize in web design, they don't stay up on the tech. And so it might be easy for you to say, oh, by the way, is it okay if I implement this like this because of these reasons? I can tell you more about it if you're interested. You know? And maybe that will help. Refrain from just saying, hey. You're doing this wrong JS really what it is. But, hopefully, you can actually have that ability to have a discussion with the the designer themselves.

Yeah. That not my job is how products start to suck.

True. And Yes.

Ideally, you would you would care so much that you'll have a good back and forth. And, ideally, you don't just throw your hands up in exhaustion, being like, you know, like, they if they start pushing back on you, I see that quite a bit where, like, you're trying to have a conversation about a specific feature and someone just they have their own, like, agenda that they need to push or whatever, then they they just go, whatever. You know? Alright. I'll do it. And that's how how products start to to suck. You know? So there's there's definitely a delicate balance there, but I certainly would, especially if it's easy things, be like, hey. I think we can implement this a little bit better.

Send them a screenshot of an existing website that that does it in in that specific way. I think that that will be highly valued.

Dope. Yeah.

Totally. Alright. Let's move into the next section, which is sick picks and shameless plugs.

I have a a sick pick. So this is actually kinda funny. I well, I don't know if it's funny. But when I, had my concussion, you know, my helmet flew off and whatever, I was riding with my AirPods in, Wes, and I didn't I I mean, I was so out of it. I like I said, I couldn't drive. I didn't even think about it. And then I get home, and I get a message on my, you know, find my whatever. And it's like, your AirPods are not with you. And I, like, look at it in the and they're, like, just in the middle of the mountain. I mean, they're on the mountain somewhere.

So, my my poor AirPods and they were, you know, AirPod Pros. I had them for a while. They were super nice. Oh, man. And I was pretty pretty bummed out about that. But, you know, I didn't wanna have to replace them with crazy expensive AirPod Pros. They're, like, $200.

Yeah. So I ended up getting these bad boys, which are the Nothing Ear. Oh.

So they're the Nothing Ear a. And these guys, besides just being, I don't know if my phone camera's not gonna focus on it, besides just being cool JS hell to look at. They're currently on sale for $79, but typically 89, 90 dollars. So they're pretty cheap, and they have noise cancellation.

They function very similar to the AirPod Pros.

And the the thing I like besides the fact that it's cool and yellow, they also make them in black and white too. It has, you know, gestures to pinch and stop. The only thing that it doesn't have is you can't do the swipe to do the volume down. You have to do some kind of pinch gesture to do volume down. I should never figure that out anyway.

Bums me out. And the case doesn't have wireless charging, so you have to plug the case in. But the case and the the and the headphone, battery lasts three times longer than the AirPod Pro does. Really? Man. I charge these things overnight or whatever. And, typically, my AirPods, I would only get, like, the podcast recordings done, and then I would have to charge them or whatever.

These things, the battery lasts my entire workday effortlessly.

So I was just shocked at how much better the battery was, and the noise cancellation is super good on them.

I was having some crazy issue with my AirPod Pros where if I was laying down on a pillow or if I had my helmet on, I the AirPod Pro would have some sort of weird feedback with their noise cancellation, and it would cause a speedy

show warning. Using Pros just because because of all of that or, like, if you're walking, then it would disconnect and and move back to the not pros, whatever those are. I gotta say for for $79

Yeah. These things are awesome.

A big, big fan. They sound great. Everything is awesome. The noise cancellation's good, and, they look cool as hell. So, yeah, big fan. The nothing ear. I bought a pair of, like,

monster earbuds this summer because I kept keep losing my my AirPods.

And I was like, I gotta try something cheaper. So I you know? And, they were not very good. So I don't use them. They're they're alright, but they're just not comfortable in my ear. So I I'm there's something just about the AirPods that I love so much.

I I just think I should try these. So they're when they're called the same. The ear two?

These are the nothing ear a. I think they are the ear two. Two a? I I have whatever the link I have in the show notes is the the one that I got. But Nothing does a lot of really neat phones. I don't know if you've seen any of their phones. Oh, yeah. They do a lot of neat design in their products. So yeah.

Yeah. We need to bring back that, like, neat design in in so much of what we're doing right now. That's great. Yeah. Doing something different.

I'm gonna sick pick. I wish I had it here, but a small rig, smartphone rig cage? I don't know what you call it. But, basically, I have all this, like, rigging stuff for my cameras. You know, you got tripods and lights and, and grips and microphones, and it's so nice that everything is based on the same, like, quarter inch screw.

Or if not, you can buy little adapters. And I have all these little small rig clamps and whatnot.

And my wife does does quite a bit of filming as Wes, just around doing, sewing and making dresses and things like that. She was like, yeah. I need, like, a battery while I'm filming. And, like, where do I how do I attach this? I was like and she's like, I need a light. I'm like, you know what? We gotta get a cage and just, like, attach everything to the cage and put your phone in the middle. So we Scott this, like, beautiful all the small rig stuff is, like, this amazing milled aluminum, and it's all pretty affordable. Big fan of it. So this thing is really cool. It's it's we got a light on it. We got a microphone shotgun microphone on it, a little small rig clamp to hold the battery, and, like, you could just attach everything to this.

It all plugs in via USB c on, like or do you have, like, a USB hub on there or something? Like, what's the

It all plugs into the phone.

So, yeah, there's they're actually a hub is is not a bad idea. She we still have lightning phones, so I've been holding off on, like, making a permanent power thing, but that would be that would be really cool.

Yeah. Interesting.

I just I'm so excited to get off of lightning for for everything else.

Yeah. Yeah. I yes. Likewise.

Shameless plug. Let's plug the Syntax YouTube channel. Go to youtube.com forward slash at Syntax FM and smash the subscribe button.

We Scott a whole bunch of really fun videos, the podcast JS well as, custom made videos for the YouTube channel, so check it on out.

That's it for today. Thanks for tuning in. Peace.