React vs Svelte × Windsurf Worth $3B × Typescript as Const × Layout Shift Tricks × More

Welcome to Syntax. First thing, Denver. We're having a meetup. May 29 in Denver.

CJ lives in Denver. Scott lives in Denver.

I'm flying to Denver. We're gonna be doing a meetup with Vercel and Mux. It's gonna be awesome. It's called the Devs Night Out. Go to syntax.com/meetup and grab your ticket for us. There's not a ton of tickets available, but we would love to come. We're gonna do some fun coding stuff. We're gonna hang out and have some drinks. It's gonna be really fun. Today, we got a Pollock episode for you. We're gonna talk about Wind Surf being acquired for $3,000,000,000.

Does UI matter any more in the age of UI? Some talking about TypeScript keys and using as Scott. CJ's got a really nifty trick for you. Couple layout shift tricks on how to avoid that with using progressive enhancement, responsive design, some tools that can help you do that, and finally, React versus Svelte. We're gonna be answering which one is better in this episode. Let's get on into it. No Scott today. Scott is are off in Barcelona, so we got CJ,

coming in. How are you doing, CJ? Doing good. I'm excited to answer some questions. I I did a little rearranging. There's more stuff visible in the background now. You can't hear it on you can't see it if you're listening to this. But Yeah. Watch watch on YouTube. You can see my all my stuff behind me. Yeah. Yeah. Scott some some grade a tchotchkes. We got a PHP elephant? Yeah. I got this at a a Luracon last year.

Ugh. Yeah. Did you know there's a website for every PHP elephant?

I learned about this. Yeah. They were telling me all about it because these were these were in very high demand because, like, yeah, various vendors put the PHP logo on an elephant of various colors, and then everybody wants one? Yeah.

It's ella, e l e p h p a n t, dot me, elephant or elephant dot me.

And, apparently, there's, like, 78 unique there's a century one. I thought about just doing, like, a I I did a quick mock up of a hilarious JavaScript one that was like a deformed elephant.

Yeah.

Oh, I think that would be great. So let's let's get on into it. We got a Pollock for for you today. Please keep the questions coming. You guys have been submitting some really good questions. Go to Syntax.fm in the top right hand corner and click on submit a question. We'll answer it in the upcoming episode.

You can ask us about anything, coding, love, life.

CJ could teach you how to kick flip if you want, if anything goes.

First of all, this is not a question, but I thought let's talk about it because it just happened, I don't know, a couple hours ago or or or twelve hours ago.

Windsurf was acquired by OpenAI for $3,000,000,000.

Yeah.

Unbelievable.

Insane.

Yeah. Yeah. It's a lot of people are kinda freaking out right now being like, oh, it's a it's a Versus Node fork for $3,000,000,000, and they've been working on their their tech for a long time.

Windsurf was a Versus Code plug in for many years called Node, and I don't think that OpenAI necessarily cares about a Versus Code fork. They care about the actual tech on how to submit it to the AI, how to apply the edits. Apparently, that's one of the hardest part about it. It's just simply taking the diffs back from the AI and and accurately putting it on. So kind of an interesting Node.

Definitely. I I think I I've been reading Reddit threads too of just people kind of, like, well, why would they pay so much money for this? I think it all like, I think they're buying time JS one thing. Right? Like, they could try to build something from scratch. But Codium has been working on this for a very long time. So they have the expertise. Like, you you have the team on the podcast. Like, they have incredible expertise. It was so cool to hear how everything works under the hood, and, like, they're they're doing really cool stuff over there. It's not just call the OpenAI API and then plug the results into an editor. There's a whole lot more that that needs to happen there, and, they they have the tech.

If you wanna listen to that one, it's syntax. Fm four slash eight seventy.

Yeah. We had the now probably very rich founder of, of Windsurf on, Varun Mohan with with Kevin Howe as well.

And,

they're they're really good guys, so I'm I'm happy for them. It's it's still a hell of a lot of money. I know they had, like like, a quarter billion dollars in funding alone. Mhmm. So it's that's it's a big business, man. Yeah. I think to talk about the like, why they would get acquired too, like so right now, I use Cursor. I don't know too much about the space, but I do know that, like, in Cursor, I'm typically using I think it's the Claude Sanity model for most of the auto completions. And I don't know if OpenAI has one that's comparable. I'm almost always using Claude Sonnet. So it's almost like, by also acquiring this, they can create their own model similar that's, like, specifically for coding for coding editors, and they have a way to test it, to dogfood it, versus just letting people use the regular OpenAI API. So I I I expect that some special model is probably coming too. Totally. Yeah. You're right. They they WinSurf probably has a ton of data on

acceptance rates and and what people want and all of our code, unfortunately. Deno.

They they say they don't.

They say they don't. So that that's a joke, by the way. Yeah. Let's get into the first question we have here. This is also about AI from Lanny J. Wes.

What do you think the future of UI is now that AI is such a heavy hitter? Will design matter? Yarn we headed for voice driven custom experiences driven by AI? Do all of us front end folk need to learn back end services and ditch the fun, creative UI and CSS goodies? This is I I put this question in there because it's this is the opposite of the question that I've I've been hearing. And I think that as the UIs get, like, standardized, you know, everything starts looking looking the same, everything works, the solving the problem of how do I actually create a custom UI, how do I solve problems with a UI that has not yet been solved? That becomes so much more of a a valuable thing JS well as just, like, creating stuff that doesn't look like literally everything else that that the AI is going to be cranking out. I think that having

creative and fun and interesting and and UIs that spark joy are going to now be one of those differentiators when literally anybody any monkey can bang their keyboard and and push out an app. Yeah. I completely agree. I I think it's the novel experiences. And then also, I mean, you could get into this idea of once AI is building everything, what's the point of doing it yourself? I mean, it's almost like it's it's like being a craftsman. Right? We don't necessarily need carpenters anymore to build stuff from wood. We could three d print everything if we wanted to, but it's about the craft. It's about, like, the the hands on that really create something unique, and I think we could bring something similar to unique UIs.

I think about this also in terms of, like, far future, though. So let's say ten years down the ESLint. And that that actually does bring up an interesting question because we've seen it in some of the products that introduced, like, an AI chat window. So if, like, I guess, like, Google Docs and some of, like, Microsoft Office and all of these tools that now all of a sudden just have, like, a chat bar Bos the Node, where you don't necessarily have to know what all the menu items are anymore. You can just say Yeah. Do this thing, and it has the context to be able to be, like, oh, well, I know that you need to click this menu, do this, do this, do that, but then the user doesn't have to know that how to do that anymore. So I do see a future where our interfacing with software becomes less and less about clicking menus and more just about, I wanna do this thing, and then it figures it out. And that's also where some of the, MCP comes into play, like Node context protocol. Because if you can have an MCP server that understands your app, understands every single menu, then it can very easily convert natural language into actions that the user can perform.

Yeah. I've I very much like that. And and even if you do need a UI, can the UI be adaptive to to what you want? You know? Like, we've all had obnoxious websites.

I don't know if I trust the end consumer to tell

them tell the AI what the UI should look like Right. Because in in that case, it's all checkboxes and buttons all the way down. Yeah. But we'll see. Yeah. And but I also think, like, at a point, there might be no AI. And, again, this is, like, far future. This is, like, we're in it. We're plugged into a virtual Sanity, and, like, there's the feed, and we're just speaking or thinking what we wanna do. At at that point, you don't you don't necessarily need to see anything because you're just telling it what to do. So, like, the UI the UI can look however it wants, but it's just, like, do this thing for me, and then it makes it happen. I don't know. Alright. This next one is from, Jason Sauer, who says, hi, Scott and ESLint CJ.

CJ. Yeah.

Long time listener. Love the show. I need to reduce spam submissions of the contact form on my website. ReCAPTCHA is the top of mind of choice, but I've had issues with Google reCAPTCHA being blocked by the ad blocker malware or spyware prevention software on my system, and I do not want my visitors to have the same issues.

What do you recommend when it comes to securing the forms on a website? Thanks.

PS, Scott, my daughter Sydney worked for you at LevelUp a while back, helping with social media newsletter and other things. I'd like to hear that she has since graduated from Ohio State University and is finishing her first year at Harvard working toward her PhD. That's awesome. We'll have to relay that to to Scott. Yeah. Yeah. I guess there's a lot of things you can do. I Wes, I haven't necessarily run into issues with, like, ad blockers in terms of reCAPTCHA. I think a lot of those have the right white listing in order to make sure that the captchas still come through. But I think beyond captchas, there's some other stuff you can do on the back end, like rate limiting, limiting by IP address. So rate limiting is essentially, you can only allow a certain number of requests every number of seconds, and then that window of time can also increase. So it gets harder and harder to to spam your spam your back end. So, yeah, rate limiting, that's one thing that comes to mind. What what do you think, Wes? Yeah. It's unfortunately

at a spot now where I don't think you can have a form submission without some mega corporations, like, recaptcha or or Node in there because, like, we used to have honeypots, which would be a a decent option. You could hide, like, an input or or ask it a a simple Wes, like, what is two plus two? But, like, AI can solve all of that plus a lot of these CAPTCHAs Yeah. Which is is really frustrating, to do.

So I think you've just have to you gotta put a CAPTCHA in there. And and even in the case of that, these CAPTCHAs are just trying to keep up with with the bots and them trying to figure it out or simply just like people have 20,000 people overseas that are simply inputting CAPTCHAs all day and and solving them for the these bots.

Yeah. My go to right now is Cloudflare Turnstile.

I moved a lot of my stuff out of reCAPTCHA and into Cloudflare Turnstile, and it's so much easier to implement. They try to not pop up anything by default, which I'm a huge fan of. Google tried does that as well. You'll notice that if you're on, like, a VPN, you'll get a lot more captchas, but if you're not, you'll often do that. And the reason behind that is because these big companies, Google, CloudFlare, they know a lot about you. They know what websites you've been to. They know that just like different things that, like, they use to detect if you are a human. They don't say what those are, but I would imagine it's it's even goes down to just simple little mouse movements. You know? If your mouse movement is on a curve, it's probably or if your mouse movement goes down out of and it keeps the, x y pixel perfect every single time, you're probably more like a bot. I'm sure there's little stuff like that that they're collecting. CloudFront Turnstiles is really good, but I have had issues with, specifically, reCAPTCHA.

My kids use on the iPads, they have, screen the screen time on Apple, and you you have to white list every website you want them to go to.

And if you wanna sign in to any application, almost always in the app, they open up like a in app browser, and then you have to allow that website to be able to work in the app. And then that website also often uses reCAPTCHA, and I could not for the life of me sign in to all these apps. And I was like, what is going on? I can't sign in to anything. And finally, I was like, it's probably Google reCAPTCHA being blocked.

So I had to figure out what all the domains were, and I had to add them to the white list on my kid's iPads. And it's just an awful experience all around, so very frustrating.

And I know a lot of, like, corporations or whatever, they just they go all they block all Google, and it's really hard to

to use anything that uses reCAPTCHA because it's such a big part of the web. I wonder if maybe you've used a tool like this, but, like, what if you handle it on the other side? So, like, we yeah. Let's say you get a lot of spam submissions, but what if you have some kind of filter that says, okay. Of all the contact form submissions you got, these are the ones that are most likely to be real people? I feel like you we could build something with AI that does that, or is there a service that does that? Yeah. Probably. But it's you always come down to the, like,

the problem of the AI is good at making itself seem human. Like, I have in my own email, I'm using miss of AI.

Every email that comes in, I I run a a ping to OpenAI. I say, does this look like someone who's trying to sell me something? Mhmm. And then it reads the email, and then it will it will return true or false, and then I can tag it as, like like, spam. Because spam spam does not work anymore. I get so much spam in my Bos, and it's because the AI is really good at at sounding human. Right? There's Yeah. There's the old, like, watch for spelling mistakes in a email because it might be spam.

That's not a thing anymore. You know? We could we figured that out. So it's it's really hard to get around it. It works pretty good, but only, like, 80% of the time. There's a lot that that gets through, and it's it's like a full time job. Again, it's my, I think that a lot of this AI stuff is gonna ruin the the Internet as we know it right now. Definitely.

Next one from MCB. I often run into the problem where mobile and desktop versions of a site design include differing versions of the same content. Let's say the design is for a group of blog posts to be in a carousel on desktop, but on mobile, it's not supposed to be a carousel, and the blog posts are just supposed to stack.

Rather than have a listener on the window resize event and the initial, initialize the destroy carousel and different window sizes, I usually just include both versions in the HTML, using media query to hide and show it. Is there a better way to do this aside from duplicating the content in the HTML? I've always been a bit hesitant.

Yeah. There's a couple things you can do here. First of all, nothing wrong with duplicating HTML.

I think we spent too far, especially with navigations.

We've we've tried too hard to, like, have the same markup for a nav and, like, the totally different experience on on the two. So that's one thing. And and second of all, most users are not actually resizing their windows.

So if you simply want to just bind on load because it it looks like a mobile browser and not have to worry about window resizes, I think that's also fine as well. The third thing is window dot match media. So, essentially, the same way that you're using media queries to style everything differently, you can simply just run a window dot match media media query in your JavaScript before you go ahead and and do all of that binding. So so that's an option as well. And the last thing I'll say here is that so much of Carousel I know it's Carousel is just one example, but so much of these new features that we used to reach for JavaScript, you can now do them in CSS with

scroll snap and view transitions and all the stuff that we're used to. So you might not even need JavaScript, and and if that's the case, then it's just a CSS all the way down. Definitely. I I completely agree. I mean, honestly, I will say, though, a pet peeve of mine is when I load a site that is, like, only mobile, and then it's missing features from the desktop site. Oh, it drives me nuts. Yeah. This happens for me, like, on Amazon. If you dive into the reviews, there's, like, filters that are missing when you're on mobile. So I always have to go, like, choose desktop. So I'm I'm a huge believer, like, conditionally show these things or just, like, re rearrange them, resize them using CSS.

And the idea of, like, a CSS only honestly, this sounds like a code challenge to me. Like, can you create a carousel that's CSS when you're on desktop, but then on mobile, it stacks and isn't a carousel anymore? It sounds doable with modern CSS.

Easy. Yeah. Yeah. Well, maybe not easy, but maybe for the next code challenge, we can build that because Yeah.

That's

definitely definitely doable. Alright. This next one's from Dave from Durham UK who says, is it okay to use a JSON file to import data for a website build? I'm building a small website using Svelte, and I'm using a JSON file stored within the file structure to store the data and access it throughout the website. There's no sensitive data in the file, just testimonials, images, and project work. Okay. So I I can think of two different scenarios here. If it's just a read only JSON file, I say great. Like, a a lot of times, you don't really even need a database for this kind of stuff. You can just kind of structure it out. And, especially, even if you're prototyping, structure it out in JSON first. Figure out what is what is the data structure needed for your site, code against that, and then you can start to go make it interactive with an API.

But I I think that's a great way to start. Where this breaks down is if your back end routes are, like, writing to that file, you could and you could run into issues if you actually try to deploy this to production. First of all, you need to make sure you're on a a server that allows your back end to actually write to the file system because you can't do that, like, in serverless environments. And then if you can, you might run into various race conditions where, like, two different users are trying to write to the same file at the same time, and then one of the files doesn't get written. And that's why we have databases that are, like, ACID compliant.

And if you deploy that thing again, then your changes are gone. Right? Exactly. Yeah. So if it's read only, absolutely. I think it's a great way to prototype, great way to, like, not even have to build out a back end. But if you are writing, you probably wanna look into a database.

Yeah.

My course platform is very heavily built on JSON files simply because I don't want to put it in a in a GUI. I don't need a CMS for that. The JSON file is the OGs, like, the OG, database.

Yeah. And now that you can import JSON files into ECMAScript ESM modules or ES modules, it's a a a really nice way to to store data, and and then you have the added benefit of no one ever accidentally putting any logic in inside of that.

Yeah. Totally fine. I think I think go for it. Definitely.

Luke Mazu says, love the show. I wanted to ask how you handle and track anonymous and duplicate users, where an app allows a user to perform actions like favoriting or creating appointments without actually creating an account.

I've run into the issue where you have multiple emails, phone numbers, and even names of the same person due to them performing different actions across the app without being signed in. Yes. This is a this is a pain even for mine with people who have multiple email addresses, and they they buy it with one email address, and they have a different account and and whatnot. And that's exacerbated when you have you don't even have the idea of an account, or you simply are just saying, like, here. Put in your email address. Put in your phone number. In this case, you need to first, you need to be careful that you're not attaching data to somebody's, like, phone number or email without confirming that they actually own that phone number or email address, because if there's a way to pull up that information simply knowing somebody's private information or semi private, then that's a a bit of a a bit of a problem. But that can be solved by simply just sending a token to the email or to SMS code to make sure that they actually own that. So what else can you do? It's you you basically have to have, like, multiple foreign keys in in your data records so that when somebody wants to query something, you're querying it from multiple versions and then also offering tools to be able to, like, claim or merge pieces of data from multiple accounts into one. Because that's such a pain where, like, you you like, I swear I bought this thing or I swear I I entered this account. And, like, oh, I used a different email address or, oh, I signed up with,

like, signed up with Gmail, you know, but then I signed in with another account that's I signed in with Twitter. It's such annoying thing. Definitely. I would say, like, as best you can, limit the amount of actions that a user can perform if they're not logged in. Obviously, it comes down to, like, business requirements or, like, what JS the person who is having you build the site want the users to be able to do? But, ideally, every user is logged in and things are actually tied to their accounts. This actually brings to mind BetterAuth. I I've been working with BetterAuth recently.

And they actually have anonymous user support, so people can just use your website, but it just stores a cookie that associates with that one browser session.

But then they have a way of linking accounts. So if that same user now wants to sign up, it can automatically merge the anonymous user with a brand new user that got created. So depending on the auth platform that you're using, that's something that you could look into as well.

Yeah. That's same thing with, like, carts as well. Right? Almost always, it happens. You you fill a cart up. You have this, like, anonymous session that lives for however long, and then you go ahead and create an account, and you transfer that session over to your to the actual account.

Right. This next question comes from Jerry from Jersey. Says, I've got a two part question. First, I love TypeScript most of the time, but why doesn't TypeScript recognize that when you use object dot keys, the keys are of type key of my object? I know there are workarounds like dot entries, but still it feels odd. Second, which do you think is Wes, using any or at t s ignore? Okay. So for your first question, why doesn't object dot keys get recognized as keys or if type key of my object? Because in JavaScript, objects are dynamic. Right? New properties could be added to that object at any time. So TypeScript isn't gonna just say, here's what the keys are because it's built on top of JavaScript and those objects are dynamic. The way you can get this to work is if you tell TypeScript that that object is read only, meaning those keys are never going to change, then you can actually extract that type out. So that's where the as const keyword comes in in TypeScript. So if you create an object, you say as const, that tells TypeScript that you're it's a it's a constant. It's read only. You're never going to change the keys in there. So if you do do object dot keys, that will actually come back as the correct type because it knows that those keys are never going to change.

I use that quite a bit in going back to the the JSON Yeah. Config. You Node? I'll import that and or I'll have an object that I've imported from somewhere, and I'll I'll export it as const so that you can get all of the keys from it really

nicely. Yeah. You get really good type completion that way. There's also a bunch of, like,

like, utility helper functions that will do the key of and extend it all. So you can also grab one of those and and throw it in.

Definitely.

But the other question, what is worse, using any or ts ignore?

What do you think? I think I think they're both both of these are an indication to the TypeScript compiler that I don't wanna worry about this, or I'm gonna worry about this later. I probably would say Sanity, because whenever I see myself reaching for any, it's because I don't wanna take the time to figure out what this type is or define the type. If I'm using JS ignore, I am explicitly saying, hey, TypeScript compiler, I know better than you, or I'm gonna fix this later, but it's a it's an indicator that, yes, I should come back to this point. And, typically, with the TS ignore, you can leave a little comment as to, like, why you're ignoring Sanity

should not be a escape hatch. Yeah. Any exists because there are some use cases in TypeScript where you literally want to accept anything. You Node? If you're doing, like, a high order function, it takes in a function with a whole bunch of arguments.

You don't know what the arguments are going to be because you're you're wrapping a function. So, you can still, of course, infer all of that, but in that case, you would would use an any.

But if you're using any as, like, an escape hatch, I don't know. It's in some cases, maybe when you're you're, like, moving over a code base, it's fine to throw in any in there. That's what I'll often do, and then I'll go back and do a search for it.

But in in many cases, if you do not know you what something will be, you should probably be using an unknown, which will explicitly make you check what the type is before you go ahead and use it. So for example, if you have a function that takes in an argument and if you don't know if that is going to be a string or a number or any other type, you should set that as unknown, and Wes that will make you first check the type of it. You check if it's a number, and then you go ahead and do math with it. You check if it's a string, and then you go ahead and and concatenate it. With anything, you just anything goes. Right. That's the question. I've I've never never thought about that. I I I don't use thankfully, I don't use either very often. I don't mean to brag or anything, but the answer should be don't use either, if you don't have to. Right. Let's talk about Century really quick. I'm just about to launch my my new website, and what I did is I diverted a little bit of traffic from my website to the new one. And, man, I did not catch everything. My I my sender started getting lit up, with with issues. It was really fun. I just I turned it on for for maybe, like, twenty minutes, and then I I put all the traffic back to my my existing Node. And I just it's just like a whole bunch of issues. I went through them and fixed them all, and then you mark them as resolved. It's my favorite thing. You mark them as resolved, and then sometimes they come back. And then if sometimes they don't come back, which means you've actually fixed it. So check it out. Century.i0forward slash syntax, and use the coupon code Sanity treat for two months for free.

Smile says, what's the difference between React and Svelte? I use React in my day job and Svelte in my side project. I prefer Svelte, but I don't I don't really have any issues with React.

The way I do loops is different. Hooks and runes are different, but the concepts are mostly analogous with each other, so I don't need to change mental models really. I feel the same way as well. I've I use Svelte and React both pretty heavily.

However, on Reddit and other social media in Svelte communities, I see people complaining about how they cannot stand React and that it is impossible to work with. I'd say I'm some sort of super developer. I can understand both, but I think it's more likely that I'm just not working with them on a deep enough level. First of all, people on Reddit just love to to complain. I think a lot of people on social media think that bashing a technology makes them seem smarter. I've I see this all the time, and it it doesn't make use you seem smarter. It makes you seem like a jerk, but a lot of people who are coming to the stuff brand new might not be have extremely strong skills.

There are way less gotchas in the Svelte world. I understand how everything works in React. I understand how how effects work, and and there's a lot of weirdness in React, but I understand how it works. And I know how to how to build kick ass apps with React, and it's not really an an issue for me. If you were to, like, learn both of those at the same time side by side, you'd be like, Svelte is clearly better. Like, this is so much easier. This is so much much better. And why is everybody using React? So I I understand

why that is the case. What do you think? Definitely. And I I think it's just, like, the history of these things. Right? Because React was one of the first, after Angular to gain popularity and and kinda just, like, really took over. And so a lot of people have been using it for a long time. And I think the other thing is the people that use React, it's job security. They don't wanna know that something is better or that they should go learn something else.

But personally, I I use them all. I use Svelte. I use React. I use Vue. I've worked with Solid. And I think that's what makes you look like a smart developer is actually knowing how all of these work, knowing the gotchas in all of these, because none of these are perfect, and then being able to build apps with them. Because I I could build an app with with any one of the the front end frameworks.

I have my preferences. And, personally, I do think that Svelte and Vue are a lot more intuitive than React. There's typically a lot less code, a lot less boilerplate, but that's just my preference. I think some people get into the world of React, and they're they're they basically their brain has been rewired to work in React. So when they see something like Svelte or they see something like Vue, they're like, no way. This is so different. But that's because they've been in React land for too long. But neither one is, like, objectively better. It's just a matter of preferences and and also past experience.

Yeah.

And the, like, problems that React have are not worth people moving a ten year old code Bos off of React.

The solution to that is you just learn how these things work, and you sort of keep going with it. So it's not that with the whole industry. React is not gonna go away anytime soon. There's just it's just too big and too much of a of a standard, which a lot of people don't like. But, unfortunately, that's the reality. It's a imperfect major player.

Yeah. And I would say, like, that's basically been Yarn half of my career is trying to convince people that Vue is better, and now, like, Svelte is better. But more recently, I'm back to Vue and Nuxt again. But it's it's an uphill battle because people people like what they prefer.

And, like, I I could show you side by side code where it's clearly simpler in, Svelte or in Vue, but you know, at the end of the day, it just comes down to, like, what you're used to and, yeah, what you're familiar with. Next one's from bike shutter nine thousand, and they're asking, how should you name your readme file? Should you do all lowercase README dot md or README is it Scott case with a capital r? So capital r, e a d, capital m e. Camel case, I always call it. Yeah. I think Pascal case as well. So Scott case dot md or all caps, README dot lowercase m d. What do you what do you prefer?

If you're doing Pascal case, you're a psycho. Don't do that. I always do it just lowercase.

Uppercase JS, like, constants to me.

Yeah. I do mine uppercase, but I think it's just a convention. I think I learned from, like, GitHub or something. It it one of the tools defaulted to all caps read me, and then now I just do that all the time. So most of my most of my top level markdown files are

screening case Wes it's it's all capital letters. I've never really thought about that, but, like, tools that have to, like, parse and find a README.

They have to, like like, lowercase them all. You know? And if you're doing the, like, capital r, capital m, you for sure are gonna hit some weird edge case someday, and that's gonna be a a pain all the way down. But, like, there's no other config files that we do upper case, is there? Like, maybe contributing dot m d, you see that quite a bit. But, like, it's not like like package JSON or, log files are are in upper case. Yeah. I think it's a markdown thing. Yeah.

Spaghetti man says, how do you find the time or create opportunities to refactor code? I'm not talking about changing if to a switch. I'm not talking about changing to a new language or tech. I'm talking about, you know, the one part of your system that is a big old pile of spaghetti, and it's going to take some time to clean up. Yes. So how do you especially, like, when you have to, like, convince management, like, hey.

How about I spend three weeks making the code Bos do exactly the same thing, but probably bugs will be be introduced.

You know? Like, we're probably gonna take a step back in here, and that that's a hard sell when people don't necessarily understand technical debt. For me, what I will do is I will often loop it into working on, like, a new feature.

So I'll say, like, okay. I'm gonna build a I'm gonna build a new checkout.

But in order for me to do that, I really need to get this, like, database thing kinda squared away, or I really need to work on this other piece of of checkout code that should be better first. And that's going to make the new feature, a heck of a lot better. So I think for, like, code that should be refactored, but you're not going to touch it, and it's not really in the way of of building any new features, just let it be. Let it let that sucker ride. But anytime it's like, well, I'm gonna Node have to build this new feature on top of that, it's almost gonna be faster just to refactor the initial thing first so that you can with the new feature in mind, you can you can do it much better.

Definitely. And I I think one of the main issues here comes down to, like, you're working a job, and you have to justify to the business why your time should be spent on this stuff. And I think that's one area where you can practice JS really letting management understand this idea of technical debt. Because if that big old pile of spaghetti sticks around, every new feature you add that has to touch it is just gonna create more spaghetti and JS gonna be harder to maintain. So just like Wes is saying, if you're gonna be working on a specific feature and it touches that code Yeah. You should add that to your estimate. Right? So now the estimate for that feature is actually just inflated slightly because you know you're gonna have to spend some time refactoring. And maybe you tell management you're gonna be refactoring, maybe you don't. Maybe you just increase the size of your estimates. But that, at least, would would give you the time to work on it.

Yeah. Otherwise, you tell them, like, hey. This this app is gonna suck in four years because it's all gonna be built on a house of towers. And and then when when something crazy like this AI stuff comes around and you need to slap in AI features to every single part of your application, the people that had, like, really Node, Scott a whole bunch of technical debt were able to add those features on much quicker. Whereas you look like, like, I was bag on FreshBooks for for whatever, but, like, they don't have AI categorization.

And I told them, like, two years ago, I'm like, I wrote this in, like, six minutes. I wrote a script that would categorize my expenses into the given categories that I have.

And two years later, they still haven't implemented that. Like, how hard could that possibly be that you would suggest, like, oh, the last 80 times that you you spent money at this business, you categorized it as as x, y, and z. How about we suggest

something? It drives me nuts. Yeah. Good luck with that. I hope you can find the the time to refactor.

Alright. This next one comes from Jakey Sanity, and they say, when you're developing and tweaking responsiveness, like working on grids or breakpoint behavior, how do you usually check your work? I find myself constantly grabbing the browser window edge and manually resizing it like an accordion to watch changes. Do you mainly use dev tools, device simulation, or is manual resizing still normal? I'm on a large Sanity, and it feels clunky sometimes. So I'm wondering if there's a better workflow you use for observing large UI responsiveness.

Personally, I maybe it's just habit, but I reach for resizing the browser window first. Like, that that's the easiest to be, like, okay, does it does it actually activate at that break ESLint? How does it look? Yeah. But, like, you're saying, device simulation is great because you can dial in that device width exactly. You can say, show me a screen when it's 960 Vercel, and now you can really debug that that break ESLint to make sure that it works at that exact because otherwise, you're trying to, like, finagle the width the width of the window to get it down exactly. So, yeah, I I think it's a mix of both. Personally, I think I just out of habit, I reach for the the window and resize it. What about US?

Yeah.

I I I kinda have levels of it. Something quick, I'll just resize the window. Mhmm. But I find it frustrating when you're debugging that because the dev tools also get smaller.

Are you a dev tools on the bottom guy, or you you you take them out or what? On the bottom. On the bottom. Yeah. Because, like, the the dev Node tools resizes. That's kind of annoying. So then if that's the case, then I'll hit the little mobile button, and that will allow you to resize the website without having to to do it. I find that also really helpful because I have many times missed a UI issue because I'm was simply just resizing the width of the browser, and I was not thinking about the height of the browser. And there's a lot of times where you go to a website, and it's just like, this looks like garbage, especially if you're on, like, landscape view because they didn't account for not having a ton of vertical room. So you Scott go for that as well. And then finally, I will often if I'm doing something that's like like a brand new layout, I'll fire up Polypane, which is a, a browser for web development, and then you could just set up, like, six or seven or or two or three different common sizes.

And then it's all live reload, and you can just code your changes. I'll have it open on another monitor, and you can view it in several different sizes. And I find that to be really helpful as well because I honestly try to build my stuff as flexible as possible so you don't need a whole bunch of breakpoints in there. If you're using Flexbox and Grid and maybe a container query here and there, you hopefully shouldn't have to throw in a whole bunch of breakpoints.

Definitely.

I'm just checking out Polypane. This looks awesome. So, like, is it, like, iframes or some so you you create several windows of different sizes, and it loads the site into them?

Yeah. Yeah. It it loads them all up multiple times, and it's all live reload. There's, like, a bazillion tools in this. Like, one of the features is being able to do that, but if you're debugging OpenGraph images, finding accessibility issues, doing like, figuring out where CSS is is being applied, form pnpm, you're syncing clicks across multiple versions of that browser.

Killen, who is, the developer of this, He's, like, absolute genius, and, I highly recommend paying for this because it's very good or at least doing the trial. I'll try yeah. It looks super sick. I'm gonna I'm gonna go to try for sure. Yeah. I always go for it when I'm open graph images Yarn my, like, my kryptonite. Is there anything in web development where you just, like like, you find yourself having to come back to it every single day or every every couple months? Like, I hate doing this. And for me, it's it's debugging open graph images.

I can't can't think of anything off the top. It's everything. Anything that I have to code again is my crypto All of Wes development. All of it. Yeah.

Oh, that's good. Alright. Last question we have here from Tibor. This is a big one, but kind of an interesting one. I'm wondering about strategies you know and can recommend when it comes to avoiding layout shift when progressively enhancing a page. I find that when building a website with progressive enhancement, there are often elements that I only wanna show in the basic HTML version or on the JS enhanced version. So progressive enhancement is this idea of you build the website so that it works with, ideally, just HTML, maybe just HTML and Vercel, like like and it works with regular form submits and all that. And then progressive enhancement is you add on a layer of of JavaScript to sort of enrich that experience. Right? So for example, consider a listing page GitHub selection in the form, clicks the submit button, and it it it submits a page, updates it. And then the progressively enhanced version, you use JavaScript and fetch requests to update the list when the user makes a selection. Right? Just a better a better experience all around. But you still have that submit button visible.

I find that it could be confusing as the user might think that they still have to click it, and they don't notice the list is already updated. Also, the original design might only be for the enhanced version without a button, and I added the button to only make it with for HTML.

So I wanna hide the button. He goes on to say, like, basically, like, what do you do when you have this case? You show the button by default, and then when the JavaScript loads, the the button is hidden, and then you get this layout shift. Right? You sometimes see this when you visit a website and, like, the login button changes from login to your to your avatar, and it's because the HTML Node, then they fetched. They ping their server. Oh, he's logged in, and then they swap it out, and that's kind of, kind of annoying as well.

So there's a couple solutions that that you have here. One of them JS, like, you gotta ask yourself, like, when do I want to hide that button? Do I wanna hide that button when I know JavaScript can be run, or do I want to hide that button when somebody can use the JavaScript? Because, I guess, those those are two different things. There could be a delay, maybe, between the actual loading and the the parsing of JavaScript.

If you simply want to say, oh, if JavaScript can be run on this page, then what you can do is you can do just an inline script tag.

Almost in, like, the head of the document or somewhere higher than your HTML that is gonna be displaying this. You simply just put a script tag in there, and that little piece of code will be will be blocking for for just a split second.

And you can add, like, a class to the body of, like, JS or something like that. And then if that's the case, that JavaScript will have run before the HTML has has been parsed and put on the page, and your when the CSS is applied to the HTML, you're not going to get that flash of content because the first render of the CSS is going to be with the class of of, like, JS on it. So that's one option that you have there.

The other option is you you could put, like, a, like, a height of a bar or put, like, an opacity zero on it so it doesn't actually shift it down. At the end of the day, you do have to to run some code, and you will have a little bit of layout shift. And I don't know that that's the necessarily the end of the world, especially if it's not pushing down the entire page. You Node? Something like you're pushing the navigation down.

Yeah. So I I like that initial idea that you brought up, and let me see if I understand it. So Yeah. The JavaScript runs, adds a class or some attribute, so that way like, to the body. So that way, your CSS styles could have an additional selector that says, if this property or class was added, that means they support JavaScript Yep. Which which then means we can style it according to the JavaScript way, and that's the first time they see it. There's no lay the outshift. Is that accurate?

Yes. Then we did the same thing with dark and light mode because what happens is the dark mode is if dark mode is not set via prefers dark mode, but it's set via, like, a like, a local storage Boolean, that's often the case where somebody will store it, and what needs to happen is they'll load the page. It'll be light mode. The JavaScript will run, then it will pull that value out of local storage, and then it'll apply the class. And then you you see light mode for just a second, and then it flickers back to dark mode. That's annoying. Right? So the fix for that is before any of your HTML happens, you put a tiny little script tag either in the head of your document or just right before the opening of right inside your opening body tag that simply just says, const is dark mode equals local storage dot get item, and that will allow you to apply a class to the body or the HTML tag before any of the HTML underneath it and before any of the CSS been applied so you don't get that flicker.

That makes sense. It almost seems like it's probably the the route they should go. Honestly, though, hearing this question, I just I just think of, like, how many of your users actually don't have JavaScript enabled? Like, I think it almost feels like you're optimizing for this, like, very small subset of users, whereas, like, maybe design with JS in mind first, but it's somehow and then maybe use CSS to conditionally hide or show these things, like, if JavaScript isn't isn't enabled. Because modern CSS does have a lot of these, like, selectors that really help with that. Like, there's the has selectors. There's also I've been messing around with, like, full HTML, CSS form validation. So you use all of the ARIA validator attributes on the form to, like, hide and show errors, but then you can also use those same attributes to enable and disable the button because it's all in CSS in terms of, like, is a input valid or whatever else. So there's ways to do that as Wes, but

yeah. I don't know.

Plus, maybe just don't hide the button. Yeah. Exactly.

Because, like, I can't tell you how many times I have, like a lot of, like, apps will have settings, and, like, you change, like, your Node. And then you're, like, sitting there looking for the button, and it's like, oh, it it does it automatically. You know? It JS soon as you you tab away, it it saves that value. Just give me a button. I wanna click it just to make sure. You know? Yeah. My preferred user experience is the button is it's still visible, but it's disabled if I can't click it. Because otherwise, I am all of a sudden, there is layout shift. I'm like, oh, well, first of all, I'm like, well, where's the button? Because maybe they have validation on blur, and I haven't blurred yet. And I'm like, well, how am I gonna submit? And then finally, when I do blur, the button pops up. Yeah. I I don't like that. Yeah. That also drives me nuts as well where you try to use some UI before their JavaScript has been loaded. Yeah. And you're, like, sitting there clicking the button, and it doesn't do anything, and it's because it is. I I think that's that's probably what he's trying to solve here. Mhmm. Because not that people are turning JavaScript off. We had a clip last summer where I was like, no one's turning off JavaScript. You know? And we got so many people mad at that because they're saying it's not that people are turning off JavaScript.

It's that JavaScript can, for whatever reason, sometimes take a second to to load. And then if that's the case, your UI is is broken. But, I don't know, especially for with these single page applications, you give it a a couple seconds to load the JavaScript, and then it works for your entire visit. Alright. Let's get into some sick picks And shameless plugs, I got a sick pick for you today, and it's a TV show, surprisingly. I don't watch a ton of TV because I don't generally like it. But me and my wife started White Lotus or my wife started light White Lotus, and I was just kinda walking by looking at the TV and, like, this is actually kinda good. You know? And we watched all three seasons in, like like, two weeks or something. And every single episode is, like, an hour. So every night, kids are in bed, like, let's watch a White Lotus.

And that was a fantastic show. I don't like a lot of shows, and I was surprised at how much I like this. So it's, it's an HBO show, so certainly check that out. Yeah. I haven't seen it. I've seen it advertised, though. I watch a lot of stuff on HBO Max, so I'll have to think of it a try. So my sick pick

is a chainsaw. So

I have.

Yeah. So, I'll I'll send some links to Amazon, but, basically, they sell portable battery powered chainsaws that use the same battery pack as the DEWALT, drills. I have had The little handheld one? Exactly. Yeah. And so I've had these, overgrown elm trees on my back fence for, like, four years now that I I would prune them. I would at least get the the branches off, but then they they got so big that I couldn't cut them down anymore.

And so yesterday, I got a I got a chainsaw that was compatible with the DEWALT batteries, and it was amazing. I just I was just chopping down stuff left and right.

Those things Yeah. Are amazing. Hey? Yeah. Like, you wouldn't think that this tiny, cheap, little chainsaw would be very good. It's amazing.

Definitely. And I have just a pile of, fallen branches and twigs that, like, I'm now gradually working through. Because before, I was like, I don't know what to do with this stuff. I guess every now and then, the city has, like, pickup days, but now I can get them down to a size that'll fit into my compost bin. So yeah. Mini chainsaws. They're awesome. You can break them down. Man, I

I have a gas chainsaw, and I almost never use it. It's just terrifying and super loud. And, like, I've got the chaps and everything that you don't cut your leg open. Oh, yeah. And then I have a I have, like, a battery, like a DeWalt, like, big chainsaw, and that thing is so much better. It's like butter through you wouldn't think it's, like, really quiet and, like, really calm, and you let go of the you let go of the thing, and it stops immediately. I'm like a gas chainsaw. It keeps spinning for a while. It's just kinda dangerous.

And then, yeah, we got one of those little handheld ones. We also have the, like, loppers as Wes, where you just it, like like, cuts it in cuts small branches.

Batteries are amazing. Battery tech JS is amazing.

Shameless plugs. We want you to check out our YouTube channel. Go to syntax.fm nope. Youtube.com/syntaxfm.

Is that it? Yes. I always forget all the the URLs for it, but check it out. CD just dropped an absolutely mammoth of how long was it?

Twelve hours total.

On Nuxt? Nuxt. Yeah. So building a full stack app from the ground up with Nuxt. Js. It's got a database. It's got auth. It uses maps.

It has multiple levels of routing. It's a massive app.

Man, that's and that's hilarious because every single comment on the YouTube channel was like, when's CJ dropping the that video? When's CJ dropping that video? And,

man, certainly, go take that course. Watch the video. It's a fantastic one. Yeah. And and also, like, my shameless plug is just the Nuxt framework. I had a really great time working with it. Like, I think if you're I I wouldn't say rewrite your app with Nuxt, but if you're looking for something new, if you wanna kinda just explore, definitely check out Nuxt because they have some really good ideas, and I do like the way you write isomorphic code. Right? So code that either runs on the server side or the client side. I'm definitely coming around to it now that I've kind of bounced back and forth between, like, Next. Js and SvelteKit. I I think Nuxt has, like, a little like, a happy middle ground there.

That's cool. Well, we're right after this, we're about to record an Node about it, and I have so many questions for you. Awesome. But that's it for today. Thank you so much for tuning in, and we will catch you in the next one. Peace.