Google & MS Duopoly, Frontend to Fullstack, Where to Put Business Logic + more(Potluck)

Welcome to Syntax. Today, we have a potluck for you. A whole bunch of questions about web development, JavaScript, CSS, rid. GitHub, etcetera.

Some good questions. If you have a question, we would love to hear it and we'll answer on a future episode. Go to syntax. Fm. There's a button in the menu Bos. It says potluck. Click it. Submit your question and we'll answer it on a future episode.

My name is Wes Bos. I'm a full stack dev from Canada. With me JS always is Scott. How are you doing today, Scott? Hey. Yo. Hey. Yo. I'm doing good, man. Rid

Landon, my son, had his very 1st breakdancing class Oh. Last weekend, and he went nuts. It was Awesome. They you know, the type of class JS perfect for kids that age. It was basically show up and get your wiggles out. I mean, the coach started, and he was just like, alright.

Rid Do any kind of dancing you want right now. Let's go. Hit the music, and next thing you know, it's like all 12 kids are just going absolutely wild. And, It it was a lot of fun. He he had a blast. He he was he's been talking about it ever since. So, it's really really cool to see him really enjoy that, and I don't know.

He he's like, he's a very active little guy.

He's a very like, his attention isn't always there kind of type little guy. So seeing him, like, be really focused on anything was definitely a little little proud dad moment for me. So

That's awesome. My Daughter Poppy is in rock climbing, and she is like the best at it. Her upper body strength is unreal. Amazing. And like She would she would Wes she's rock climbing, sometimes she can't reach the next footing. So she just puts her foot like on the wall and then sort of jumps up. And rid And I I was like that. I was like, oh, like, that's an interesting way to do it. And then she got her, like, report card, and they said she's doing awesome at Snubbing or some there's some word for that. And I was like, oh, that's that's a thing. Yeah. Like rock climbers often do that when they can't reach it, they'll just quickly try to jump off the wall. I thought Wow. Man, didn't even didn't even teach her that. That's so cool.

Well, hey.

If you're learning anything new, whether it be rock climbing or break dancing, you're going to need a a little bit of a safety net to make sure you don't get hurt. Right? Rock climbing, you Scott You got a what are they, auto what do they call those? The auto belay? Auto belay. You got an auto belay. You Scott a trained rid A belay, somebody doing it for you, hopefully.

Or in in breakdancing, you you got the ground really nice and close for you, maybe some kneepads or something. Well, in computer programming, hey. You gotta have somebody in your corner too.

And our favorite service to be in your corner is rid Sanity because we're presented by Sentry, and, it's a really great service. You know? One of the cool things that it does is it gives you an re Detailed view into what's going on in your application at all times. You can't solve bugs that you can't see. And with Sentry, you can see all those bugs. It's like turning on the light and, seeing all those bugs only. They don't scatter, so you can take them 1 by 1 and very kindly put it in to a little cup and get it outside so you're not squishing it or something. So people talk often talk about squishing bugs, Wes, but what about taking bugs outside? That's what I'm about.

You go. Yeah.

First question we have here from Worried Listener. Are you concerned about duos duopolistic Companies taking over the web, I. E. Google pushing features of Chrome to block ad blockers on rid. On an Internet Explorer level or Microsoft owning basically everything in JavaScript land, GitHub, NPM, TS, VSCode, Playwright, etcetera.

Even if it has never been a better time, I'm a little bit worried about the future and the the openness of the web.

This is A very good thing to always be worried about. As much as we love all of these companies doing such amazing things, as much as we love that Like Microsoft, all of us web developers that warp like, Node, MacBook.

See you later, Microsoft.

And then they somehow like rid Pulled it over our eyes, and the only thing I'm using that's not Microsoft is my computer, you Node? Yeah. I'm using GitHub, NPM, TypeScript, Versus Code, Playwright. Rid. Node using teams,

though. Can't catch me using teams. Node, thank goodness. No.

Rather die.

I'm sure it's fine. I just rid. I've had to I've had to join a couple of calls from teams before. It's just it's been a pain. Yeah. It's been a But, Yeah, we should be concerned. We should be worried about companies having too much control over Node specific thing. As good as Google is For the future of the Wes, you never want to allow 1 company just to control absolutely everything. So that's Node thing we talk a lot about with the possibility of Firefox sort of go into the wayside.

Even if Firefox were to, like, do what Opera did Scott 10 years ago, Opera had its own engine and it was pretty progressive. They were often first to get a lot of these new features and just Their usership waned over the Yarn, and at one point they said, you know Node, we can't maintain our own browser engine anymore. We're going to switch it out and we're just going to throw Chrome in there or Chromium as their actual engine. And then we'll we'll focus on like like what Yarn does Providing a nice experience on top of it. And we're kind of worried that that is also going to happen to Firefox.

But We're starting to see Safari sort of coming out swinging. Safari's got their own issues of blocking features because they don't want to take their 30% App Store away.

But In my mind, Apple and Safari are always very security focused and are often pushing, and Safari controls the browser, the only browser on the iPhone. Right. So It's not like you could just not support Safari. It's literally a good chunk of the Internet is using it, so certainly always have to worry about this. What can we do about that? Don't tweet that everyone should be everyone should be Chrome. As much as I would love that for support wise, It won't end well. Yeah. I I agree. I mean, having 1 browser is kind of a

developer's dream as a test, rid you know, as in you you only have to support 1 engine there, but it's not great for what is the web. Right? That said, I do wanna correct, rid some, like, misinformation that's going about. A lot of people are saying that that Chrome is is blocking ad blockers.

In fact, I did a TikTok on this, and you'd be surprised at how many people, even watching the TikTok, are still blaming Chrome for blocking ad blockers Wes in reality, there is the the web extension.

The web extension world has long been kind of interesting, rid. And there's versions of web extensions that have been supported on various browsers.

And the what's happened recently rid. There's been a shift in the version of what web extensions are going to be supported. And as web extensions have grown over the time for browser extensions, we've learned different things, and all browsers implement the same standard.

At least they do now.

So what Chrome has done is they said, hey. In the past, Chrome has for a long time Been supporting version 2 of the manifest file, and now it would also supported version 3 of the manifest file. Version 3 of the manifest file actually has better security for you, better privacy for you. It's a bit more of a pain, and it's a bit more restrictive, but that's rid. Pro user privacy. Okay? And what Chrome has done is they've said, alright. We are reaching the deadline For which version 2 will be supported, and we're ending support for version 2 of the manifest.

Some ad blockers have not migrated to version 3.

Those ad blockers, have stated, you know, there are some challenges with the new privacy features.

Rid. And because of that, they might not be able to migrate their code base as is, and they've since started new ones. There are plenty of ad blockers using the manifest V3, but people see that u block origin is not able to migrate for some reason, and they're saying Chrome is blocking ad blockers. Chrome's not blocking ad blockers.

They're actually doing a pro privacy thing, which is it's it's crazy that the amount of comments I got on my YouTube And TikTok video about this where people hear that Chrome's increasing user privacy and that they're just Yeah. Deprecating an older version, And they still say, Chrome is out to get the ad blockers. They have ulterior motives. This is like this isn't just Chrome.

All of the browsers are going to be on this version 3 because it's a better version of web extension. So it's Not saying that that Chrome probably doesn't want ad blockers to be destroyed. I I'm very sure that Google hates ad blockers. Right? That's their whole business.

Yeah. But I don't think that this is Chrome killing ad blockers, as much as some people really, really want it to be. Like, there's such a trade off with Privacy

and ease of doing things because, like, I don't maybe people don't realize is there are a lot of Chrome extensions stealing Your data.

The Honey extension. Everybody loves to throw the Honey extension on every website. That extension is for sure rid. Watching what you buy and what you're viewing on every single thing. It's crazy the privacy, even like when you buy something on Amazon now, They don't. When they email you to tell you that they've charged your card, they don't even tell you what you bought because they don't want Google's greedy little fingers Scraping your email and saying, oh, wow, it looks like a lot of people bought vitamins this year. Let's rid. Jack up the rates for vitamin ads and things like that. So like, at the end of the day, corporations are evil And everybody wants to make money, and, it goes back to the last question. That's why, like, Google is an advertising company. Apple is a hardware company, and that is why Apple is so aggressive on privacy. And that is why Google rid. Is Scott, but we should be glad that they are doing a lot here to

protect your privacy. There's a lot of shady stuff going down in Chrome extensions. Yeah. Yeah. Absolutely. And and I agree. I mean, even ad blockers are doing a lot of reading the page. And and granted, I know ublock is open source, but still, Yeah. I I do think that that is it's a net positive thing. I think we need to get whatever the next gen ad blockers are on the new manifest.

One, Bob from Bob the Builder. Could you guys share your influencer stacks? What you use for video sharing, creation, etcetera? And so what Bob is asking here, Wes, is, like, if you were gonna be putting out a YouTube video and you want to just have a quick stack To get going to show your demo in or to work in your Node. Like, what is that stack of code? And for me, It's pretty much what I am using on the syntax site. I was trying to make this spell out Scott somehow, the Scott stack. I couldn't do it. Scott thinking, like, a SvelteKit, just straight up CSS, and an ORM of some kind. So right Node, it's Prisma.

So I got SCO, but I couldn't think of 2 t's that fit in here. So, you know, it could be like a a MySQL and, Prisma. It could be Drizzle. Who knows? I I need to dive into that more. It could even be Supabase or something like that. I really do like those services. But more or less, I'm picking SvelteKit, and I'm picking up straight CSS to the Node. And that's primarily how I'm working, 1st and foremost.

But, you know, I one thing I don't ever wanna do is hitch my wagon too tightly to any piece of technology because what happens is you start to really make your personality part of that technology And say, everything else is garbage, and everybody else who doesn't use the, the CSS stack or whatever we come up with, rid You Node, they don't know what they're doing or or whatever. My my stack is infallible. When in reality, I'm definitely more of the mind that, like, rid. Hey, man. Your stack should be fluid, and it should be open to open to change Yeah. When you find things that are better. Awesome. Yeah.

My stack is whatever the hell I'm teaching.

It's HTML, CSS, JavaScript. So for a lot of my like like short form videos, I just have a folder called Node, and I can create whole blown projects in there, or I can create HTML files that just have CSS and JavaScript linked in it as well.

And I go, I don't really like Scott said, I don't hitch my wagon to anything specifically, just because the world is fluid and opinions are different.

And I'm not going to go all in on something because I understand it. I do it this way because that's the most frustrating thing to me JS when people don't understand that rid. Other people could possibly do it some other way or have some other set of requirements. It's the same thing with the like, Like the server rendered arguments right Node. Is that like, oh, absolutely everything should be server rendered and Like a lot of people don't have they have existing APIs and they need to be able to.

Work with those APIs, they're not using server routes and actions and and rewriting their entire app in that because

their their infrastructure looks a little bit different. Yeah. I I do think yeah. Like, when you start to, like, really assign, you know, your identity as part of a software stack, you can get really dogmatic about it. And I don't know if that's, like, the best thing for personal growth in general. You know? I I'll see people defend things to the death when you Node, Different perspectives, different workflows, Scott of valid stuff out there.

And I I'm happy to hear What other people are using at at various points, and maybe the thing that I'm doing that feels great isn't always great.

Next question from Mike. I've been a front end developer my whole career. Over the years, I've learned Node and MongoDB by working on some side projects, and my current day jobs requires me to do some back end work with our APIs. Although I feel more comfortable at the front end, I can get tasks done and I feel pretty comfortable in the back end. It still feels work.

Weird to mark myself as a full stack developer when applying to jobs.

How do you know once you're ready to officially make the switch from front end to full stack? Rid I think this this line is is blurring, especially with the like the whole meta framework thing and like the server rendered thing.

It's it's not so much of a. Oh, the the back end team does build the API and then I'll go ahead and rid. Build the front end.

Quite honestly, even building the syntax website, I don't know what's running on the back end and the front end, you know, like that.

Obviously, we Node, but.

I don't think about it a whole lot in terms of how it should be done, so I think you could probably if you're able to query a database, loop over some stuff, you understand cookies.

What are what are some other like fundamental things of understanding? Like what is a request and a response? Maybe like how to If you've ever worked with WebSockets once or twice, and probably a really important one is like you understand what streams Yarn. I would say you're full stack. Rid Yeah. Yeah. I I do think that the definitions have been definitely blurred. And,

yeah, how do you know when you're once you're ready? Hey. You're you're ready the moment that you, you know, written her out or something like that. You know, I think my first introduction to back end code In a real sense of building, like, full on apps with with Meteor, and Node those lines were, like, super blurred in that case. And, you know, At that moment, the moment you're able to make something happen in the database or you're able to change an API, hey. You're a full stack dev. Now you just gotta Learn the intricacies there if you want to, or you'll hit pain points along the way, and you'll understand things and and pick things up more. But, Yeah. I don't I don't I don't think that, that definition is really all that important beyond, like, knowing the tech, which, again, A lot of the back end skills, like you mentioned, knowing about requests and those types of things, they're they're only gonna make you a better front end developer anyways. One one more thing is a lot of the APIs are

Are just bringing browser APIs to the server, right? Like we've talked about this a 1000000 times over JS standards. All of these frameworks now are using the Wes response API, which comes from fetch. Right.

Wes now have event listeners on The server, you can fire off custom events. You don't need a special one. Like if you're doing JavaScript on the server and on the client, rid. It's very much the same JavaScript at the end of the day. It definitely and and it's getting more and more that way all the time. Yes.

Next one here is from Dylan. Dylan says, as someone new to tech and looking to apply for junior front end positions, How much should I know about DSAs? I feel confident in my ability to build web pages rid well and accessible with the basics and tech up to TypeScript.

React, but I have zero confidence in my ability to solve elite Code like questions.

How much of that do I really Node to know for a junior front end position in this day and age? Yeah. I you You know, some places are gonna put a heavier emphasis on this than others. Now, Wes, do you know what a DSA is? Design systems and algorithms. I get Probably once a week somebody Instagrams me this question because they're. Wait, data's structured. You know, data.

What did I say? Design systems? Yeah.

Oh, no. It's not design system. Data structures and algorithms. Although Correct. Design systems and algorithms maybe.

Yeah. Design systems Might be more important for a front end developer to learn than, data structures and algorithms. Now I think the biggest thing for for you, Dylan, like, Solving LeetCode is a good way to get better at this stuff because you can start really small rid and work into harder and harder problems.

One thing that will help you here is spending time with array methods.

Rid. You wouldn't believe how many of these things can be solved with a map, reduce, a filter, or any of that stuff. Right? Or even a for each. A lot of those, array methods can be used to solve these things.

And, honestly, the biggest thing that you're going to hit As a front end developer working in JavaScript that is anywhere in this neighborhood of actual things that you'll really hit JS how do you take 1 piece of data structure and manipulate it to fit another data structure that you might need? Like, you have a charting library. Your data's coming in from the a pay API. It looks a certain way. You need to get that data shaped Into what the charting library actually can use. That's like a very real world thing that you might hit. Now granted, you're not gonna have to Know all the different algorithm types and and things like that to get too deep into there, but you will need need to know how to use JavaScript to manipulate that data.

So in my opinion, I think some companies are going to value this much higher than others. Whether or not that's valid is a different conversation. I think that It's more or less what type of work you're working on.

99% of the time JS a front end dev, you hardly need to get into this stuff, but that doesn't mean you won't. I asked this. I'm going to link up a Twitter thread. I asked this 2 years ago because it's

All the time people ask me this, and in the replies, Dropbox, yes. Sentry, yes.

Rid. Adobe, all practical. So no. Uber, all practical. Netflix, mostly practical practical.

One hard data structure queue. Twitter, all practical. Airbnb, multiple data structures and algorithm questions. Twitch, multiple data structures. Amazon. Yes. Absolutely. But these are all very specific type of like, these are all

apps app companies. Right? And I think that's a different world. Right. If you're if you're working for an agency, I don't think anybody's going to ask you any of this stuff. Node, no. I think that's

The world of web development is broad.

And if you are going to Silicon Valley to work at A FAANG company, you're probably going to encounter some of these things. If you are joining a team to build out a React interface or working at an agency, You're probably not going to encounter these things. Could I answer these? That's a great question. Maybe. I think once we get the video podcast rolling, it'd be kind of interesting. Oh, yeah.

Let's put Scott and I on some of these leak code questions and and see how well we fare Mhmm. With them. Yeah. That's a good point. We should do that. Next Question from David Myers.

Which tools would you recommend for crafting HTML from Emails from scratch.

That's a good Wes. I am using I haven't done HTML emails in a couple of Yarn, So this is probably a little bit out of date, but I was using Zurb Foundation email layout. I know MJML was Probably the big one, but last time we talked about this question, it looked like MJML hadn't been. I don't know if it needs to be updated. That's the thing about

emails. Yeah, right. Doesn't need to be updated.

Hasn't really changed all that often.

So there's MJML.

There's A couple other ones. There's another React one, which is pretty nice. I think, like, whatever you do choose, try to, like if you're doing a React Project, try do your emails in React as well because you're going to be able to reuse quite a bit of the stuff. You will need Some sort of framework that A, inlines your CSS and B, gives you some like reusable components for things like rid Laying things out because you're not gonna wanna lay out emails yourself from scratch. That's a world of pain. Rid. It's a world of pain. And, ultimately, if I'm not using MJML, which I have in the past,

LevelUp tutorials, even though that was a Svelte rid Based site, we still used MJML for our emails, even just generating it all on the server side.

Rid No problems there. I I I do like MGML as a system. You know, one thing that I end up doing rid with HTML emails JS if the HTML email is a part of a marketing email platform.

I'm always just using their WYSIWYG straight up. I'm never coding that from scratch. Why? I just really don't want to. I I I Spent, you know, a good amount of my career doing a HTML email and there's so many pitfalls there. There's so many issues there ESLint across all kinds of different things. So for me, if it's custom stuff, I'm using MJML.

And if it's marketing stuff, I'm using their their WYSIWYG.

Rid. Especially because like with marketing, you likely are going to need somebody from marketing that wants to use the WYSIWYG because they want to do different layouts. And if you go all in like my marketing emails are just I just took the very basic example and I sort of extended it rid For myself, and that's fine for me because I can get in there and change anything I want.

But If I had somebody doing marketing emails, they're like, oh, how do I put 2 videos side by side or how do I make a button span all the way across?

Rid. You just got to use the the WYSIWYG there. It's just not worth it. But react. Email is is the one I was thinking of. That that's also a good option that's rid being worked on right now. I found a Svelte version too that I haven't used, so I can't vouch for it. But they're out there. If you Google, like, Svelte review email, whatever you're using, chances are somebody's made something that could help there beyond MJML.

Next Node from Daniel Pointecker.

Hey, guys. Listening since episode 1 here. Wes, Daniel.

Wow. Hey. Are you guys setting up your own CICD like GitHub Actions or GitLab CI.

I use GitLab at work and tinkered around with setting up a GitLab runner on my Raspberry Pi in my home lab.

I can now automatically deploy software to my Raspberry Pis at home. My mind was blown by that. What type of tools do you use? So we largely do use GitHub actions, and that's kind of what I've used In the past, once they came out, it really felt like a good option just for how well they're integrated. They can be a bit of a pain to debug. We all know that.

Rid. I've also used one called Sema 4, that I did enjoy. I have used GitLab CI before. That was really nice experience. Rid these types of tools are really great for all kinds of things. Right now, for syntax specifically, we're using it to run our end to end tests with Playwright. We are using it to run Svelte check, which will check for accessibility issues, TypeScript issues, and Overall HTML and CSS issues, and we're using it to increment our version number on PRs.

Now that was something we did somewhat recently and mostly for Sanity, for our air tracking. Right? Because if you're always incrementing rid. On on Merges, a minor Vercel, if you're merging that stuff into main, then each time you have a bug in Sentry, it's gonna tell you what version of the software Wes That bug is present in, and you can quickly and easily see if things beyond just checking has this been regressed or you you check solved and Sanity will tell you if it's regressed. But, like, beyond that, you could see the versions of this span. What version did this error start popping up, and when did it so, having an automatic versioning system is great. In the Wes had it doing automatic change logs and stuff, generating change logs with AI, and I found it to be awful.

I think there's some some movement there, But,

like, it caused a lot of problems. And I think the Vercel one is such a such a good example of of what to do because you could have, Like people listen to the podcast. It's hours long, right? And we might not refresh the page.

So If we fix it in century, we mark it as fixed in version whatever.

But then if that error comes back, rid How do you know if it's with the new code Bos or not? So but by versioning it, you can say, like, if this error pops up again in that version where it was broken, Ignore it. We don't care. Like, we fixed it. But if it pops up in the new version, then we got a problem and we got to figure out, okay, well, We have a regression or we didn't actually fix it here. Totally.

But for the actual build and deployment, we don't we don't use GitHub actions. We use Vercel's build a P. I. And for my personal website I use Netlify's build and deploy because it's it's built right into the platform.

Yeah. Though when that when those started dropping in the platform, it did make a lot of these CI tools easier. It's like the CI tools are there now for, rid. Control pre deployment and stuff, and then the platforms can take care of building and deployment.

Next question we have here from Ed Undefined.

What do you think about unstyled component Libs? Example Yarn.

So we often call these like like headless components Wes the components will provide functionality and accessibility for you, And sometimes they'll provide very low level styling. But usually you bring the CSS, you bring the styling to it. And I am very much on board with this type of thing because like that's that's the problem. That was the problem we had with Bootstrap JS that People got sick of Bootstrap partially because of how it looked, you know, like the functionality of a lot of the boot stuffs. Strap stuff was was Okay.

Obviously, we have much better. We have React Aria. We have Arc. There's lots of libraries out there now that are much better. But Often you want a fully drop down multi select filterable list, but you want to make it look like you want to make it look like so These like headless CSS Wes component libraries are key, and I don't think I would build a complex application without one of them simply for the accessibility,

let alone the all of the functionality that comes along with it. Yeah. And I honestly, if you're asking me if you prefer unstyled versus styled, I'm gonna prefer unstyled all day because Yeah. You know, granted, I don't wanna say anything bad about Chad CSS because those components look awesome, and that's a great library and tool. But there it it looks like a a lot of Atkins these days are are are looking very, very similar.

You know, I I pop open a a couple of services and That's not necessarily a negative thing, but, like, I don't know if I want every service to look like a Vercel dashboard.

Yeah. It just kinda feels a little soulless when they all feel and look the exact same. So, you know, I'm I'm definitely Keep it weird kinda guy or keep it interesting kinda guy. And and having unstyled components library, to me, is the way to go simply because I want To control what it looks like, and I have, like I don't wanna say, like, confidence to know that I can make it look okay, but I have confidence to know that I can Given an aesthetic that's at least a little bit more,

you know, personalized than the the generic. Yeah. It's it's because, like, sometimes you do just want to slap a dashboard on there and get going because it's an extremely functional dashboard.

It looks Node. Like it looks great, but yeah, you do. And of course, you can take it a little bit further and style it yourself. It's not like you can't add your own CSS, but Like Scott, I think I'm on team unstyled by default.

If I was rebuilding my admin dashboard right now, I'm trying to think like I would probably not care what it looks like, you know, like. Yeah. But if I was building the course viewer, rid Rebuilding it, I would care what it looks like. So it it it really does depend. Yeah. I was thinking there was, like, little side projects here and there that, like,

styled makes perfect sense for that because I have no because I have no no want to spend time designing a dashboard or an admin UI for something that It's just a little goof around. You know? Mhmm. Next one is from Zach Paul, who you know, he says, I'd add pronunciation, but I think you guys got this. So, yes, we do. Thank you, Zach.

Hello, Wes and Scott. Long time listener. First time potlucker.

I'm developing a pretty complex app in Next. Js, a specialized text editor meant for creative writing.

Rid Oh, Zach. Okay.

I got thoughts here. It requires many different components and ways to for the user to interact with the UI And was therefore planning for it to be a desktop and laptop experience.

However, I think there should be, at very least, A way for users to interact with the editor itself and write on mobile even if this isn't as feature rich on mobile as it is on desktop.

I feel like a fully responsive design where all the components were made to work on both in mobile and desktop would water down the desktop re experience. Imagine Versus Node on a phone, they say.

My question is for very com It works. Yeah.

For very complex apps Like mine, do I need simplified or separate mobile components that just use shared logic? Do I need to have every single feature on mobile JS I do on desktop, am I okay with just forging ahead on the desktop app and wait for mobile implementation after I find my user base? Okay. So, Zach, let me tell you about an app that I've used that kind of has gone through this transition itself, and it's a writing app. Rid. Obsidian. That's what I use for taking notes. For a long time, Obsidian was just on desktop. And let me Sanity was a pain in the butt, But it was fine that it was just on desktop. I waited patiently for it to come on mobile, but the fact that it wasn't on mobile for day 1 did not, like, rid Didn't sink it for me.

That said, it depends. You Node, some users will see, especially if they're looking for a creative writing app and say, I can't use this on my phone. I'm out.

So you really have to determine, you know, really truly who your audience is rid Your audience technical people who probably have a computer around, you know, maybe they do most of their writing on a computer anyways, then sure. Desktop app, I think that's probably fine. But, again, more and more these days, people do just about everything on their phones. And and I know, Wes, you and I both you know, if we can't capture An idea to save for later easily on our phone.

It makes us very upset because, like, sometimes You're not you're not at your computer. You see something interesting. You wanna capture it for later. You wanna jot that idea down. And so maybe perhaps Having some, like you mentioned, simplified interface for mobile. Now, technically, how do you pull this off? Now I've done both of these situations before, And, you know, granted, I do think the responsive web design is probably your best bet if you can make it work, but I do understand that there's just Scott times where you can't.

You know, like, mobile navigation is one of those times where it doesn't make a ton of sense.

Oftentimes, they have the same exact component for desktop and mobile navigation given occasionally, sometimes major structural differences between the two. So I have certainly shipped apps that have used a mobile component Vercel a desktop component in the same code Bos with shared logic. And let me tell you, rid Worked just fine. I liked it. But if you can make it work, I think responsive is the way to go Because then you don't have to maintain 2 sets of components, which will inevitably get out of sync.

I've seen it firsthand.

They do get out of sync, And Yeah. That it it's more work. So if you can make it work with just CSS and some JavaScript showing and hiding, the very least, Give your give your people an opportunity to at least jot down basic ideas in this thing in a in a mobile context, I think. Unless

you are rid. Airbnb or LinkedIn or something like that, don't build 2 apps.

You're gonna be in a world of hurt trying to maintain the 2 things. Even if you can share things between the 2, it's much easier to like like Notion or sorry, not Notion.

Missive, which is my email ESLint, is a single HTML CSS JavaScript codebase. Go back and listen to the Missive so lovely. We did with Etienne.

And I didn't even know that it Wes. I thought I was like, oh, they do a native app, you know, but, like, They do it all in Node. So I think from day 1, even if you don't plan to offer it, don't think they just use desktop. No people. That's that's the worst.

And don't think, oh, I'll give them a watered down an experience with not all the features. I hate that. Like my Synology.

Wes I log into my Synology from my phone, rid. Like, yeah, I need to do something. What's going on there? It like this crappy experience. I'm like, no, I want all the features. So you have to push the button to get the desktop experience. And I'd rather have the like zoom in and out desktop experience That I can do everything on it, then having to use some watered down experience that doesn't doesn't have all of the actual features in there. Even like even Instagram desktop is like that. Like they have 2 different apps. And I talked to the devs From Instagram and they're like, we're a small team. We're trying to keep up with the features as fast as possible. But case in point, one of the biggest companies in the world Can't move fast enough to keep all the features so often. I'll be using Instagram desktop and it doesn't have It's like open the app to view this thing or you can't do any of these features on the desktop, so

I wouldn't do that. Can we just say how absurd it is that that the the iPad version of Instagram is still just a low res rid. Blown up version of the the mobile app. Is it really? Yeah.

What's going on? Trying to Like, can you not Trying to keep boomers off of, Instagram. You know what? A lot of times this is sorry. This is kind of abstracted from that conversation, but it it was really weird how there was a time when, rid people were saying that, like, the Android way of doing layouts and stuff was worse than the Bos way because the Ios has special iPad apps. But what we've seen is now devices, they span completely different view ports. And Android apps are way more like responsive design, and Bos apps are more like, You know, you have a phone app or you have an iPad app. And so I I I do think that responsive design here is particularly adept at being able To shrink down to any capacity that you Node it to. Yeah, I agree.

So think about think about mobile from day 1, even if you don't plan to offer it. Think about it in every single thing that you do.

Use pointer events instead of click events, you know? Rid. So at least if you have some drag and drop interface, your pointer events is going to get you a lot of the way there.

Rid. You might have to do a little bit of touch events here and there, but try to do pointer events.

It's supported in all the browsers. You're in really good shape with that type of stuff. Don't give your users a crappy experience. I realize you're just trying to get it to work, and it's totally fine to focus on desktop if that's what you think most of your users are going rid. But don't shoot yourself in the foot for the the future of this application. Yeah, that's a good point. Next question from Bilal.

How can I get better at planning my code right now? If I plan my code with flowcharts, etcetera, I find that One wrong assumption can throw off the whole plan or a significant part of it.

Is it even worth planning? Ps Y'all rock.

I have found Scott's got some really good recommendations on, like tooling and stuff like this, but I find that.

It's just something that you need to get better at, meaning that like, how do I get better at it? You get better at it.

And what I mean by that is you will run into situations where you realize, oh, crap. I put both of these things in the same function, and now I want to be able to only do one of them. So do I Node I have to refactor it out into 2 functions or do I just pass a do I pass a boolean in like should update? You know, like that's always the rid. The quick fix for that type of thing and you wrap that piece of logic in an if statement, then it sort of turns into spaghetti over time. So I think JS you run into those situations where you go, crap, I realize I

shouldn't have coupled these things as tightly as I want, You get a bit of a better idea as to how you should be architecting and planning your code. Yeah. This stuff is tough. You know, I have some tools in here for you you did say that, like, You plan your code with flowcharts. There's Node interesting, like, good flowchart apps like Mondo, draw.

I I did find this really neat site, that I have used before called octopus.do.

I think they probably reached out to me because I think they wanted to sponsor or talk to us at some point. But in turn, I just looked at this website. And I think this is really neat because it is, like, kind of a flowchart designer for apps web apps.

And you can even generate or crawl a u l URL. So if you wanted to, like, have a a starting position but there's also, like, really nice, like, little low fi prototyping tools and stuff. I think this is a neat tool, something that to maybe possibly check out as a good planner.

Mermaidjs.org is a good JavaScript rid. Flowchart planner if you want to get into writing code to plan, but that again feels like a hefty thing in its own.

I think, personally, I'm I'm a fan of prototyping and refactoring and prototyping and refactoring and just making those changes in the code. Sometimes you can lose sight of the bigger picture of it all, because you you're in the code there. But I do think, like, me personally, I'm much happier looking at my file system in Versus rid code and releasing that as a structure for things.

Sometimes if I'm not writing components or I'm not getting into the phase of actually writing the code, I will write out the folder structures ahead of time. I will I will create that structure for the things that I know I'm about to do. Yeah. Rid. Especially for routing now because routing is done in folders. So I'll I'll do, you know, my full routing before I even get into writing a single component for things. Maybe like a utils folder, a library folder, a database.

And that at least stops the like, where do I put this thing, you know? And Wes, I don't know. I'll just stick it here and worry about it later if you have the the structure for it. I like that. Yeah. Last question from Zach Paul. Zach Paul again. Wow, Great questions.

I, a front end dev, was in discussion with a back end dev, and we were debating on whether a piece of logic should live in the back end or the front end. I wanted Business Logic to be in the back end so that I wouldn't need to worry about that in the Vue logic. They agreed about business logic being in the back end, but they didn't agree about that particular logic. What I was talking about was business logic. They said it was client side logic.

What exactly makes it so that a piece of logic is client or front end logic and back end logic? Rid. We have to get questions like this where people are like, can you help explain the difference between x and y? And the reality is the world is not JS cut and dry as that type of thing. Just sort of put this in your mind of probably what this type of thing was JS we're submitting some data to the back end And in order for it to be ready and formatted in a certain way, sometimes you need to do a little bit of data massaging before it gets put into the into the database. And I bet that this was something around.

Should we do that massaging and Wrapping of the data. Maybe it was resizing of an image.

Should that happen on the client side or should that happen on the server side? So should you send the raw data to the Back in and let them figure it out there, or should you do that on the client side? And I think sometimes business logic does need to happen in the ESLint. Like Resizing an image is a really good one example because if somebody uploads a 15 meg photo, you can't You can send 15 megs over the wire and resize it on the back end, but it probably makes a lot more sense to resize it in the browser And then send it to the back end before it gets done.

You could have validation on the back end for that type of thing, but Sometimes it makes a lot more sense to do it in the front end. So it's a little bit I tend to.

Say if the user does not need to be alerted to any of this data and if it's not a big deal to send it to the back end, I tend to put a little bit more of that business logic on the back end. But if the user needs to if you're having real time validation or the user needs to Modify the data in some way, then, yeah, it's it's fine to throw that into the client. Yeah. I agree with you. You know, it is kind of one of those rid things that you learn. I remember the 1st time, like you mentioned, sending a big old image to my server.

It was fine when I was doing it on dev. And then when a lot of people were doing it in production, I realized, holy cow. I'm asking my server to do a whole lot here.

So Yeah.

You know, then you you learn, okay. What can I offload onto your client? So there's rid Definitely, like, different issues Node different situations that you will run into, and it becomes a bit of a feel thing. This is definitely one of those ones that you'll get more experience with. Yeah. Could Could be a security thing as Wes, like

generating a slug for a blog post. That should happen server side, right? Like even if you're generating a ESLint Node, there's a possibility that someone's going to realize, oh, we're sending the slug for that. Let me make the slug custom or let me override it or Let me do something nefarious with it. So you also have to think about like.

Should the user be able to if they were rid. If they were nefarious, could they do anything fishy here? Yes.

Fishy. Indeed. Cool. Well, that's it For the potluck, these are all great questions. If you have any questions, again, head on over to Syntax Scott f m and click that submit a potluck question button. And you can ask Listen. We will answer it on the show if we deem your question to be lovely enough.

Questions asking about when Wes' type score TypeScript course, will come out, will not be read on air.

Because there's been certainly enough of those. My okay. So let's get into the part of the show where we talk about sick picks, things that we pick that we enjoy, things that we find to be truly sick.

I have a sick pick, for you today.

And you know what? This is a a Yarn game that we've been playing with our kids.

And we got it as a gift from one of our neighbors. And when it came out or when we rid got it. I think our kids may be just ever so slightly too young for it.

It's called Sleeping Queens, and it's, Let me tell you.

Our kids will never stop playing this. It says it's for ages 8 plus, which is maybe rid A testament to our our kids' ability to pick up games like this.

But my daughter who's 4, She gets the rules. The the only thing she can't do is there's a small math section, and we'll play without the math section because, rid. She can't do that on her own. But my son, he's 6. He can do the math. He can play this completely on his own.

And, we play this, and our our family We've been playing this on our family game night all a lot, and it's a lot of fun, especially if you're looking for card games for the family type of things that kids will pick up and play. Rid. That's cool. Scott these cute little cards the kids love about, they fight over the different queens and kings that you can get, whether it's the, What's the favorite? The favorite king is the puzzle queen because my or puzzle king because my daughter loves puzzles.

Favorite queen is probably the heart queen because it gives you 20 points. I'm going to sick pick a package Bos, if you have room for that on your porch. So I know that you can buy Package boxes that have pin codes on them and they want you to put the pin code on it, and there's no chance that the delivery driver is going to spend time Punching in a pin Node.

Simply just a box where you can put a big old plaque on it that says packages. So rid. We've had this like I don't know if it was a toy box or an outdoor box. It's just a big wooden box with a lid on it.

And a couple of years ago, I got a custom plate made for it that says packages So simply just putting a package box on there was really nice because if we're not home and the package is delivered, we Node, okay, at least it's not laying on the front porch where Someone's going to quickly snatch it from from us. So it's been awesome and it's great. The weather stays off of them.

And Probably about 87% of the time the drivers actually use the package box.

The other times they just put it on top of the box, which is they probably don't care enough to actually open the lid and throw it in. But you can also get like a resin outdoor box or a deck box. I think they're often called Wes people store, like, outdoor cushions in them. I Scott, like, a really small one to store my charcoal in Node the barbecue so it doesn't get rained on, but that would that would be a good good idea for a package box as well. Yeah. Neat. Yeah. I've I've always wondered about having something like this. We we end up having, like, a pretty good blind spot that the that

the people just put it behind the blind Scott, like one of the rid Post service. Oh, that's good. Yeah. So you won't see it from the street.

Cool. Well, shameless plugs. I'm gonna plug the Syntax newsletter.

You can find out about the Syntax newsletter over at syntax.fmforward/snackpack.

I'll have the link for that in the show. We do all kinds of stuff whether we're finding a hot take tweets or interesting links that we found over the course of the week. We've done 8 issues at the time of recording this, but we do that every other week a new issue comes out, or we just share neat stuff. So if you want to join and become a part of the Syntax Snack Pack, head on over to Syntax.fmforward/snackpack.

Beautiful.

I'll shamelessly plug My social media, check me out wherever you I've been posting absolutely everywhere. So if you're on rid TikTok, Instagram, LinkedIn, Twitter, threads. I think that's that's all of them. I've been posting ESLint all of those places, so check it out. Send me a tweet. Send me a post that says, hi. I'd love to hear from you.

Rid. Word. I'm at Wes Bos on all of those. Yeah. At west boss. Yeah. And we're on syntax on all of them as well too. Syntaxes everywhere you Yarn, so check it out. Thank you so much for listening to this potluck. We will join you on Friday Wes we're gonna be talking to Yagiz Nizipli about Node. Js performance, which I could not be any more excited about. He has so many great tips about performance in general, debugging, benchmarking, those types of things. So It's gonna be a really good one.

Peace.

Head on over to syntax.fm for a full archive of all of our shows.

And don't forget to subscribe in your podcast player or drop a review if you like this show.

Rid.