938: Hot Takes + Bike Shedding  ## Metadata - Author: [[Syntax - Tasty Web Development Treats]] - Full Title: 938: Hot Takes + Bike Shedding - Category: #podcasts - URL: https://share.snipd.com/episode/aab1daaf-ad0c-4c44-86be-72d9ec334319 ## Document Notes ## Highlights - **Use Semantic CSS Variables** - Prefer semantic CSS variables like --primary for UI roles instead of literal color names that may change. - Map semantic variables to color tokens so you can update themes without renaming usage. Transcript: Wes Bos This is in CSS. When you're naming your variables, do you name them after the color that they are, like dash dash red? Or do you name them after something like primary, secondary, base, border, things like that? Like what more of what they would do in your application. So what I'm going to put myself, I made these questions up and I'm actually not sure right now. I think I'm going to tend towards the primary side of things. I will have a variable of my colors, but then what I'll do is take primary and assign it to red. ([Time 0:01:30](https://share.snipd.com/snip/fa144156-9167-49fe-ab29-8f0076003062)) - **Snake Case Can Aid Differentiation** - Snake_case can help visually distinguish your code from built-in camelCase APIs and improve readability for some developers. - Choice often comes down to team convention and personal taste rather than technical necessity. Transcript: Scott Tolinski All right do you prefer snake case or camel case as javascript developers oh my has brought a new head in here and it's larger i prefer snake case myself west what do you think man all the Wes Bos Arguments for snake case make so much sense i just have not made the switch myself i've been in many projects before the syntax website themselves, where we use snake case, and it makes A lot of sense. But I simply am still on team camel case for most of my projects by default. Scott Tolinski Yeah, team camel for sure. I mean, I personally man snake case for me all the way. Not only do I think snakes are cooler than camels, I just tend to read this so much better when I'm looking at my code. And I certainly don't mind the fact that I'm the only one writing snake case. ([Time 0:03:37](https://share.snipd.com/snip/a90d6ff3-ff5f-4b82-b70f-737414178552)) - **Favor Named Exports** - Prefer named exports so imports remain explicit and refactors won't break other files unexpectedly. - Use default exports only when a file conventionally exposes a single primary item, like a route or page. Transcript: Wes Bos All right. When you're writing JavaScript, do you prefer to export default from a file? You have one file and there's one main thing that happens in that file. Do you prefer export default or are you using export, like a named export from that file and why? Scott Tolinski I am almost always going to export named because for me personally, it is so much more predictable, reliable, extendable. If I add another module to this file, I don't have to worry all of a sudden about changing anything else in any other file. To me, it makes the most amount of sense. And I will use this 100% of the time. Wes Bos Yeah, I agree. Unless I'm using something where the convention is, the main thing exported from this file, like routing, right? You have an index.tsx in a specific route, and the main thing that you export from that will be your layout or your page. Otherwise, if you're importing that anywhere in your application, I'm going named export all the way. And I find it much easier to have the autocomplete import. I find it much easier to rename things. ([Time 0:04:54](https://share.snipd.com/snip/c82887ea-d9ff-4079-94b5-860222a7810f)) - **Skip Barrel Files In Apps** - Avoid barrel files in apps because they hide imports and can hurt tree-shaking and code-splitting clarity. - Use barrels when publishing a library to present a single explicit public API surface. Transcript: Scott Tolinski Okay, do you prefer barrel files or importing directly from the file itself? A barrel file is when you have an index file at the root of a directory, so therefore you can import things essentially from the directory itself. It kind of scoops up all the exports from the files and then re-exports them into so you can import directly from a directory which do you prefer to do man i 100 don't like barrel files because Wes Bos I find it's just another file to make i don't like any of the magic of having to explicitly import from like a directory and just assume like an index file inside of there. I don't even like importing without the extension on it. You know, I want to import.ts in all of mine. I want to be as explicit as possible. I think the whole require Node.js lookup tree is very complicated and it's a huge pain once you're switching different environments. So I'm very much of just put it in a file. Even if I have like a file that is named like format money and I'm putting that in another folder of the same name, I'm totally fine with that. I much refer that over just like an index.ts in my project. Scott Tolinski I am going to say I agree, especially because I think that like earlier in my career, I thought the, it was a style over substance for me. I thought, let me make you come out of, I'm going to come out of your ear here. I thought that specifically, it would look so nice to have just the import from a directory. But I didn't necessarily think about the logistics. I didn't think about tree shaking, code splitting, those types of things where, like, you're really trying to reduce the amount of things anything loads at any given point. I shouldn't have to load every single file from a directory when i'm importing from one directory i shouldn't have to if i don't need to so for me personally it was definitely a style over Substance thing and once i was just like why am i doing this like what am i getting out of this and taking a look at it from a more objective point of view i realized there wasn't any single Good reason to do it so i'm not doing barrel files i ([Time 0:06:23](https://share.snipd.com/snip/10a86e15-e6b8-4511-bbe0-e226a52c4034)) - **Prefer Function Declarations** - Declare functions with the function keyword for clarity and to use hoisting intentionally. - Prefer declarations unless you have a specific reason to assign a function to a variable. Transcript: Wes Bos And the difference between those two are a function declaration is where you write the word function and then the name of the function and then the whole signature. Sticking a function into a variable. And this could be an arrow function. This could be simply just saying const do things equals a regular function. They are different in how they work given the way that hoisting works. But other than if you understand how hoisting works, they are, I don't know, for a while we saw a lot of people just doing the function expression, sticking an arrow function in a variable. But I am very much of the mind that a function declaration is the way to go. I much prefer that. The only pain in the butt is that with TypeScript, the hoisting problem bites me in the butt. And I have to often do like, if you want to check if a variable exists, you have to do it in every single function. But other than that, I'm much, I'm a big fan of the declaration. Scott Tolinski I am a big fan of function declaration as well. I just feels like it makes less sense to me to make a variable. This is stupid because so many of my decisions are aesthetic and ergonomic based. But to me, it feels like it makes less sense to just declare a variable to equal function where it's like, we have a keyword for that function is the thing. ([Time 0:09:24](https://share.snipd.com/snip/0c4b5c78-f51f-4e6b-82eb-97eaf2ffaf1f)) - **Be Explicit For Public Types** - Make TypeScript types explicit for public APIs and places where AI or other devs will consume them. - Lean on inference for internal code where brevity aids development and types remain clear. Transcript: Scott Tolinski Do you prefer, Wes, inferred types in TypeScript or explicit types in TypeScript? Dear God. Wes Bos I'm running out of these fun ones that I made. I should have spent a little longer working on them. I used to be on team infer quite a bit because when you made changes up your tree, it sort of like filtered its way through much more easily. However, I find that with AI, it's often better to have more explicit types. So I've sort of landed on like two things. One, is this an external API that will be imported and used somewhere else in it? If I am going to be importing this function or this API somewhere else in my application, I'm going to make that explicit. And then two, if this is something where AI is going to need a little bit of help in that, I will also make it as explicit as possible. Otherwise, I love leaning on inferred types. I find them very handy. Some type script, even if you use some of these libraries, like a lot of the TanStack stuff, it's inferred all the way down. You're not actually writing any types yourself. It's just inferred, inferred, inferred, and you just have full type safety all the way down. So I'm going to put myself maybe in the middle of that one, given that I will be explicit when it's necessary. Scott Tolinski Wishy-washy here is what you're saying. You're a flip-flopper. I'm going to put my flag in the sand on explicit types. I'm talking, we're talking parental advisory here. That's what I like to have here for explicit types. I'm dropping F-bombs in my types. No, I personally think that it is, for somebody who likes things so streamlined, this is one of the absolute things I do not mind being verbose on. It makes things crystal clear. To me, it like clears up anything it finds little bugs yeah you could say okay you know your function returns uh this and therefore having that be inferred that makes a lot of sense but For me if i'm writing code i can write the inputs and the outputs first as types and then i can write the function and then i can know if there's anything potentially in that function that Would cause an issue there. ([Time 0:11:00](https://share.snipd.com/snip/eec0f287-2e31-4a21-915b-c4f2768b19f4)) - **Sentry Helps Debug AI Issues** - Wes and Scott mention Sentry's new features as helpful for AI-driven projects and debugging. - Sentry can surface issues and even submit pull requests to fix problems automatically. Transcript: Wes Bos Let's talk about Sentry real quick. Absolutely hilarious. The Sentry.io website now has two things that's hilarious. So the new tagline is someone's got to babysit the bots. So if you are working on anything AI, things will go wrong and you're going to need Sentry in there to help you find out what happened and help you fix it. And a lot of times it will just automatically fix it and it can go as far as just send a pull request to you. So that's really cool. But also they have a marketing mode toggle on their website now where you can like turn it on and it will simply just give you a chat box. No marketing copy, no value props, no obligatory logo rivers. What's the point? Everyone uses it already. The fact that you don't can't be fixed. It's just a chat box of ask me about features and troubleshooting, blah, blah, blah, blah. So check it out. Century.io forward slash syntax. ([Time 0:13:41](https://share.snipd.com/snip/00a81086-f003-4dfc-9846-9ae8274c828c)) - **Choose Descriptive Variable Names** - Prefer long, descriptive variable names over short names with comments to keep meaning with the value when imported. - Use comments sparingly because they often get lost when code is moved between files. Transcript: Wes Bos What it does? Or do you prefer a variable that is shorter, paired with a comment above it? Scott Tolinski You know, this is one of those things. Again, when I was a young buck, I was like, let's name background BG. Let's name color CLR. Let's go as short as possible for no stinking reason. And I have grown up. And that is one of the reasons why I absolutely go for long and explicit. Let's give me as long as you want, it for me tells me exactly what the dang thing does. And that is such a man. I don't mind writing comments, too. I'm going to say I'll write comments with this style. But I have no need for things to be short. Like there's my computer's got gigabytes on it. I'm not. ([Time 0:14:45](https://share.snipd.com/snip/5cdf0334-8a32-46cf-9fee-893391ec823c)) - **Use Comments For Context** - Write comments to explain context, quirks, or integration details that names can't convey. - Use comments liberally when they clarify non-obvious interactions in the codebase. Transcript: Wes Bos A lot of people say you don't need comments in your code. Should your code be able to self document? What are your thoughts on that? I love comments,ments all day long. Scott Tolinski Yeah, like, please, like, sometimes telling you simply what the thing is and what it, you know, what its name is and what act it does doesn't give you enough context about even like, I Don't want to say just quirks, but like the things of the way the application actually integrates and works with each other. I mean, personally, I like comments. I comment all day. ([Time 0:16:31](https://share.snipd.com/snip/a9cce167-488c-40b4-a1bd-94e82e829a5e)) - **Merge Vs Rebase Tradeoffs** - Merge commits keep history intact and avoid some rebasing pain when branches depend on each other. - Rebase cleans history but can introduce extra work when coordinating dependent changes. Transcript: Wes Bos Man, I have flip-flopped back and forth so many times on this. I don't like the merge commit because it muddies up the history. But I also don't love the rebase a whole lot because I find it a pain in the butt. As soon as it's been rebased and then put into a single commit, then, oh, I have some other code that's dependent on this. And then I have to rebase that. And I just, I find it to be a bit of a pain in the butt. So I lean on my repos a little bit more towards the merge commit. The syntax website we have on rebase. And it's it's OK. But I much prefer to just squash my own commits, make sure everything is good and then just have a single merge commit and happy with that rather than rebase it. ([Time 0:17:10](https://share.snipd.com/snip/81fe88fc-37ea-4a14-8863-46847b011119)) - **Use Common Short Parameter Names** - Use concise parameter names like e for events and req/res for request/response in event handlers where conventions are clear. - Reserve err or errr for errors to avoid confusion when multiple contexts overlap. Transcript: Wes Bos Right when you're doing an event listener and you need to pass the event as a parameter um are you using e ev or typing out the full ass event i'm doing e i would only ever do e which is interesting Scott Tolinski Because i also do e for air which it feels like that should probably like i do e for air i do e for event and then like only at this very moment am i realizing is there some kind of conflict this Wes Bos Is like not something i've ever thought of before but is it is it a conflict actually you know like it's like well it hasn't been sitting here it hasn't about it yeah no it hasn't been a conflict Scott Tolinski Actually. And in fact, this also is a conflict with my previous answer of long name that describes what it is or does. But like, for some stupid reason, things like errors or events like, you know, that's one of the few things I'm willing to make an exception for. Wes Bos I have a list of like things that I allow explicitly in my ESLint config and E. And these are also variables that can go unused. REQ for request. RES for response. ([Time 0:18:39](https://share.snipd.com/snip/e3394ef0-d10e-4244-a560-dabf4aa97b35)) - **Prefer Tabs For Indentation** - Use tabs for indentation to keep files smaller and let each developer control visual width. - Configure formatters and linters to enforce tabs and avoid debates about display. Transcript: Wes Bos Am on the same team as the underscore, where I have fully understood that tabs are better because it's less characters. Anybody who's using a tab character can adjust visually how big it displays in their editor. At first, the argument for spaces was that tabs show up really funny when you're like viewing source or it shows up really funny on a lot of editors. Those are solved problems. You know, you can you can change the actual tab one. And then quite a few of my projects still use spaces, but I've switched over to using tabs simply because it's one character. You can adjust how big they display in each one. So I'm a big fan of that. Scott Tolinski Yeah, I personally, I am a tab man all the way. I use tabs. It's an easy thing to change over to. I used to use spaces. You just change a setting in your formatter, your linter, whatever. You're done. That's it. Bingo. Who cares? Tabs all day. It makes the most amount of sense to me. You can change the space in the editor. Tabs to me make the most amount of sense. And I am firmly in that camp. I actually don't even understand the argument for using spaces. What is it? ([Time 0:20:41](https://share.snipd.com/snip/395fe883-0e88-4820-9a1e-154fbb77cc2d)) - **Keep Small Line Height For Density** - Favor smaller line height to increase information density while coding and reduce scrolling. - Use larger line height only if it noticeably improves readability for you personally. Transcript: Scott Tolinski Which one do you prefer? Wes Bos Man, I am firmly in the camp of small line height. I don't know how these PHP developers do it where they have six lines of code on their screen at once. I'm all about having things feel calm, but have high amount of information density. Part of that comes from being able to screen record and you don't really have a lot of space when you're screen recording. You want to show as much code on the pages at once. But part of that is just like, I don't feel like scrolling around as much as I want. So I'm firmly in team small line height here. Scott Tolinski Yeah, I am in team small line height in practice, and big line height in concept. I'm the poster child for somebody who should like big line height because it like helps me read and stuff like that. But I just can't stick with it. What I end up doing is I've done this multiple times. I set my line height to be decently big. And then over the course of a week, I'm like, you know, this is feeling a little slow. Let me move it down just a little bit. And that happens eight times until I'm at the original line height that I was at before where I'm like, this is just feeling not right to me. So I end up always rocking with a small line height. ([Time 0:22:23](https://share.snipd.com/snip/04f13ca1-dd87-429d-8526-85de4b74cfe0)) - **Use Formatter Wrap With Generous Limit** - Let your formatter wrap long lines and set a generous limit (e.g., 140 chars) to balance density and readability. - Prefer wrapped lines over hard scrolling when you want to view more content without side-to-side scrolling. Transcript: Wes Bos Right, this is another one that I think comes from a lot of like older coding and people still follow. And this is hard line length. Like you say, I want to be 80 or 120 characters in, or do you just let your code wrap around? So if you're chaining a bunch of methods, is it fine to let it wrap around? I'm curious your thoughts on this. And I think there might be some, it depends here. Scott Tolinski So I tend to keep it as vertical and thin as possible. But in practice, end up just using uh i i don't use either of these i just i don't have it wrap i have it scroll oh side to side and because of that i do tend to make it a line length in terms of Like when i code i keep it all vertical yeah but i don't have anything forcing that. And I don't also have line wrap because I like one line per line. And that line wrap to me is obnoxious. So if you were to make me be in one of these camps, I would say give me that hard line. Wow. But in practice, I just end up scrolling. I'm a VS Code user. Now that I'm a NeoVim user, maybe that changes. Wes Bos Man, I love line wrap. And I do put, I think I have 140 character limit. And basically, I don't necessarily care about either of these because I just let my formatter take care of it for me. ([Time 0:23:51](https://share.snipd.com/snip/724ddef6-5ec5-4fbf-8eef-c341656e9c5d))