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

Scott and Wes answer your listener questions! They debate Axios vs. Fetch, discuss whether Next.js is overkill without a backend, talk htmx and Alpine, dive into tech career transitions, and tackle everything from podcast ads to password hashing myths. Show Notes 00:00 Welcome to Syntax! 00:55 Scott’s health update. 04:11 Submit your questions. 04:26 Is Axios still worth using over Fetch? shiki. xior. ky. 10:17 Does Alpine.js solve HTMX’s client-side limitations? Syntax Ep. 868: The State of JavaScript. Server Driven Web Apps With HTMX. Syntax Ep. 568: Supper Club × Caleb Porzio. Alpine.js. Inertia.js. 16:47 How should I host my database for a local-first app? Neon Tech 22:50 Brought to you by Sentry.io. 24:14 Should I use Next.js if I want a separate backend? Create Vite Extra. 32:08 Are ad networks like BuySellAds worth it for podcasts? 36:36 Can I transition from airline pilot to senior software developer? 41:23 Is Base64 encoding a valid alternative to password hashing? 45:43 How do I use unexported functions from a third-party package? 48:09 How do you stay on top of package and browser updates? Syntax Ep. 425: Updating Project Dependencies. npm-check-update. 52:38 Why are Chrome and Firefox’s mobile presets outdated? 57:20 Should I give feedback on bad UX/UI designs from agencies? 01:01:53 Sick Picks + Shameless Plugs. Sick Picks Scott: Nothing Ear (a). Wes: SmallRig Phone Cage. Shameless Plugs Wes: Syntax on YouTube. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:01Wes Bos?

  Welcome to Syntax. Today, we got a potluck episode for you, which is got some really good questions. One on like, where does HTML5 fall short when you need to like hop to the client? And what's the best approach to that? Should you be using Next.js for a website where you don't want the backend stuff? Or should you be reaching for something like TanStack, or React Router 7? 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 hating on Axios. So 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

• 0:44Wes Bos?

  small should a media query go? All of that and more.

• 0:55Wes Bos?

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

• 1:00Scott Tolinski?

  Hey, doing all right. Back in action here. Feeling feeling pretty normal. I don't know if you revealed to the audience what happened about my accident. But yeah, yeah, I'm all good, man.

• 1:12Wes Bos?

  You bunked your noggin. Well, tell us what happened. You were carving up a mean sesh?

• 1:17Scott Tolinski?

  Yeah, yeah. Yeah, you know what? I've been 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 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 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 not kidding, it was it was steep. What it did is it caused my body to fall, kind of like

• 2:00Scott Tolinski?

  like a whip, you know, you whip a towel. 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. My helmet flew off and and I was just like, I didn't get knocked out, but I was just on another planet for a bit. And it was, uh, yeah, it was, uh, you know, I've had concussions before. So the moment that I hit, I was just like, oh, uh, this is bad. I'm in, I'm in trouble here. And, uh, I just needed to like, take a moment to like, you know, get myself back to normal. But I actually want to tell a story about this. This is like pretty new. I was on the chairlift. Be like earlier on in the day in a, I was talking, sometimes you just get into conversations with people on the chairlift.

• 2:43Scott Tolinski?

  And I was talking, uh, 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. Is Scott Zelinski from Syntax? And I was like, yes. His name was Brian, Brian Dunn. Uh, what a cool guy. 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 cool dude. We just chatted the whole time. But, uh, because I was riding with him, luckily, when that happened, uh, 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 you, if you can't get back to Denver, which I honestly couldn't,

• 3:28Scott Tolinski?

  that he would, uh, give me a place to stay out there and stuff. So shout out to Brian. Yeah. Brian, uh, um, was just really incredible. I ended up having a friend. Uh, drive me and the kids back. Cause my kids weren't a lesson. So I couldn't even drive. I was, I was that out of it. So I had to have a friend drive us back and had the ER and stuff. It was, uh, it was a massive bummer. So if, if you noticed that, like, I'm not a hundred percent with it. I'd like, this is my first episode back, folks.

• 3:57Wes Bos?

  It may be buffering a little bit, but I'll, uh, I'll fill in.

• 4:01Scott Tolinski?

  Yeah, right. Totally. Yeah.

• 4:03Wes Bos?

  Well, we'll get ready to put the little buffers, the circle over top of your face when you're.

• 4:08Scott Tolinski?

  When I'm just like, uh.

• 4:11Wes Bos?

  All right. Well, let's get on into it. We've 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 question, 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 requests. So what do you do with fetch? I create a wrapper to attach my token. Not everyone uses cookies

• 4:55Wes Bos?

  for that, etc., etc. Yeah, this is kind of interesting is if you are making repeat requests to like an API endpoint and you want to automatically attach something like a custom header or a token via like an authorization or a bearer header, or simply just tacking on a API key onto a get request. That is a really nice feature of Axios where you can just sort of set default, right? Number two, errors. Axios will throw an error if it is an error. No questions. That's fair. With fetch, is it an error or is it not? You gotta make sure and don't forget

• 5:37Wes Bos?

  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 away, double away for JSON response. Yeah, 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.

• 6:21Wes Bos?

  For that, not to say that you can't use Axios for that. We even did an entire episode on this, like, why would you still use Axios? Because I certainly understand why. I took the position of there are many use cases for Axios. Interceptors is another really good one. If you want to, if somebody like sends out a fetch request, you might want to intercept that and make sure the token is valid, or you want to make sure that they're logged in. If not, you want to redirect them. Lots of really good use cases for it. However, most people think that the entire library weight is not worth it,

• 7:01Wes Bos?

  as 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,

• 7:45Wes Bos?

  you simply just need to pass it a web request. And how that web request is made, it doesn't matter, right? 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 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 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,

• 8:29Wes Bos?

  and then XML HTTP request. And now, 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.

• 8:47Scott Tolinski?

  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 in my, my like, the way that I've always done things, at least since I've been making a lot of requests is with fetch or fetch polyfills or anything like that where that's just the way I've done it for so long that it feels like natural to me. And before that I did most things with a, oh man, like some kind of RPC system like Mini Mongo 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

• 9:29Scott Tolinski?

  it never really bothered me too much. But yeah, I think it's just a, I never got into the habit of using Axios. So I never saw it. But I, you know, I guess I didn't know anything about those limitations that you mentioned either.

• 9:41Wes Bos?

  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. X I O R. I don't know how you say that. That's a very similar packet, similar API. It's not a drop in replacement, but super tiny, 3KBG zipped. So has no problem throwing that in your, in your package or Kai, KY from Sindre Sorhas, similar package that has the whole idea of interceptors and defaults and base names.

• 10:17Scott Tolinski?

  Nice. Yeah, totally. All right. Next question is from Mark Volkman. Shout out to Mark. In show 868, Scott commented on how HTML is great until you decide you need some client side functionality. Alpine pairs very well with HTML and provides exactly that. It is commonly used in HTML and I show many examples in my HTML 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 HTML is suitable and not suitable for, because I think

• 10:57Scott Tolinski?

  it's just building different types of things. HTML 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 would be interested to see where people are using HTML back, like a backend for HTML with multiple different UIs. Because with HTML, the server returns straight up HTML, right?

• 11:41Scott Tolinski?

  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 client. That data is stored as JSON, right? Or it's just stored as data. And HTML, 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.

• 12:25Scott Tolinski?

  And that's where something like React or Svelte or Vue, in my mind, just makes way more sense for this type of thing. So HTML 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 a web 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 going to make a ton of sense, right? Or you're going to 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 HTML here.

• 13:10Scott Tolinski?

  So 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 that case, it works really well. I got no complaints there. But that's a situation where I'd see that HTML kind of falls apart.

• 13:29Wes Bos?

  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 Alpine JS. Also, common in the space is inertia JS. You know, you server render and then you can pick it up with React on the client side. We have Aaron Francis coming on to talk about Laravel Fusion, which is kind of interesting where it's like you build a, and this right now it's just view, you build a view app, but you could put PHP tags in the view app and that that will run a lot of that that server side. I think that those

• 14:12Wes Bos?

  are all 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 client, which is why I'm a big fan of of React server 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.

• 14:51Scott Tolinski?

  That makes so 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, what is it like EJS or one of those?

• 15:05Wes Bos?

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

• 15:30Scott Tolinski?

  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 HTML. But at that point, I'm just like, give me the whole thing in one platform, right? Yeah, give me the just the salt 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 is HTML, but yeah, I'll just take the thing where, like you said, one templating language for the whole stack. And let me differentiate with client and server.

• 16:02Wes Bos?

  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. But shout, shout out to Mark's book. I didn't realize he had written this, but it's called Server Driven Web Apps with HTML from the Pramatic Programmer. So certainly pick that up. Mark is a very smart guy.

• 16:48Wes Bos?

  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 where 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 Superbase overkill when you have a sync engine on top? Ideally, I'm looking for something that is simple to set up and manage. But as long as I don't have to SSH and reboot 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.

• 17:28Wes Bos?

  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're up and running. And then sort of 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?

• 18:05Scott Tolinski?

  Planet Scale.

• 18:07Wes Bos?

  Planet Scale, services like that, where 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 on the very end of the spectrum, you get something like a SuperBase or a Firebase or whatever, where 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?

• 18:40Scott Tolinski?

  Yeah, it depends, you know, 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.

• 19:08Wes Bos?

  Okay.

• 19:09Scott Tolinski?

  Just by chance, I just didn't see that checkbox and because of that, you know, I was like, it 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.

• 19:31Wes Bos?

  Oh, really?

• 19:32Scott Tolinski?

  I don't know why they haven't added 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 kind of thing? No, we got branching. All right.

• 19:42Wes Bos?

  But so what, how do you, how do you back up your, your database then? You run a? Like a script to dump it or what?

• 19:49Scott Tolinski?

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

• 19:56Wes Bos?

  That's a must have. That's a must have 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.

• 20:07Scott Tolinski?

  I know. I know. It's like when I had my MongoDB set up for for the level up site, 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, so you know, I do host things on Neon. Planet Scale is good, but there's also again, some quirks there, but it's a great platform. These are, these are kind of like things that are going to be hosted for you. And basically you click go and they give you a connection string. And that's great. That said, if you are doing zero sync, it needs to be Postgres and Planet Scale is just MySQL. So Neon would be 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,

• 20:49Scott Tolinski?

  but I'm not that, I'm not that adventurous. I'm going to say that. I'm not gonna, I'm not into hosting my own database infrastructure, especially on like a VPS through a managed thing. I'd just be so worried about losing data. So typically, I know like many other people have the chops there to manage their own databases like that. I'm usually going to run to a service. What I'm doing right now, Wes, is I'm moving my Habit Path database to AWS right now. And yeah, typically, that's the type of thing I don't want to do because AWS has, 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 want to, you want to see why I'm stressed out

• 21:32Scott Tolinski?

  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 Zero. So Pontus, if, if you're doing something with Zero, 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 all have it as infrastructure as code. But there's, there are options for hosted database hosts.

• 22:12Scott Tolinski?

  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.

• 22:24Wes Bos?

  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 liked like a platform as a service that would tell you, however, this is a sponsored ad.

• 22:52Scott Tolinski?

  Yeah, I was gonna say.

• 22:52Wes Bos?

  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 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.

• 23:37Wes Bos?

  Cause that's, that's one of the big things I was using it for. Check it out. Sentry.io forward slash syntax.

• 23:43Scott Tolinski?

  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 Roku, right? Some super simple type of thing.

• 23:54Wes Bos?

  And another thing that we didn't talk about is like your database being close to where your web app is. Cause 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.

• 24:13Scott Tolinski?

  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?

• 24:22Wes Bos?

  No, no, haven't seen movies.

• 24:25Scott Tolinski?

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

• 24:35Wes Bos?

  I don't know who Brendan Fraser is either.

• 24:37Scott Tolinski?

  Yeah, that's not true.

• 24:39Wes Bos?

  No, I just Googled him. Brendan Fraser.

• 24:42Scott Tolinski?

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

• 24:45Wes Bos?

  Never seen Tarzan, never seen the mummy.

• 24:48Scott Tolinski?

  Bro.

• 24:49Wes Bos?

  Um, no, I don't, I don't think this is a movie star.

• 24:54Scott Tolinski?

  I like really feel like you're, you're playing a prank on me, but I will go with that.

• 25:00Wes Bos?

  No way. Tarzan, is that like Jumanji? Is that the same movie? I also didn't see Jumanji.

• 25:05Scott Tolinski?

  Yeah, yeah, yeah. Okay. Uh, hi guys, love the podcast. Question about front end frameworks with frameworks like NextJS. It seems like it's expected or at least strongly encouraged to implement the backend part in NextJS as well. But I always prefer to have a separate backend, an express server like Hono that has all the endpoints and logic. So I can point all my different frontend applications to this one server. A custom frontend, an internal admin frontend, maybe a mobile app, et cetera. So all I need for my customer facing frontend 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 box. And if it would be React, that would be a big plus.

• 25:50Scott Tolinski?

  Is NextJS 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, you know, I think that is 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 NextJS. You could have your whole. Separate backend as API routes within NextJS and everything, including the UI app that is NextJS, 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

• 26:35Scott Tolinski?

  own API. And in that case, sure, you could use NextJS as the frontend 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 was a good option as well. And in reality, you don't even have to get that deep with it. Veet and React has the Sorry, could you say that again? I said Veet and React. I didn't say Siri, what are you talking about? [laughing]

• 27:19Scott Tolinski?

  What's my watch talking to me about? So in reality, I think Veet and React on its own as 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 going to 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.

• 27:51Wes Bos?

  I, I think if you are wanting to build your backend totally separate, there's still value in choosing a, a framework. I probably would not say to use NextJS, certainly because NextJS works the best when you are doing everything the NextJS way. That is a lot of your backend and frontend. Your backend code could simply just be fetching your data and, and talking to your backend 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

• 28:33Wes Bos?

  don't have to fuss with like auth or rate limiting or API keys or anything like that because you just have like a trusted system, which is your next JS application, talking to your trusted other system, which is your API endpoint. But I probably would say, reach for Tanstack Start or reach for React Router 7. So Remix is officially dead, meaning that they took all of the features and they moved them into React Router 7. So Remix is not dead, but they have pushed all of the features back into React Router 7. And that's because if you want to build like a full-fledged application, you really have

• 29:15Wes Bos?

  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 got to pick something with a strong router and then also something that is really good at doing either static rendering, like pre-rendering, or something that is good at doing server rendering. And those that I just talked about are probably a good approach. I did on Friday, I've been trying to, I've been moving my Next app or my Gatsby site, I moved it over

• 29:55Wes Bos?

  to server components. And I moved it over, I use Next JS because that was like one of the only ones that supported server components at the time 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 Cloudflare is working on, it's called Open Next JS, but it just like kept hitting all kinds of, 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 going to try use WAKU or Wake U. Here, yours Japanese, how do you say that? W A K U. You're not Japanese, but you know, Waku.

• 30:34Scott Tolinski?

  Wa- Wa- Ku. So like, you know, you know, Wa Luigi, Wario?

• 30:40Wes Bos?

  Yeah.

• 30:40Scott Tolinski?

  Yeah, Wa.

• 30:41Wes Bos?

  No, I don't, but yeah.

• 30:43Scott Tolinski?

  Well, come on.

• 30:43Wes Bos?

  I think. Wa- Ku. Okay, so Waku is essentially NextJS without the NextJS features, the specific features, meaning that it's a Veet and Hanno-based React server component framework. And I moved over everything in probably like three or four hours because I had built everything on React server components. And it's largely a static content-based website. But I was, I was pretty happy with it as well. So 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.

• 31:29Wes Bos?

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

• 31:36Scott Tolinski?

  Yeah, neat.

• 31:38Wes Bos?

  Yeah, I'd friggin' love Veet and Veet and Hanno. That just got rid of all so many like webpack issues I was hitting. And it's because I was doing things not the NextJS blessed way.

• 31:52Scott Tolinski?

  Yeah.

• 31:52Wes Bos?

  Because I was coming from Gatsby. I was trying to like shoehorn my like content into the NextJS way. And then I just kept hitting all kinds of issues all the way down. So I'm pretty happy with Waku right now.

• 32:05Scott Tolinski?

  Nice. Yeah, that sounds neat. I can't wait to hear about it.

• 32:08Wes Bos?

  Next one from Paige Needringhouse. Hey, Weston 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 Buy Sell Ads asking if we'd be interested in advertising for their dev-focused clients on the podcast. Yes, I am very familiar with, with Buy Sell Ads. Before Sentry acquired Syntax, you had different episode sponsors. Did you ever work with an ad platform group like this?

• 32:53Wes Bos?

  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 would talk to them directly. People who want to sponsor a podcast that is developer related, they're not selling underwear or vitamin gummies or things like that where they simply just need a warm body and they will convert a specific amount. Some of these like big podcasts that you hear,

• 33:36Wes Bos?

  Athletic Greens and whatnot, they have that whole journey figured out and they know that they can simply just put in 20,000 ears and out the other end, they can sell 400 boxes of gummies 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 going to sponsor the podcast and I'm going to make a whole bunch of money. In most cases, that was not 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 our product, like we'd often go on calls with

• 34:20Wes Bos?

  them and get a little demo 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 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 had just said. Buy Sell Ads is pretty heavily in the developer space. You'll probably remember them back in the blog days, 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. And now they have sort of

• 35:04Wes Bos?

  the whole Google Ads type of thing where they will try to place the best ad on there. They are, 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 going to 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 want to sponsor your podcast. Cause you can ask them, hey, what do you want to get out of this sponsorship?

• 35:36Scott Tolinski?

  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 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 going to be in, in it, you know? So I, I haven't worked with them 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.

• 36:08Wes Bos?

  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 where I think, I think the stat is like, like 60% developers have ad blockers turned on. And probably the other 40% is just mobile traffic where people don't know how to install an ad blocker on their phone.

• 36:35Scott Tolinski?

  Yeah, right. All right. Next question here. Uh, 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 30s. 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 and 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?

• 37:15Scott Tolinski?

  What path would you recommend to best prepare for the inevitable? Thanks for running an awesome podcast and peace. You know what? I'm skeptical that you'd 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 sized teams, different sized 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.

• 38:00Scott Tolinski?

  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?

• 38:07Wes Bos?

  Yeah.

• 38:08Scott Tolinski?

  Not to say that you can't. 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 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 the thing a little bit higher, that you have some actual on the job, like real training.

• 38:51Scott Tolinski?

  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.

• 39:02Wes Bos?

  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, a little apps and you have, your GitHub is full of a to do app. And then you can, like, you're going to 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,

• 39:45Wes Bos?

  or whether it's you even find somebody who's looking for a technical co-founder. There's a lot of people out there with stupid ideas of stuff they want to 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 know, 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.

• 40:25Wes Bos?

  And if you can sort of pair up with somebody like that to try to build something for a couple of years, it's going to 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 somebody hiring.

• 40:47Scott Tolinski?

  Yeah, I think that's such a good point. You could always like, and like you said, build with what you know. You have this aviation background. Surely you have experienced things in your time working professionally that like,

• 41:03Scott Tolinski?

  You know, rub you the wrong way or 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 fastest track at that, that point to getting a senior dev role or moving into a place that would be to build something that somebody else wants and have it get acquired. But that's, you know, obviously very difficult. All right. Next one here from broccoliboy69. hashing passwords is a waste of time when you can just 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. All right, broccoli boy.

• 41:42Wes Bos?

  Hold on, before you even answer this, this is a bait question, is it not?

• 41:47Scott Tolinski?

  I, you know what, when I first read this in 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 username broccoliboy69.

• 41:59Wes Bos?

  That's the username I used on one of our last YouTube videos, where I made a fake, I made a fake TikTok question and I made the username broccoliboy69.

• 42:09Scott Tolinski?

  Okay, well, that's very funny. So whoever is baiting you, I hope this is a bait question.

• 42:14Wes Bos?

  Thank you for the softball.

• 42:15Scott Tolinski?

  Yes, thank you for the softball. But 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 you could decode it, and you, let's say you encode base 64 encode a password, you save it to your database, somebody else can 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.

• 42:55Scott Tolinski?

  It's the equivalent of, oh, God, 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 want to know how to securely store your passwords, it always needs to be one way irreversible. Because if you can de-encrypt or de-encode any of these things, then it's, you might as well just, not maybe not might as well, just sort of in plain text, but the reason people do it in hashing is because it's irreversible and you cannot unhash something. So, that's why broccoliboy69.

• 43:41Wes Bos?

  That's actually a good explanation of the difference between encoding and like, well, what did you call it? Encrypting or?

• 43:51Scott Tolinski?

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

• 43:57Wes Bos?

  Yeah. Absolutely. 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 only 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, you're encrypting things right now. And unless you have the key, I was trying to explain to her, I'm like, this is what computers do, where if you want to keep something private, you, you encrypt it, and then you can only

• 44:39Wes Bos?

  get access to it the other way when you decrypt it, if you have access to the key. And she didn't seem to think that was very cool.

• 44:46Scott Tolinski?

  I was gonna say, the moment you say, that's how computers work, she's gonna be like, all right, great, thanks dad so much. I always try to do that with my son when he's like talking about Minecraft. And that's just like, let me tell you about this real life thing. It was just like, all right, we can talk about Minecraft again?

• 45:02Wes Bos?

  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. And then unfortunately, people just put them in chat GPT and decoded them immediately. So it wasn't as fun as I would thought, but. There was like a whole world of different encryption approaches for just like simple letters that you can decrypt them, even just like there's like letters off by one, if you were to write all of your text and then just shift the letters in the alphabet by one, kind of interesting world. Jonathan Bell, next question is, what is the best

• 45:46Wes Bos?

  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 dot TS or package 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 utilities that live

• 46:25Wes Bos?

  inside of a library and not the actual end result. And you often have to go spelunking in your node modules folder 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 export it just as a nice utility. So what I would do in this use case is I will use PMPM's patch package to 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 other

• 47:06Wes Bos?

  package that has done is say, hey, love the library. I would love to be able to access this directly. And almost always they say, oh, yeah, absolutely. They merge it and publish a new one. If it's just like doesn't work, you know, 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.

• 47:32Scott Tolinski?

  Yeah, I recently did that in my Zero Svelte package. There were some utilities that were in the Zero mono 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 just straight up do that. So.

• 47:51Wes Bos?

  Yeah, nothing wrong with that.

• 47:52Scott Tolinski?

  Yep.

• 47:53Wes Bos?

  Especially if it's like a mono repo 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 sometimes just easier to copy paste it, put it in your project.

• 48:09Scott Tolinski?

  Yeah, totally. All right. Next question for 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, theoretically, there could be like 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.

• 48:55Scott Tolinski?

  And it makes consuming change logs difficult. So for me, 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 that are 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 Yolo update those or whatever. I'll find a blog post if there's new stuff I want to be aware of. As far as like other libraries, like something that's in active development right now, like Xero, 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's a major version, especially, I'm

• 49:40Scott Tolinski?

  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, uh, 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'm up to date on everything. Browser stuff, new features, that's maybe a little bit different. Uh, we're just kind of tapped in. I'm more or less not super paying attention to every browser release, but watching for large shifts or I follow, uh, people like Jen Simmons who post about what's new in

• 50:25Scott Tolinski?

  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 even like feature releases and stuff like that. Uh, I do tend to go directly to the source. Look at the change log. Many times those change logs are in the repo itself under releases. So yeah, that's what I do.

• 50:48Wes Bos?

  Yeah. For me, we have a whole episode, syntax.fm/425 on updating project dependencies and sort of different approaches for it. But I will do, I use a package called NCU or NPM check updates. And I'll, I'll make it like a, like an actual commit where I upgrade everything in one go. So Semver is, is three releases, right? You have 1.2.3 and that's major, minor and, uh, 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, um, to see if there's any new features that. Have been added and then major, you don't see major releases all that often.

• 51:32Wes Bos?

  Almost always there's going to be a blog post or a GitHub version release. That will collect all of the commits or all of the breaking changes associated with that one. So that's kind of 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 and it's, it's kind of, kind of like a full-time job.

• 52:01Scott Tolinski?

  Yeah, it's different if you're working on a big team, big project. You're going to be doing one of these things at a time. You're going to be making sure you know exactly it's included in everything and, and all that stuff.

• 52:10Wes Bos?

  So I 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 breaking change could possibly happen in this. I'm not too worried about it.

• 52:35Scott Tolinski?

  Yeah. Cleaned up types, group types or behind the scene, you know?

• 52:38Wes Bos?

  Yeah. Yeah. Phil Deschamps 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 want to 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 of other things where Ultra like emulate touch and whatnot, but you're not actually getting.

• 53:24Wes Bos?

  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, hmm, that's a bit weird. Why do they not have X, Y, and Z device? Because it literally should work on every single device out there. I don't think I ever look at the like dropdown and be like, oh, it's not working on the Asus ZenBook Fold properly. Let me get that working.

• 54:01Scott Tolinski?

  Yeah, I'm the same way. I never look at the presets. And for that part, I'm typically using Polypane if I want to

• 54:09Wes Bos?

  Yeah.

• 54:09Scott Tolinski?

  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 today, there is no standard device sizes. There just straight up isn't. There's every single device size under the sun. So you kind of got to support it all. And yeah, sure, you can fire it up in the latest iPhone major variants 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.

• 54:39Wes Bos?

  I think the only time those might be useful is if you're working with aspect ratios. You know, you want to 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 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 know, how small should you go? It used to be 320. Are we still going down to 320?

• 55:16Scott Tolinski?

  I'm not. Yeah. No, I don't know. Honestly, I don't know.

• 55:20Wes Bos?

  iPhone SE is 375.

• 55:23Scott Tolinski?

  The current one?

• 55:24Wes Bos?

  The iPhone XR is 414.

• 55:29Scott Tolinski?

  Uh.

• 55:30Wes Bos?

  Three, 320. We still doing 320? That seems, that seems very small.

• 55:37Scott Tolinski?

  Yeah.

• 55:38Wes Bos?

  Yeah. Does my website look good at 320?

• 55:41Scott Tolinski?

  That's a great question. Does, what does our website, what does our websites look like at these various sizes?

• 55:47Wes Bos?

  Yeah, it looks good. I, I think I've, I've put it there, but I also wrote that CSS. Four years ago. Let's see the syntax website at 320.

• 55:57Wes Bos?

  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 breakpoints. Think about it as like fluid. Um, and then, and then at, once things start to get tight, you know, you kind of cling to one of your, one of your breakpoints. I'll, I will tell you one thing on my personal website is I threw breakpoints in wherever I wanted. I kind of 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 kind of wish that I picked

• 56:38Wes Bos?

  like a handful of a little more breakpoints like we did on the, the syntax website.

• 56:43Scott Tolinski?

  Yeah. 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 a 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,

• 57:05Wes Bos?

  A min max, a key, auto fit. Yeah.

• 57:09Scott Tolinski?

  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.

• 57:20Scott Tolinski?

  Next question from Komandor. I wonder if this is... Komandor is a big old version of my dog, the Hungarian Pooley. So Komandor. "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 designed it?" This is a tough one and something that I've experienced personally. You know, 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

• 58:01Scott Tolinski?

  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 out yet, but Sketch was 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

• 58:45Scott Tolinski?

  was just like something straight out of, you know, 2009-era web development. And this is 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 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 didn't...

• 59:14Scott Tolinski?

  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 implemented 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, where you had that direct feedback. If this is a freelance thing

• 59:59Scott Tolinski?

  and the client has signed off on the design, the client says, this is what I want it to look like. It's now being passed to you. You know, 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

• 1:00:44Scott Tolinski?

  from just saying, hey, you're doing this wrong is really what it is. But hopefully you can actually have that ability to have a discussion with the designer themselves.

• 1:00:54Wes Bos?

  Yeah, that not my job is how products start to suck. And 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, wow, you know, like 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 just go, ah, whatever, you know, all right, I'll do it. And that's how, how products start to suck, you know? So there's, there's definitely, definitely a delicate balance there, but I certainly would.

• 1:01:39Wes Bos?

  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.

• 1:01:52Scott Tolinski?

  Dope. Yeah, totally.

• 1:01:53Wes Bos?

  All right, let's move into the next section, which is sick pics and shameless plugs.

• 1:01:59Scott Tolinski?

  I have a sick pic. So this is actually kind of 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 mean, I was so out of it. 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 looked 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. And I was pretty, pretty bummed out about that. But, um, you know, I didn't want to have to replace them with

• 1:02:44Scott Tolinski?

  crazy expensive AirPod Pros. They're like 200 bucks. So I ended up getting these bad boys, which are the Nothing Ear. So they're the Nothing Ear A. And these guys, besides just being, um, I don't know if my phone camera is not going to focus on it. Besides just being cool as hell to look at, they're currently on sale for $79, but typically $89, $90. So they're pretty cheap. And they have noise cancellation. Um, 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.

• 1:03:27Scott Tolinski?

  You have to do some kind of pinch gesture to do volume down.

• 1:03:30Wes Bos?

  I can never figure that out anyway.

• 1:03:32Scott Tolinski?

  Bums me out. And the case doesn't have wireless charging, so you have to plug the case in. But the case. And the headphone battery lasts three times longer than the AirPod Pro does.

• 1:03:43Wes Bos?

  Really?

• 1:03:44Scott Tolinski?

  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, the AirPod Pro would have some sort of weird feedback with their noise cancellation and it would cause this really

• 1:04:17Wes Bos?

  I stopped using Pros just because of all of that. Or like if you're walking, then it would disconnect and I move back to the not Pros, whatever those are.

• 1:04:27Scott Tolinski?

  I gotta say for 79 bucks, these things are awesome. A big, big fan. They sound great. Everything is awesome. The noise cancellation is good and they look cool as hell. So yeah, big fan. The Nothing Ear.

• 1:04:42Wes Bos?

  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 all right, but they're just not comfortable in my ears. So I, there's something just about the AirPods that I love so much. I think I should try these. So they're

• 1:05:07Scott Tolinski?

  Functionally the same.

• 1:05:08Wes Bos?

  The Ear 2?

• 1:05:10Scott Tolinski?

  These are the Nothing Ear A. I think they are the Ear 2.

• 1:05:14Wes Bos?

  2A?

• 1:05:15Scott Tolinski?

  Whatever the link I have in the show notes is 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. They do a lot of neat design in their products. So, yeah.

• 1:05:27Wes Bos?

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

• 1:05:34Scott Tolinski?

  Doing something different.

• 1:05:35Wes Bos?

  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. Now, 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 well, just around doing sewing and making dresses and things like that. She's like, yeah, I need like a battery while I'm filming and

• 1:06:18Wes Bos?

  like, what 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 got to get a cage and just like attach everything to the cage and put your phone in the middle. So we got 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.

• 1:06:47Scott Tolinski?

  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?

• 1:06:54Wes Bos?

  It's all plugs into the phone. So yeah, there's, the hub is not a bad idea. 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.

• 1:07:08Scott Tolinski?

  Yeah. Interesting.

• 1:07:09Wes Bos?

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

• 1:07:14Scott Tolinski?

  Yeah, yeah.

• 1:07:17Wes Bos?

  Jimos plug, let's plug the syntax YouTube channel. Go to youtube.com forward slash at syntax FM and smash the subscribe button. We've got a whole bunch of really fun videos, the podcast as well as custom made videos for the YouTube channel. So check it on out. Uh, that's it for today. Thanks for tuning in. Peace.

• 1:07:39Scott Tolinski?

  Peace.