You're listening to syntax the podcast with it's hasty a swept development treats out there strap yourself in and get ready. Here's Scott Zelensky and West boss. Welcome to syntax. Then we have a pop luck for you.
A whole bunch of questions about web development, JavaScript, CSS, GitHub, et cetera. Um, 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 bar. It says potluck, click it, submit your question and we'll answer it on a future episode. My name is West boss. I'm a full stack dev from Canada with me as always at Scott.
How you doing today, Scott? Hey, yo, yo, dude. Good man. Landed my son had his very first break dancing class last weekend and he went nuts.
It was awesome. They, you know, the type of class is perfect for kids at age. It was basically show up and get your wiggles out. I mean, the coach started and he was just like, all right, to 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 was a lot of fun. He had a blast. He was he's been talking about it ever since.
So it was really, really cool to see him really enjoy that. And I don't know. He's like, uh, he's a very active little guy. He's a very like his attention isn't always their 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. Well, my daughter, Poppy is in rock climbing. Um, and she is like the best at it.
It's her upper body strength is unreal. Amazing. And like she would, she would, when 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 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 the thing. Like, 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, man, they didn't even, didn't even teach her that. That's so cool. Well, hey, um, if you're learning anything new, whether it be rock climbing or break dancing, you're going to need a little bit of a safety net to make sure you don't get hurt, right?
Rock climbing, you got a, you got to what do they call those? The auto belay. Auto belay. You got an auto belay.
You got a trained a belay, somebody doing it for you, hopefully, or in when break dancing, you got the ground really nice and close for you. Maybe some knee pads or something. Well, in computer programming, hey, you got to have somebody in your corner too. And our favorite service to be in your corner is a century because we're presented by a century and it's a really great service.
You know, one of the cool things that it does is it gives you a detailed view into what's going on in your application at all times. You can't solve bugs that you can't see in what century 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 one by one and very kindly put it into a little cup and get it outside so you know, squishing it or something. So people talk often talk about squishing bugs, but what about taking bugs outside? That's what I'm about. There you go.
Yeah. First question we have here from a worried listener. Are you concerned about do opolistic companies taking over the web, i.e. Google pushing features of Chrome to block ad blockers on an Internet Explorer level or Microsoft owning basically everything in JavaScript, and GitHub, NPM, TS, VS code, playwright, etc.
Even if it has never been a better time, I'm a little bit about worried about the future and 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 were like, not MacBook, see you later Microsoft. And then they somehow like pulled it over our eyes. And the only thing I'm using as not Microsoft is my computer, you know, using GitHub, NPM, TypeScript, VS code, playwright.
Not using teams though. Can't catch me using teams. Oh, thank goodness. No, rather die.
I'm sure it's fine. I've had to join a couple of calls from teams before it is just as a problem. Yeah, it's better. But yeah, we should be concerned.
We should be worried about companies having too much control over one specific thing as good as Google is for the future of the web. You never want to allow one company just to control absolutely everything. So that's one thing we talk a lot about with the possibility of Firefox sort of going to the wayside, even if Firefox were to like do what Opera did. So 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 their usership waned over the years. And at one point, they said, you know what, 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 what Arc does, providing a nice experience on top of it.
And we're kind of worried that that is also going to happen to to Firefox, but we're starting to see Safari sort of coming out. So we can so far as get 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 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 agree. I mean, having one browser is kind of a developers dream as a test, you know, as in you only have to support one engine there, but it's not great for what is the web, right? That's it.
I do want to correct some misinformation that's going about. A lot of people are saying that that Chrome 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. When in reality, there is the the web extension, the web extension world has long been kind of interesting.
And there's versions of web extensions that have been supported on various browsers. And the what's happened recently was 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 two of the manifest file. And now it will also support it version three of the manifest file version three 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 pro user privacy. Okay. And what Chrome has done is they've said, all right, we are reaching the deadline for which version two will be supported and we're ending support for version two of the manifest. Some ad blockers have not migrated to version three.
Those ad blockers have stated, you know, there are some challenges with the new privacy features. 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 V three, but people see that you 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 crazy that the amount of comments I got on my YouTube and TikTok video about this, where people here that Chrome's increasing user privacy and that they're just 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 three 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'm very sure that Google hates ad blockers, right?
That's the whole business. 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 extension stealing your data. The honey extension, everybody loves to throw the honey extension on every website.
That extension is for sure watching what you buy and what you're viewing on every single thing. It's crazy that 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 really little fingers scraping your email and saying, Oh, wow, it looks like a lot of people bought vitamins this year. Let's jack up the rates for vitamin ads and things like that. So like the 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 is not. But we should be glad that they are doing a lot here to to protect your privacy.
There's a lot of shady stuff going down in Chrome extensions. Yeah. But still, yeah, 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.
Next one, Bob from Bob the Builder. Could you guys share your influencer stacks? What you use for video sharing creation, et cetera. And so what Bob is asking here, Wes is like, if you were going to 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 code, 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 the spell out Scott somehow, the Scott stack. I couldn't do it. The Scott stack.
I was like, a spell kit just straight up CSS and an ORM of some kind. So right now it's Prisma. So I got SCO, but I couldn't think of two T's that fit in here. So, you know, it could be like a MySQL and Prisma.
It could be drizzle. Who knows? I need to dive into that more. It could even be super base or something like that.
I really do like those services. But more or less, I'm picking spell kit and I'm picking up straight CSS to the dome. And that's primarily how I'm working first and foremost. But, you know, I one thing I don't ever want to 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 ass stack or whatever we come up with. You know, they don't know what they're doing or whatever. My stack is infallible. When in reality, I'm definitely more of the mind that like, Hey, man, your stack should be fluid and it should be open to change when you find things that are better.
Awesome. Yeah. My stack is whatever the hell I'm teaching. It's HTML CSM JavaScript.
So for a lot of my like, like short form videos, I just have a folder called code 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, 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 is when people don't understand that 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 now. Is that like 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 rewriting their entire app in that because their infrastructure looks a little bit different. Yeah.
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'll see people defend things to the death when, you know, different perspectives, different workflows, a lot of valid stuff out there. And I'm happy to hear what other people are using 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 in 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 with 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 flying to jobs. How do you know once you're ready to officially make the switch from front end to full stack? I think this line is blurring now, especially with the like the whole meta framework thing and like the server rendered thing.
It's not so much of a, oh, the back end team does build the API and then I'll go ahead and build the front end quite honestly, even building this in text website. I don't know what's running on the back end and the front end, you know, like that. Obviously we know, 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 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 web sockets once or twice and probably a really important one is like, you understand what streams are. I would say, you're full stack.
Yeah. Yeah. 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 ready. The moment that you, you know, written around or something like that, you know, I think think my first introduction to back end code in a real sense of building like following obstacles with media and 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 full stack dev. Now you just got to learn the intricacies there if you want to, or you'll hit pain points along the way and you'll understand things and pick things up more.
But yeah, 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 backend skills, like you mentioned, knowing about requests and those types of things are, they're only going to make you a better front end developer anyways. More than the API's are just bringing browser APIs to the server, right? Like we've talked about this a million times over is standards. All of these frameworks now are using the request response API, which comes from Fetch, right?
We 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, it's very much the same JavaScript at the end of the day.
Definitely. 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 DSA's? I feel confident in my ability to build web pages well and accessible with the basics and a tech up to TypeScript react, but I have zero confidence in my ability to solve lead code, like questions. How much of that do I really need to know for a junior front and position in this day and age? Yeah.
I, you know, some places are going to put a heavier emphasis on this than others. Now, West, you know what a DSA is designed systems and algorithms. I get it. Probably once a week somebody Instagrams me this question because they're wait.
Data structure now data. Do what did I say, design systems? Yeah, no, it's not as easy data structures and algorithms. Although in science, it's just 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 you, Dylan, like solving lead code is a good way to get better at this stuff, because you can start really small and work into harder and harder problems.
One thing that will help you here is spending time with array methods. 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 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 is how do you take one 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 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 real world thing that you might hit. Now, granted, you're not going to have to know all the different algorithm types and things like that to get too deep into there. But you will 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 is more or less what type of work you're working on. 99% of the time as 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 with Twitter thread. I asked this two years ago because it's all the time.
People ask me this. And in the replies, Dropbox, yes. Sentry, yes. Adobe, all practical.
So no. Uber, all practical. Netflix, mostly 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 apps, apps, app companies, right? And I think that's a different world, right? If you're working for an agency, I don't think anybody's going to ask you any of this stuff. No, no.
I think that's the world of web development is broad. And if you are going to Silicon Valley to work at a FANG 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. Let's put Scott and I on some of these lead code questions and see how well we fare with them. Yeah, that's a good point.
We should do that. So from David Myers, which tools would you recommend for crafting HTML from emails from scratch? That's a good question. I am using, I haven't done HTML emails in a couple of years.
So this is probably a little bit out of date, but I was using the ZIRB 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 is that it doesn't need to be updated. It 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 whatever you do choose, try to, if you're doing a React project, try to 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 reusable components for things like laying things out because you're not going to want to lay out emails yourself from scratch.
That's a world of pain. It's a world of pain. And ultimately, if I'm not using MJML, which I have in the past level of tutorials, even though that was a felt-based site, we still use MJML for our emails, even just generating it all on the server side, no problems there. I do like MJML as a system.
One thing that I end up doing with HTML emails is if the HTML email is a part of the 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 spent a good amount of my career doing HTML email, and there's so many pitfalls there. There's so many issues there testing 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 WYSIWYG.
Especially because 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, my marketing emails are just, I just took the very basic example, and I sort of extended it 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, I was like, oh, how do I put two videos side by side, or I don't make a button span all the way across, you just got to use the WYSIWYG there.
It's just not worth it. But React. That email is the one I was thinking of. That's also a good option that's being worked on right now.
I found a smelt version too that I haven't used so I can't vouch for it. But they're out there if you Google like, Selt or View email, whatever you're using. Chances are somebody's made something that could help their beyond to MjML. Next one from Daniel Pointtecker.
Hey guys, listening to since episode one here. Yes, Daniel. Hey, are you guys setting up your own CI, CD like GitHub actions or GitLab CI? I use GitLab at work and tinker it around with setting up a GitLab runner on my Raspberry Pi in my home lab.
I can now automatically deploy software to my Raspberry Pi's at home. My mind was blown by that. What type of tools do you use? We largely do use GitHub actions and that's 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. I've also used one called Semaphore that I did enjoy.
I have used GitLab CI before. That was really nice experience. 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 Selt Check which will check for accessibility issues, TypeScript issues and overall HTML and CSS issues. We're using it to increment our version number on PRs. That was something we did somewhat recently and mostly for our air tracking. If you're always incrementing on the minor version, if you're merging that stuff into main, then each time you have a bug in Century, it's going to tell you what version of the software that bug is present in.
You can quickly and easily see if things beyond just checking has been regressed or you check solved in Century. If it's regressed, but beyond that, you can see the versions of the span. What version did this error start popping up and when did it? Having automatic versioning system is great.
We had it doing automatic change logs and stuff, generating change logs with AI and I found it to be awful. I could hear some movement there, but it caused a lot of problems. The versioning one is such a good example of what to do because people listen to the podcast. It's hours long, right?
We might not refresh the page. If we fix it, in Century, we mark it as fixed in version, whatever. But then if that error comes back, how do you know if it's with the new codebase or not? By version, you can say if this error pops up again in that version where it was broken, ignore it.
We don't care. We fixed it. If it pops up in the new version, then we got a problem and we got to figure out, okay, well, we have regression or we didn't actually fix it here. Totally.
But for the actual build and deployment, we don't use GitHub actions. We use Vercels build API. For my personal website, I use Natlify's build and deploy because it's built right into the platform. When they started dropping in the platform, it did make a lot of these CI tools easier.
The CI tools are there now for control, pre-deployments and stuff and then the platform can take care of building and deployment. Next, we have here from Ed undefined. What do you think about unstyled component lives, example arc? We often call these headless components where the components will provide functionality and accessibility for you.
Sometimes they'll provide very low level styling, but usually you bring the CSS, you bring the styling to it. I am very much on board with this type of thing because that was the problem we had with bootstrap is that people got sick of bootstrap partially because of how it looked. The functionality of a lot of the bootstrap stuff 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. These headless CSSless component libraries are key. I don't think I would build a complex application without one of them simply for the accessibility, let alone the functionality that comes along with it.
Honestly, if you're asking me if you prefer unstyled or styled, I'm going to prefer unstyled all day because granted, I don't want to say anything bad about shad-c-n because those components look awesome and that's a great library and tool. But it looks like a lot of back-end these days are looking very, very similar. I pop open a couple of services and that's not necessarily a negative thing, but I don't know if I want every service to look like a Vercel dashboard. It just feels a little soulless when they all feel and look the exact same.
I'm definitely a weird kind of guy or keep an interesting kind of guy and having unstyled components library to me is the way to go simply because I want to control what it looks like and I don't want to say confidence to know that I can make it look okay, but I have confidence to know that I can give it an aesthetic that's at least a little bit more personalized than the generic. Yeah, it's tough because sometimes you do just want to slap a dashboard on there and get going because it's extremely functional dashboard. It looks nice, it looks great, but yeah, 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 unstyled by default.
If I was rebuilding my admin dashboard right now, I would probably not care what it looks like. But if I was building the course viewer rebuilding it, I would care what it looks like. So 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 want to spend time designing a dashboard or an admin UI for something that is just a little goof around, you know.
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. Hello, Wes and Scott.
Long time listener first time potlocker. I'm developing a pretty complex app in next JS, a specialized text editor meant for it creative writing. Oh, who 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 and mobile and desktop would water down the desktop experience.
Imagine via code on a phone, they say. My question is for very complex apps. 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 as 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 up city and that's what I use for taking notes for a long time. Obsidian was just on desktop and let me say it 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 one did not like didn't sync it for me. That said, it depends. You know, 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 here. Is 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 of these days people do just about everything on their phones and I know West, you and I both, you know, if we can't capture an idea to save for later easily on our phone. Yeah. And so that's because like sometimes you're not, you're not at your computer. You see something interesting.
You want to capture it for later. You want to 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?
No, 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 sometimes 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 is sometimes major structural differences between the two. So I have certainly shipped apps that have used a mobile component versus a desktop component in the same code base with shared logic.
And let me tell you, work 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 two sets of components, which will inevitably get out of sync. I've seen it firsthand.
They do get out of sync and 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 mobile context. Unless you are Airbnb or like LinkedIn or something like that, don't build two apps. You're going to be in a world of her trying to maintain the two things.
Even if you can share things between the two, it's much easier to like notion or sorry, not notion, missive, which is my email client is a single HTML CSS JavaScript code base. Go back and listen to the missive episode we did with it. And like I didn't even know that it was, I thought I was like, oh, they do a native app, you know, but like they do it all in one. So I think from day one, even if you don't plan to offer it, don't think.
And they just use desktop. No, people, that's, that's the worst. Um, and don't think I'll give them a watered down experience with not all the features. I hate that.
Like my Synology, when I log into my Synology from my phone, like, yeah, I need to do something. What is going on there? It like, you just crappy experience. 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 than having to use some watered down experience. It doesn't, doesn't have all of the actual features in there. Even like even Instagram desktop is like that.
Like they have two different apps. And I talk 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 iPad version of Instagram is still just a low res blown up version of the mobile app. Is it really?
What's going on here? Like, can you not kind of keep boomers off of Instagram? You know, a lot of times this is, this is kind of abstracted from that conversation. But it was really weird how there was a time when people were saying that like the Android way of doing layouts and stuff was worse than the iOS way because the iOS has special iPad apps.
But what we've seen is now devices, they span completely different viewports and Android apps are way more like responsive design and iOS apps are more like, you know, you have a phone app or you have an iPad app. And so I do think that responsive design here is particularly adept at being able to shrink down to any capacity that you need to do. Yeah, I agree. So think about, think about mobile from day one.
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, 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. You might have to do a little bit of touch events here and there, but try to do pointer events. It's supported 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 to be, but don't shoot yourself in the foot for the future of this application.
Yeah, that's good. Next question from below. How can I get better at planning my code right now? If I plan my code with flow charts, et cetera, I find that one wrong assumption can throw off the whole plan or significant part of it.
Is it even worth planning? PSCL 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, now it's refactored out into two functions or do I just pass a, do I pass a Boolean in like should update, you know, like that's always 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 like as you run into those situations where you go, oh 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 flow charts. There's an interesting like good flow chart apps like Mondo draw. 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 flow chart designer for apps, web apps. And you can even generate or crawl a URL. So if you wanted to like have a starting position, but there's also like really nice like little lo-fi prototyping tools and stuff.
I think this is a neat tool, something to maybe possibly check out as a good planner. Mermaid.js.org is a good JavaScript flow chart 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 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're in the code there. But I do think like me personally, I'm much happier looking at my file system in VS code and really seeing 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.
The things that I know I'm about to do. Yeah, especially for routing now because routing is done in folders. So I'll do my full routing before even getting 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 yes, I don't know. I'll just take it here and worry about it later. If you have 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 the 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 view 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. We have to get questions like this where people are like, you know, public's playing the difference between X and Y and the reality is the world is not as cut and dry as that type of thing. Just sort of put this in your mind of probably what this type of thing was is 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 prepping 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 end 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 client. Like a resizing 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.
And 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 would 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 it's fine to throw that into the client.
Yeah, I agree with you. And it is kind of one of those things that you learn. I remember the first 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 learn, OK, what can I offload on your client? So there's definitely like different issues and different situations that you will run into. And it becomes a bit of a field thing.
This is definitely one of those ones that you'll get more experience with. Yeah, it could be a security thing as well, like generating a slug for a blog post. That should happen server side, right? Like even if you're generating a client side, there's a possibility that someone's going to to realize, Oh, we're sending a slug for that.
Let me make the slug custom or let me override it or let me do something nefarious with it. So yeah, I'll have to think about like, should the user be able to if they were, 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.fm and click that submit a potluck question button and you can ask us and we will answer it on the show. If we deem your question to be lovely enough questions asking about when West is it.
TypeScript course will come out will not be right on air. That's been certainly enough of those. My OK, 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 car 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 first got it, I think our kids maybe 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 eight plus, which is maybe a testament to our kids' ability to pick up games like this. But my daughter who's four, she gets the rules.
The only thing she can't do is there's a small math section and we'll play without the math section because she can't do that on her own. But my son, he can do the math. He can play this completely on his own. And we play this in our family.
We've been playing this in our family game night all a lot and it's a lot of fun, especially if you're looking for a card game for the family type of things that kids will pick up and play. That's cool. It's got these cute little cards that 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. The favorite queen is probably the heart queen because it gives you 20 points. I'm going to stick back a package box 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 code, simply just a box where you can put a big old plaque on it that says packages. So 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.
Because we live in an area where people steal a lot of our packages. So simply just putting a package box on there was really nice because if we're not home and a package is delivered, we know, okay, at least it's not lying on the front porch where someone's going to quickly snatch it 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 like a resin outdoor box or a deck box.
I think they're often called where people sort of like outdoor cushions. And then I got like a really small one to store my charcoal in near the barbecue. So it doesn't get reined on. But that would be a good, good idea for a package box as well.
Yeah. Yeah. I've always wondered about having something like this. We end up having like a pretty good blind spot that people just put it behind the blind spot.
Like one of the posts. Oh, that's good. Yeah. So you want to see it from the street?
Cool. Well, shameless plugs. I'm going to plug the syntax newsletter. You can find out about the syntax newsletter over at syntax.fm forward slash snack pack.
I'll have the link for that in the show. We do all kinds of stuff, whether we're finding a hot take a tweets or interesting links that we found over the course of the week. We've done eight issues at the time of recording this, but we do that every other week, a new issue comes out where we just share it neat stuff. So if you want to join and become a part of the syntax, snack pack, I'm number two syntax.fm forward slash snack pack.
Beautiful. I'll shamelessly plug my social media. Check me out wherever you I've been posting, absolutely everywhere. So if you're on TikTok, Instagram, LinkedIn, Twitter, threads, I think that's, that's all of them.
I've been posting into all of those places. So check it out. Send me a tweet. Send me a post.
This is high. I'd love to hear from you. Word. I'm at West Boston.
Yeah. At West Boston. Yeah. And we're on syntax on all of them as well, too.
Syntax is everywhere you are. So check it out. Thank you so much for listening to this potluck. We will join you on Friday where we're going to be talking to you.
Gives an easy plea about no JS performance, which I could not be anymore excited about. He has so many great tips about performance in general debugging, benchmarking, those types of things. So it's going to be a really good one. Hey, and 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.