940: Picking a Fullstack Stack, Is Next.js Too Complex? Services vs Self-Hosted + More

In this potluck episode, Wes and Scott answer your questions about modern full-stack stacks, Node.js backend options, managing database indexes, developer burnout, handling toxic bosses, and more! Show Notes 00:00 Welcome to Syntax! 02:36 What’s your go-to Node.js backend in 2025? Polka 06:18 Do you proactively manage database indexes—or fix them only when they become a problem? 09:40 Brought to you by Sentry.io 12:14 After planning a new project, what’s your real-world dev workflow? 931: Project Init - How to Make Good Choices When Starting a New Coding Project 18:19 What to do when you’re feeling burned out as a developer 23:34 Picking the right tech stack for your partner’s website 28:18 How do you deal with a toxic boss? 33:10 The ideal tech stack for launching a SaaS MVP 39:46 Is GraphQL still worth it vs REST or RPC? 44:26 Is Vercel steering modern web dev in the wrong direction? 51:20 What’s up with TanStack Forms? TanStack Form Latest 59:35 Sick Picks + Shameless Plugs Sick Picks Scott: Flesh and Code Wes: WAGO connectors Shameless Plugs Syntax YouTube Channel 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:00Wes Bos?

  Welcome to Syntax. Today, we've got a Pollock episode for you today. We're going to be talking about Node.js backend choice. Well, if you want to build a quick REST API, what you use in Node, a whole bunch of questions around like full stack, like what stack should I pull together in order to build like a SaaS app or a CMS that I want to do your own? We talk a bit about when to use a service versus when to host it yourself. That free tier will come and bite you in the butt once they pull the rug from you. Scott is wrong about Tanstack forms and doesn't understand what they're for.

• 0:31Scott Tolinski?

  No.

• 0:32Wes Bos?

  And simple stacks. Someone's saying like, was Express in Vue and MySQL the perfect stack? Should we go back to that? Is Node.js too complicated? But we're getting all into that, so let's get it going.

• 0:48Scott Tolinski?

  I feel like this is the stack episode, Wes.

• 0:50Wes Bos?

  Yes, it's a stack. Nothing but stacks. Full stack flapjack.

• 0:54Scott Tolinski?

  Full stack flapjack. Let's go.

• 0:56Wes Bos?

  You ready, Scott? How you doing today?

• 0:58Scott Tolinski?

  Hey, I'm doing good, man. Just chilling, hanging out. Being back on my Mac feels weird. I've just been turning into a Linux boy, so.

• 1:07Wes Bos?

  You've been all over the Omarchi, using Linux, App Get, installing things.

• 1:13Scott Tolinski?

  I have not used App Get. There's something called Pac-Man. I've been Pac-Man-ing. I've been chomp-chomping, waku waku, all that stuff. How are you doing?

• 1:23Wes Bos?

  I'm doing good. We're recording on a Thursday today, which is a little odd, but I'm heading out next week, so we're getting ahead of it, cranking out one for you. And like, honestly, we do a Pollock once a month, and there's a lot of questions today. I couldn't believe it. Like, we often come back to the Pollock and we're, man, like, we could maybe do two of these a month sometimes. There's just so many good questions. So please keep the questions coming. Go to syntax.fm and in the URL bar in the menu, there's a button that says "Pollock Cues." You can fill that out and we'll answer your question up on an upcoming episode.

• 1:59Scott Tolinski?

  So you would say URL or Earl?

• 2:02Wes Bos?

  Earl.

• 2:02Scott Tolinski?

  Which one?

• 2:03Wes Bos?

  No.

• 2:03Scott Tolinski?

  Yeah.

• 2:04Wes Bos?

  I just say URL. I just.

• 2:06Scott Tolinski?

  I just say URL as well. No, I'm just saying, you gotta make a choice. Somebody says, URL or Earl? What are you picking?

• 2:15Wes Bos?

  No, it's URL. But the one thing I do say that's weird. Oh, Earl?

• 2:21Wes Bos?

  Or URL.

• 2:22Scott Tolinski?

  You gotta pick.

• 2:23Wes Bos?

  They're both stupid. No, I'm not. I don't stupid that. You know what I do say? I say href. Ahref?

• 2:29Scott Tolinski?

  You do? You say href?

• 2:30Wes Bos?

  Yeah, href, a href. That's, it's not right, I know, but I've been saying it my whole life and I'm not, I'm not about to change. But let's get into the first question from Finnish George. What is your preferred choice for a Node.js backend? I mean, something newer than Express. And how much would you say there is an it depends factor? I mean, when it's basically just a crud API. So basically, you're spinning up a Node server, you have a crud API that's taking in get requests, post requests, there's, there's bodies that come in, maybe JSON, maybe you need to handle streaming, you know, just your, your standard REST API that you need to be able to build out

• 3:10Wes Bos?

  with Node.js. And my reach for that is usually either like Hanno or H3. And the reason why I'm, I'm saying those things is that both of those frameworks follow the standard web request and web response. In fact, like, almost everything these days follows the standard web request and web response signature, meaning that any handlers, any API handlers that come in, you will be able to move those from like, like if you're in Hanno, you need to move it to like, let's say you, you want the functionality to exist in like a next JS request, or, or maybe you're using like a Svelte server function.

• 3:53Wes Bos?

  That code will be almost entirely movable, meaning that the, the URL, access to the URL, access to the body, access to the parameters, the query params, all of that stuff will be, it will look exactly the same way. And then the response that you send from that handler, also, those are, are standard across the board. There is some like helpers for like sending JSON and sending text, but that is different than like Express was, because Express, there was no standard for doing this type of thing. So they just made it up. And now luckily, other like Connect, other people picked that, that sort of standard up, but the new standard is web request, web response.

• 4:35Scott Tolinski?

  Yeah, yeah, I would also probably picked Hono. I, in the past, I've used Fastify, Fastify.dev and really, really liked it. Those there, Eliza, I used Eliza as well.

• 4:47Wes Bos?

  Yeah, that one's a good one as well.

• 4:48Scott Tolinski?

  But to me, Hono is probably just what I'd pick today. That said, I'm usually working in a more of a meta framework, so I'm not having to pick up one of these that often. But yeah, I think that would probably be it, you know?

• 5:02Wes Bos?

  That's the other alternative as well is like, maybe don't even spin up a node backend. Like, the only reason why I don't use Hono more than that is that I'm often using like a full stack meta framework that also does my front end and handles all that for me.

• 5:17Scott Tolinski?

  Yeah, and if you want something that is like really lightweight and you're, you know, you're just looking for something super easy to spin up, Polka is an interesting option as well. This is actually what SvelteKit uses underneath the hood. It's a 90 lines of code. So, yeah, it's a pretty minimal here.

• 5:38Wes Bos?

  That's, that's, that's really nice. Oh, because you can, you can specify things like route handlers with like, like IDs and whatnot in them. Similar to how you would, you would specify like, catch all routes or, or variable routes, param routes in Express.

• 5:53Scott Tolinski?

  Yeah.

• 5:54Wes Bos?

  That's pretty cool. Yeah, it's, it's, it's a good, good thing. I still have an Express app and I've been slowly like writing like a conversion layer. Anytime I add anything new, because eventually I'm trying to move myself off of anything Express specific and move to just standards based stuff. So that I'll be able to one day just move, move entirely over.

• 6:15Scott Tolinski?

  Yeah, eventually, right? Next question from Halindra. Hey, Wes Scott and CJ, shout out to CJ. So, after moving my database from Postgres over to Convex, where you would have explicitly chose the index for each query, I realized my indexing was kind of a mess, causing a lot of full table scans. Do you actively manage your database indexes to prevent that? Or is it something you usually only fix when it's a problem?

• 6:47Scott Tolinski?

  Yeah, so for me indexing really has always come down to what are the queries that I'm making? What do I plan on querying off of and like what needs to exist? And from there, it's usually something I take care of when I initially write the schema. I tend to think very deeply about what am I actually querying for and off of what parameters? So for people who may not know too much about indexes, oh, man, I wish I knew technically. I'm sure you might know a little bit more technically, what exactly indexes are doing. But from a non-technical perspective, what they're doing is when you set up an index,

• 7:28Scott Tolinski?

  the database becomes optimized to look up over certain parameters in or certain columns in a table. So combinations of columns, individual columns, yeah.

• 7:40Wes Bos?

  Like if you have like a user column somewhere and that user column has like an email address, first name, last name, and like like social handles, right? You gotta ask yourself like, will I be querying this? Like, obviously you have a primary key and that's you're going to be able to pull up that really quickly. But if you are trying to like query somebody based on like, say their email address, if you don't have the email column indexed in your database, what happens is that your database literally loops through your entire, every single item in your database and will be looking for that specific one.

• 8:22Wes Bos?

  And when you specify a field as an index, it will often scan your database and keep those things in memory or somewhere so that it can quickly look that up. So you just have to ask yourself, like, I always look up users by email address, right? Whereas like sometimes I'm looking up people by some weird combination of it and the query will be a lot slower, but that's okay. And often what I'll do is if you don't know it ahead of time, it's going to show up in in your stats that you're having very slow database reads. And in fact, we had one in the syntax website where I forget which column it was,

• 9:05Wes Bos?

  but we were not in that, I think it was shows and we have a show number. And we were often looking up shows by show number, but the show number was not indexed.

• 9:16Wes Bos?

  As the database grew, the queries got slower and slower. Every single time we added a show, the queries got slower, slower, slower, to a point where we got a Sentry alert that said, hey, slow query detected. And then we went in there and realized, oh, add an index, boom, solved immediately.

• 9:37Scott Tolinski?

  Yeah, you know, so part of it again is paying attention. That's really what it is. But another thing is, if you want to use a tool to do this, Sentry has slow queries. They have a slow query tool. And then, just to be clear, we work for Sentry. So this is me plugging Sentry. Sentry, at Sentry.io, is the perfect place to find your missing indexes. Or even for better yet, track your slow queries, because there is an entire slow query feature within Sentry that allows you. And honestly, I think that's how we found our slow query with their shows, our missing index.

• 10:17Wes Bos?

  Yeah, that's exactly how it emailed us.

• 10:20Scott Tolinski?

  Yeah, to email us, right?

• 10:22Wes Bos?

  It was actually funny to watch the query over time as it got slower and slower.

• 10:28Scott Tolinski?

  Yeah, that's actually the best part, is when you make a fix and then you get to see the bars go down in terms of like, yeah, how long it took, latency or whatever. So check it out, Sentry.io, use the coupon code TASTYTREAT, all lowercase, all one word, and you get two months for free. Man, really, really nice tool. But yes, that is mostly it. Another cool thing you can do nowadays in 2025 is you can ask AI to do it for you. Not like to trust it blindly, but you can pass in your whole ass website and say, hey, am I missing any indexes here? And it might say, you should consider adding an index for this. I've had really good luck with that, because then it's not even like writing the code for you, it's just looking at everything and being like, hey, I noticed you're querying

• 11:13Scott Tolinski?

  off of this, but you're not indexing for it. So maybe consider that, or change your query.

• 11:18Wes Bos?

  Rip through your code base, find all the queries and say, hey, you're searching based on these fields fairly often. It's worth adding indexes. I have, and also you have to ask yourself, like, do I even need this? Like, I have some queries in like an admin tool that I use three or four times a year for some reporting. And I don't put indexes on those. Those queries are slow as hell, you know? But it doesn't matter, because I only use it three or four times a year. It's not worth the extra cost to add that.

• 11:48Scott Tolinski?

  What is the extra cost?

• 11:51Wes Bos?

  The extra cost is that like your database grows. So like, you could, obviously, you could just index everything in your database, and it would all be fast. But then the storing of those indexes becomes very large, and you need more memory, or you need a larger database to be able to handle that. So if you've got lots of money, you could.

• 12:11Scott Tolinski?

  Make the whole plan out of the black box, right?

• 12:13Wes Bos?

  Yes, exactly. Another question, a couple of weeks ago, we did a episode on like, creating a new project, like initializing a project. What do you even do? Planning? How do you do that? So we had a question, which is, following up on that episode, when you're done your initial plan, so you've figured out kind of what you want to build, and how you want to tackle it, what does your actual workflow look like when it gets time to actually write in the code? Do you update your package JSON with everything you know you're going to be using? Do you start with front-end components? Do you start with routes, database structure? Do you tend to scaffold out the whole project first, or work on one section, front to back, and then add the extra pieces along the way? Also, how do you order the work? Is it core functionality first? And/or do you get things like auth,

• 12:58Wes Bos?

  translation, etc. set up first? So that's a really interesting question. I think it breaks down to like, what type of application it is? So I thought, like, let's break it down, me and you, Scott. Let's talk about two different kinds of apps, and how we would tackle them. So probably one of them is just like a crud app, right? You've got a node JS backend, you got like a React, or Svelte, or Vue frontend, you have a database, you have authentication. What's your plan of attack for something like that?

• 13:28Scott Tolinski?

  Oh, man, the reason why I'm going to have a hard time answering this question, Wes, is specifically because I

• 13:36Scott Tolinski?

  The only structure I have in planning things is that that planning process changes every single time. So it depends on how I'm feeling that day. So let's, let's break it down. Okay. I tend to take something, especially like a crud app, a crud app, I'm almost always thinking about data first. Always thinking about what data I need to have, what the structure of that data is, and then doing my very best to accommodate for the entire app at once. Things change, projects evolve, but nowadays I am taking out and thinking about that entire data structure first, building out that schema. And then even as

• 14:20Scott Tolinski?

  far as like planning the UI and front end of all these things go, I will build out the route structure in files before writing any of that code. If your framework allows for that, creating the files, creating the routes, things go where they're supposed to go. And then you start at the root and work your way to the leaves in terms of UI stuff and then changing and evolving as you go. And I like to build a lot of things my dang self for some stupid reason. So inevitably I'll be writing a form and being like, this should be abstracted. Okay. You know, and just kind of do that as I go. So it's starting at the root and then routing out. So that, that's pretty much it. And now more recently,

• 15:05Scott Tolinski?

  I'm worrying about the UI in code of paint at the end because it's easy to change HTML. And if I don't write any classes on anything, I don't have to worry about that. And another thing is, is the way I work is with scoped CSS via Salt Component. So like, man, I can just write CSS targeting specific elements and not have to worry about even like modifying classes or changing it or whatever. So for me, that, that's kind of the way I go. An interactive component, 3D color, those types of things, man, a lot of that stuff I just YOLO. I'm just writing everything all at once. I'm just dumping here and there. Just going for it. Yeah. The database, like I always talk about like bringing a database into this world is like caring

• 15:50Scott Tolinski?

  for a pet or a child where like now you got responsibilities.

• 15:55Wes Bos?

  Yeah.

• 15:56Scott Tolinski?

  If I don't have a database, you know, whatever, I can go off and just goof around. But with the database, I'm like, let me actually think about this.

• 16:04Wes Bos?

  Yeah. So when I have a plan for like a, like a full stack crud app, what I'll do is I'll first install everything that I need. So that includes all my backend packages, everything that I think I need, right? You're not going to know exactly what you need, but you need your like your server framework, your front end framework, all of that, your database. Then I'll go into database usually. Sometimes I'll try to like skirt it, especially if I'm trying to go like as fast as possible. I'll try to like, I don't know, just store it in a file and whatnot. But unfortunately, I sometimes, I often regret that because then I have to go back and shoehorn it in. So database often auth,

• 16:46Wes Bos?

  if I feel like I need it. And then the reason behind that is because when I'm making features, if you don't have the concept of auth or users in your application yet, then it's, it's kind of a pain in the butt, right? It's much easier to get that stuff set up ahead of time. Then, once your like sort of foundations is down, then I'll just go simply feature by feature. I'm not going to scaffold all, all of my routes. I'm not going to scaffold out any UI components or anything like that. I'm simply just going to say, I'm working on this feature right now where a user can create list and read, update and delete all of those pieces, you know? And then, okay, that, that, those are all on the thing. Now let's go on to the next feature.

• 17:29Wes Bos?

  And then I'll, I'll sort of get two or three features out and you can spend a little bit more time on what the actual UI works. But I do go like the whole, like the blending of backend logic, server logic and like front end logic is, it's, it's just one thing to me these days, you know, like when I'm building a feature, I don't necessarily think like, let's make a whole app API, REST API first. And then I'll go into it. It's like, no, I'm building all of that exactly at the same time, especially with like RPC.

• 18:00Scott Tolinski?

  Yeah, I feel that for sure.

• 18:02Wes Bos?

  Also, translation, that is thankfully something I don't have to, I haven't done in many years, like multilingual, such a pain in the butt. You certainly will want to have that ahead of time.

• 18:15Wes Bos?

  Yeah, cuz that sucks.

• 18:17Scott Tolinski?

  Yeah, that sucks. That's hard to do. Yeah. Next question for Mr. Rye. I've been working as a front-end developer for the past six years with a year of backend. I mostly do React and Next.js and for backend, Node, Express and Postgres. Currently, I am not sure what to do. I mean, working full-time, but not as excited before. Oh, sorry. Man, I'm reading it. I am working full-time, but not as excited before. I feel like the growth-

• 18:49Wes Bos?

  You still mess it up. I am working full-time, but not, I'm not as excited as before.

• 18:54Scott Tolinski?

  Okay, yeah, sorry about that, folks. I feel like the growth for me has been stagnant. What do you think I should do to have the same energy as I have years back? Man, I'm just reading. Okay. In short, I need some guidance for the career path goal. Mr. Rye is working and he's just not as excited before. How about that? Yeah, you know, I think, I, I think we've all hit this, especially when you have long-running projects. Those projects like can get to a point where like, yeah, you got stuff to do, but is that stuff interesting or exciting? Or is it the same thing you've done 100 times before? Or is it just like, it's not calling to you? The cool thing here, Mr. Rye, is that

• 19:36Scott Tolinski?

  your ability as a developer opens you up to be able to experience all kinds of different problems, all kinds of different UIs or backend challenges or any of that stuff. And I know that a lot of this is your day-to-day job stuff, and that, that can feel tough. But maybe there's something else that can be exciting while you do your day-to-day job stuff. Maybe you can get your day-to-day job stuff done early so that way you can work on problems that are more interesting to you.

• 20:12Wes Bos?

  Take on dangerous hobbies.

• 20:14Scott Tolinski?

  Take on Danger. What was that where people were seeing where they could iron in different locations, like they were tightrope walking and ironing or playing chess? That was like some of these things. You could bring your computer while tightrope walking. No, I think really what you need to do is is find a way to tap into some bit of tech that is calling you. And that can bring you more interested into the big development picture overall. Maybe there's something that exists in your day to day job that could help the org, can help your day to day job without it necessarily being on your task

• 20:57Scott Tolinski?

  list and something that you can spend some time really diving into. I really think that is the whole thing is that novelty at the end of the day is always going to be more exciting. And if you can find some way to inject novelty into your work, that is going to go a long ways for improving your motivation. We talked a couple of episodes ago about just how motivating Hack Week was and all those things. And we got a comment on the video from somebody saying, oh, we, our company instituted a Hack Week, but then soon after, the managers declared that all the projects have to be something that would push the

• 21:37Scott Tolinski?

  core product forward. And it's just like, y'all missing the point. Missing the point. Like, yes, that's great. And people might find those things, but to enforce that is going to squash all the novelty. It's going to remove all the creativity from it. And ultimately, it's removing the entire purpose. So you've got to find some way to inject novelty into your day to day job.

• 22:03Wes Bos?

  Yeah, you got to have fun. And we get this question quite a bit. And part of the answer is yes, like work on more stuff, but something that is different, something that is exciting. But also, like, I agree with that as well. You have to always be having side projects and new stuff and be dipping into things like that creative, flexing that creative muscle is super important to fending off that burnout where you're, you're just like, I'm so, so sick of working on this stupid thing every day in and day out. But also, like, I think there's probably other Environmental stuff, like if I haven't worked out in a couple of days, I just, I just don't feel as excited about the work that I'm doing.

• 22:46Wes Bos?

  And then once I get back in the gym, I'm like, ah, that's, that's it, you know? It wasn't that I was using the wrong AI for this thing. It was that I needed to lift weights. Perhaps there are some non-developer things in your life that are, are worth addressing as well.

• 23:06Scott Tolinski?

  How can you have non-developer things in your life? What does that entail? Like, that's, I, it's, it's true though.

• 23:13Wes Bos?

  Like I, like my life is very much, very much about coding. Like almost everything I do is, is about coding, right? And yeah, it's, it's hard. It's hard because that's all I want to do, you know? But then the burnout man comes, comes calling and you're, you're going to get bit.

• 23:33Scott Tolinski?

  Yeah, I know.

• 23:34Wes Bos?

  Loving husband says, hey guys, my wife needs a website. In order to create and publish content for a personal hobby of hers, she turns, hopes to turn into a nonprofit. The site will mainly be a blog with educational content, but she doesn't want any of the social features like comments or likes, et cetera. There will also be a page to donate and eventually, yeah, years down the road, a merchandise store. As a mid-level developer, I'm interested in building this for her to grow and level up my skillset so that I can become a senior engineer. I would love your thoughts on which tech stack. Man, so many questions about tech stacks today, which would be good. I'm primarily a JavaScript developer, looking at future JavaScript jobs.

• 24:15Wes Bos?

  I'm interested in building this in Redwood SDK since Peter came on the podcast, but maybe it is too new. I have some experience in WordPress, but I want to choose a path that will help me grow and make me the most viable candidate for future job opportunities. Thanks for your help. Yeah, this is kind of an interesting one because you need to think about. Like your wife and her hobby of like, you have to build something that is good. So that they actually use it. Um, because certainly I've built lots of like CMSs or I've built lots of apps over the years, but then like, no, we're just talking about this with, with home assistant as well, where like Scott and I are trying to get our home assistants to the wife factor, like

• 24:57Wes Bos?

  close enough that the family will actually use it and it's not like a pain in the butt. Right? So you need something that's good on that half, but then you also want to like, like, further your own skillset and, and, and learn a whole bunch of new stuff. And it's a really good portfolio project as well. So I think you should break it down into building it on something that is a little bit more stable because like, like I agree, Redwood is awesome, but it's, it's certainly very early. So I probably would not bet the farm on that just yet. And, and start asking yourself like, what do I need? Do I need a CMS? It sounds like you need a CMS for this

• 25:39Wes Bos?

  type of thing, right? And then maybe look into, into something like payload. Um, sanity is a paid option, but also a really good option. You could use WordPress and just use the, like the JSON API and suck that on up. Um, but I don't know, like what I, I always tell people, don't build your own CMS because it's, that's a, that's a hard thing, right?

• 26:01Scott Tolinski?

  Yeah.

• 26:02Wes Bos?

  There's a lot of features in the CMS.

• 26:04Scott Tolinski?

  Loves to build their own CMS.

• 26:05Wes Bos?

  Yeah.

• 26:05Scott Tolinski?

  Built my own CMS like 18.

• 26:06Wes Bos?

  It's really hard. And then just think about like, like integrations versus building from scratch, like e-commerce store. I wouldn't worry about that right now. You know, when that comes time, you gotta look at it and be like, okay, am I selling like three things and I'm not worried about inventory? Then yeah, you probably, you probably put that together with, integrate with Stripe and whatever. And that'll be a fun project. But if it's like, you need inventory management and shipping and emails, something is out of stock when they need to restock, then you're probably looking at like a Shopify or something similar to that. So.

• 26:40Wes Bos?

  That's a whole lot of non answers of like, what stack would you pick?

• 26:44Scott Tolinski?

  Yeah.

• 26:45Wes Bos?

  I would probably pick a full stack modern JavaScript. So whether that is 10 stack start, maybe look at some of the new remix stuff that's coming out next month. Next JS is a contested option in that case, or go like, like full stack Nuxt and Vue. That's probably, that's pretty in demand as well. You certainly want to pick something that is fairly established and in high demand. And, and, and right now that is, that is a full stack JavaScript. And then go from there and figure out what integrations are you gonna need?

• 27:23Scott Tolinski?

  Yes, I'm gonna go ahead and say tech choice does not matter at all, in my opinions. Whether it's mature, not mature, whatever, tech stack, whatever you pick, does not matter. What matters is that you make it work and that you make it work well and that you make it easy. I have done this so many times and like have handed something off that like works. And then people go to use it like, cause it's a side project. It's just for like casual, whatever. And then, oh, here's a bug here and there, here's a bug here and there, here's a bug here and there. Next thing you know, you got a whole ass job in front of you. Like you're, you're now tracking edge cases, you're doing this or that.

• 28:06Scott Tolinski?

  Just make sure you understand exactly all of the functionality that is needed. Out of the gate, you think about it deeply and you make it good. I think that's the only thing that matters. Yeah.

• 28:17Wes Bos?

  Beautiful.

• 28:18Scott Tolinski?

  Next question from RGV Cycling. How do you deal with a toxic work culture whose source is your boss? Oh, man. So it depends.

• 28:31Scott Tolinski?

  Because where is this boss in the chain of things? Is this boss the boss? Like the boss? Or is this boss your boss? Because a toxic boss is a problem. But a toxic boss is not just a problem to you. It's a problem for that whole organization. It's a problem for that company. If a boss is being toxic for whatever reasons, in terms of like not being like giving the team the support it needs to complete its tasks and goals, whether that is like being unprofessional,

• 29:14Scott Tolinski?

  having potential HR issues, you know, those types of things. That is a different situation. I will tell you this. I have been in two situations with a major toxic work culture because of a boss. One of each, one of which the boss was the co-founder of the company and I was a direct report. That one, you can't do anything about it. You know what I did? I quit. I said, I quit. I've told this story a whole bunch because it's one of the reasons we started Syntax. They were messaging me on a Sunday at 10 o'clock, the week my first child was born because of a broken feature in pre-alpha software. I quit on Monday and I did not have a job lined up.

• 29:58Scott Tolinski?

  I just had a kid and I quit because you can't just live with that. Now, I'm not recommending everybody just go and quit. If you have a unfixable toxic boss, you probably want to see if you can line something up. But that will ruin your mental health. It was ruining my mental health and best decision I ever made to quit that job. Another number two scenario where I've had a toxic boss was a project manager. I was a part of a team at Ford and I was working on some experimental interfaces for Ford as like a part of this crack team of like 30 people. And we had a boss and this guy was

• 30:42Scott Tolinski?

  A nice enough dude, but he was doing a lot of weird stuff like saying inappropriate things, getting really aggressive at some of the other PMs and stuff like that. He was my direct boss. And at one point, he stepped over the line several times. And he had never stepped over the line to me personally. So I didn't feel like it was my place to step out and like, it was toxic, but like, I was fine completing my tasks. But he stepped over the line with one or two other folks. Those folks went right to HR. And guess what? He got shit canned, like day of, out the door. And guess what? We were all fine. It was

• 31:25Scott Tolinski?

  great. And in fact, it was a huge, huge boost. So like, if you have like, very real, like professional concerns about this person, HR is there for a reason. You can talk to them. You don't have to like, go snitching on minor little things here and there. But if somebody has crossed a clear gross boundary in some sort of way, talk to HR about it. If this person is at all receptive, talk to them about it. Now, only do that if, only do that if you, you know that you'd be comfortable with that. You'd be like, okay with getting fired potentially for going to them and expressing your concerns about a toxic work culture

• 32:06Scott Tolinski?

  that they've created. So like, maybe, you know, I think ultimately, if you're looking for a low friction, if it's a professional HR thing, go to HR. If it is something that maybe even like, I would say going to their boss is something you could possibly do. But like, you have to be very gentle in how you do that. And you have to be prepared for potentially getting let go or creating more problems.

• 32:31Wes Bos?

  That's a lot to answer, Scott. But honestly, I think this, this can be dealt with a lot easier is you get, get as big as you can to assert your dominance.

• 32:40Scott Tolinski?

  Yeah.

• 32:40Wes Bos?

  Arm wrestle. Just beat him in arm wrestle.

• 32:42Scott Tolinski?

  Arm wrestle.

• 32:43Wes Bos?

  Assert dominance. That's done.

• 32:44Scott Tolinski?

  You know what? Talking about asserting dominance, my kids have decided that they really want to do thumb wars all the time. And

• 32:51Wes Bos?

  Thumb wars would work as well. Imagine, like, there's no man that loses that thumb war that is not just like, broken inside.

• 32:57Scott Tolinski?

  Dude, I, I will tell you what. I destroy my children at thumb wars. They're like, they're I don't even let them for one second. You gotta assert that dominance.

• 33:10Wes Bos?

  Oh, man. All right. We got another question about stacks for building a SaaS project. I want to help a friend build a SaaS product. We want to dish out an MVP and aim not for so many users at the start, of course. So you're aiming low. That's good. I like that.

• 33:27Scott Tolinski?

  Yeah.

• 33:28Wes Bos?

  "I can't get hung up on hosting, rolling my own auth, etc. I want to pick a quick and easy solution that would not break the bank, so have a generous free or next cheap paid tier. What I need is server, database, hosting, planning on one full stack framework like Tensac." Okay, so he needs a database. He needs somewhere to serve it up, right? He needs image storage, email sending, and then authentication. What are some nice providers for each? For hosting, so far I've used fly.io. For auth, I've used Clerk, but I have never hosted any images anywhere. Could Cloudflare meet all of my needs? The thing that I don't want to do is go with AWS and doing that is too much work.

• 34:13Wes Bos?

  Do you have a suggestion for this kind of stack? The goal is to not pay much monthly, but have a functional app that scales. We can start dipping into the bank if we get more users." Yeah, this is the never-ending trap of the free tier. And I have had the rug pulled out from under me so many times that I know that you go, "Ah, whatever. If we get more users, we'll start paying for it," or whatever. But, man, I have some super high bills of stuff where I'm just like, "Ah, I don't feel like switching this over. I'm just gonna pay the man and move along." So certainly be very wary of generous free tier, because those generous free tiers are

• 34:55Wes Bos?

  often funded by venture capitalists, and those venture capitalists want their money back at one point. We had one on the show. And he wants his money back eventually, plus some. So it's not, it's not a, a nice thing that they're doing. So it's always hard, right? Like, like, do you just go and, and roll together a million services? And then just, just YOLO it. And then before you know it, you're like, remember we had that like, no code guy on and he said he spent $700 a month on services, just clipping them all together.

• 35:31Scott Tolinski?

  Yeah. You can, can't find me doing that. I'll be honest.

• 35:34Wes Bos?

  Yeah. Honestly, I'm a, I'm a CloudFlare stan. I think that that is probably a good, CloudFlare does not send email. Um, you would have to hook up, but what, whatever you choose for sending email, choose something that supports like an SMTP gateway, meaning that like, don't use something that is like, you use their SDK to send email and you're like totally locked into them. Use something that simply uses SMTP, meaning that you can, you can sign up for, well, I don't know, what are the ones? I use Postmark, but everyone hates them now because they got bought and Lucky Lucky, the VC's favorite cousin, private equity is they just,

• 36:16Wes Bos?

  service goes down, price goes up. Uh, what are, what are the other ones that people use?

• 36:22Scott Tolinski?

  For email?

• 36:23Wes Bos?

  For SendGrid, Mailgun, SES is, he doesn't want to use Amazon. So yeah, you can't use that. So yeah.

• 36:31Scott Tolinski?

  Resend is one that people are using nowadays.

• 36:33Wes Bos?

  Resend is the one that.

• 36:35Scott Tolinski?

  It does more though. Yes.

• 36:37Wes Bos?

  Yeah, it does a lot more, but then you're, you're locked into.

• 36:40Scott Tolinski?

  Yeah. Yeah. Yeah.

• 36:41Wes Bos?

  To their system.

• 36:43Scott Tolinski?

  Yeah. I'm pretty much always using something like SendGrid or, or.

• 36:47Wes Bos?

  Yeah.

• 36:48Scott Tolinski?

  Paper.

• 36:48Wes Bos?

  Image storage.

• 36:49Scott Tolinski?

  Oh, I think the one I've always used. Post something, post.

• 36:53Wes Bos?

  Postmark?

• 36:54Scott Tolinski?

  Yes.

• 36:54Wes Bos?

  That's what I've been, that's what I've been using for many, many years.

• 36:57Scott Tolinski?

  Yeah. Uh, I used to use Mandrel until Mandrel got.

• 37:01Wes Bos?

  Yeah, they, they took it away.

• 37:05Wes Bos?

  Image storage certainly use Cloudflare's image storage. It is extremely cheap. The pricing, yeah, the pricing is great on that. They don't charge for bandwidth, but they do charge for transforming him into multiple sizes and for storing those images on their server. So like doing the math on these things is, is always hard because it's, it's, it's really easy just to look at like $20 a month for this service. But if you're trying to like, look at raw infrastructure, you have to start doing these weird calculations of how it does. FlyIO, awesome. I think I would probably stick with that, right? You can, you can throw, you could go like an external database host as well, but you can, you can throw it all, all on there as well. Authentication, yeah, this is, I, I probably, what do you think?

• 37:50Wes Bos?

  Betteroff, Scott?

• 37:51Scott Tolinski?

  Betteroff, 100%.

• 37:53Wes Bos?

  Always hesitant to use like a SaaS that is auth.

• 37:56Scott Tolinski?

  Don't ever use a SaaS that's auth. I like, don't understand that whatsoever. Yes, there are, unless you need like high-end concerns, like what is that? A single sign-on?

• 38:06Wes Bos?

  Single sign-on or?

• 38:07Scott Tolinski?

  Yeah. Yes. Betteroff is, is like so insanely powerful. It does everything you need to do. It doesn't lock you in. Like, I can't imagine paying a service to do auth. And then now you got a, now you've got another database that's hosted on some other company that's storing just your auth and stuff like that? No, no thanks. Keep it all in one spot for me. Or at least under my, my controller purview. I know you mentioned the images thing. The, the Cloudflare Images, Transform Images API is really good. So I've been using that lately. That's been something that's been nice for me is the Cloudflare Images with their, their capabilities there for database. SupaBase is a great host for Postgres.

• 38:51Scott Tolinski?

  It's a great way to get set up easily with Postgres. Planet scaled is Postgres now. So you can do either of those two options. Those are types of services that I do offload. We've had, we have Planet Scale for the syntax and I like Planet Scale. So I would, I would probably use something like that for each of those. Again, we said mail. Again, Betteroff for me is the choice for auth.

• 39:12Wes Bos?

  Other images is like, clout in area is good, but it also suffers from that like drug dealer free plan, you know?

• 39:20Scott Tolinski?

  Definitely.

• 39:20Wes Bos?

  It's very generous, but it goes to 100 bucks a month. Once you go over that and that's especially if you hit this place where you're like, oh yeah, we have an app and I want to keep it running and it's not bringing in a ton of money. But you know, like you're kind of just maintaining it and people use it. Those like monthly costs can can get out of hand really quickly. You could be six, 700 bucks between all of these services before you before you realize it. Danny Manny says, is REST first GraphQL still a relevant question? Are there any advantages for going for a GraphQL API over REST API? So this is, this is a great question. GraphQL, super popular for for many, many years.

• 40:02Wes Bos?

  Everybody thought it was was the rest killer and in probably the last three or so years, it's sort of fallen out of love. And I think there's kind of two reasons for that. So GraphQL seems to be still very popular in the corporate world where people are combining multiple data sources, multiple services all into one. So we had, shoot, what was his name? He worked for a like a big BBC or something like that, big TV vendor. And they have 30 different teams and they need to have a single API for sending data, performing mutations and querying all of that data and a GraphQL layer.

• 40:46Wes Bos?

  That's this is exactly where or sort of Gatsby went with with their whole GraphQL thing as well. As a single layer that sits on top of, I don't know, your 40 year old COBOL API and your six different REST APIs and your internal Salesforce weird thing, just as a nice single layer. GraphQL also is is great if you want to have a single API for like an iOS app, Android app, web app, TV, you know, all of that stuff. However, it is for most people, it's not that GraphQL was bad, but most people I think found that this is too much overhead and you found yourself doing way too much work

• 41:28Wes Bos?

  on the server GraphQL schema in your database and then on your client. There's just way too much stuff, whereas a REST API was fine for a lot of people. All right. So I would say. Oh, go for a REST API, or I would say probably the third option, and then the reason why GraphQL fell out of love is RPC.

• 41:48Scott Tolinski?

  Yeah.

• 41:48Wes Bos?

  Meaning that people aren't even building REST APIs anymore. They're simply just using RPC, meaning that they can call server functions from the client. And, and you don't have to worry about API endpoints and accepting arguments and whatnot. As you're, you just define your server function on the server. You can call it from the client and obviously there's authentication and all of that stuff in the middle there that will make sure you're not doing stupid stuff. But that, where the TypeScript just flows from the backend to the frontend is, is beautiful. If you are building an app that is simply just backend web frontend.

• 42:26Scott Tolinski?

  Yeah, I think the, the, what we saw with GraphQL was the hype curve went up and I, the hype curve went up, right? And this was all the people being, wow, this is so cool. This solves so many problems I have. And then it got into the point where people are like, everyone's talking about this. Therefore it must be right for me. And then they implement and then they're like, wow, this is a lot of extra steps. Now I'm hitting N plus one issues. Now I'm having to write way more code than I was even with my, my REST API. Or someone like me, I came from an RPC setup before all of this. I mean, Meteor is essentially RPC in many ways. So like, I went from RPC to GraphQL to REST, now back to RPC. And I'm like, why did I ever make that jump at all? Right?

• 43:12Scott Tolinski?

  So I think a lot of people, like you said, they discovered it wasn't necessarily right for them. And in turn, what happens is there becomes this like pushback, like GraphQL sucks or something like that. When in reality, you just tried to shoehorn it in something that it wasn't made for. And so I think GraphQL, for the use cases you mentioned are, is like great solution. There's a lot of great upsides to GraphQL. There's a lot of great reasons to use it in the right scenario. But if you are just... You know, building an app, you got control of the front end, back end, whatever. Like, I don't see any reason to do that unless you really need to build out this API layer that connects it all. So yeah, that's my thoughts on it. I like GraphQL personally.

• 43:54Scott Tolinski?

  I haven't used in a while because I haven't been building stuff and I'm like key the type of person who hit the, this isn't for me. This isn't for my needs, right? I'm not building things that need this, so therefore I'm going to stop using it. But that doesn't mean it's bad or not useful or anything like that.

• 44:11Wes Bos?

  Yeah, depends on, it's a tool, right? And it solves a lot of hard problems for people that have those problems. But I think a lot of people realized this is a lot of typing for problems I don't have.

• 44:24Scott Tolinski?

  Lot of problems, yes, exactly. All right, next question from Bob, bob.com. Bob, I think Express plus View plus MySQL plus AWS was the best stack I've used in production. I've built large enterprise apps.

• 44:37Wes Bos?

  Another stack question, yeah.

• 44:38Scott Tolinski?

  Yeah. Now on my job, I've adopted Next15, Payload3, Postgres, plus Vercel. Although it's growing on me, I sort of hate the direction that Vercel is steering modern web development. Now that React is getting a compiler inspired by View. Inspired by View, bro? View, how to say it? Inspired by Svelte, man.

• 45:00Scott Tolinski?

  Come on. That was the original compiler, yes. Inspired, but TSX is objectively uglier than View templates. Agreed. And sorry, but Svelte has some ugly templating too. No, that, bro, what are you talking about? It's handlebars. All right. The Vercel stuff gets more complex, more black boxy, and LLMs often suck with newer technologies. Your opinions? Yeah, I mean, I agree on a lot of this stuff. I gotta say, it's not like, I don't want to declare myself a hater, but like, man, I never understood the NextJS appeal and I didn't understand the React appeal. And I don't necessarily still understand it because was definitely a skeptic of React when it first was announced and then I sucked it up and used it for 10 years.

• 45:43Scott Tolinski?

  And then I went and stopped using it and was like, what did I gain? What did I gain there? And personally... Yeah, like you can do everything that you can do with React easier and oftentimes with less trouble and better performance in other systems. That's just my thoughts personally. The Vercel business too, the thing that bugs me the most about Vercel is not like them as a company or what their goals are. It's the people who act like hosting on Vercel is the only way you can have good developer experience and an easy time hosting anything on the web. I saw like a Reddit thread the other day and like there were people being like, I use Vercel because it's the only one with

• 46:27Scott Tolinski?

  good DevX. And then there was a response to that being like, oh, there's a lot of other good options too. And they're like, I don't want to host my own Linux box. Like, that's not the only other option. Like, going straight AWS or running like a Coolify or like hosting your own VPS, it's not the only other option than like Vercel. There's tons of other options. Where that is, I think Cloudflare is easy as hell to host on. Railway is super easy to host on. Fly.io, really easy to host on. Even using SST, less easy and more into getting into the weeds there. But like, yeah, there's a lot of options to host that are easy. TSX, man, I find TSX to be ugly too. I'm with you on that one.

• 47:10Scott Tolinski?

  I could rant on this all day, but I'm not going to. So, your opinions? Bob, I agree with you on everything except for Svelte having ugly templating syntax. I think Svelte has some ugly syntax sometimes, but I think the templating syntax is perfect and has never done anything wrong. So, I think you're wrong on only that piece, Bob.

• 47:31Wes Bos?

  I honestly think he's right in that, like, sometimes I do think about like the good old days of Express backend, simple frontend, yeah, MySQL database. That was a fantastic stack. And I believe that you probably like that because of the simplicity, you know? You knew it really well. You can get stuff done. You can hop into the app and find where it is you want. And there's not a lot of like, there's not a lot of like gotchas in that, you know? Like, having to know NextJS and like, I know Next and React very well, and I have a swath of Weird gotcha knowledge, you know?

• 48:13Wes Bos?

  And then the people like, like I love React, but the people that say like, "Skill issue." It literally is a skill issue that you don't know these weird gotchas and how these weird things work. And that is fine to have that skill issue because it's not something you maybe should have to spend your brain power on. I agree with you there.

• 48:34Scott Tolinski?

  Yeah, I'd rather have skill issues with the web platform itself.

• 48:37Wes Bos?

  Yeah, yeah, exactly. Than having to figure out how like, like updates and affect dependencies and stuff work like that, right? So yeah, I agree with you. And I think like, what you should do is there are in every single category, there are very simple, easy to use options in there, you know? Hono, Hono, Vue, maybe even just go full stack Nuxt. You could still use MySQL, you could still use AWS.

• 49:09Scott Tolinski?

  Still exists.

• 49:10Wes Bos?

  All of this type of stuff, you don't have to. And like, like on the like Next, Payload, Postgres, like these things aren't, they're not making them complicated for complicated sake. They're trying to do things where you can build a fast ass website and host it and scale it and do all of these types of things. But often that means you have to do things in a very specific way. And that rubs a lot of people the wrong way because there's, like I said, there's a lot of weird knowledge that you have to get. So I don't, I don't think that like, Vercel is intentionally doing any of the stuff. They obviously have a business and they want it, want it to do well. But I, I honestly do think Vercel cares about the future of the web.

• 49:55Wes Bos?

  It's just that like Next JS is what 10 years old, right? There's, there's a lot of baggage that comes along with a very old framework, especially when you're trying to do things like have dual compilers or you're trying to have a Rust based Webpack alternative, but also still maintain the old one and still maintain like, like your, your pages API and then like, there's all of this sort of like baggage that needs to be supported. And then when there are new features that need to come to Next, they have to consider all of that. How will this work with all of the baggage and how will this work with, with everything? Which is probably very frustrating to, to have to do that.

• 50:36Scott Tolinski?

  Yeah, I think my biggest rub is when like they choose to use their own in-house things like walled garden approach. Like sometimes Vercel really takes the walled garden approach at the expense of the product, the experience and everything. And that rubs me the wrong way because the development experience is so much better in the extra outside world.

• 51:03Wes Bos?

  The amount of times I've had like a next JS question and the answer is Vercel answer and everyone just assumes that you're hosting it on Vercel, that is very frustrating because like those, those things are separate, you know, they shouldn't have to come hand in hand there. Last question we have here from Sam says, have you seen the new Tanstack forms? Aren't they great? Fully typed via inference. All inputs are totally controlled. So this is awesome. I actually did not see this. So first of all, there's also a Tanstack DB, which is like a local first sync engine. I'm very excited about that. And then Tanstack

• 51:46Wes Bos?

  Form is a headless UI for building type safe forms. And I'm really excited about this because when you want to build forms on the web, and this is not just a React thing, this is works with absolutely everything.

• 52:02Scott Tolinski?

  This is a React thing. No, this is a React thing.

• 52:04Wes Bos?

  When you want to build forms, you have to do a lot. You have to have like types and you have to have validation. Sometimes you want to bring ZOD in to make sure that the data actually looks fine. And then you often have server side validation, then you have messages that need to come back. And like, it's very frustrating building forms. And I feel like I've spent my career building that, this, which is forms, you know, you submit something, it sends data and it comes back and you can display messages and whatnot. And this is just a headless UI, which means that like you still, you bring, you still bring the HTML, but this brings a lot of the functionality and you would wrap it. So you can still bring your ShadCN or whatever UI component library that you want. But if

• 52:49Wes Bos?

  you want the functionality of The, there's validation. What happens when you have a submit handler, saving data to state? And then like fully typed all the way down so that you can take the data out of the form and use it in other parts of your application is, is really good. So I'm, I'm glad that Tansack is, is the team there is solving forms. Cause I absolutely love the approach that they've taken on so many other things. And now, now to see that they're, they're tackling forms and form submissions and validation. It's hooked into standard schema, which we did an episode on, which means that it's not just ZOD.

• 53:30Wes Bos?

  You know, it's any validation library that adopts standard schema can be used.

• 53:36Scott Tolinski?

  Yeah. I, I will say, I think Tanstack Form, I love Tanstack stuff. I love Tanner. I, I love what they're doing. I will say that this type of library is solving a problem that like only React has. Because when you get into binding form state to like simple state variables, you end up having such an easier time. Uh, I think there's like two types of issues with forms. One is that people sometimes control their form when it doesn't need to be controlled. And then therefore like you're allowed to have a normal form.

• 54:16Scott Tolinski?

  And then like use the data from form data or use the data from the form itself. And control the form on submit. If you don't need a controlled form, you're allowed to do that in any framework. And people just don't, people are going to automatically wire up every single input to a state variable all the time when they don't need to. So I think that's one problem. But another problem is that complex form state becomes so much effortlessly easier when you have a binding state. You got binding state, you don't have to do on change events. You don't, the state is just there. It just updates, it's just available. And then the stuff that this would come into handy for would be like the on change async debounce kind of stuff.

• 55:00Scott Tolinski?

  Like that's where the Tanstack Form stuff would actually help you out. But so many of these things. If you're bringing your inputs.

• 55:07Wes Bos?

  I don't think you understand what this is. You're saying that this is just like a way to bind state.

• 55:13Scott Tolinski?

  No, no, no, no.

• 55:14Wes Bos?

  To inputs?

• 55:15Scott Tolinski?

  No, no, not necessarily. I'm saying that like forms in general is like it being a React problem. The reason why you need an additional like library to do that in forms in React is because to get complex with it, you then start having to take control over everything, everything. Like what, what, what exactly, what problem is this solving?

• 55:40Wes Bos?

  So I built the submission form on the Syntax website, which can take in like, there's a dropdown of different types of submissions. And then there's, there's a data input, you can put your name. And like, I had to build all of this stuff myself in Svelte, meaning that like, when somebody submits the form, you go to the backend, you validate the data, you send that back and then you have errors, you got to figure out where the errors are attached to. If you have fields that are linked together, password, confirm password, focus management, multiple, multi-step forms. All of that stuff is, is something I've had to rebuild.

• 56:23Wes Bos?

  Like Svelte doesn't have any tools for working with forms built in, other than you can submit it to, to the client. And I guess the, the input binding.

• 56:36Scott Tolinski?

  What does this do that gives you better multi-step forms than just using straight up state and input binding?

• 56:43Wes Bos?

  This is not about state. This is about validation. This is about handling submission. This is about when somebody types into like a box or maybe you have like a slider and you want to check if that thing is available. I think that this stuff is really handy. It's not just state. No, no, like I, I've built many forms in Svelte and I think that this would be. Very helpful as well.

• 57:08Scott Tolinski?

  I don't get it. I'm gonna say that I don't get a single thing that this would help with, that I cannot do with.

• 57:14Wes Bos?

  You can do anything you want. It's just not like...

• 57:17Scott Tolinski?

  What I don't see is, how is this making any of that easier, is what I'm saying.

• 57:21Wes Bos?

  Okay. I, I don't know. I think it's, there's a lot of people who build very complex forms, and you want all of the validation built in there, and it's not just a simple HTML form that gets submitted, and then you come back with, with any validation that used to happen.

• 57:39Scott Tolinski?

  That's a state.

• 57:40Wes Bos?

  No, it's not just state. No.

• 57:43Scott Tolinski?

  I built some complex ass forms, and I had no issue just doing state.

• 57:49Wes Bos?

  Let's see your, your complex ass form.

• 57:52Scott Tolinski?

  Oh, man, I'm working on one right now. Although, it is, I will say, it's on my Linux computer. I'm working on one right now for uploading video that then brings back thumbnails, and then if you have thumbnails, you can select the specific frame of the thumbnail. Otherwise, you can have a code or an image input, which then changes all the inputs, and specifically, the, the types of fields and everything like that. Not extremely complex, not multi, multi, but like, even multi-step forms, again, it's just a big old state object that is like, where, what is the status of this form? What's the UI then being shown there? Validation, man. I mean, validation can happen in all kinds of easy ways. I mean, that's not like...

• 58:32Wes Bos?

  Yeah.

• 58:33Scott Tolinski?

  That's not a challenge I have, I don't think.

• 58:35Wes Bos?

  Yeah. All right. I will say, like, forms in React are, are probably the worst, right? Like, it makes no sense that you have to listen for a change handler, and when something changes, you have to then go update state in order. Like, that's such a broken, awful, awful way to, to do it, right? I hate doing forms in React, but I think that, that this thing would be handy in, in anyone, because it works. They have examples with, with Vue. They don't have Svelte examples, though, so maybe you're right there.

• 59:04Scott Tolinski?

  Yeah. Yeah, I, I just don't get it. I, I sincerely hold up that I could be wrong on this. I, I definitely think that I could be wrong on this, but I've never personally written a form that was too complex that I couldn't do it with just managed state, personally.

• 59:21Wes Bos?

  Yeah.

• 59:21Scott Tolinski?

  That's, that's, yeah. Wes, I think this is the first major disagreement we've ever had on this show.

• 59:25Wes Bos?

  No, no, I think, I, I...

• 59:27Scott Tolinski?

  You okay?

• 59:27Wes Bos?

  I think it's a skill issue. Yes, yes. No, I'm, I'm totally fine.

• 59:34Wes Bos?

  But, all right, let's get into the last section, which is sick pics.

• 59:40Scott Tolinski?

  Sick pics. Hey, I got an interesting podcast, you know, podcasts for me, I love finding new podcasts, new and interesting ones. And one of the things that always bugs me is like Wondery podcasts, you know, they're 800 ads for other shows and just like how they break up stories like Wondery, good production, all that stuff. But like, man, some of their, their way that they do things bugs me. That said, I was willing to deal with it for this podcast, which I, I found to be so fascinating. I had to send it to my wife for psychology reasons, but this is called Flesh and Code. And it's really about people falling in love with their AIs and like a AI companionship app.

• 1:00:22Scott Tolinski?

  And like the just wild amount of like attachment people would have to this AI. And like, it's largely people who do not understand how AI works. So like that, I feel like that's part of it. Because they're interviewing this guy and he's like, I don't know, I don't get her personality just changed overnight, you know? And like the, his friends are just like, do you not know how any of this stuff works? Like, there's not a person here, there is not a, a, there's not an entity here. And, and this shocking amount of numbers, like sheer numbers of people who are falling in love with AIs or like, like treating them as a real person.

• 1:01:07Scott Tolinski?

  Or trusting them with all this kind of crazy personal information or getting emotionally invested in these things. Uh, man, this was a disturbing and eye opening podcast for me to listen to. I was like, holy cow. Yeah, we, we are there. Uh, and it is, dude, it's wild. Yeah. It sounds awful and it definitely will make you feel a little, but as somebody who works in this space, I, I think it's kind of important to understand this stuff. See what's like going on with some people because. You gotta prepare some of your family members who might be susceptible to this kind of thing. You know, I don't have any personally, but like, you know, people are getting older or whatever. And AI is only going to get crazier.

• 1:01:52Scott Tolinski?

  So I think chances are it's going to become more of a topic of conversation. But yeah, nasty stuff.

• 1:01:58Wes Bos?

  I'm going to sick pick something that is not awful like that. Hold on, let me grab it. I've talked about these in the past, but anyone who doesn't know about Wago connectors, they're good for like, like household wiring, but also good for like, I use them in electronics projects as well. Wago connectors are the best and the Europeans are going to be laughing at this because these have not become popular in North America until, I don't know, maybe, maybe four or five years ago. And what it is, is you, you have a wire in, let me, let me take one of these out here. If you want to like connect multiple wires together, you basically just open it up. You strip it, you throw it in, you, you close it down, right? It makes a lot of sense, but in North America here, we use something called morettes or, or wire nuts.

• 1:02:43Wes Bos?

  And just crank them down together, you know? And then if you want to take something out, you're twisting the copper. It's a pain in the butt and they're huge to fit like behind a light switch or something like that. So if you're doing any sort of, yeah, they're, they're so good. And I also, I recently found these ones, which is they're called inline.

• 1:03:02Scott Tolinski?

  Yeah, yeah, yeah, yes. I know about inline.

• 1:03:05Wes Bos?

  These are awesome. So if you have like just two wires that you want to connect in, in, in a line, these ones are fantastic rather than having to loop the wire back into the, the bottom of the connector. So that, and then I also have been printing these, um, these DIN connectors. You can buy them that they, they mount on this rail as well, but I, I'm working on like a little low voltage project. I would not do this with.

• 1:03:31Scott Tolinski?

  Yeah, I was going to say, these are exposed.

• 1:03:33Wes Bos?

  Yeah. Yes, yeah, that's, that's not allowed with, with mains voltage. I'm working on what's called a class two circuit, um, which is, that's allowed. But, uh, yeah, you could just connect two wires together and, and especially when you're prototyping things, you don't want to have to solder them together. I used, I use that for a lot of my LED project as well. So big fan of them. Grab yourself some Wago connectors. Do not, you, you can buy knockoffs, but.

• 1:04:01Wes Bos?

  I probably wouldn't. They're cheap. They're like 50 cents a piece. I've had the knockoffs in the past and they're fine for just like I'd like put like a vacuum line together, low voltage stuff. But I would not ever, ever trust them on anything that has any serious power. And then I would also be very careful where you buy them because I think there are a lot of counterfeits, counterfeits out there as well.

• 1:04:25Scott Tolinski?

  Yeah, I've been using these for any time. I put a number of like smart switches in our house and I use those every time. They're just so nice. And they're nice when you're installing things because it all clips on very nicely. You don't have to worry about it pulling out. I do tend to really like them.

• 1:04:41Wes Bos?

  They're starting to make light switches with them in the back of the switch, like a little clip. Sorry, go ahead.

• 1:04:48Scott Tolinski?

  No, I said, give me that. I just replaced the light switch last week and it felt very nice to use my Wago's.

• 1:04:53Wes Bos?

  Beautiful. I've actually never used one behind a light switch. I probably should. I've always just used them on electronics project just and use a stupid wire nuts where you get to jam them behind the thing. It doesn't seem like a great idea. So Europe, first time you were right about everything. You got your unpasteurized cheese you're right about and your

• 1:05:13Scott Tolinski?

  Unpasteurized cheese? I don't know anything about that.

• 1:05:16Wes Bos?

  Now your Wago connectors, all the cheese in Europe is much better than the supermarket crap you get here. Yeah.

• 1:05:26Wes Bos?

  Cool. All right. Thanks everybody so much for tuning in. Please submit your questions at syntaxotfm. We'll answer them in a future episode. We'll catch you later. Peace.