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

In this potluck episode of Syntax, Wes and CJ answer your questions about OpenAI’s $3B Windsurf acquisition, the evolving role of UI in an AI-driven world, why good design still matters, React vs. Svelte, and more! Show Notes 00:00 Welcome to Syntax! Devs Night Out 02:35 OpenAI acquires Windsurf for $3B Windsurf Ep 870: Windsurf forked VS Code to compete with Cursor. Talking the future of AI + Coding 05:20 What is the future of UI now that AI is such a heavy hitter? 08:45 Handling spam submissions on websites Cloudflare Turnstile 14:18 Duplicating HTML for desktop and mobile websites? 17:03 Is it okay to use a JSON file for simple website data? 19:04 How to handle anonymous and duplicate users Better-Auth 21:55 Working with TypeScript Object.keys() and “any” vs “@ts-ignore” 25:51 Brought to you by Sentry.io 26:38 What is the difference between React and Svelte? 30:24 How should you name your readme file? 31:55 How do you find time to refactor code? 35:20 Best practices for testing responsiveness Polypane 39:19 Avoiding layout shift with progressive enhancement 46:56 Sick Picks + Shameless Plugs Sick Picks CJ: Portable Chainsaw Wes: White Lotus Shameless Plugs CJ: Nuxt Wes: Full Stack App Build | Travel Log w/ Nuxt, Vue, Better Auth, Drizzle, Tailwind, DaisyUI, MapLibre Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax. First thing, Denver. We're having a meetup, May 29th 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 Dev's Night Out. Go to syntax.fam forward slash 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 Windsurf being acquired for $3 billion. Does UI matter anymore in the age of UI? Some talking about TypeScript keys and using ascents. CJ's got a really nifty trick for you.

• 0:45Wes Bos?

  A 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 off in Barcelona. So we got CJ coming in. How you doing CJ?

• 1:09Speaker 01

  Doing good. I'm excited to answer some questions. I did a little rearranging. There's more stuff visible in the background now. You can't hear it. You can't see it if you're listening to this, but watch on YouTube. You can see my, all my stuff behind me.

• 1:21Wes Bos?

  Yeah, CJ's got some, some grade A tchotchkes. You got a PHP elephant?

• 1:26Speaker 01

  Yeah, I got this at a Luricon last year. Yeah.

• 1:32Wes Bos?

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

• 1:36Speaker 01

  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.

• 1:47Wes Bos?

  It's ele, e-l-e-p-h-p-a-n-t.me. Elephant or elephant.me. And apparently there's like 78 unique. There's a century one. I thought about just doing like, I did a quick mockup of a hilarious JavaScript one that was like a deformed elephant.

• 2:08Speaker 01

  Yeah.

• 2:11Wes Bos?

  Oh, I think that would be great. So let's, let's get on into it. We got a poll 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 an upcoming episode. You can ask us about anything, coding, love, life. CJ could teach you how to kickflip if you want, if anything goes. First of all, this is not a question, but I thought, let's talk about it. It just happened, oh, a couple hours ago or 12 hours ago. Windsurf was acquired by OpenAI for $3 billion?

• 2:47Speaker 01

  Yeah.

• 2:48Wes Bos?

  Unbelievable.

• 2:51Speaker 01

  Insane.

• 2:52Wes Bos?

  Yeah. It's, a lot of people are kind of freaking out right now, being like, oh, it's a, it's a VS Code fork for $3 billion? And they've been working on their, their tech for a long time. Windsurf was a VS Code plugin for many years called Codium. And I don't think that OpenAI necessarily cares about a VS 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 is just simply taking the diffs back from the AI and accurately putting it on. So kind of an interesting move, eh?

• 3:28Speaker 01

  Definitely. I, I think, 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 is 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 had 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.

• 4:01Wes Bos?

  If you want to listen to that one, it's syntax dot FM four slash eight 70. We had the now probably very rich founder of of windsurf on Varun Mohan with with Kevin Howe as well. And they're really good guys, so I'm happy for them. It's still a hell of a lot of money. I know they had like like a quarter billion dollars in funding alone. So it's that's it's a big business, man.

• 4:29Speaker 01

  Yeah, I think to talk about the like, why they would get acquired to 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 sonnet 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 dog food it versus just letting people use the regular OpenAI API. So I expect that some special model is probably coming to.

• 5:04Wes Bos?

  Totally. Yeah, you're right. They windsurf probably has a ton of data on acceptance rates and what people want and all of our code. Unfortunately, they say they don't. They say they don't. So that's a joke, by the way.

• 5:19Speaker 01

  Yeah.

• 5:20Wes Bos?

  Let's get into the first question we have here. This is also about AI from Lanny J Dingquist. What do you think the future of UI is now that AI is such a heavy hitter? Will design matter? Are 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 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 UIs get

• 5:54Wes Bos?

  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 valuable thing. As 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.

• 6:36Speaker 01

  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 3D print everything if we wanted to, but it's about the craft. It's about like the, the hands-on that really creates 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 10 years down the line. And that, that actually does bring up an interesting question because we've seen it in some of the products that introduce 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 on the side,

• 7:20Speaker 01

  where you don't necessarily have to know what all the menu items are anymore. You can just say, 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 want to do this thing and then it figures it out. And that's also where some of the MCP comes into play, like model 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.

• 7:57Wes Bos?

  Yeah, I very much like that. And even if you do need a UI, can the UI be adaptive 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, because in that case, it's all checkboxes and buttons all the way down.

• 8:21Speaker 01

  Yeah.

• 8:21Wes Bos?

  But we'll see.

• 8:23Speaker 01

  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 reality and like, there's the feed and we're just speaking or thinking what we want to do. 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. All right. This next one is from Jason Sauer, who says, hi, Scott and Wes and CJ.

• 8:51Wes Bos?

  And CJ.

• 8:51Speaker 01

  Yeah. Longtime 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. P.S. Scott, my daughter Sydney worked for you at Level Up 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 Scott. Yeah. Yeah, I guess there's a lot of things you can do. I guess I haven't necessarily run into issues with like ad blockers in terms of recaptcha. I think a lot of those have the right whitelisting in order to make sure that the captcha still

• 9:36Speaker 01

  come through. But I think beyond captchas, there's some other stuff you can do on the backend, 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 span your, spam your backend. So yeah, rate limiting, that's one thing that comes to mind. What do you think, Wes?

• 9:56Wes Bos?

  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 something in there. Because like, we used to have honeypots, which would be a decent option. You could hide like an input or ask it a simple question, like, what is two plus two? But like, AI can solve all of that, plus a lot of these captchas. Which is really frustrating to do. So I think you've just have to, you gotta put a captcha in there. And even in the case of that, these captures are just trying to keep up with, with the bots and them trying to figure it out.

• 10:36Wes Bos?

  Or simply just like, people have 20,000 people overseas that are simply inputting captures all day and solving them for the, these bots. 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 does that as well. You'll notice that if you're on like a VPN, you'll get a lot more captures. 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.

• 11:20Wes Bos?

  They know that, just like different things that like they use to detect if you're a human. They don't say what those are, but I would imagine it's, it even goes down to just simple little mouse movements. You know, if your mouse movement is on a busy 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. Cloudflare Turnstile 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 have to whitelist every website you want them to go to.

• 12:05Wes Bos?

  And if you want to sign in to any application, almost always in the app, they open up like an 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 into all these apps. And I was like, what is going on? I can't sign into 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 whitelist on my kids' 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.

• 12:50Wes Bos?

  To use anything that uses recaptcha because it's such a big part of the web.

• 12:54Speaker 01

  I wonder if, maybe you've used a tool like this, but like, what if you handle it on the other side? So like, 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 we could build something with AI that does that, or is there a service that does that?

• 13:11Wes Bos?

  Yeah, probably, but it's, you always come down to the like,

• 13:17Wes Bos?

  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 run a ping to OpenAI. I say, does this look like someone who's trying to sell me something? 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 inbox. And it's because the AI is really good at, at sounding human, right? There's, there's the old like, watch for spelling mistakes in an 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.

• 14:02Wes Bos?

  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 going to ruin the, the internet as we know it right now.

• 14:17Speaker 01

  Definitely.

• 14:18Wes Bos?

  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, use a 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 of things you can do here. First of all, nothing wrong with duplicating HTML.

• 15:04Wes Bos?

  I think we spent too far. Especially with navigations, we've tried too hard to like have the same markup for a nav and like the totally different experience on the two. So that's one thing. And second of all, most users are not actually resizing their windows. So if you simply want to just bind on load because it looks like a mobile browser and not have to worry about window resizes, I think that's also a find as well. The third thing is window-match media. So essentially, the same way that you're using media queries to style everything differently, you can simply just run a window-match media media query in your JavaScript

• 15:47Wes Bos?

  before you go ahead and do all of that binding. So that's an option as well. And the last thing I'll say here is that so much of carousel, I know 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 if that's the case, then it's just a CSS all the way down.

• 16:15Speaker 01

  Definitely. 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.

• 16:24Wes Bos?

  Oh, it drives me nuts.

• 16:26Speaker 01

  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 a huge believer like conditionally show these things or just like 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 it isn't a carousel anymore? It sounds doable with modern CSS.

• 16:54Wes Bos?

  Easy, yeah. Well, maybe not easy, but maybe for the next code challenge, we can build that because that's definitely, definitely doable.

• 17:03Speaker 01

  All right. 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 can think of two different scenarios here. If it's just a read-only JSON file, I say great. Like, 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 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 think that's a great way to start. Where this breaks down is if your backend routes are like writing to that file.

• 17:47Speaker 01

  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 server that allows your backend 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, or 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.

• 18:11Wes Bos?

  And if you deploy that thing again, then your changes are gone, right?

• 18:15Speaker 01

  Exactly, yeah. So if it's read-only, absolutely. I think a great way to prototype, great way to like not even have to build out a backend. But if you are writing, you probably want to look into a database.

• 18:25Wes Bos?

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

• 18:42Speaker 01

  Yeah.

• 18:43Wes Bos?

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

• 19:03Speaker 01

  Definitely.

• 19:04Wes Bos?

  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 this 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 pain even for mine with people who have multiple email addresses, and they buy it with one email address, and they have a different account and whatnot. And that's exacerbated when you have...

• 19:44Wes Bos?

  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 bit of a, a bit of a problem. But that can be solved by simply just sending a token to the email or 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

• 20:28Wes Bos?

  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. Or like you, you like, I swear I bought this thing, or I swear I, I entered this account and like, oh, I use 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 an annoying thing.

• 20:59Speaker 01

  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 does the person who's having you build this site want the user 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 Betteroff. I've been working with Betteroff 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.

• 21:41Wes Bos?

  Yeah, that's the same thing with like carts as well, right? Almost always it happens. 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.

• 21:56Speaker 01

  All 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 worse, using any or at ts ignore?"

• 22:18Speaker 01

  Okay, so for your first question, why doesn't object dot keys get recognized as keys are of 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 going to 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 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.

• 23:04Wes Bos?

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

• 23:22Speaker 01

  Yeah, you get really good type completion that way.

• 23:24Wes Bos?

  Yeah, 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 throw it in.

• 23:35Speaker 01

  Definitely.

• 23:36Wes Bos?

  But the other question, what is worse, using any or TS ignore? What do you think?

• 23:42Speaker 01

  I think they're both. Both of these are an indication to the TypeScript compiler that I don't want to worry about this, or I'm going to worry about this later. I probably would say any, because whenever I see myself reaching for any, it's because I don't want to take the time to figure out what this type is or define the type. If I'm using TS ignore, I am explicitly saying, hey, TypeScript compiler, I know better than you, or I'm going to fix this later. But 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 it. But yeah, any to me is, I'm just, I don't want to take the time to define this type.

• 24:18Wes Bos?

  I agree. And any should not be a escape hatch.

• 24:23Speaker 01

  Yeah.

• 24:24Wes Bos?

  Any exists because there are some use cases in TypeScript where you literally want to accept anything. You know, 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 wrapping a function. So you can still, of course, infer all of that. But in that case, you 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 like moving over a codebase, it's fine to throw an any in there. That's what I'll often do, and then I'll go back and do a search for it. But in many cases, if you do not know what something will be, you should probably be using an unknown,

• 25:09Wes Bos?

  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 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 concatenate it. With anything, you just, anything goes. So that's a good question. I've never, never thought about that. 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.

• 25:51Speaker 01

  Right.

• 25:52Wes Bos?

  Let's talk about Sentry 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, my Sentry started getting lit up with, with issues. It was really fun. I just, I turned it on for, for maybe like 20 minutes. And then I, I put all the traffic back to my, my existing one. 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 is my favorite thing. You mark it 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.

• 26:31Wes Bos?

  Sentry.io forward slash syntax and use the coupon code tasty 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 have, 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, 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.

• 27:17Wes Bos?

  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 see this all the time and it doesn't make you seem smarter. It makes you seem like a jerk. But a lot of people who are coming to this 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 there's a lot of weirdness in React, but I understand how it works and I know how to, how to build kickass apps with React and it's not really

• 28:02Wes Bos?

  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 understand why that is the case. What do you think?

• 28:20Speaker 01

  Definitely. And 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 kind of 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 want to know that something is better or that they should go learn something else. But personally, 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 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.

• 29:02Speaker 01

  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 also past experience.

• 29:26Wes Bos?

  Yeah. And the like problems that React have are not worth people moving a 10-year-old code base 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 going to 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 a reality. It's an imperfect. Major player.

• 29:59Speaker 01

  Yeah. And I would say like, that's basically been a part, 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 uh, yeah, what you're familiar with. Next one's from bike shitter 9000 and they're asking, how should you name your Readme file? Should you do all lowercase readme.md? Or readme, is it Pascal case with a capital R? So capital R, E A D, capital M.

• 30:42Wes Bos?

  Upper camel case, I always call it. Yeah, I think Pascal case as well.

• 30:45Speaker 01

  So Pascal case dot M D or all caps readme dot lowercase M D. What do you, what do you prefer?

• 30:54Wes Bos?

  If you're doing Pascal case, you're a psycho. Don't do that. I always do it as lowercase. Uppercase is like constants to me.

• 31:05Speaker 01

  Yeah, I do mine uppercase, but I think it's just a convention. I think I learned from like GitHub or something. One of the tools defaulted to all caps readme and then now I just do that all the time. So most of my, most of my top level markdown files are screaming case where it's all capital letters.

• 31:21Wes Bos?

  I've never really thought about that, but like tools that have to like a 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 going to hit some weird edge case someday and that's going to be a, a pain all the way down. But like, there's no other config files that we do uppercase, is there? Like uh, maybe contributing.md, you see that quite a bit, but like, it's not like, like package JSON or uh, lock files are, are in uppercase.

• 31:53Speaker 01

  And I think it's a markdown thing.

• 31:55Wes Bos?

  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. How do you, especially like when you have to convince management like, hey, how about I spend three weeks making the codebase do exactly the same thing, but probably bugs will be introduced, you know? Like, we're probably gonna take a step back in here. And that's a hard sell when people don't necessarily understand technical debt.

• 32:36Wes Bos?

  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 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 building any new features, just let it be. Let that sucker ride.

• 33:20Wes Bos?

  But anytime it's like, wow, I'm gonna now 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 do it much better.

• 33:33Speaker 01

  Definitely. And 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 is 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 is 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, 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 give you the time to work on it.

• 34:17Wes Bos?

  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 nice, not a whole bunch of technical debt, were able to add those features on much quicker. Whereas you look like, like, I always bag on fresh books 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.

• 35:01Wes Bos?

  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.

• 35:17Speaker 01

  Yeah, good luck with that. I hope you can find the time to refactor. All right, this next one comes from Jakey Pants, 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 emulation, or is manual resizing still normal? I'm on a large monitor 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, OK, does it? Does it actually activate at that breakpoint? How does it look?

• 35:56Wes Bos?

  Yeah.

• 35:57Speaker 01

  But like you're saying, device emulation is great because you can dial in that device width exactly. You can say, show me a screen when it's 960 pixels. And now you can really debug that that breakpoint 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 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 you, S?

• 36:22Wes Bos?

  Yeah, I I kind of have levels of it. Something quick, I'll just resize the window. 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? Are you you you take them out or what?

• 36:38Speaker 01

  On the bottom.

• 36:39Wes Bos?

  On the bottom. Yeah, because like the the dev dev 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 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 gotta 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

• 37:24Wes Bos?

  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.

• 38:03Speaker 01

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

• 38:13Wes Bos?

  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 inputs, you're syncing clicks across multiple versions of that browser. Killen, who is the developer of this, he's like absolute genius and

• 38:44Wes Bos?

  I highly recommend paying for this because it's very good, or at least doing the trial.

• 38:49Speaker 01

  I'll try. Yeah, it looks super sick. I'm gonna go to try for sure.

• 38:51Wes Bos?

  Yeah, I always go for it when I'm open graph images are my like my kryptonite. Is there anything in web development where you're just like, like you find yourself having to come back to it every single day? Or every, every couple of months, like, I hate doing this. And for me, it's, it's debugging open graph images.

• 39:09Speaker 01

  I can't think of anything off the top. It's everything. Anything that I have to code again is my kryptonite.

• 39:14Wes Bos?

  All of web development.

• 39:15Speaker 01

  All of it, yeah.

• 39:18Wes Bos?

  Oh, that's good. All right. 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 want to show in the basic HTML version or on the JS enhance version. So progressive enhancement is this idea of you build the website so that it works with ideally just HTML, maybe just HTML and CSS. Like, like, and it works with regular form submits and all that. And then progressive enhancement is you add on a layer of JavaScript

• 39:57Wes Bos?

  to sort of enrich that experience. Right? So for example, consider a listing page with a filter form in the basic HTML version. A user makes a selection of the form, clicks the submit button and it, it submits the 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.

• 40:38Wes Bos?

  And I added the button to only make it for HTML. So I want to 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 the. 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 loaded, then they fetched, they pinged 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 of solutions that you have here. One of them is like, you gotta ask yourself, like, when do I want to hide that button?

• 41:23Wes Bos?

  Do I want to 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 are two different things. There could be a delay maybe between the actual loading and 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 going to be displaying this. You simply just put a script tag in there and that little piece of code will be it'll be blocking for for just a split second.

• 42:07Wes Bos?

  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 you're 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 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 run some code and you will have a little bit of layout shift.

• 42:51Wes Bos?

  And I don't know that that's necessarily the end of the world, especially if it's not pushing down the entire page, you know, something like you're pushing the navigation down.

• 43:02Speaker 01

  Yeah, so I like that initial idea that you brought up. And let me see if I understand it. So 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, which then means we can style it according to the JavaScript way. And that's the first time they see it. There's no layout shift. Is that accurate?

• 43:26Wes Bos?

  Yes, 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 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 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

• 44:09Wes Bos?

  or just right before the opening of, right inside your opening body tag, that simply just says, const isdarkmode=localstorage.getitem. 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.

• 44:34Speaker 01

  That makes sense. It almost seems like that's probably the route they should go. Honestly, though, hearing this question, I just think of like, how many of you 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 somehow, and then maybe use CSS to conditionally hide or show these things. Like if. JavaScript isn't enabled because modern CSS does have a lot of these selectors that really help with that. There's the has selectors. There's also, I've been messing around with like full HTML CSS form validations. 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

• 45:16Speaker 01

  to enable and disable the button because it's all in CSS in terms of like is an input valid or whatever else. So there's ways to do that as well, but yeah, I don't know.

• 45:25Wes Bos?

  Plus, maybe just don't hide the button.

• 45:28Speaker 01

  Exactly.

• 45:29Wes Bos?

  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 name and then you're like sitting there looking for the button and it's like, oh, it does it automatically, you know, as soon as you tab away, it saves that value. Just give me a button. I want to click it just to make sure, you know?

• 45:48Speaker 01

  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. And 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 going to submit? And then finally, when I do blur, the button pops up. Yeah, I don't like that.

• 46:06Wes Bos?

  Yeah. That also drives me nuts as well, where you try to use some UI before their JavaScript has been loaded.

• 46:13Speaker 01

  Yeah.

• 46:13Wes Bos?

  And you're like sitting there clicking the button and it doesn't do anything and it's because it is. I think that's, that's probably what he's trying to solve here. 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 load. And then if that's the case, your UI is broken. But I don't know, especially for with these single page applications, you give it a couple of seconds to load the JavaScript and then it works for your entire visit.

• 46:56Wes Bos?

  All right, 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 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.

• 47:28Speaker 01

  Nice.

• 47:29Wes Bos?

  That was a fantastic show. I don't like a lot of shows and I was surprised at how much I liked this. So it's a, it's an HBO show, so certainly check that out.

• 47:38Speaker 01

  Yeah, I haven't seen it. Um, I've seen it advertised. I watch a lot of stuff on HBO Max, so I'll have to give it a try. Uh, so my sick pick is a chainsaw. So I have, yeah, so, uh, I'll, I'll send some links to Amazon. But basically, uh, they sell portable battery powered chainsaws that use the same battery pack as the DeWalt, uh, drills. I have had-

• 48:00Wes Bos?

  Like a little handheld one?

• 48:01Speaker 01

  Exactly, yeah. And so I've had these, uh, 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.

• 48:24Wes Bos?

  Those things are amazing, hey?

• 48:27Speaker 01

  Yeah.

• 48:27Wes Bos?

  Like, you wouldn't think that this tiny, cheap little chainsaw would be very good. It's amazing.

• 48:33Speaker 01

  Definitely. And I have just a pile of, uh, fallen branches and twigs that like I'm now gradually working through. Cause 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 the size that'll fit into my compost bin. So, yeah, many chainsaws. They're awesome.

• 48:50Wes Bos?

  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.

• 49:03Speaker 01

  Oh, yeah.

• 49:03Wes Bos?

  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. Uh, and then, yeah, we got one of those little handheld ones. We also have the like loppers as well. Where you just, it like, like cuts it and cuts small branches.

• 49:33Wes Bos?

  Batteries are amazing. Battery tech is amazing. Shameless plugs, we want you to check out our YouTube channel. Go to syntax.fm, nope, youtube.com/syntaxfm? Is that it?

• 49:46Speaker 01

  Yes.

• 49:46Wes Bos?

  I always forget all the URLs for it. But check it out. CJ just dropped an absolutely mammoth of... How long was it?

• 49:54Speaker 01

  12 hours total.

• 49:56Wes Bos?

  On Nuxt?

• 49:57Speaker 01

  Nuxt, yeah. So building a full stack app from the ground up with NuxtJS. It's got a database. It's got off. It uses maps. It has multiple levels of routing. It's a massive app.

• 50:08Wes Bos?

  Man, and it's hilarious because every single comment on the YouTube channel was like, "When CJ dropping that video? When CJ dropping that video?" And man, certainly go take that course. Watch the video. It's a fantastic one.

• 50:21Speaker 01

  Yeah. And also, my shameless plug is just the Nuxt framework. I had a really great time working with it. Like, I think if you're... I wouldn't say rewrite your app with Nuxt. But if you're looking for something new, if you want to kind of 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. I've kind of bounced back and forth between like NuxtJS and SvelteKit. I think Nuxt has like a little, like a happy middle ground there.

• 50:52Wes Bos?

  That's cool. Well, we're right after this. We're about to record an episode about it. And I have so many questions for you.

• 50:58Speaker 01

  Awesome.

• 50:58Wes Bos?

  But that's it for today. Thank you so much for tuning in and we will catch you in the next one. Peace.

• 51:03Speaker 01

  Peace.